Scripting Features

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/

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/

To clarify: Remove the throttle on the function, but not the settings which can be applied through the region debug options. Currently, there is a throttle of 10 positive values every 30 seconds. This limits the ability to efficiently use this function in environments where it requires multiple hits to defeat a single target unless using a node or rez-based system which increases the complexity and performance impact of items which are required to do so - ie. any weapon which can strike multiple times in a short window which is a very broad category. As a result, this throttle makes 'rezless weapons' nearly impossible due to hitting the throttle very quickly. For context, most automatic ranged weapons fire at 600 RPM, or 10 rounds per second. If said weapons took 3 hits to kill, it would hit the throttle after killing 3 avatars and within a timespan of a single second. Region settings are already in place to limit damage output of weapons, namely damage_limit and damage_throttle respectively, thus making this additional limitation redundant. These region settings also stop most common workarounds previously described making it more effective overall.

There is currently a lot of debate on how to improve driving, sailing, and flying experiences through mainland where those individuals may have to either deliberately or inadvertently find their way onto a privacy focused parcel during their recreational vehicular activities. The argument is currently focused around the preservation of privacy vs. the desire to not be sent home via teleport for a momentary and potentially unavoidable encroachment onto a private parcel. A solution that could serve both sides of this argument was proposed by omoMMomo Resident as a comment and expanded upon by me. Due to how this may actually solve both sides of the problem without causing either side to "lose" anything, I felt the proposal deserved it's own canny post to discuss and upvote as needed . Here is the original pitch within the comments: Original Proposal (with edits/updates) The ability to place a static volume (box, cylinder, sphere) tied to a list that separates the residents living there (listed) from the residents passing through (unlisted), as though two dimensions occupy the same space; similar to how private parcels do it except access will not be denied. It might be worth exploring if this is possible without having to modify the clients (viewers). Listed residents will not be disturbed because they cannot see/hear unlisted (and vise-versa) (including media). Unlisted residents can navigate through the property without hassle. hide objects (like cars, planes, boats) of residents that are unlisted from the listed ones.* disallow unlisted residents from interacting (touch, sit) with any prims within the volume.* prevent unlisted residents (on the same parcel) from IMing listed residents while inside the privacy area.* Like this, everyone can be happy. Those that want privacy get their privacy. Those that want to explore get to explore. Such a system could replace and obsolete existing systems for privacy (parcel rules, ban lines, llEjectAgent() , etc.), modernizing and simplifying the whole concept going forward . * - Edits to the original proposal. Expanded Proposal As was mentioned, I liked the idea of this proposal and added to it with my own thoughts on how an implementation might work: To expand on the original proposal, in the spirit of what the 'volume' or "prim" bordering suggests, perhaps we can utilize something similar to the EEP system that allows for different environments at different levels. Instead it would allow for different privacy permissions at different altitudes. Starting from 4096m, as that is the highest one can rez anything, every 'entry' that is added encompasses the space from the next highest entry down to the present entry, at which the new policy/privacy preference takes precedence (the reverse of the environment system). It could incentivize folks to use their land and space in new ways. Say someone wants to have a portion of their parcel be public, but wants a private space for just their friends. They set everything below 3000m public and then everything from 4096m - 3001m is private, subject to the limitations you suggested. I think that would be a win, and based upon the other logic within the original proposal, it would make the space from 4096-3001m still passable, but they couldn't interact with the individuals or objects inside of that space and vice versa. I did a small mock up of what that could look like. I also like this idea for the other fact that you could essentially do a 'block and derender' of someone through the land without listing them. They still get to pass through, but unless you've got radar or your mini-map up, you'd be none the wiser. Assumptions I want to make note that this change if made would have some assumptions around it: This would apply solely to mainland regions. Parcel Bans would still be effective for those that need them (for public parts of their space, for instance). Modifications may need to be made to parcel access lists to work more like estate access lists where they can accept both groups and people. This implementation would also go in line with changes to how llTeleportAgentHome() works within mainland, to help solve the original problem stated above. Thank you for taking the time to read this proposal.

Currently, light sources utilizing a Projector Texture casts the texture "correctly" when observing the surface of whatever the light is cast upon. However, if you also have the same texture on the object face of for example a TV screen casting light into a room, the projected texture appears _wrongly_mirrored_ compared to the texture itself on the screen. The current workaround is to mirror the texture/image _before_ uploading and then flip the Horizontal scale of the texture face it is applied to on the object. Current Flag Parameters are as follows: [ PRIM_PROJECTOR, string texture, float fov, float focus, float ambiance ] My Suggestion -- Add the params "integer boolean" (TRUE or FALSE to set horizontal scale of the projector texture to 1 or -1 to mirror it) and "float rotation_in_radians" (just in case the object's rotation is not aligned with the projector's native emission direction) as follows: [ PRIM_PROJECTOR, string texture, integer boolean, float rotation_in_radians, float fov, float focus, float ambiance ] The only use case I can think of that this solves a problem for is TV displays casting their applied texture as a light without having to mirror the texture manually before uploading, but there are likely other uses this can be helpful for. Thank you.

Please consider adding an endpoint to the map API for fetching data useful for navigating the grid. This data would be readily available map information. At the present, this is a very, very strange task to accomplish. We can pound LL's servers using this API: https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=region&grid_x=1000&grid_y=1000 And scanning every possible range of coordinates we think is useful. Or We can use a bot on a custom viewer, making MapBlockRequests until we've got the whole grid. Each of these really need an external service running, and hit your servers pretty hard--but it's all for information that you already have that would be valuable to us to use for scripted applications (eg for navigation HUDs, custom maps, games with distributed locations, exploration apps, touring pods) and also, just in general to know how our world is doing. Proposal: Two https endpoints to fetch paginated region info lists. First API endpont: region list by number. The order is determined by LL and is arbitrary, but is used for pagination. A script can ask for the first N regions, then another set of regions starting from N and so on. In this way, scripts can parse the region list without hitting the api server, sim, or script memory too hard Second API endpoint: region list by name. Similar to searching a word on the map and getting one or several regions that match the name. Responses are delivered as JSON, with each region'd details in an object of the following form: { { "name" : "Da Boom", "coordinate" : "<1000.0, 1000.0, 0.0>", "estate_name" : "mainland", "region_map_image" : "7963f194-82f9-23b3-3d89-c21f1bd0a8bc", "access_name":"Moderate" } } Example of using the first endpoint, the enumerated API: The endpoint can be called with a page number, and an optional maximum. For example, suppose we are permitted up to 25 list items in a single call: Example: Fetch default 25 items starting with the 437th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=437 Example: Fetch only 5 items starting with the 75th region in the rest api: https://cap.secondlife/com/cap/NUMERICAL_ENDPOINT?start=75&length=5 In this way, external services we write and LSL code in-world could reasonably work with the large list of region data in a way that doesn't flood the API (feel free to rate limit) and that permits us to work within script memory limits. Example of using the second endpoint, the named API: The endpoint is called with a search term, and returns one or more regions that have a name starting with the term. There should be a minimum character limit. Ecample: Fetch regions starting with the name "Da B" https://cap.secondlife/com/cap/NAME_ENDPOINT?search=Da%20B Summary: There are many standing requests for access to the map tile information, map region names, and map grid coordinates, all in separate feature requests. I propose this API mechanism to capture data you already have in a way that solves every request.

trying to get a script to talk to me, as llOwnerSay() didn't work tried regionsayto, also not working

This feature enhancement by itself or with touchM,touch_endM,touch_startM requested elsewhere would allow for simulated HUD or llDialog() like selections and interactions.

This feature request is for a llGetObjectDetails()-like function, but one that gets details for an object's face-based prim properties. Proposed syntax: list llGetObjectFaceDetails(key object_id, integer face_number, list params) Optionally, accepts the ALL_SIDES constant for face_number, which would return data for each face of the target object. Proposed first parameters: OBJECT_FACE_ALPHA - returns a float for alpha. OBJECT_FACE_GLTF_BASE_ALPHA - returns a float for GLTF base alpha. Collision and castray based applications have needed access to the alpha value of a prim face for some time now. Like with llGetObjectDetails(), the proposed function allows future expansion. If anyone has ideas on what additional constants should be included and why, feel free to comment.

I would like to interface with an external API via LSL, but it only responds with the content type of application/x-ndjson. The response data is actionable data that LSL is capable of processing, however as the content-type is not on the strict list of types that HTTP_ACCEPT permits, it returns status 415 "Unsupported or unknown Content-Type." The header from the API I want to use is Content-Type: application/x-ndjson; charset=utf-8 Sample return data { "id": "9mkQIvL8rnrn", "time": 1740453264, "expires": 1740496464, "event": "message", "topic": "demo", "message": "a demo message" } { "id": "uOim1bYhnisq", "time": 1740453267, "expires": 1740496467, "event": "message", "topic": "demo", "message": "a demo message" } { "id": "wFhpksR0U2Lc", "time": 1740453267, "expires": 1740496467, "event": "message", "topic": "demo", "message": "a demo message" }