Wulfie Reanimator

If we're going to throw our hands up in the air like this, then LSO cannot go away as an option for new scripts as it serves a tangible purpose. I would invite you or anybody else to join some SL combat, then trying it again after all the scripts are switched to Mono. (Or heck, just switching your own scripts to Mono.)

Other way around, Alpha Blending is what will cause issues with other Alpha Blending surfaces, because the viewer can't accurately guess which surface is in the front. Alpha Masking can be a solution, but it can't have partially transparent pixels, which makes a lot of hair pretty ugly looking. Edit: I don't even know who you are, apologies. Edit 2: Oh. Our last interaction was over 4 years ago...

Make sure it's set to public, alternatively you can just drag the photo from your PC to the post editor to upload it here directly. 🙂

Could you post a screenshot of the neck area, so we can see where the head and body skin connect? It's usually pretty easy to tell if it's a skin or a lighting problem.

Does the LI stay at 3 even if you pick it up and re-rez it?

And the start-up speed of Mono scripts in general.

You missed this part: "They would leave the interpreter running so existing LSO(non-Mono) scripts could still function" Regarding the region crossing speed, one reason LSO scripts are better/faster is in the way their memory space is handled. The following is ancient (for better or worse) knowledge: LSO scripts will always be allocated exactly 16KB of memory, regardless of what they actually use. This should make it pretty trivial to transmit the script between sims. Mono scripts have dynamic memory, meaning that during region crossings, the potential memory area needs to be scanned (accounting for memory fragmentation and garbage collection) and serialized in a more complex way for transfer. Whether that difference still holds up after the move to AWS and the massive improvements we've seen to region crossings, who knows. I won't be affected by it and don't have any significant use-cases besides the above, and actively maintaining some old scripts. (I guess that's what the question is. Who are the people doing this maintenance, why is LSO the better alternative, and is there no way to achieve the same thing under Mono?) Edit: Wait. I do know a relatively common/important one that's still in active use. Rezzed scripts. Scripted weapons used by SLMC (Second Life Military Communities) in LLCS (Linden Lab Combat System.. the thing with avatar health) will generally fire physical projectiles, and Mono scripts are just not viable in projectiles. Mono will initialize much slower, especially during sim lag, and this will cause projectiles to bounce off of surfaces and be a much bigger pain to work with in general. (These weapons will fire hundreds of projectiles a minute, at minimum 150m/s.) The most basic script will call llDie() on collision to make the projectile disappear if it hits any surface, but many will need do other things like play sounds, effects, rez things, etc. There's still the issue of Mono scripts sometimes taking several seconds to receive any event (even on_rez) after being rezzed. I used to be a dedicated developer for an SLMC group, have made several things for many others, and still have connections to those groups. Being forced to use Mono would definitely cause "a wailing and gnashing of teeth" in this case as Rider said, because it would be a significantly breaking change. 😅

The llDetected* functions are special, the index only works in the context of a few specific events that are able to detect something. For example, llSensor can detect up to 16 things (not just avatars), so the index will be in the 0-15 range (never higher), based on distance and the conditions of the previous llSensor call. Meanwhile, multiple people can touch an object at the same time, usually only one person (index 0), up to as many people as there are in the sim. But they have to be actively touching the object and you can only detect them in touch/touch_start/touch_end. All this means that there's no index you can use to track just any avatar you want, if they aren't related to the current event.

On Firestorm: World > Improve Graphics Speed This is a new tool which gives a much (much) more accurate indicator of whose avatar is actually too complex, and which of your attachments are taking the longest to render. You can also derender the avatars that are actually causing lag in your viewer by using it.

It does! Thanks for explaining your use-case.

Explain it to me like I'm 5. 🙂 I guess I'm not seeing LSD as a general communication device like llMessageLinked. (I see it as data storage, as in it holds state.) My current thinking of how the events should work is: When a key is created, other scripts are notified, and all of those scripts know the value of that key with no additional checks from that point onward. At that point, every script in the linkset can continue to do their job because they know that value. If any other script creates or sets the same key to the same value, there should be no change in behavior necessary for any script, since they were already doing their work with the same, known value. (Right? Or this assumption not correct?) This way the functions really are "fire and forget" in the sense that you don't have to check the current value, a new event will only happen if the function *did* something to the storage. If the value changes or the key is deleted, that's an important state change that other scripts should be able to react to.

Can you give an example?

But that's the thing; there was no update because nothing changed.

I think I would rather have an event per change (it might make more scripts simpler), but no strong opinion yet. I'm trying to come up with use-cases for no-op events, but the only thing I can think of is linkset-wide signals, which is already covered by llMessageLinked. When would a script want to react to LSD updates that don't change its state?

A linkset is a group of objects. One object is the root (or "parent"), the rest are links (or "children"). It's a single-level hierarchy, the children can't also be parents of other objects. It's closer to a plain old array (1-indexed), if you wanna think of it in terms of data structure. That's how you'd iterate through a linkset, too. Those tutorials will be fine.

'\' is an escape character in LSL strings. If you have '\u' in a string, the backslash is trying to escape the 'u' and doesn't end up in the final string. To use the shorthands, you have to write them out as "\\u". (The first '\' escapes the second, and the pair becomes a single literal character for the string.) Single brackets have a specific meaning in regex. "[abc]" is a set of characters 'a', 'b', and 'c', and any one of them will be matched. LSL is using a POSIX-compliant parser (not necessarily PCRE2 as I originally thought), you can read about the specification here. It's actually more interesting than I thought! * The RegexTester website has two standards you can choose from; ECMAScript (default) and PCRE. There are more implementations, another site I like to use is Regex101. "A[[:digit:]]C" finds the same (subset) of keys as "A.C". They both match "A0A0C". @Quistess Alpha pointed out earlier in this thread that keys were not found based on substring matches. The implementation has changed and now "A" matches "CAT". This is a good change, and you can still match "only strings of 3 characters in total length" if you wrap your pattern as "^A.C$".🙂 ('^' meaning line start, and '$' meaning line end.) ------------------- * To ramble about the double bracket thing a bit more... from the PCRE2 specification: So the first '[' symbol begins a character-class ("a set") definition. The second '[' symbol begins a POSIX character-class (if followed by POSIX syntax "[:" and ":]"). So that's why they're usually wrapped in double brackets. POSIX just defined it that way. But interestingly, you can use the POSIX syntax on its own in LSL, outside of any other brackets. We can even use the POSIX "collating elements" as described on that manual page (which would NOT work in PCRE2!): Fancy.

"Zero on success" is common practice in software development when there can be multiple reasons for failure and a more specific reason is wanted. Return codes from programs work this way under Windows/Linux/Mac too. There's already a feature request about it. https://jira.secondlife.com/browse/BUG-232792

...or Patch doesn't know / hasn't had time to find out during a single Friday, and the Speedlight dude hasn't been on the forum since the end of July.

I was there using those functions when I wrote that comment, can you post the script that was giving you errors?

Well, I found something similar in there: "FSLetterKeysFocusNearbyChatBar: If enabled, the chat bar in the Nearby Chat window will be preferred if it contains a chat bar and LetterKeysAffectsMovementNotFocusChatBar is FALSE." As the description says, this means you have to disable WASD movement first and then your chat messages will be typed into that window. (And if the debug setting FSNearbyChatbar is TRUE, which it is by default.) I didn't find anything that would make it possible to use the chat bar in the window while also having WASD movement enabled.

Mauve is mostly build-enabled, and the functions work there. If you type "mapto mauve" into local chat (Firestorm feature), you'll land in a parcel with building enabled.

A sitting avatar becomes part of the linkset, so a HUD could do llGetObjectDetails(llGetOwner(), [OBJECT_ROOT]) to get the key of the vehicle.

How about you use the root key of the vehicle itself? That way the channel is easy to figure out regardless of if the script is in the vehicle or the riders, and the channel is inherently unique to that vehicle.

There's no way for you to change the UI so that the chat window's text field gets focus when you press Enter to begin typing. You'd have to click into that field, as you would when typing into group chats or IMs. The "bottom chat toolbar" you're talking about is exclusively used for local chat.

Back in my day there was no choice but to pay for your profile picture! You young'ins have had it too good! /s