Qie Niangao

Cannot rez anything? Usually that error message is limited to a particular scripted object that's somehow confused the sim in the recent past. I just went to Ciarnau, found a parcel that allows public building, and successfully rezzed some scripted objects there, so I don't think it's a sim problem. Couple things you can try: one is to take whatever's not rezzing on Ciarnau and try it in a sandbox on another sim. Second, see if Ciarnau will let you Wear the thing, and if that works, Drop it.

RitterAlvarez wrote: You obviously are one of those who feels the inante need to put down, degrade, or insult anothers efforts.Why? because most likely you lack the ability to even attempt these yourself. This guy Maximillian is taking tattoo's to a new level and no doubt when they take off they'll be plenty of others doing the same.Good for him....Tattoo designing on SL has basically become stagnant, the same ol same ol. Nothing new , the same boring designs , smudgy tribals, Bad details with the most ridiculous colors.Someone that takes the chance, puts in the effort and ups the bar as for putting out something new should be commended for his efforts OFFS. Did I say anything bad about your buddy's mad skills tattooing virtual arms with pixel ink? No, I did not. But come on. We're not talking about rocket surgery here. It's just friggin' tattoos, the whoopee cushions of fashion.

Superior to the Bieb's ink? Perish the thought! But of course there's only one authentic Tattoo!

Be all that as it may, it's reassuring to learn that Justin Bieber tattoos are still in fashion.

TaylorMcKenna wrote: I also have notecards from the Green Lanterns, who have been working with region owners, peoeple who have places that have been griefed. Yeah, don't do that, not if you ever want things to get back to normal. It's a proven way to spur griefers to continue and escalate. Considering how much aggravation results from their involvement, one really has to wonder who's the real griefer. That, and they prey exclusively on the most vulnerable: those who've already been harrassed even to the point of accepting such "help".

Oh, I'm sure a listen consumes some server resources just being open -- at least a few bytes of memory somewhere as record of the script's interest for when an event is raised on the subject channel. I, too, would love to know more about the detailed performance effects of an open listen, along with everything else. Then we'd be equipped to make some better decisions -- although not necessarily easy rules-of-thumb. For example, the alternative to an open listen is some code (using more memory -- or maybe less? -- than that needed for a persistent open listen) that calls a timer -- where an interval timer (or, more precisely, a homegrown scheduler approximation of an interval timer) instantaneously consumes more CPU to insert and remove than does the very listener entry it may delete on expiry. So then the tradeoff involves the dynamics of demand: if the frequency of user interaction is greater than once a TBD interval, leave the listener open, else spend the extra resources for a timer (plus creating and deleting the listener again), where we don't know if "TBD" is best expressed in minutes, fortnights, or half-lives of the universe. So yeah, in lieu of some really detailed performance data about the script engine, it's a judgment call, and I'm only guessing that an open listen on an obscure channel is less like lights left on than it is like an LED night light left plugged in during the day.

Yeah, I'm not sure what's going on, but a search of the email address in the posts turns up (deleted) spam in other forums including "The Mighty Quest for Epic Loot" (apparently a Ubisoft game), nVidia's geForce support, some World of Warcraft forum ("wowhead" -- maybe a fan site?), the opera browser, and even Tesla motors. I'm not forum-savvy enough to guess whether these are all Lithium-based, in which case the vendetta might be against Lithium itself... or maybe all the forums outsource administration to the same company of which the spammer is a disgruntled ex-employee... or maybe nothing like any of this.

Well, I think the confusion is mostly caused by lack of text formatting. The script doesn't open a new llListen() in the collision_start() event handler; rather, that's a listen() event handler. And it's generally okay to just keep one listener open forever, rather than managing a fresh one each time a dialog is raised. (Yeah, it's primitive but it will work, and given an obscure enough channel, there will never be enough crosstalk for the listener to have any impact.) Besides the listen() handler simply having no code to handle the "Get All" input, as Calamari points out, the script is also using a global variable as if the avatar who last collided with the object will always be the next one responding to the dialog -- which means the script will be texting and sending stuff to the wrong person much of the time. Luckily, there's no reason for it. Just delete the gAV global variable and instead use "id", the locally-bound variable in the listen event.

There are several jira reports of the problem. One is BUG-4433 filed by Sassy Romano last November 12th, and closed as "Unactionable" by Alexa Linden on January 24th. Probably you can't see that jira because I don't think it's been opened for general view, although I believe Sassy could do that. If it's currently hidden, that doesn't indicate anything sinister, just a snafu of the ancien regime. Anyway, there certainly are Lindens who know of the problem. [ETA: Coby Foden filed one last week that appears to be public: BUG-5741. Not closed yet.]

Uh... no, I don't think this should need to be a problem. Multiple distinct parcels with the same owner (group or individual) will each have a distinct media and audio stream. It sounds to me that these controller devices are either setup incorrectly (sharing the same channel or something silly), or they're the wrong tool for the job.

I know nothing about this device, but on that podcast he does with Jo Yardley, Drax is forever yammering on about the Leap Motion as if it may be useful for SL. I guess you'd still need somewhere to perch the thing, but you wouldn't need to touch it, and evidently somebody is doing with it something SL-related. I guess.

bambi Littlebird wrote: [...] My objects are sometimes'lost' as well. I've never gotten some of them back, he just ignores me on this one as well.:matte-motes-frown: What did you expect him to do about this? That you apparently did expect him to do something about it puts the rest of this in a somewhat different light. He may not be the best landlord in the world, but it's just possible there are two sides to this.

I'm to the point of rooting for the spammers now. Maybe if they just keep flooding in the spam, eventually somebody will decide to do something preventative for a change. Yes, that's engaging in a constantly escalating war. As is, however, it's a war lost daily, evidently without firing a single shot.

Maybe glance at https://marketplace.secondlife.com/p/ML-CalendarCog-Kiosk/255158 although I have no idea if it's viable for what you have in mind. I like the idea, though, of basing it all from a Google calendar, so you can manipulate it in a browser, etc., assuming your avatar has a Google account. (Disclaimer: An alt used a precursor to this product, back in maybe 2007. No clue whether it still works, or was upgraded, or anything more about that ancient history.)

You could offer them three different payment amounts with llSetPayPrice(), and then deliver product according to which amount was received in the money() event. One reason pretty much nobody does such a thing is that, once folks click "Pay", the script has no way of communicating with them -- they'll just get the payment amounts, with no explanation for what they'll get for the different prices, and a script can't know they're even interacting with the payment menu until they've chosen a price and confirmed payment. So, basically, this is asking for an endless stream of customer complaints about getting the wrong product. It's also possible to engage in some a priori menu dialogue with the customer and then set a single corresponding pay price, but that's never done either because, once set, that price applies to anybody using Pay, not necessarily the one who made the product selection. The script can know it got paid by the wrong person and refund the money, but it's just far too confusing for users, and infinitely simpler to have distinct prims for the different product offerings.

Seems unlikely. I mean, you can terraform right through objects; the challenge is seeing what you're doing (perhaps by choosing not to render some types in the viewer). Maybe this is more than just the usual edge-of-parcel condition that I described. (Perhaps PM me with coordinates, if you want me to take a look? I may not know what's happening, but I'll be happy to see if it looks familiar.)

Not sure this is the problem you're experiencing, but: The terrain mesh will "ripple" some distance in both directions from a sheer cliff. The larger and steeper the cliff, the more extensive the ripples. That's based on experience with regular terraforming, as opposed to defining a new .raw terrain for the sim -- and I honestly don't know if that works any better. (In fact, I suspect not; I believe it's a limitation of the terrain mesh, not only of terraform operations on that mesh, but I'm not 100% sure.) [Edit to add: This part isn't correct: "he should be able to sink his land up to his boundary if thats how he wants it without affecting the land on parcels he does not own and has no permissions on" -- even on Mainland, parcel boundaries don't completely limit the effects of terraforming on either side of the border. The overall effect is generally limited to less than 1 meter into the neighbor's parcel, but again, those ripples can extend further.]

Perrie Juran wrote: If only there was a real way to measure a script's impact. Or maybe there is and I'm missing it. From within a script it's possible to get an accurate view of its actual memory consumption, either instantaneously or its peak usage over an interval while it's running. One can also get a pretty good estimate of the amount of processor time it's using, but that's tricky to interpret because a freshly-started script will burn a lot more CPU than the same script will after it has run for a while. (Maybe there are also artefacts of measurement, I'm not sure, but scripts just arrived in a sim really do lag the heck out of all the other scripts in the sim, so the effect is real, too.) As has been discussed elsewhere at great length, most scripts usually lag only other scripts, not viewers and not the sim. There are exceptions. For example, back when everybody was focused on script memory, the concern was that scripts could use so much memory that all processes on the host machine would compete for finite real memory, causing the machine to page to disk, thus dramatically slowing all the sims sharing that host. I think only Lab folks ever knew how common this ever was, what if anything was done to prevent it, or if it still happens today. (I've seen claims that there is now much more physical memory per sim than there used to be, but that is usually cited by folks trying to claim that we should never bother our pretty little heads about too many scripts.)

Phil Deakins wrote: There's a faint bell in my head that's telling me that, even though a script limits the amount of memory for itself, and will only use up to that set limit, 64k is neverthless set aside for it. And if that bell is real, it's you who put it there in a thread some years ago Nope, the idea that memory is "set aside" when a limit is set is not my doing. For years now I've been trying to disabuse folks of that unfortunate misunderstanding. It all started because of the "allocated" wording that I think originated with Kelly, but he soon clarified that it wasn't "allocated" in the conventional sense of "malloc" or the like. Rather, it's the script setting a kind of "quota" for itself (to those who remember the early days of timesharing). Being too close to it, I never considered that laymen could be confused between llGetUsedMemory of the script itself and OBJECT_SCRIPT_MEMORY of llGetObjectDetails of another object; it may not be obvious why only the former can afford to be accurate. It's fine if a script wants to stop what it's doing and go off measuring its memory consumption, but quite a different thing if any ol' self-appointed measuring device can impose the same delay on every other script it encounters. The way scripts execute, it's a very expensive operation to update memory usage constantly, as is painfully evident when using llScriptProfiler.

Pussycat Catnap wrote: Note how the meter is NOT a division of 16 (though About Land is). The meter may be doing something painfully pedantic about how a million bytes isn't a megabyte. Maybe. Otherwise it's just buggy, because About Land has the best data available, and I've never seen it deviate (for long) from what's obtained using the available LSL functions. A little history here. The LSL script memory functions were intended to do something useful because the script-set memory limit was to determine whether the script "fit" on script-limited parcels and avatars. Then there was great fussing about how LL shouldn't limit creativity by cheaping-out on memory (kind of missing the point that unlimited memory use will end up using infinite memory). That, combined with the messiness of actually implementing the limits on the grid ended up postponing them indefinitely... well, permanently, as far as we know. So the result of that was that these weird functions set and report what amount to artificial memory limits. They don't actually reduce the script's memory use (except in the disastrous case where they're set too low and the script crashes). They're really more an historical curiousity than anything of value -- and, in fact, just counting scripts is as good an indicator of actual memory use as totalling up the numbers reported by these functions. Maybe better, inasmuch as that doesn't suggest such false precision. (I'd feel moderately guilty about following this tangent while the OP chided us for not solving her friend's problem, but I'm still betting that 99% of it will end up being exactly what Pussycat suggested earlier: missed permissions dialogs.)

For businesses starting out, though, they simply won't clear enough revenue from their in-world parcel to cover tier (or rent, or however the monthly land fees are getting passed down the food chain). Same for businesses that are fading, or those too long-tail to expect buyers on any regular basis. That's in contrast to mass-market stuff (those that do enough sales that you would call them a business, apparently). For those, yeah, they'd do well to urge folks who read their Marketplace ads to venture in-world to see the demo or whatever, in hopes of steering purchases there rather than incur the Marketplace commission. For a business to decide to open an in-world presence solely on the basis of saved Marketplace commissions -- thus assuming that every in-world sale would have been a (commission-paying) Marketplace sale -- that takes a lot of in-world sales, because then one can't start claiming benefit when sales exceed land costs, but rather when sales are more than twenty times costs. Anyway, much of the stress on Land is a direct result of the Marketplace commission being way, way too low. If they're not going to charge an up-front nor recurring listing fee (independent of sales), then they really should have followed Apple's 30% app store model. I suppose that wasn't an option back before Marketplace when there were competing private outlets: they'd have undercut each other. And if LL tried to do it later, merchants would have squealed like stuck pigs.

Oh, yeah, that refreshed my memory: some of the "newbie-friendliness" of poseballs is said to be about choosing pink or blue and getting it right on the first try without having to fuss with menus nor play que es mas macho with the sofa parts. Although nPose use seems to be growing, I can't say for sure that it's the one Pussycat is seeing. There are several no-poseball engines now that do much the same things, including at least a couple of commercial ones (AVsitter seems popular), and all of these -- as well as MLPV2 -- have seen a lot of changes in the past few years, so the lead shifts back and forth, and older creations using any of them may be pretty behind the curve. As far as memory consumption goes, it's pretty difficult to beat nPose's approach for large numbers of animations, because it only loads pose-specific notecard data as needed instead of storing monstrous lists of the stuff the whole time. That said, Lear went to some trouble to slim MLPV2's memory use as well as the amount it reports using when LSL got the relevant functions.

Pussycat Catnap wrote: If its furniture you're shopping for - shop elsewhere. There really shouldn't be any furniture for sale left that uses poseballs. Its been obsolete for years. If you see it its a sign the item is just going to be buggy or laggy or otherwise poorly scripted as its coming from someone who is no keeping up to date with changes in SL, and changes in what code works... Personally, I vastly prefer no-poseball furniture, too -- the npose engine in particular, for items I'm not scripting from scratch -- but I don't think it's accurate to say all poseball furniture is obsolete. Many creators still prefer the MLPV2 engine specifically because it uses separate poseballs. After this thread, however, the oft-cited reason to prefer poseballs, supposed newbie-friendliness, seems specious. (I wouldn't wish xpose on my worst enemy, but I gather some folks still use it, and AFAIK it uses poseballs, too.)

Nothing to do with SL, but Christo Graham's Muppet Christ Superstar is worth a seasonal listen. Prove to me that you're no fool Hop across my swimming pool __________ HT : NPR monkeysee's Pop Culture Happy Hour

It really sounds to me as if most of this is caused by not noticing the dialog that pops up when remote-poseball scripts ask for permission to animate the avatar. As Pussycat mentioned, that dialog can get buried in a "99+" chiclet at the upper right corner of the screen, but it's also easy to just miss the dialog until something else pops up and it disappears. If the script hasn't gotten the sitter response to that permissions dialog, it will leave the avatar in the default sit, and the menu it gives -- if any -- in response to touching the furniture may be different from what other sitters (or non-sitters) see. I don't know that there's any way to make the viewer's behaviour any more intuitive without switching viewers altogether, and that would be asking for more and different trouble. Perhaps it will help just knowing to expect that dialog and to expect to need to trigger it again if things aren't working and he doesn't remember seeing that permissions dialog. (Note that furniture without poseballs generally won't need that permissions dialog; that's because someone sitting directly on the furniture grants that permission without needing to be explicitly asked. Really old or primitive furniture may have poseballs linked directly to the furniture, and those don't show the dialog either.) There may be other problems, too, but I'll bet the permissions dialog causes most of the trouble he's having. [ETA: I meant to suggest that you watch Develop / Avatar / Animation Info while he's having trouble, to detect any "ghost animations" or other weirdness different from what you see with your own avatar -- all with AO removed, of course. I very much doubt this is related to his problem, however, so this would only help confirm that it's not.]