Lucia Nightfire

Clearly mesh feet, but what isn't clear is if you're actually wearing a mesh body or not.

Please do not post script examples/snippets on the wiki using Firestorm's preprocessor as it is not officially supported.

Is there a region on aditi that is NOT running version 2023-02-02.578100? I want to test a specific vector that causes scripts to be set to not running, that was NOT mentioned in the bug reports. [EDIT] NVM, found one. Said vector "seems" to be fixed as well.

Because the scripter they keep commissioning has rarely ever evolved their practice over the years. And they won't ever seek other talent because they equate their current one as "family", so they're doomed.

Almost looks like a RL photo with the lighting.

Fight the machine! 🦼🚽♻️

To be fair, LL shot them self in the foot with the Adult user group as they wouldn't let you talk about specific products nor would they let you talk in detail about acts/fetishes. It was more geared toward Adult policy Q&A. It was doomed before it even started.

Sadly, I still have to use "other means" to get further metadata, such as number of bone translation/rotation keyframes per bone, the names of all bones animated as well as when the animation was uploaded to the CDN servers.

My comment was mostly towards the ones that charge to change your name in a system, when that system could just be updated. I think there is an incentive not to change the format to be more efficient.

It isn't too late to correct the data. We now have https://wiki.secondlife.com/wiki/LlRequestUserKey It is, essentially, an official, remote Name2Key means. I use this function with old names to get current names, via uri.

This happens when phyiscs memory is too high in the region. A region restart is needed to fix the issue. Sadly, with all the sim stats we're going to get access to via LSL in the coming weeks, physics memory was not included. If we had access to that stat, we could know about high memory usage early.

IBTL 🤖

Is the sit object within the target's FoV, IE, close by and in their interest list (on-screen)? Is the sit object in a location in the region, that when an agent who is not alt-cammed on anything, camera is following them, draw distance is low enough to not load other regions, get sat causes an adjacent region to load when their camera position changes?

The means was made official because there were already other ways of determining someone's account level. I, myself, was using one of at least six other known means before LL added OBJECT_ACCOUNT_LEVEL to llGetObjectDetails(). What do I use the data for? Offering discounts/points/perks to those with Premium accounts that use my in-world services. Also, PIOF and/or PIU is all one would need to be considered a target for scams, but really, the ones who commonly fall for them are the newest to SL, MMOs or the internet in general.

This happens when an LL staffer reclaims land directly in God Mode. It is a bug. File a bug report and it will be fixed when Unix time rolls over, heh.

It's called the "interest list". If someone gets scripted sat on something outside of your FoV, they might not update correctly when you change your camera angle to bring them back into FoV. Everything from hover text, to prim position/rotation is affected. There's also an issue with sitter rotation not updating when their viewer is minimized. https://jira.secondlife.com/browse/BUG-202856

Unrelated, but I suggest doing your LSDFindKeys in blocks instead of puting the entire list into script memory when doing cleanup, else, you easily risk crashing a script.

For the "A" regions, you need to be Premium or Premium Plus. For the rest, you need to be a member of the group, "Second Life Beta". IM me in-world and I can send you an invite to the group.

I'd be more turned off at businesses using bot clusters to generate 95% of their traffic rating than I would at random survey bots coming and going all day. It might be nice if Scripted Agent status could be read by script so visitor alerts and/or moderation could be more "efficient". Also, aside from the horrible practice of forever equating an IP between a RL entity and any one user, something that other systems like Voodoo and CDS use, the final nail with Red Zone was the discovery they were harvesting incorrectly inputted passwords on their website with the hidden data field "possible Secondlife password" or something similarly titled in each user's account data.

LSDRead is 10x slower than List2* LSDListKeys is 6.5x slower than ListFindList LSDFindKeys is 13x slower than ListFindList This also means LSD generally uses more script timing. With this in mind, unless you're saving a significant amount of script memory and/or script timing, you probably shouldn't convert EVERYTHING from list handling to LSD, else I predict in the years to come, that LSD could become a new concerning source of region script lag. My 2 pennies...

See https://jira.secondlife.com/browse/BUG-225527 to allow resetting the skeleton to be seen by others.

Not surprised by either. It meant that the tongue was either being exercised by another animation using bone translation for the tongue or a worn rigged mesh had embedded bone translation for the tongue. In the case of the jaw, it meant there was no other animation exercising it, nor any worn rigged mesh with embedded bone translation for that bone.

I mean script time does not advance until a minimum of one server frame has advanced. Display_Bytes_Check(string s) { integer bytes = ((3 * llSubStringIndex(llStringToBase64(s) + "=","=")) >> 2); if ((display_bytes + bytes) < 1024) { display += s; display_bytes += bytes; } else { llOwnerSay(display); display = s; display_bytes = bytes; } } string display; integer display_bytes; default { touch_end(integer i) { if (llDetectedKey(0) == llGetOwner()) { llResetTime(); for (i = -50; i < 0; i++) { display += "\n" + (string)llGetEnv("frame_number") + " | " + (string)llGetTime() + " | " + llGetTimestamp(); } list T = llParseString2List(display,["\n"],[]); display_bytes = ((3 * llSubStringIndex(llStringToBase64(display = "Test A\nFrame Number | llGetTime() | llGetTimestamp()") + "=","=")) >> 2); for (i = -llGetListLength(T); i < 0; i++) { Display_Bytes_Check("\n" + llList2String(T,i)); } Display_Bytes_Check("\nFree Memory: " + (string)llGetFreeMemory()); llOwnerSay(display); llResetScript(); } } } Drop the above script into a box a click and notice repeated calls to llGetTime() within the same frame number return the same value whereas timestamp is unaffected.

llGetTime() should never be used with subsecond precision reliant speed testing as it is server frame advance dependent. You should be using llGetTimestamp() instead as it is not server frame advance dependent.

Until https://jira.secondlife.com/browse/BUG-232687 is implemented.