Lucia Nightfire

There are dedicated perms grabbers in "combat" HUDs that do all this extracting, retitling with target's name and returning to owner inventory automatically. It's been a mechanic in SL since at least 2006.

Copying while rezzed on the ground will yield a copy without stored perms, but if you copy an object that has stored permissions while it is detached and in your own inventory, the copy will retain those permissions. This is how griefers maintain their stockpile while griefing. When an perms container, which is the copy of a master object, loses perms due to the target revoking them, the owner will discard it, copy the master and wear the copy and continue.

It just uses individual animations, one for each face bone, and plays them all together. It's no different in operation than the AnyPose application that uses incremental animations per body bone.

Other than facilitating RP elements, Soul Stealer, Soul Taker, Soul Seize, etc. could also be animation and/or camera permissions collector objects. Anything owned by someone else that you sit on or anything owned by someone else that sends you a permissions dialog asking for animation or camera tracking/controlling permissions can store said permissions. Sometimes these use obfuscation tactics such as retitling their name to something innocuous like "Hugging HUD" or "Funny Chair" or the classic "BEER COOLER". The ones that are sneaky are the invisible ones set to click-to-sit that follow you around waiting for you to click something in-world. Sometimes these have child prims that cover everything around to increase the chance of you clicking something. If you don't use a TPV that prevents click-to-sit, then you'll be force-sat on these followers if you click them and permissions extraction will occur. There are other flavors of operation, but the end-result is the same. TPV's also have revoke permissions options on sit or stand, but sadly there are ways around these and permissions can still be extracted.

The same developer also recently changed permissions with llUnSit() and allowed a bug that I twice reported after it was allegedly twice fixed, to be released. The developer is now working on features of lesser importance instead of fixing the bugs they created. There is a conscious decision to allow these changes to release/remain with these bugs present.

Because the developer responsible for the change has not prioritized fixing it yet.

I don't friend strangers. I tell them so. I tell them maybe after we've run into/talked with each other a few more times. The only exception is when business matters/relationships are involved.

You would have to look at packet data to see if multiple PRIM_LINK_TARGET calls to the same link are stacked or if only end-result of all changes per link is sent in the packet. A link's complete visual params "should" still be sent with full updates else doing tricks like updating invisible settext to force other visual prim param updating that previously failed due to packet loss or out-of-interest-list scenarios wouldn't be a thing. It also isn't clear how the server "bundles" inputs either. You can replace a texture UUID with an integer to force an error and the server will still update everything up until that error. Intuition dictates trying to bundle calls by link and face as best as possible, though.

The person in charge of finalizing last name suggestions is an intellectual, but not one of business mind. If you bring the subject up at the Web meeting, you might see/hear what I'm talking about.

I actually had a friend once that would intentionally obfuscate the names of EVERYTHING they wore in hopes that it would prevent someone else from wanting to create the same outfit. I've encountered, far more times than I can count, people who've titled their attachments with their name in possessive format ("Lucy's Head") and those who've retitled things are part of a cosplay or themed outfit. All of these things are not uncommon in the mod community.

No, that is just a facet of no-mod in general, which creators use to cite everything under the sun from protecting artistic expression to deterring heavy work load on CSR's having to deal with people that break their content. Personification, though, is a common thing in the mod community and it does obfuscate what product someone is wearing, which could hinder someone's efforts in finding said product, especially if they don't bother asking the wearer what they're wearing nor whom/where they got it from.

Thing is, one of their QA reps said they have a process for keeping certs from expiring, but apparently it is buggy. Is there anything in SL that isn't? heh

Yeah, but they demo'd something entirely different to me a few years ago that is no longer in their store. They were playing a synthesizer in RL and it was connected to an in-world keyboard.

https://marketplace.secondlife.com/stores/72153 IIRC, this store used to offer a "program" that would connect between a MIDI capable keyboard and an SL piano object. They also once sold a gesture based keyboard that would use letters for piano keys. Maybe contact the creator for details.

Their store has "Xolo" style skins for the "Hellhund" dog avatar created by Murder of Ravens. I'm looking for skins for the "Xolo" dog avatar recently created by Sugarcult.

Any exponential influence will do. You might also have to trend either TD or FPS over some time length as they can change sporadically for a multitude of reasons. There are also cases where lag is present and TD is normal, but FPS is low.

If they did, they would kiss an entire continent and a massive chunk of revenue and users goodbye.

Max rez distance = 10.0 + (triagonal of the rezzing link's size * 0.5); To get triagonal, simply use llVecDist(ZERO_VECTOR,rezzing link's size). So, a 1x1x1 rezzer prim can rez up to 10.866 meters away. Trying to rez 10.866 meters away will succeed. Trying to rez 10.867 meters away will fail. This is why 1024 meter long laser megaprim can rez a payload at "hit" location 100+ or 200+ meters away across a sim. Worn megaprims also facilitate this mechanic even in HUDs.

The Sugarcult Xolo dog avatar comes in BoM form factor. The dog looks good enough to also use as an Animesh companion, but I'm not finding any raw textures for it, only wearables, which Animesh does not yet support. If anyone knows of any skins offered in applier format or as raw textures, please let me know. Thanks.

INB4 one of SL's prominent user base asks, "Where's the 'Blender After Dark' version?".

So now it's metaverses we all need and not a metaverse? Got it. Capitalism, patents and brand/IP rights/protection won't allow for a true metaverse anyway. All this metaverse slanging that tech companies are doing now is to gage interest and to signal to those with less money to throw around that, "We got this. Don't even try it.". All the while, no one is going to come up with anything remotely like the pie in the sky everyone is dreaming of. Until the day full-dive is actually a thing, it's all an absolute waste of time. P.S. Full-dive without RW-to-IW observed time ratioing will be a bummer to. I want to overclock my brain and live pseudo forever while acquiring the knowledge of a god and all the time to do it in. IDC if I lose my humanity/identity/compassion in the process. Yeah...

There is no "broadcasting". Scripts that contain experience permissions (0x62000) automatically monitor when the perms holder either blocks the experience or enters land that does not have a land scope experience allowed and removes all perms. FYI, llAgentInExperience() can return false negatives while the target is over land that does not have the land scope experience allowed.

Unanswered experience permission requests remain active in the background for any one agent up to 5 minutes. You need to tailor your work flow to only handle one user at a time and ignore denied events from anyone other than the person of interest. What you encountered is the opposite of someone granting permissions after someone else steps in and has a request made and granted. https://jira.secondlife.com/browse/BUG-228162 In that scenario, we really need a dedicated error code.