Scripting Features

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.

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.

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 .

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.

Rationale We have sit targets to define where an avatar should sit on a linked object. But when standing up, it's always at that exact same position. This is awkward for things like vehicles where the user will unsit inside the vehicle instead of stepping out gracefully. This goes together with a possible unsit event as proposed here: https://feedback.secondlife.com/scripting-features/p/unsit-events Proposal Add a possibility to let us define the exact spot and rotation where the avatar will be positioned/moved to at the moment of unsitting.

Rather than having in built "freezes" in certain functions like object rez / ll email etc, which are trivially circumventable by "LINK_MESSAGE"ing another script in the same prim and having that other script swallow the delay (providing a 'burstable' limit on these calls) these could be better handled in slua by reworking how these delays are implemented - perhaps on a per prim or per script setting where these calls can be made at "no cost" up to some specific rate after which they stall or fail (for example the way HTTP requests can be performed - there is no function delay here but there is still an overall limit on HTTP requests) The work around of having often multiple 'worker' scripts that just listen for a link message then execute the call to llEmail / etc has always been a bodge, but also rather necessary one if you don't want your main server script to become unresponsive regularly, which is quite important for a simultaneous multi user server style script (e.g. providing a region wide service to all players, the main script here can not be stalled without noticable impact to the players and yet some of these functions with delays in are needed for operation). Made a longer post here https://community.secondlife.com/forums/topic/530018-of-functions-with-delays/ Since so much is changing in the lua implemented stuff we could use this opportunity to redefine or rework how these function delays work, /only/ for pure lua scripts compiled using the new lua mode, while legacy LSL to lua / LSL mono / LSL classic scripts can maintain their previous behaviour regarding delays. This would be great to avoid what is essentially a "gotcha" that new scripters sort of 'need to know' how to work around to have a performant system that needs to use these delayed calls, as well as avoiding the wasted overhead of multiple worker scripts with their overheads and the time wasted in link messaging (especially since all the worker scripts receive all link messages even though only one of them will take up the work) Would just be a great and rare opportunity to revisit a rather archaic piece of the scripting languages implementation that just doesn't really work as advertised anyway once you know of the bypass by offloading to worker scripts, not often breaking changes can be brought in to a new language checkpoint. If this isn't clear enough please let me know and I'll give some better examples or something but I assume this fairly trick is widely known.

I've spent about the last week updating some scripts to handle both PBR and Blinn-Phong updates simultaneously. The scripts work fine, but the current way you have to update PBR values - through llSetPrimitiveParams and the full list of values - is not ideal. In order to avoid overwriting your existing values with blank or incorrect data, you have to have a way to know and store your existing values, modify those values, and send the whole list back in. Adding in some llFunctions for PBR values, so you don't have to modify the entire parameter array to change one value, would make scripting PBR modifications much more pleasant to work with. If llFunctions are not feasible, a way to update individual values in the parameter arrays without data loss (e.g. being able to pass a blank string as a texture and have it skip the value instead of applying it) would be appreciated. I've compiled a list below of how I would personally pop each value out into a Set function (they would have matching Get functions, a la llGetColor and llSetColor): --- For PRIM_GLTF_BASE_COLOR: llSetGLTFBaseTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFBaseColor(vector color, integer face); llSetGLTFBaseAlphaMode(integer gltf_alpha_mode, integer face); llSetGLTFBaseAlpha(float alpha, integer face); llSetGLTFBaseAlphaMask(float alpha_mask_cutoff, integer face); llSetGLTFBaseDoubleSided(integer double_sided, integer face); --- For PRIM_GLTF_NORMAL (this really only has one function): llSetGLTFNormal(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); --- For PRIM_GLTF_METALLIC_ROUGHNESS: llSetGLTFMetalRoughTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFMetallicFactor(float metallic_factor, integer face); llSetGLTFRoughnessFactor(float roughness_factor, integer face); --- For PRIM_GLTF_EMISSIVE: llSetGLTFEmissiveTexture(string texture, vector repeats, vector offsets, float rotation_in_radians, integer face); llSetGLTFEmissiveTint(float emissive_tint, integer face);

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

When a script needs a resident to select another resident uuid it would be super cool to have a function that opens for [id] the Resident Chooser already used in the viewer's invite to group. This would be so much better than the llTexBox(id,"please enter avatar's UUID,channel); we often use Upon "select" the CSV of choosed residents uuid would be sent to[id] on [channel] optionally "close" could send NULL_KEY to[id] on [channel] Ideally it could also have flags to restrict to only 'near me' and/or 'friends' tabs This new function working like llDialog() and llTextBox()

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