Hooten Haller

I’m dragging onto a large flat rectangle floor. I’ve been able to drag from object inventory for years. It’s how I develop embedded scripts: drag the embedded object to the floor, edits its scripts, and save it back to object inventory.

I made a script to rez objects ("rezzables") from a rezzer's inventory. It works fine. But I cannot drag that rezzable onto the floor next to the rezzer. The mouse cursor turns into circle-slash.lock. Do I need modify + copy to be able to drag an object from my object's inventory? Why can my script rez the object but I cannot drag it out? This seems inconsistent, so I wonder what I have done wrong. I created and own the rezzer object and script, and the refer is not associated with any group. I am on my own parcel. Someone else created the rezzables. The rezzables are mCt permission (no modify, copy, no transfer).

I am probably observing the same problem. The last sound played by llPlaySound will sometimes be replayed when I click some viewer UI controls, controls that are obviously not in-world. For example when I close the debug-channel window, or an llDialog window using the "X" in the upper right corner. I too have tracked my uses of llPlaySound using llSay(DEBUG_CHANNEL,...). I tried switching to llOwnerSay instead and can't reproduce the problem but as it's a bit unpredictable I can't be sure that really works around it.

"... keeping all its unused parts loaded as well ..." This is an excellent observation. I expect to use only 1/16 to 1/8 of the image at any one time. "If the individual faces were changing what they're displaying often, ..." The textures don't change often, maybe every 10 minutes. Altogether it looks like individual images will serve me better. Thanks for the insights.

Textures reload often in relatively static situations as the viewer discards and reloads the same texture over and over. Each reload causes it to blur, and worse sometimes the reload stalls so it remains blurred. It's terrible for playing games. I know fixing this was mentioned in a recent LabGab, but I have the meantime to consider for the game I'm creating. My game uses a large (slightly over 1024 pixels square) texture applied to various prim faces, and zooms in using repeats+offsets (*). All the faces blur out during the single texture's reload. Would I still get the reloading blur if I used a lot of smaller, unzoomed textures for each face instead? Or maybe the reloads would simply go a lot faster and not stall? * Like the zooming + offsetting technique mentioned here: [https://community.secondlife.com/forums/topic/496784-texture-offset-for-a-number-display/#comment-2566428]

As a Mac user I mostly use BBEdit now. Partly this is for a more responsive feel to editing, and familiar behavior. A major benefit is that every single save I make is saved to my local storage. I wrote a small app that manages the version history storage. So even if I get an accidental disconnect, or have to end editing suddenly with malformed LSL, or the inventory server glitches (which is frankly rare for me) I have a way to go back to old editions, compare changes, and even use git if I want to.

Is there much of a performance impact for a Mono script set to "not running"? Does it use simulator memory when it is marked as not-running?

Has anyone implemented ECDSA (Elliptic Curve Digital Signature Algorithm) message signing in LSL? I could use it for some LSL-to-server work.

I missed seeing that caveat. I'd considered noting the time of the changed event as well. I want to compare with an external version of the notecard. I'll ponder some alternate designs before I go as far as making a feature request. Thanks, folks!

Is there a way to get the modification timestamp of a notecard in inventory? `llGetObjectDetails` `OBJECT_CREATION_TIME` returns an empty string. `llGetInventoryAcquireTime` returns the timestamp when the notecard came into the inventory; it's not updated when the NC is edited. The notecard's description reflects its creation time. My objective is to know which version of a notecard is most recent. I may need to satisfy myself with manually bumping a number suffix on the name. That requires discipline and isn't reliable.

Is there a way for a script to determine if the object it is in is marked "Animated Mesh"?

Yes, I do have, but it was a bit more complex than a simple in-memory list so it was swamped by the unexpected flood. Each day I learn something new. Thanks.

It has only happened with firestorm viewers. I don’t have a large test set to confirm it is only firestorm or always firestorm. The code was simple and’s very small so I can post it if a anyone wants it. For all I know it t be related to avatar characteristics. It is interesting enough that I will put this on my list to investigate further.

A quick test shows llVolumeDetect does exactly what I need even with Firestorm users: just one event when they enter the volume. Thanks, Molly. (This the second case I've found that Firestorm events vary from the standard SL viewer. FS does not make me happy.)

I have a dance floor. When people walk onto it I expect a collision_start event so I can welcome them. In the standard viewer it's great because I get just one event. In Firestorm I get dozens of collision_start events as the avatars walks around the floor. I think I'll need to maintain a list of UUIDs and maybe timestamps that filters out excessive events over a short period of time. Does anyone have alternative ideas?