Scripting Features

Proposal Originally proposed on the Jira Allow non owners to receive HTML content. In responses from llHTTPResponse with llSetContentType(id, CONTENT_TYPE_HTML) Currently the restrictions are: (per the wiki) - the web browser is the Second Life client - the user (logged into the SL client viewing the page) is the owner of the object. - the user (logged into the SL client viewing the page) is connected to the region the object is located in I would propose relaxing at least the 2nd, "owner of the object" restriction. Reasoning The current restriction encourages the hosting of content external to sl, resulting in a form of "link rot" over time, leading to ever more broken scripts and objects as users forget/actively take down those external services. Removing it would allow prims to actually host their own pages when needed, in a simpler manner. There are already a few ways (but cumbersome) to circumvent it, so it is already ineffective. There has also been talk of serving content for HTTP requests directly from notecards at SUG meetings, this would compliment that massively. Concerns This should have no impact on either, security or privacy for SL users, as I mentioned above there is already a workaround for this, and the prim could just load an external site that can capture any data far better anyway. User privacy is primarily controlled client side with the decision on whether or not to load the page in the first place (be it via media being disabled, whitelists, or other settings). Additional The 1st and 3rd restrictions could also be lifted, but that is debatable, depending on how LL feels about prims being used to directly host content for use external to SL. I personally would like to make things like control panels etc for user to work with, and instead of having to upload complex meshes and moved things around with scripts a simple html ui would be perfect... but right now you have to bypass this restriction for that.

Per https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/ This is putting the respawns part of what Rider had drafted up as a proposal into a feedback. The Teams portion of the draft is available at: https://feedback.secondlife.com/scripting-features/p/combat-21-teams Respawns builds upon Teams. Adding additional mechanisms to support reliable server-side respawns. That means that Teams can be built as a feature first and Respawns can be considered and built in after. Respawns have a current viable workaround with Experience but Teams are a more fundamental issue that all of SL can benefit from beyond SLMC but also Games and RP sims. --- Currently respawns can only be done through Experiences. Setting the DEATH_ACTION to disable server-side checks and teleportation. Instead upon avatar death, an experience manages via scripts the teleportation to a respawn. But as shown in the Teams proposal, there are many difficulties around identification, checks and logistics. For reference the current implementations either work via Combat Log, observing DEATH events to then teleport an individual to respawn. Or via temp attachment HUDs that rely on on_death to then trigger a teleport to respawn. --- So I would like to see Rider's implementation of Respawns. Which builds upon Teams to enhance it further. See the thread for more details: https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/

Together with https://feedback.secondlife.com/scripting-features/p/offset-position-for-particlesystem we could add particle systems to rigged mesh that follow a certain attachment point instead of the root. Like: PSYS_PART_ATTACHMENT_POINT, point_id Since rigged mesh follows the bones as they are animated, a particle system can not be made to stay in sync with the attachment. This proposal would make that possible.

The way it is now, reading the PBR properties of a face using llGetPrimitiveParams() with the PRIM_GLTF_X flags will only return parameters that are overrides of the underlying material asset. In other words, it is impossible to read all PBR texture parameters via scripts. This is a severe restriction, and one that appears to be more severe than what applies to Blinn-Phong textures. Being able to get and set all texture parameters is very useful in a number of contexts. This is unfortunately made very difficult if not impossible in the current model. We need way of accessing all parameters of PBR materials applied to a surface, not just the overrides. While it may be necessary to impose permission-based limitations, at a minimum it should be possible to do this on objects that the user has modify permissions on. PS: It's not always obvious what constitutes an "override." For example, all that is needed to create an override of the Tint parameter is to click the color swatch and then immediately close the color selection dialog without clicking a color -- any color, even the currently selected one. The tint clearly doesn't change, yet the parameter is now an override.

llSetParcelForSale() should use a dedicated permission and not piggyback off of PERMISSION_SILENT_ESTATE_MANAGEMENT. The permissions dialog needs to make it very clear that permission to resale land is being requested. Currently, the only thing a user will see in the perms request is "Suppress alerts when managing estate access lists". This has nothing to do with selling their land. Yes, this will have to wait on a viewer update, but that is what is takes to have clarity and offer peace of mind.

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.

Per https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/ This is putting the teams part of what Rider had drafted up as a proposal into a feedback. --- Right now it is very difficult to clearly identify combatants except for using groups which is a hassle. It requires someone to join a group, set it as active, etc. Or systems that implement Teams via scripts like the Combat2 DevKit can be cumbersome and hard to maintain. Requiring the hacky group checks, a lot of listeners and messages for anything that cares about team assignment, such as a restricted door, a forcefield, a claymore that checks friendlies or enemies in a sensor. And if group checks are used then you need to distribute and update all the scripts involved if something changes. A military has an extra group? Update the entire armory. Want to play with 3 or 4 teams against eachother? Update all the scripted objects deployed in the battlefield, sometimes across multiple sims. Even the Pew Pew combat 2.0 party we had with the lindens showed the issues greatly affecting the event, as the feature was rushed out and it wasn't possible from a lot of strangers in many different groups as to who which team they were fighting for. Experience based respawn systems also need to manage identification, to know where to put someone. We had an issue where a group wanted to have an internal fight, people had to change their active group, ... which then led to problems because army-specific equipment can have required group identification that ties it to the active group as authorisation, we resolved that (since we had a militia group that it allowed usage with) thankfully but it showed the cracks in the system from lacking a fundamental system. --- So I would like to see Rider's implementation of Teams. Which allows some predefined teams to be configured (8 but hopefully up to 12-16 personally). See the thread for more details: https://community.secondlife.com/forums/topic/516319-combat-21-teams-respawn/

As a high-performant and modern alternative to the llHTTPRequest and llRequestURL , (web)sockets would be a great addition. It will allow objects and HUD elements to have direct bi-directional communication with back-end server software. The same can be achieved with the existing HTTP methods, but it requires a lot of effort to implement. The (web)sockets would have to be proxied through the Linden Labs servers just like the HTTP requests to avoid the leaking of IP addresses. If websockets are to be used, the benefit of HTTPS certificates exist for a secure connection. I am not requesting (web)sockets in the script to act as a server like llRequestURL , but for the script to always be the client to an external server (though feel free to implement that as well!). The functions could look like: key llSocketOpen( string url /*, Other options... */ ); llSocketSend( key id, string data ); // llSocketSend does not need a 'key' to return; packets identify themselves llSocketClose( key id ); The events could look like: socket_receive( key id, string body ) {} socket_close( key id, integer code ) {} // Code would follow the standard, but code '0' could be "closed by own script". There could be events for when the socket is opened or errors, too. In that case the llSocketOpen function can be non-blocking. Example code: key handler; default { state_entry() { handler = llSocketOpen( "wss://example.com:8081" ); llSocketSend( handler, "Hello world!" ); } socket_receive( key id, string body ) { if( id == handler ) { llSocketClose( id ); } } socket_close( key id, int code ) { if( id == handler ) { if( code == 0 ) { llSay( 0, "The socket was closed by us!" ); } elseif( code > 0 && code <= 99 ) { llSay( 0, "The socket was closed by the Linden proxy with code: "+ (string)code ); } else { llSay( 0, "the socket was closed by the remote server with code: "+ (string)code ); } } } }

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.

As someone who has been scripting in SL for a long time and made many work arounds to deal with rez distance limits and now that I'm working on a region-scale game I'm trying to work on a feature where I can do a "level change" for the entire region by using llDerezObject to remove unscripted objects and swap it out with a new level by rezzing it in, then it occurred to me that the rez distance limits don't really make much sense or are way too strict. At least for parcel owners, people making experiences or tools we are left with setting up messaging systems to reposition rezzed objects to their intended destination. In my case I want to do a complete level change of an entire region by rezzing unscripted objects in place and manage their lifetime via llDerezObject. That's my current primary usecase. But in the past I've made tools, HUDs and other things that could have benefitted from unscripted unlimited rez distance rezzing with llDerezObject control. For example a HUD that renders markers and icons, for others to see as well, which would have eliminated hundreds of scripts having to be instantiated and listening for commands. Could you please reconsider removing or increasing the rez distance limits? If there are legacy compat concerns this change could be made only against llROWP which is still relatively brand new and unlikely to create problems. Ideally as an experience tools scripter and region owner I should be able not to have any rez distance limits. There's really no point. Likewise I might not want to impose rez distance limits on visitors either. As devils advocate I could potentially for the distance limit to exist for mainland for attachments on avatars, I do admit I feel wary about that. But on the other hand a consistent removal of the limit would be great to see for innovation along with a message in encouraging the use of llDerezObject to manage rezzed objects.