Qie Niangao

If that's your honest reaction then no, SL is not going to work out for you. On the other hand, if that reaction is all performance, you've found the right place. We do drama here on the daily.

Occasionally I buy a thing and decide an alt also deserves a gifted copy, but way more often I see a thing I like but there's just no way Qie will ever wear or use it, so I try to imagine it working for an alt. That would work better if I had more diverse alts, and had interest in more diverse content. It would also be a lot more expensive. At one point I had tiny, furry, and even female alts, but I somehow couldn't be bothered to spring for their mesh upgrades. Never buying female clothes, especially, saves a lot of both time and L$s.

The mystery to me is how it was 24 prims before the change. (I'm trying to understand more precisely what happened in specific cases led to higher Land Impact with this accounting change.) In this case, the prims were set to Prim physics which presumably was also true before the accounting change, so maybe somehow their proper Physics weight was being ignored in the object's total LI until this accounting change forced a recalculation. It would be fun to see what happens if the linkset were merely re-linked in the few briefly-preserved regions on Aditi. (Although, come to think of it, do mere mortals have a way of forcing an update of their Inventory over on the beta grid? At some point, one could trigger that with an account password change and a couple logins, but does that still work??) I'm also pretty mystified how Server Weight could change. It's a simple calculation on counts of links and scripts* that, to have changed, must be simply wrong either before or after the update. (That's in contrast to both Physics and Download weights that include in their calculations some quantities divinely revealed, so if those change we can at best discover patterns in the whims of the divine.) I guess a correct Server score of 2.8 could only happen with objects of 3, 4, or 5 links, with script counts of five, three, and one, respectively, but how could such an object ever have scored 2.0? Hmm. I just discovered that a 4-prim linkset can have four scripts added and remain at 2.8 Server weight whereas that number should be only three scripts. That 2.8 is very volatile, though: take a copy into inventory and re-rezz it and it's 3.0, and changing Physics Type causes a proper recalculation, too. (I have a feeling this bug is reported already but searching Canny is hopeless and there's no telling what made it into the github jira archive.) It's not obvious how that particular bug would generate the 2.0-to-2.8 discrepancy, but bugs tend to be buggy. ________________ *Note in that wiki article the link to the "final" formula, MIN{ (0.5*num_prims) + (0.25 * num_scripts), num_prims }

It depends who is doing the address tracking and why. One of the big problems with RedZone was that it claimed to provide "networked security" which meant that it collected every IP address/avatar identity pair it could detect and then shared that information with any paying subscriber so the landowner could ban all avatars matching the IP address of the one they thought needed banning, no matter where those "alts" were observed. I'm pretty sure it even let subscribers go snooping for alts of avatars none of which had visited the region where that subscriber's RedZone box was located, and it would know about them if they ever had media enabled while visiting any region in which RedZone was active. So if such a system still existed, a subscriber could learn about your shared-address "alt" even if neither you nor the alt ever visited that subscriber's location. Why anyone might want to do that is none of my business, but it seems a sport of only specialized interest.

Oh, now I see the confusion I caused. When this was first reported, for me it appeared to happen not only at login but also when I teleported to a new location, but apparently that wasn't a normal part of the bug, or at least I'm not seeing it now when I teleport. It was that quirky flying-after-teleporting behavior that I would have liked to keep as a feature, so we're not standing on top of the previous arrival. (It would still be congested at landing points, but the inevitable collisions would be a little less impactful if everybody were to arrive flying. On the other hand, that would completely defeat the kludgy little collision_start-triggered landing pad contraptions that try to slide new arrivals off to the side randomly.) The flying-on-login thing doesn't make the viewer present a "stop flying" button, which was the part I found briefly disorienting. (Now suddenly I'm curious about the specifics of what happens when teleporting in to a no-fly parcel when you were flying before the teleport. I vaguely recall that sometimes you stay flying and sometimes the parcel forces a ground landing. Maybe it depends on whether there's a landing zone or something even more obscure. Or maybe that was all a bug that got fixed at some point.)

It's not limited to audio. In fact, the original "RedZone" plague was based on a particular flavor of Parcel Media (typically used for streaming video, such as in-world TVs) as opposed to Parcel Audio (DJ or "land radio" streams) or Shared Media (aka "Media on a Prim" or MoaP, used mostly for interactive webpages on in-world objects). There's no secret about how RedZone worked. An in-world script used PARCEL_MEDIA_COMMAND_AGENT to know the key of each avatar its media successfully targeted and passed that to a web server along with the connection attempt so that server knew the avatar key associated with the IP address making the connection. (Sorry, somehow that comes out sounding complicated no matter how I try to explain it, but it's actually stupidly simple.) That particular form of Parcel Media can be very handy. For example, I used it ages ago to show in-world webpages in the same language the avatar's viewer is using. It's also especially handy for this address-tracking junk but there's nothing prohibitively challenging about using other media and audio streaming to map an avatar's identity to its current connecting IP address. The sledgehammer response is to just disable all media and audio in the viewer. Third-party viewers added a way to whitelist and blacklist specific stream addresses so you could still listen to your favorite DJ and use your SL TV, etc., without opening up to everybody's address-tracking streams.

Oh boy. If this is happening then somewhere, stuff is getting returned for exceeding parcel LI limits.

In lieu of Flickr, you could show them a YouTube:

I usually try to arrive flying when I TP into a populated area, intending to quickly vacate a crowded landing point without inflicting much carnage. I'd be all in favor of keeping it as a feature, but starting out that way when first logging in is a little disorienting.

This is where the logic goes off the rails for me. Why are these snoopy people trying to discover alts in the first place? Just idle curiosity about "the average user" who really doesn't care whether somebody discovers their alts? If that's the game, then sure: let's congratulate IP address matching for its marksmanship in shooting all those fish lined up neatly in a barrel. But anybody with reason to care whether their alt is discovered is simply going to hide their IP address. It's just stupidly easy to do, especially with relatively cheap, fast, and safe VPNs (in parts of the world where people have the luxury of worrying about alt detection). I haven't seen this mentioned but maybe it's a tacit assumption: It's true that estate bans extend [temporarily] to alts with some reliability. Notwithstanding what Estate owners may say, I don't think you'll ever find a Linden saying that's done exclusively with IP address matching.

Except it works for exactly 0% of those with alts they try to keep anonymous. So, yeah, it'll identify some alts whose alt identity only matters to the creep obsessed with finding alts.

AVsitter comes with a utility specifically for this.

Oh, I agree. The lower the LI, the higher the value!

Not always, though. I mean, a 15% reduction can push a 1.7 weight down to 1.445, so a 2 LI item drops to 1. And that's a 50% drop! I think that's pretty rare in practice because creators and buyers will "nudge" sizes and other factors to avoid such borderline rounding-up conditions. But I can't quite convince myself one way or another whether a uniform distribution of fractional weights (not nudge-biased) would end up saving 15% on average. I guess I could run a simulation and find out, but I bet some forums reader knows without even needing to think about it. And also I'm lazy.

There remain ways to get IP addresses easier and more reliably than Vivox ever was, but as amply explained above, only idiots would rely on an IP match to identify alts with any kind of confidence. IP address-based "alt" detection, as laughably flawed as it was, nonetheless made for stupendous drama—and helped send a creep back to jail so it wasn't all for naught. Even after that fiasco, it's never been against the ToS to merely get the IP address of an SL connection. Rather, the violation is in identifying and revealing alt accounts by any means, reliably or not. Most third party viewers changed to make it easier to avoid certain forms of IP address leakage that are especially simple to grab by alt-obsessed creeps.

I really haven't seen much difference, but I tend to have a comfortable cushion of spare Land Impact (except on my little Bellisseria hovelboat), so I might not notice even if it were a big deal. There might be math to better guide expectations here, but I'm not mathematician enough to know how to start. Some considerations that seem as if they'd matter: It only affects the Download weight of Land Impact, which is only sometimes larger than the other two weights (Server and Physics), and when Download isn't larger than the others it can't matter if it's reduced. Download weight only matters for objects that use "mesh accounting" to determine Land Impact. These days that's practically everything, but very old prim and sculpt builds use the old non-mesh accounting iff they never adjusted "Physics Type" from "Prim", nor applied any Materials texture tricks (not even Alpha Mode "Masked" for efficient or sane alpha rendering). Assuming the 15% applies to the floating point value of Download weight, it only matters at all if it pushes the value below rounding threshold. For example, suppose I have an object that started with a Download Weight of 4.2. Fifteen percent of that is 0.63, and 4.2-0.63 = 3.57. That may look like a reduction, but the LI calculation will round it up to 4, just as it used to round 4.2 down to 4. This suggests to me (where's a math major when you need one?) that assemblies of stuff with large total Download weights (like whole builds linked together) will be more apt to see some benefit than separate little things with only a few links and low total LI. I think my eccentric LI-reduction practices make me particularly unlikely to see benefit: I tend to unlink stuff as much as scripts will allow, and then re-link them to balance the weights and take advantage of rounding-down when possible.

Yeah, it was mentioned at the Simulator User Group on Tuesday as a problem in the latest server roll (which otherwise has some good features). Should go away with the next roll, probably next week. There was a request to just keep it this way—which on reflection would have some advantages—but imagine the complaints!

I wonder if we can be talking about the same thing. Granted, I avoid recording video (or even taking photos) so my needs are simple, but I cannot imagine navigating SL without using just the two alt-LMB and ctrl-alt-LMB drag gestures to position the cam, essentially instantly. No doubt, that "instantly" would be a problem for recording, though.

Unless you're already familiar with what Wulfie and Amelia were explaining, maybe try the description in the Knowledge Base, specifically the section "Keyboard controls". This needs to be so over-practiced it's automatic—no temptation to "cheat" with on-screen controls—before even starting to think about screen recording and the more advanced techniques Jackson described.

I did steal the idea, but I refuse to abandon a good April Fool's joke just because I'm late to the thread—nor just because everybody else is pretending to take it seriously.

If it's a good idea to take the exchange rate from 250:1 down to 100:1, surely it's a better idea to make it 1:1, or let's make it 1:4. But nobody wants to spend a minimum of US$4 for uploads, etc, so the NewL$ will need fractional units, . As long as we're going to have 2K textures, we should have high-resolution currency, too, so let's give three decimal places to NewL$. Oh. What a coincidence! 0.001 NewL$ = 1 L$. See what fun the central bankers have in Argentina?

One can edit one's profile on the web, but I don't think it's possible anymore to replace the photos without logging in and doing it in-world. Maybe there's still a back door for that, too. (I'm not sure the "copied" profile had the photos anyway, given that the OP specified "literally the same words" so maybe that's not a problem needing to be solved.) Anyway, aside from the photos, I think all the rest could be a trivial bit of LSL telling a web bot to scrape the text of a new arrival's profile and paste it into the mystery avatar's profile; could be done in a few milliseconds and might stay there until the next new arrival in the region, in hopes of freaking out the faint of heart (or something). Technically, I suppose it is a copyright violation. Hard to prove damages, but a cease and desist letter could be some lulz. Now where did I put that contact card from Dewey, Cheatham & Howe?

Now that I think about it, I was surprised to see this again a month or so ago, not having seen it for at least a year, on items only I can modify. Also, I use only recent viewers, so if a fix involved a protocol change that needed viewers to update to new messaging to prevent them corrupting rezzed content, I'd surely have that in any viewer I use. Trying to read through what remains of the old jira archive, I think they tried such a fix in 2021. One of the original 2015 bug reports survives in "[BUG-8715] [MAINT-RC] Material enabled objects with a diffuse texture set to alpha blending mode randomly (but often) change to alpha mode none locally. If the avatar that sees this breakage has modify rights over the objects, ALL observers see this change." But a couple other things: This frequency of flipping every couple of days is very much different from anything I ever saw or heard of before, so I wonder if this could somehow be something new going wrong. Or something about this particular situation (content, object owners' viewers or networks, something) could increase its occurrence it might be a clue for preventing the problem. In any case I'd definitely suggest letting Support know that it's happening with that kind of frequency. Weirdly enough, the region where I saw this happen recently (Tussock) is also running RC Ferrari. That sounds like a coincidence, except… how many regions could be running that RC?

Way longer than a year. But it's not that there haven't been attempts to fix it. Apparently what happens is that textured surfaces are actually set to the wrong alpha mode by viewers visiting the region attached to avatars with permission to change the affected objects (usually their owners). As it was explained to me it's not exactly a bug so much as an unfortunate design of the messaging protocol that makes it possible for a network error to actually flip the bits controlling alpha mode on those objects. I imagine that locking them would reduce the likelihood of that happening, although that's just a guess based on that explanation.

Do the HUDs necessarily respond to random objects chatting at them or something? I ask because scripts can't see HUDs just by using llGetAttachedList, but could see the other attachments, but really, who wants to look inside a vampire's mouth? What might work is to hammer the Search interface to the Bloodlines page with the avatar name, but I suspect that database includes everybody who ever mistakenly accepted a bite request and didn't know to get themselves removed from the database. (Actually… IIRC, they used to keep a record of people who rejected or had themselves cured or whatever it takex to un-vamp one's virtual self, so god knows what Search returns for recovered bite victims.) But with the OP's reply, I realize it's not necessary to find all vamps, only detect when they bite, which seems as if it should be impossible unless the system goes out of its way to make that detectable. Right?