Qie Niangao

Commerce Linden is the recipient of payments to Marketplace merchants, but I believe that's also the account that gets payments by Marketplace merchants for things like enhanced listings. Once arranged, those would be recurring payments. Search doesn't find the OP as a merchant (but: alts, so who knows?). In any case, I would think the Description field of the Transaction History would shed some light. (I doubt it has anything to do with the L$299 purchase.)

It seems some of these "snippets" could be pretty complicated, such as the conversation between an NPC and a player. I don't think they're going to all fit neatly into one script with branching, no matter how you do the branching. So if you're going to need multiple scripts anyway, I'm not sure grouping a few snippets per script is a big win over having a separate script per snippet. So if you do have one script per snippet, because there could be multiple players on the sim at the same time, it seems pretty clear that it's better to put the scripts in something permanently rezzed on the sim, rather than in player HUDs, as long as the snippets aren't trying to do anything that needs the kind of permissions one gets for free by virtue of being attached. (Or, even if they do, perhaps the attached HUD could just perform those particular functions in response to commands issued by the snippet scripts running out in the sim.) The thing is, the scripts don't necessarily need to be in those task objects; they could all be in one "server" that has a controller script with a single listener that dispatches link messages to the snippet scripts (so they don't each need individual listeners). In fact, it may be worth keeping those snippet scripts asleep when not in use; see llSetScriptState() for how that controller could activate them individually as needed. (Note that this is all based on wild guesses about this particular application. A different set of wild guesses might recommend writing your own "language" for these snippets for your LSL script to interpret and execute, where you control which snippet you run according to how you index into a table list or notecard -- but that would only make sense if the snippets can be expressed in just a few primitive operations.)

Min Barzane wrote: I am not any different from movie company,or game company! My intelectual property is MYNE! You steal from me ,you get cought,you pay for damage done! End of story! If it's so valuable then don't leave it out in places where it can get stolen, like Second Life. Hire goons like the MPAA does to pay-off ISPs and legislators, if you like that model so much. Or face the facts: your precious stuff is just not worth that level of effort and expense. Instead, there's the DMCA. LL took measures to improve DMCA effectiveness, notably the requirement for RL identity to upload Mesh (and then made the "model = instance" mistake, to reduce the bookkeeping necessary to track guilt). And I'm serious about OnLive and SLGo: It's not practical as a complete replacement of all SL viewers right now, but a relatively modest shift in economics could change that. Then there's nothing delivered to the user's machine that could be ripped (not from SL, that is; games still using client-side rendering would still be easy prey, as evidenced by all the blatant game rips on sites like TurboSquid). Incidentally, for those watching Rosedale's High Fidelity, that architecture depends on a similar shift in network economics as does OnLive, but for the opposite purpose: to distribute processing among participants rather than to centralize rendering. Philip got his start at Real Networks, and even SL shows he's apt to bet on bandwidth too cheap to meter.

On SunKissed right now I get "Unable to create item that has caused problems on this region" no matter what I try to rez from Inventory. You're right, it lets one build, but won't let me wear anything from inventory, although it will allow me to wear prims built on site, and drop objects that are worn. I think this one will behave better after a restart.

Min Barzane wrote: Prims are mesh! Avatars are mesh! From day 1 od SL! Cube is always a cube,no mater how much you strch,twist and retexture it!ITS A CUBE! You missed the point btw! You have no idea what I'm talking about, do you? On the off chance you take the time to figure it out, the castration of SL's Mesh representation isn't the first time the Lindens have reduced SL functionality in a misguided attempt to placate IP-paranoid creators. For example, watch what happens to the contents when you paint a no-transfer texture on the face of any object. That's how the no-transfer permission on the texture is viral to the object. Now ponder the real effect of that design decision: there is no practical market for textures except full-perm, and no practical way to sell full-perm textures without an End User License Agreement. The point? Be careful what you wish for, lest the result even further diminish the world. And just in passing: There is a way to defeat copybotting, and that's by dumping the viewer altogether and doing all rendering server-side, like OnLive's SLGo. Not very practical, and once end-users rented the rendering service and the bandwidth there'd be little left to pay for user-generated content. but that content would be ever so safe.

Min Barzane wrote: Question was and still is "WILL LL EVER DO ANYTHNG TO STOP COPYBOTERS/CONTENT THEFT? WHAT DO YOU THINK? " They already did: they crippled Mesh. Unlike every other object type, Mesh has no layer of abstraction between the model and the instance. The result is that every other object type can be changed into any other object type without losing the identity of the object. With Mesh, you're stuck: it is always Mesh; even worse, it must remain always the same model. This was done to placate creators crazy about protecting their precious intellectual property. The result is the increasingly static, "behold the pretty pixels" Second Life. Happy now?

Madelaine McMasters wrote: Science (nature) may be cooler because it's not limited by our imaginations. Science and nature are two very different things. Science certainly is limited by our imaginations. Sure, sometimes nature is unexpected, but ultimately we only look for it under the streetlamp where the lighting is better. (One might say that nature is limited by god's imagination -- which would say more about god than nature.)

Medhue Simoni wrote: Well, the creator of a mesh avatar could make textures with alpha'd parts of it, to hide things also. We can also rig their avatars to the collision bones and be able to use all of the body sliders, [...] Testing my understanding of the situation: It's specifically the body sliders that control collision bones, right? And not the face sliders? Which maybe constrain the facial morphs? Although come to think of it, I bet the head can be controlled a lot more than on these new defaults. This must be written down somewhere, not merely embedded in the system avatar model. God I hate all this stuff now.

Brises Ravenheart wrote: On a related point, If two people have the premium 512 land tier, and want to deed both to a group to create 1024, is there still no land tier fee, since they are combining two premiums? Yes, that's correct. In fact, as you may have already discovered, there's also a 10% bonus for group land, so in fact this two-account group could own up to 1120 sq.m. of Mainland tier-free.

PeterAims wrote: I really appreciate the help, its really great, but some suggestions here can get pretty technical for a person just starting to do this. Isn't llSay or llShout with llGetOwner enough for a simple functioning HUD? I recently just read a little about llRegionSayto, and please excuse my ignorance but wouldn't llRegionSayto also control multiple objects if there duplicated next to eachother? That is what I'm hoping for, controlling an object only when I'm close to it. I might not understand alot but llSay or llShout with llGetOwer seems like it should be enough. The llRegionSayTo function would only control whichever object you explictly tell it to talk to. No other object gets to hear. The trick is knowing which specific object you want to talk to, and that may be easy or hard, depending on how these objects come into existence. Anyway, I don't really think that's going to help you much. What might help was something Nova mentioned in passing: the ability to use an owner-specific channel, thus filtering messages automatically without your having to match owner with sender for a lot of unmatching messages. Now, in practice, this probably isn't a big deal either: doesn't seem likely there'd be that many of these objects with different owners, in overlapping areas. You have to handle the possibility but you don't need to be optimally efficient about it.

Phil Deakins wrote: What is the reason why LL introduced a range of mesh avatars? What are they aiming at with them? Are they looking to a future where only mesh avatars exist in SL, and the originals will eventually disappear from the Library? I do not think they plan to remove the ability to use the old system avatars and replace them completely with attached Mesh. I think, frankly, they (and a bunch of creators) have been sold a bill of goods, that folks really, really want Mesh avatars, and so if they offer them at startup, maybe it will help fix retention, making SL look more up-to-date and on a par with video games. If that's the intent, they really needed better ones. The "bill of goods" thing is that attached Mesh is just not good enough. I mean, it's great for "replacement parts" (like feet), but full-body avatars? No facial expressions? No real customization of a bunch of slider features that aren't linked to "fitted" Mesh? Hand positions through insanely laggy alpha kludging, unlinked to existing animations? No practical means of mixing and matching surface textures and alphas? These new avatars unintentionally demonstrate that there's no point wasting time on this intermediate stage, and it's "Avatar 2.0" or nothing. (But I'm still fine with the zombie. I mean, my alt is. I mean, on the rare occasions that alt is in-world, he can be a zombie. Until now, he was a plywood box, so zombie is a big step up. And, incidentally, a plywood box turns out to be a really confusing avatar for an alt who often needs to rez large numbers of plywood boxes.)

The requirement to allow privacy walls would be an absolute show-stopper for anywhere nice.

Yay for Experience Permissions! ... Experience Keys! ... Experience Tools! (You know: the project in the Witness Protection Program.)

Yeah, too bad: no surprises there. Just in passing, one also gets that same message when a group-owned script returns objects, but those LSL functions aren't supposed to return objects deeded to the group, nor those owned by group owners (and maybe officers, not sure which Ability on which it actually depends), and I've not seen that fail, as I said above. I have to say that this sure sounds more like pilot error than an actual griefer thing. Something silly like accidentally having a bunch of stuff selected using "Hide Selected" in order to find the object intended to be returned... or some analogous mix-up using the About Land object return. (Actually, do we know whether the intentional return was a "right-click and return" on the object itself, or done from About Land?)

I also checked the notice when the items were returned and it stated the items had been returned by 'Natural Wilderness Lovers ie the group the land is deeded to. What else did it say, as to the reason the landowning group returned the items? It may have said "... due to parcel auto return", or "... due to parcel owner return", or "... because the parcel is full", or maybe some other reason. I suppose the "owner return" is most likely, and least informative, but the others could be very informative. (For example, there was at one time a bug that triggered "parcel is full", nothing to do with griefing.)

The land doesn't allow others to terraform, right? I'd just mention that there are some new-ish LSL functions that do return objects owned by others (specifically llReturnObjectsByID and -ByOwner). It's theoretically possible that these may have some obscure bug, but nothing I've encountered in my limited use of these functions. If anything, I've sometimes found it challenging to figure out why they refuse to return certain objects. The point being, as far as I know, they'll never return objects owned by the landowner, nor by owners of a landowning group.

See the wiki entry for llInstantMessage to learn about the throttle. It's per owner per region, so it would have to be your own objects throttling your messages. Also, it's a pretty big number, so it's usually only triggered by things that send out messages to whole lists of customers or group members or whatever. Unless you're doing something like that, you might first want to be sure you didn't accidentally mute the object.

Note that it's the shape that was supposed to be mod, not the mesh itself. That's easier for users than replacing the supplied no-mod shape, so that's an improvement (I think). Had the mesh been mod, there'd be that whole new industry of "skins 'n' stuff" for these avatars. That would have been okay, too (and what I'd originally expected, somehow) but I'm not sure these models are really good enough to be worth the effort. I mean, the skins certainly could be much improved, but consider those feet: no skin can cover up that mess.

Hoshi Kenin wrote: Poitical correctness has formed it's own poison within society, in general, not just SL. Some recent RL "child porn" paranoia at Instagram raises a pretty high bar for kneejerk reactions. Don't you think the OP feeling "uncomfortable" is perfectly rational, surrounded by hysterics seeking witches to burn?

Assuming you're looking at the object I think you're describing, it's actually in the Wards sim, and if you brave the dopey security system, you may see the creator and owner. But I wonder if maybe you're using a different non-Linden viewer that's sort of "trying too hard" to get details about those. Both the creator ("Gene Replacement" -- a common creator of old-school megaprims) and owner ("Meeka Sihtu") show as "This name is unavailable" in their profiles, although of course they're fully available using other viewers. That part is often a side-effect of inherited default hyper-restrictive "privacy" settings -- but doesn't prevent the names from being populated at least in normal viewers.

Pussycat Catnap wrote: I believe the service is only $9.95/month - quite reasonable. That's my understanding, too, and if it produces satisfactory results (as I understand it does), then that price is fairly reasonable compared to the depreciation on a decent graphics card that will be pretty much obsolete in three years. I think that's a viable market for the service, in fact, for those who have no other desktop with good graphics. Those who do have high-performance desktop graphics, however, might want to use Splashtop to remote SL to their (local) tablet. And yeah, for remote, Lumiya seems closer to practical under bandwidth constraints such as those faced by those of us in Canada, the corrupt backwaters of broadband.

I do remember that thread and all the fun you and others had, spreading the brokenness. If we found a new way to break Mainland now, I wonder if anybody could be bothered to fix it.

Personally, I'd prefer if they simply made all those settings be script-controllable. Then the estate owner could revert a setting by an individual parcel renter, warn them by IM or whatever, and make it a general covenant-enforcement matter, however the estate wanted to handle it. The thinking is that having scripts able to set these things could be very useful anyway, even for parcel owners, even on Mainland. For example, I could imagine wanting to turn on access lists occasionally while I'm actually on the parcel, and have it revert to open access when I leave... but there's no sure way of doing that unless scripts can control that parcel setting. And it's just laziness that the setting isn't script-controllable, inasmuch as the named banlist is.

You may have better luck if you make sure your avatar is in the same region as the object for which you're trying to get information.

I think the highest point in SL is on the Heterocera Atoll.