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?

As a general principle, yes. For a couple retirees, no.

We don’t have animations. We have poses and move the pose balls around. Making custom fluid animations is expensive.

Coffee Pancake's explanation seems to be most relevant, but I've benefited from all the answers. Yes, we have a kind of geometric scaling issue: the more people who participate, the more updates get sent to each viewer. (We're a folkdance simulator, where the dancers sit on objects that pose and move them. We don't have the moolah to develop mocap animations.)

We have a complex script involving coordination of many objects which are not linked. It performs quite well in a region that is very lightly used, apart from an animal nursery up in the sky. Now we want to take this system on the road to regions that will be heavily loaded and probably very laggy. Is there a sandbox that provides a simulation of a heavily loaded region? Is there a way to make a region be heavily loaded without trying to find 60 accounts to log in?

Ah yes, did that. We ran into using search (UI complexity), the really bad performance of the search window, how do you then use the search result to get to me or message me (further UI complexity). Even finding the IM window, particularly after it had collapsed into a chicklet button at the top right, had to be carefully explained.

When I invite a friend into Second Life, I cannot find them. It takes something like 24 hours before they’re added to the search results. So for their first day on-Grid they are cast adrift without a way to reach the one person they know from first life who can help them. Oh sure, I worked around it a bit by emailing them a SLURL to me, but those aren’t exactly easy to use either. Paid Mentors are nice, but your friends should be able to connect with you immediately. That scales much better.

Last year I invited a number of friends to SL to try a square dance system I created. These were very smart, computer literate people. They were already using Minecraft, and I wanted them to make the jump to SL. Two complaints stood out from multiple people: the avatars and the movement controls. The avatar complaints were either "This is uncanny valley" or "The stock women are WAY too femme." The movement complaints had nothing to do with the dance system. The main complaint here was the system was "old fashioned". I am not sure if it was the key assignments or physics. None of them came back, preferring Minecraft for their dancing as well as general building/creativity. I was able to get a few more people to try again later. These were not game-literate people, and though they were _basically_ comfortble using computers. They had a lot of trouble with camera controls and moving. They had trouble noticing instant messages and teleport offers. They didn't know how to detach the handbags and other unnecessary starter avatar objects. Clearly there are a LOT of barriers people run into using SL.

Thanks for all of the answers. We don't need to communicate across regions, and repeaters might introduce a slight lag when synchronization is critical. We only send a few messages per second so we'll be well under the 200msgs/10sec limit. This is for improving scalability of our folkdance system.

We have a system which communicates the same message to a couple dozen objects at once. Currently they are within the 20m say-range, but we anticipate needing to talk further afield. Possibly several dozen such listening objects. Does anyone have solid numbers on what's better to use in that situation, llSay, lLShout, or llRegionSay? My concern with the calls that filter objects on range is how much work it is to know what objects are in range. llRegionSay sidesteps that and addresses all objects listening on that channel, with no concern as to how far away they are. I think that would be more efficient. But perhaps the grid is already very efficient on knowing what objects sre in range of what other objects?

In fact I tried a 2 second sleep and it works fine. If this becomes critical I'll try adding the code you suggest. I also tested this across a logout/login region change, and it work fine that way too. Not to cast aspersions entirely on FSV, SLV had a similar issue but the 0.1 second sleep was all I needed to fix that. (For SLV it didn't get confused about the detachment state, it simply didn't detach after the TP.) Now my fellow dancers can enjoy the temp-attaching HUD while dancing, and it will vanish when they TP elsewhere. Thanks everyone for the advice and patience.