Kyrah Abattoir

What's the issue exactly? Cause I've been using the feature quite a bit, and the fact they don't always start isn't a deal breaker, at least for me.

if you want to catch other events while your "long running loop"... is running, you'll have to make sure it interrupt itself and re-schedule a time to resume. Scripts only have one execution pointer, you cannot be in two events at the same time.

Another important thing is that LSL scripts only have a single execution pointer, your timer() will only be able to fire after the current event is completed. In addition, events are not guaranteed to fire on the frame they are scheduled, I believe that is what the "missed event" region stat is.

@Lucia NightfireFunny thing is, at some point i wanted to move all my scripts to use touch_end, like a proper UI. Then a realized that it felt very "wrong" because using touch_start kinda masks some of the latency. Not directly related to the issue at hand but i thought i'd mention it.

Another discussion in this section got me wondering about equality operations on floats in lsl. In c# for example it is advised to avoid using strict equality operators because floats can end up unequal due to precision errors but still relatively close to eachothers (within 0.0001 for example) I'm now wondering if those recommendations are valid for LSL too.

Sorry i ment an operation at the binary level.

Isn't it technically a binary operator?

You do if you intent on previewing volume bone deformation (fitmesh). It obviously doesn't apply if your own avatar doesn't use them. In addition, getting a perfect, or near perfect fit isn't hard if you are the original body creator anyway, since you have access to the complete reference. Also solidify? come on. Give us some good old wireframe pictures there if you want to be judged.

There is no "wrong" tool out there, just wrong workflows. Once you are done sculpting in Z brush, you still have to rebuild your model as a proper low-poly asset, suitable for SL (or any game really).

Here is another method which I use sometimes: You can write into the rezzer's description, the message intented for the rezzed object. When the rezzed object wakes up, you can use llGetObjectDetails() and OBJECT_REZZER_KEY to know which object rezzed it, and then OBJECT_DESC to read that string. For me the main advantage is that there is no message that can get lost, delayed, requires parsing, or sanity checking, you set the description upon rezzing the object, and it will be there, read for reading as soon as on_rez() fires.

A few that I think are important: SL is a multi-user environment, you only control the part of it that you write yourself. You, as a scripter are not in charge and your scripts are not a priority for the simulator. SL is good at some things, and not so good at other things. Sometimes, the thing you want to do simply cannot be done efficiently. Despite that, it is also very possible that, what you are trying to do is simply a really bad idea, within the contraints of SL. The LSL compiler is not very good at optimizing your code: choose speed/efficiency over readability/maintainability. Don't assume that anyone knows what they are doing, especially when reading other people's code. Keep the LSL wiki on hand, at all time. Try to keep up with any new functions. A new function can change the way you approach a problem completely.

As a region owner i know i would definitely try to reduce whisper range to 2 meters But not if it's also applied to non-zero channels. It would also break a lot of "emote" systems that rely on whisper to relay textual cues that should be "visible" to people nearby. There is no real way for those to "ignore" the reduced whisper range, they would have to use either llSay/llShout (not a great idea) or to spam llRegionSayTo to everyone in close range, which is just inefficient.

I actually do and recommend doing so, I just have no way to know that the talking object did, and thus the first argument of a TB message HAS to be the targeted avatar. Which wouldn't be necessary if we could just check who the message was sent TO.

I agree but, with LM for example, we always HAVE to supply a target key as part of the payload, because there is no way to know if the message was for us or not. Would be nice if we could know for sure "this script used our key in llregionsayto", maybe not for LM but for future protocols, it has always been weird being unable to know this.

Protocol strictness on my end Until RegionSayTo became a thing for instance, the LockMeister reference specified that to avoid wasteful message processing in potentially busy areas, messages should under no circumstance be sent using llSay or llShout. Personally? I'd love if there was a way for scripts to know which function was used to send a given message. Being unable to differenciate llRegionSayTo from all the other public broadcasts is frustrating.