Scripting Features

I feel this has to have been discussed before.... but can we get a version of llGetTimestamp() that returns SLT so we're not reduced to adding 70+ lines of code and the associated overhead just to get the same timestamp that's showing up in every viewer?

Particle system sorely need an overhaul and additional settings to make the best use of it. I've broken up a list of features to make tracking for each one easier for the devs. Texture Animation for ParticleSystem Easing Interpolation for ParticleSystem Alpha blend mask mode for ParticleSystem Color Noise for ParticleSystem Reverse Target for ParticleSystem Emissive Interpolation for ParticleSystem Select Sprite for ParticleSystem Offset Position for ParticleSystem PBR for ParticleSystem "MID_" Flags for ParticleSystem Follow a chosen attachment point

Since texture transforms aren't part of the PBR asset, we can't just use the "" hack in llSetLinkPrimitiveParamsFast(...) to preserve their values. Instead we need to record the transforms (offset/repeats/rotation) for each face and reapply them with the new alpha value. A function like llSetLinkPBRAlpha() would be very much appreciated. Coming to think if it, most use cases (except for fading) could actually be addressed by having something like llLinkVisible(LINK_THIS, ALL_SIDES, TRUE) - llLinkVisible(LINK_THIS, ALL_SIDES, FALSE) - taking the usual LINK_* constants and face numbers.

I'm not 100% sure of the implementation, but maybe something similar to llSetAnimationOverride: First off, you need to request a permission such as llRequestPermissions(target, PERMISSION_CONTROL_PLAYER) llSetPlayerController(list params) Where params is a list of PLAYER_CONTROL_* followed by data. Suggested PLAYER_CONTROL_* settings: PLAYER_CONTROL_JUMP_HEIGHT, (float)percent - Modifies the current jump height by percent. Some upper limit could be added. 0 would disable jumping entirely. This would be useful because the default jump height is so unrealistically high that most games end up disabling jumping altogether. PLAYER_CONTROL_RUN_SPEED, (float)percent - Modifies the base run speed by a percentage. Some upper limit could be added, 0 disables running. PLAYER_CONTROL_WALK_SPEED, (float)percent - Modifies the base walk speed by a percentage. 0 could disable walking entirely. An upper limit could be set. These two would be useful for games and roleplays where a player could get a temporary speed boost, or perhaps slow players down while carrying heavy objects. The one concern I can think of is running/walking animations going out of sync, but that would be up to the dev to supply appropriate animations. PLAYER_CONTROL_CLIMB_RADIUS, (float)radians - Modifies how steep inclines the player can walk up. This would be useful because right if there's just a minuscule incline to a wall, players can walk right up it. The angle players can walk up in SL is very small.

Something I've had issues with is making stuff that communicates with other stuff easily configurable. It'd be nice if we could utilize build tools in conjunction with LSL to do this. The simulator is already aware of what is selected, so it shouldn't be too difficult to expose it via LSL. Think of the following: I make two teleporters, instead of going through making the resident copy UUIDs or set up channels, they can just select the two teleporters then do /1234 link and they are linked automatically. Ideally, it would return a list of objects (up to a limit, I'm aware large amounts of objects can be selected at once, enough to cause a stack heap collision), with the first entry being the last object someone selected, and the last being the first selected. As for the function signature, maybe something like llGetSelectedList(key agent, list options) . Might want to put it behind some sort of permission though if it is someone other than owner. Might be useful to have a singular llIsSelectedBy(key agent); as well, to avoid having to do loops / list index checking in timers / events.

note: I didn't set the title to "LinkSet" and I have no clue why it's doing that, considering it's "Linkset" in the editor! weird! This suggestion was brought up a year ago and closed a few days later. I think, with respect to Spidey & Lucia, it deserves a second crack with a more well-defined spec, because we are actually missing an important function here. Problem There is currently only one function that returns any useful data regarding the memory usage of the linkset datastore - llLinksetDataAvailable , which only returns the bytes remaining for the entire datastore. It is currently impossible to measure the bytes used by any specific pair(s) without either reading them and running a base64 count (expensive, risky) or deleting them and measuring the change in available bytes (pointless). This is a problem because there is no limit on the size of linkset data pairs. Unless you only have a single pair in the datastore, it is currently impossible to tell if the pair you are about to read will be too large and crash your script. To that end, it is trivial to come up with an extremely tiny script that creates a pair so big that it is practically guaranteed to crash any script that tries to read it. Nor is it difficult to imagine scenarios where this could occur unintentionally. This will become even more likely with Luau support as Lua scripts (and, AIUI, Luau-compiled LSL) will switch back from UTF-16 to UTF-8, changing how strings count against script memory and facilitating bigger pairs. Proposal llLinksetDataBytes( string name ) string name - The key of the linkset name:value pair to count the bytes of. Returns an integer with the number of bytes used by the pair (including its name and 32-byte passphrase hash, if used), or 0 if it does not exist. llLinksetDataBytesFound( string pattern ) string pattern - A regular expression describing which keys to sum the bytes used of. Returns an integer with the number of bytes used by all keys matched by the regex. The point of these function names is to avoid confusing them with counting length as opposed to bytes . Also, linkset data storage is not "memory" per se, so I don't think the previous suggestion of llLinksetDataMemoryFound is semantically correct. Use Cases llLinksetDataBytes can get the bytes used by a linkset data pair without needing an expensive, risky, or destructive workaround. This is a separate function from llLinksetDataBytesFound because LSL lacks a regex escape function (although it can be done manually, just inefficiently) so it is more efficient if you want to check a single pair immediately before reading it. llLinksetDataBytesFound allows you to measure all pairs matching a certain regex at once. For example, say you have two concurrent data schemas in a single object - some pairs start with "array" and are used for a large array-like structure, some start with "config" and store notecard values, whatever. Trying to actually measure the bytes used by either of these schemas individually is potentially memory-intensive and slow, even though we already have llLinksetDataFindKeys and llLinksetDataDeleteFound . The only current practical solution is to run the aforementioned base64 count on every value you write, modify, or delete, and maintain a byte total manually. Additionally, llLinksetDataBytesFound makes it possible to calculate the entire space available to the datastore (128kB as of this writing, though it was once already raised from 64kB). This is currently impossible because there is no function that returns the complement of llLinksetDataAvailable , nor is there a function that returns the entire capacity, à la llGetMemoryLimit . This function fills that gap without needing to provide a function to return what may well be a constant (but not guaranteed!) 131072 forever. Caveats It is possible that someone could consider the bytes used by a protected pair to be sensitive information that this function shouldn't disclose; however, since llLinksetDataAvailable can be used to do this already, the novelty of this risk would be negligible. Since the bytes within the linkset datastore are UTF-8 but get read into Mono-compiled scripts as UTF-16, the bytes reported will not exactly match the bytes the value would use once read, although any value is better than nothing. (This won't be a problem under Luau, and wasn't a problem under LSL-2, just Mono.)

Limits on strings are in bytes[1] everywhere it matters. llStringLength returns a count of characters (code points, presumably). Luau already gives us string.len() utf8.len() to distinguish between the two. ll.OwnerSay("bytes: " .. string.len("abcdᴥ")) // 7 ll.OwnerSay("points: " .. utf8.len("abcdᴥ")) // 5 The suggested approach to getting the byte length of a string in LSL is to convert it to base 64, parse that to a list to strip padding, cast the list back to a string, get the length of that string (since the code point count will now (nearly) match the byte count), and do some math to clean it up. For complexity, performance, and GC, It would be nice if we didn't have to do that. Mono having a utf-16 soul might complicate things? - although vm 2025 certainly uncomplicates them again if so. [1] https://wiki.secondlife.com/wiki/Limits#Communication https://wiki.secondlife.com/wiki/LlGetNotecardLine https://wiki.secondlife.com/wiki/LlHTTPRequest https://wiki.secondlife.com/wiki/LlEmail ... etc ---- Also related- https://feedback.secondlife.com/scripting-features/p/functions-to-get-byte-count-of-a-notcard-line-as-well-as-total-bytes-used-availa

Proposal: llLinksetDataWritePublic( string name, string value, string password, integer perm_mask ) If password is an empty string, it does what llLinksetDataWrite does, plus setting a perm mask for that name. If password is not an empty string, it does what llLinksetDataWriteProtected does, plus setting a perm mask for that name. Perm mask can be a bitwise combination of: LINKSET_DATA_OWNER_READ: Allows scripts with the same owner to read. LINKSET_DATA_OWNER_WRITE: Allows scripts with the same owner to write LINKSET_DATA_GROUP_READ: Allows scripts with the same group to read. LINKSET_DATA_GROUP_WRITE: Allows scripts with the same group to write. LINKSET_DATA_PUBLIC_READ: Allows any script to read. LINKSET_DATA_PUBLIC_WRITE: Allows any script to write. The permissions are dropped on: Using llLinksetDataWrite / llLinksetDataWriteProtected on the same name (this fixes the issues of someone preloading an object with tons of public values). Deleting the key through llLinksetDataDelete... or llLinksetDataReset. To access the data from a different linkset, use: string llLinksetDataReadRemote(key uuid, string name, string password) integer llLinksetDataWriteRemote(key uuid, string name, string value, string password) These function exactly the same as the non-remote versions, except with a key specifying the prim to read from. ---- Why this? ---- If you're gonna work on a large scale project in SL you're likely going to have to keep some data synced across linksets. This can be anything from a game controller keeping list of player HUD UUIDs, or player metadata such as skill points, status effects such as "broken leg" etc that players and NPCs can react to. In order for linksets to acquire such data, you have a few options: A remote server / experience keys: These are relatively slow, and asynchronous, meaning you often have to rely on caching since you can't easily or frequently access the data. Listeners: These are faster, but requires some sort of syn/ack system, fallbacks (because listeners have a tendency to fail during lag spikes) and a lot of string parsing, eating up significant script time as you start adding more and more NPCs that all need to be kept updated. Descriptions: These are fast and synchronous, but limited to 127 characters and don't allow special characters. And the attachment would need to be either attached to a non-HUD slot, or you'd have to cache the HUD UUID somewhere. In which case you're back to square one. Being able to using public linkset data would have the following benefits: The data is synchronous. The data is never dropped because of lag spikes. The data doesn't require two-way communication. The data isn't limited to 127 characters and may use unicode. The data doesn't require your script to perform time-consuming string parsing since linkset data uses key/value pairs. Personally I'm mostly interested in the reading part, but I know some people have been asking for the ability to write, so I included it in the proposal.

Basically it does the same as putting a script with llSetRemoteScriptAccessPin in the object's on_rez Right now if you have a project that relies on updating scripts of rezzed objects, you'll need to make a script that sets the pin and requests an update via the llSay system. This makes said script a major failure point because llSay has a tendency of being dropped during lag spikes, forcing you to set up a syn/ack system. And if you later discover that your syn/ack system wasn't as robust as you thought, or want to change it in any way, you may potentially have hundreds of items that you need to manually rework. Being able to set the remote script access pin directly on rez would eliminate the need for a syn/ack system entirely. Because you could: Rez object with pin Remote load the script(s) immediately in object_rez Profit! Another added benefit of this system is that you could rez the object without the scripts that you intend to overwrite with remote loading, saving time rezzing the object.

The provisioned features and power of the game_control() event are impressive, and miles ahead of the support available to scripters for processing input events for standard keyboard+mouse usage. Currently there's no way to respond to other mouse buttons (scroll wheel, middle click, right click, shoulder buttons) and there are no vectors for user input aside from the standard movement keys. Thus if someone wants to make a game for users without a controller, they're limited to the interactivity of Quake 1, which is notable as being an aggressively minimalist design (shoot only, all doors open automatically) that was largely abandoned by other games. For SL to really work as a game environment, we need a way to bind a "use" key, or keys for reloading weapons, or for using special powers like a quick melee attack. I'd like to propose the following: - Adding 6 new mouse button bits to control(): scroll up, scroll down, mouse 2 (right), mouse 3 (middle), mouse 4 (shoulder 1), mouse 5 (shoulder 2) - Adding 4 new general-purpose control inputs to control(): action 1, action 2, action 3, action 4 - Adding the general-purpose action inputs to Preferences › Controls - Allow all control() bits to be mapped to controller buttons so vehicles without game_control() can be used with controllers and receive all the benefits of these new features — though this could/should be a feature request on its own The bitmasks for level and edge have plenty of room for these 10 new bits, so I don't think this is too crazy a request.