Qie Niangao

Kenbro Utu wrote: Kelli May wrote: Rez a prim, size to 30m cube, hollow to maximum. Copy and rotate 90 degrees on the y-axis. Congrats, you have the most basic room available. TWO PRIMS!. Now convert to convex hull -- ONE PRIM! Naughty! (The convex hull of a hollow cube is a not-hollow cube. So I suppose it's still in the running for "the most simple 'skybox'" because it's one that can never be cluttered with avatars inside.) [ETA: I actually meant to add something potentially useful: For some meaning of "most simple", a single 8-faced mesh model would beat anything you could do with prims here. Not sure if it would have a Land Impact of 1 at scale, but it would be simpler to render, at least.]

I think there's a difference, though. The warning sign is apparently enough to keep the poster's account from being deleted for merely recording the text without being present during the chat -- and I agree that such remote monitoring is a kind of disclosure inasmuch as the chatter has lost control of who might see the chat (assuming the sign need not specify all parties to whom the remotely monitored chat may be disclosed, lacking any guidance about the sign's required contents). But that immunity from account termination wouldn't guarantee the poster a right to make public that chat log in a Marketplace review nor other Lab-hosted services. Could a chat log collected under a warning sign be disclosed privately in-world, as in IM, without violating ToS? I think even that is open to debate, given the wording of that KB article. The section about disclosure is pretty direct about requiring "consent", not merely "knowledge or consent" -- but then later it further constrains scripted remote monitoring or logging to require consent, too, and I'm not seeing the distinction between that and the earlier remote monitoring that was somehow kosher just for having some unspecified but "clearly visible" sign.

But isn't that a different rule, though? It seems to be about remote monitoring, not about sharing chat logs via Linden (or other) services. (In case that's not an obvious distinction, consider how they also distinguish between collecting IP addresses for the landowner's private fetish of banning suspected alts, vs making public the landowner's suspicions.)

Basic avatar eyes use the same texture on both sides. See this handy reference site for a beginning creator's discussion of all this stuff. Note, however, that more and more of the avatar is commonly being replaced by custom (especially fitted) mesh, as discussed above as a way of getting asymmetrical tattoos. Same works for eyes, and there are certainly mesh eyes, but that's a simple enough body part that there have been prim eyes for a long, long time.

There's a two month gap in posts to this thread; I don't know why it's again top of mind. In any case: 0seagypsy0 wrote: You can record a conversation if you have a sign blatantly posted in the area hte conversation takes place. Where did you get that idea? Such a sign might prevent the conversation-poster's account from being deleted -- although getting explicit consent would be much safer -- but that doesn't keep LL from deleting the posted conversation from their services. As far as I can follow the claim here, you posted some chat to your blog, and somebody else posted some possibly doctored chat to a Marketplace review. The latter was taken down. Of course the Lab isn't going to go after your blog, and of course they're going to remove a chat log from their Marketplace site -- whether or not it's a true record, and whether or not it was collected under some warning sign. Thing is, you got this part exactly right: 0seagypsy0 wrote: they can, that's true, but they would lose revenue if htey did that. ... but you didn't take the conclusion quite far enough. The Lab really, really does not care about any spats between Markeplace merchants, customers, etc. The Marketplace sales commissions make only a razor-thin margin over the cost of keeping the service running (such as it is), so the Lab can't afford to spend any more time policing it than is absolutely necessary to keep the masses comfortable continuing to use Second Life. And that's even more true for non-Marketplace abuse reports. It's all well and good to have principles, but there's no more motivated Libertarian than someone for whom enforcing the rules is a cost of doing business.

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.)