Scripting Features

I'd the ability within LSL, possibly tied to a runtime permission, to be able to adjust the following parcel settings. This would be for moderation, estate management, and event management. Parcel name (string) Parcel description (string) Parcel sale (integer price, key buyer, integer sell_objects_with_land - NULL_KEY for anyone can buy, negative price (or const) to set not for sale. Should always be possible for an object running with estate manager permission, tying this to its own runtime permission for safety would probably be wise) Everyone can: Edit terrain, fly, build, object entry, scripts Group can: build, object entry, scripts Safe (damage) Pushing Show in search (+ category) Adult content Avatars on other parcels can see and chat with avatars on this parcel Landing point (quaternion (x,y,z,rotation) - have const values for blocked TP and anywhere) Snapshot (key texture_id - NULL_KEY for default/unset) Abandon land (Possibly its own runtime permission for safety, should always succeed if owned by an estate manager) Locking these adjustments behind estate manager permissions would be acceptable but not ideal only if absolutely necessary, also completely acceptable would be a reasonable script sleep penalty to prevent unfair use of server resources or abuse. Being able to specify the position or the parcel UUID to act upon for this would be nice to allow for the efficient management of estate regions and large event spaces, possibly with a const to reference the parcel the object resides in currently for convenience in non-centrally managed applications. Any changes that are not authorized would fail and result in an error. This would greatly reduce the reliance on bots / scripted agents which are currently used to accomplish these tasks. Allowing these tasks to be completed totally on-platform would simplify event/venue and estate management dramatically and reduce the load on servers by eliminating the need for bots to idle around waiting to handle these management tasks as needed.

I'd like an LSL function to find out whether a teleport would land at the intended destination. Currently if the destination is in another region, the only way to know if the avatar will arrive at the target is to teleport them and find out. I would like to check the destination first, so i dont need to start a teleport that won't arrive at the target. For example, if i wanted to teleport an avatar to another sim at <128, 128, 3020> there's no way to know if they'd actually land at that point or 3000m away on a ground landing point, or if they can't teleport into that parcel at all. The proposed function would send the avatar id and group and target position, and the remote sim would return a vector back indicating where the avatar would land. This would either be at the target destination, at the parcel's landing point, or zero_vector if they dont have permission to enter the target parcel. This would mean a teleport script can check the target first, and not teleport the avatar if they will end up far from the intended destination.

llGetUnixTime() , because of LSL integer type limitation, can return only 32 bits of epoch seconds. This means that around 19 January 2038, scripts that rely on counting the delta between two unix times will likely fail to function. Some workarounds are possible, but requires a lot of code to implement. Short of introducing a new type, integer64 , a (probably) much simpler workaround is to implement the following 2 functions: list llGetUnixTime2() returns a list whose first member is the higher-order 32 bits of a 64-bit unix epoch, while the second member is the lower-order 32-bits of the same unix epoch. The latter part is a bit tricky because it should be unsigned, so manual arithmetic might be a bit complex; hence, a second function: integer llDiffUnixTime2(list unixtime_a, list unixtime_b) given two list constructs as returned by llGetUnixTime2() , the function returns the number of seconds difference according to the rule of a - b . Alternatively, encode the 64-bit unix time into string using Base64. And introduce the functions string llGetUnixTimeB64() and integer llDiffUnixTimeB64(string a, string b) . This might use less memory because list is a complex structure that requires more memory than a string .

Add the ability to receive input from game controllers such as joysticks, Xbox controllers, etc. This will allow the creation ofhHelicopters and planes that use analog input from console controllers, attachments that control drones, arcade games, cranes, machinima puppetry, etc. This new feature will be implemented by adding a LSL event game_control(...) which script authors can use to capture and respond to input from users. For further details, see https://wiki.secondlife.com/wiki/Game_control

key llGetRegionWorldMapTile(string region_name) A LSL function to return the UUID of the current world map tile for a named region, so that it might be placed on a face using PRIM_TEXTURE. This could also be added to llRequestSimulatorData Currently the only ways I know to accomplish this depend on MOAP and voodoo to get an image from slurl.com , or pulling the CDN UUID from gridsurvey.com via a HTTPRequest. Which all seems pretty hacky and unfun.

I'd like to suggest a per avatar data store for experiences. The agent data store would belong to each agent, but would be used by experience scripts to store agent data. The data would only be accessible to scripts in objects owned by the avatar and in the same experience. For example, an attached experience HUD or weapon. Other scripts would only be able to access the data indirectly via a script that has access. This would make experience data more scalable. The avatar's data would only be accessible if the avatar visits the experience. The experience data store wouldnt grow if more people join. For grid wide experiences, any avatar data could go in the avatar data store. It could make per agent data more secure. For example, you could store visitor tracking info or scores so only the avatar concerned can access their data. Personal data wouldnt be accessible to anyone who can read the experience data store. If an avatar left the experience the agent data could be automatically deleted from their data store. There would be new functions similar to the existing experience data functions: llCreateKeyValueAgent llDeleteKeyValueAgent llReadKeyValueAgent llUpdateKeyValueAgent llKeysKeyValueAgent llKeyCountKeyValueAgent llDataSizeKeyValueAgent This shouldnt increase data storage overall, as the data would otherwise be in the experience data store. There can be a limit to how much data an experience can use, it doesnt have to be a whole notecard's worth.

Linkset data is amazing for persistent storage and sending data between scripts. Having a set of data for avatars would be great too. It would enable synchronizing settings between multiple items of the same brand a lot easier. Storing shared settings, for example access block lists for interactive attachments. Or storing settings data when before swapping to a redelivered version of the same item, that can then read it. Sending password protected data between HUDs and other attachments, instead of using chat channels. I’m sure scripters would fine plenty of uses for something like this. Functionally it should have all the features of the LinkSetData, with some differences: • No equivalent for LlLinksetDataReset, as we wouldn’t want one brand’s items destroy other brand’s item’s data. • Larger storage than 128k, as there can’t be 30k avatars in a sim, compared to regular prims, more storage shouldn’t be a problem, I’d say 1mb or more sounds reasonable starting point. • Equivalent of https://feedback.secondlife.com/scripting-features/p/edit-linksetdata-from-inside-the-viewer would be a must, with a reset all button for the viewer. We wouldn’t want a broken item filling in someone’s whole storage, so ability for the Residents to clear all data or just select data would be required. • Maybe add a permission request before item can Write/Delete AvatarData, no read permission, or auto-grant read on attach. Again, since it is permanent storage on avatar, we wouldn’t want it to be corrupted by a broken script. • In terms of documentation there should be caveats pointed out that the data can be reset at any time by the Residents and that it should not be used for storing any license key or authorization type data. • Should have a listener functionality (similar to chat listen) for specific key changes instead of an equivalent of linkset_data event, as we wouldn’t want to trigger loads of scripts on many different attachments with each change.

I'm posting this here since my original post as a bug was closed with an "expected behavior"-type reply. As referred to by the discussion mentioned in the LSL portal documentation for llGetLinkPrimitiveParams() ( https://community.secondlife.com/forums/topic/486118-only-set-ambiance-on-prim_projector/?_gl=11wd89ez_ga_T7G7P6DCEC*MTcwNjU2MzkwNS4xLjEuMTcwNjU2MzkwNy41OC4wLjA.#comment-2446570 ) the call with PRIM_PROJECTOR currently triggers shouting on the DEBUG_CHANNEL about an unsupported parameter. I understand that PRIM_PROJECTOR is considered, for now, as write only, but I see no valid reason why it could not be readable at all. The current situation is inconsistent in my opinion. While I understand the potential problem with texture rights, I believe the behavior of this parameter should be consistent with that of PRIM_TEXTURE: if the texture is in the prim's inventory, return its name, else if the owner has full permissions over the object return its UUID. Otherwise return NULL_KEY. This is important to be able to "copy" a user-set parameter from one object to another for example, I want to read the parameters and send them to another object. Please make PRIM_PROJECTOR behave just like PRIM_TEXTURE in this regard, as described in the discussion. Thanks!

The existing mono memory cap of 64kb per script is based on simulator hardware that is no longer in use. The 64k limit is regularly subject to workarounds by use of 'slave' scripts to hold on to memory, at excessive cost to performance, from having multiple scripts doing the job of one, resulting in a net loss of performance versus a single script with increased memory. Is there any possibility that this could be increased, even slightly?

With the introduction of PBR and new features in SL the The 64k memory limit is becoming increasingly hard to work with and not suitable for modern designs. When designing more feature intensive HUDS its hard not to keep running out of memory, suggestion to double or increase the limit would be very much welcome for 2024.