Scripting Features

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.

to allow flying or driving over or across edge of parcels without interruption, add a short delay to llEjectAgent() so that the shortest delay is a few seconds. What problems might this cause?

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/

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.

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/

This is a refiling of BUG-233175 I would like to propose a mechanism for users to modify and customize some of their agent's attributes including (but not necessarily limited to) the various movement speeds, jump height, and scale of the agent's physics shape. My initial thought is for a set of three functions: llSetAgentParams llGetAgentParams llResetAgentParams The setting of these agent parameters could behave similar to llSetAnimationOverride: where once an attribute is set, the customization will persist until explicitly overridden, reset, or the user logs off. Also like the animation override, this would require a new runtime permission: PERMISSION_CHANGE_AGENT_PARAMS Action: configure the overriding of default agent parameters Category: Agent Granter: Anyone Auto-granted when: Attached llSetAgentParams(list params) Sets the agent parameters specified in params. Survives script reset/removal, attachment removal, changing regions and teleporting - but not relog. Setting a zero/null/etc value is the same as resetting it to default. Invalid inputs cause the function to shout an error on DEBUG_CHANNEL. The function will still accept and act upon valid inputs that preceded the invalid one(similar to llSetPrimitiveParams). Requires new permission: PERMISSION_CHANGE_AGENT_PARAMS. [AGENT_WALK_SPEED, float speed] : Agent's walking speed [AGENT_RUN_SPEED, float speed] : Agent's running speed [AGENT_CRAWL_SPEED, float speed] : Agent's crouch-walking speed [AGENT_TURN_SPEED, float speed] : Agent's turning speed [AGENT_FLY_SPEED, float speed] : Agent's horizontal flight speed [AGENT_FLY_UP_SPEED, float speed] : Agent's hover-up speed [AGENT_FLY_DOWN_SPEED, float speed] : Agent's hover-down speed [AGENT_JUMP_SPEED, float speed] : Speed at which agent achieves apex of jump height [AGENT_JUMP_HEIGHT, float height] : Agent's vertical jump height [AGENT_STAND_PHYSICS_SIZE, vector size] : Scale applied agent's standing physics shape [AGENT_SIT_PHYSICS_SIZE, vector size] : Scale applied to agent's sitting physics shape [AGENT_GROUND_SIT_PHYSICS_SIZE, vector size] : Scale applied to agent's ground-sitting (ALT+Shift+S) physics shape Min/Max values up for discussion. I imagine minimum size would mimic prims; no single dimension being smaller than 0.010 meters. list llGetAgentParams([list params]) Essentially same as llGetPrimitiveParams. Only accepts the AGENT_* flags as listed above. Requires PERMISSION_CHANGE_AGENT_PARAMS. llResetAgentParams([params]) Reverts specified parameters back to their system defaults. Only accepts the AGENT_* flags as listed above. Additional param: AGENT_ALL_PARAMS as a shortcut to reset all (or alternatively: supplying an empty list?). Requires PERMISSION_CHANGE_AGENT_PARAMS. Since llSetAgentParams and the persistence of its effects are modeled after the llSetAnimationOverride functions, it would have similar (if not higher) potentials for abuse, given the fact that these would go beyond cosmetic changes and could impact user navigation throughout SL. For that reason, I also suggest some additional viewer/server components to go alongside with this feature as defined below. If there is still concern, perhaps adding a throttle to how many times attributes can successfully be changed in a given time frame (in which case having the set function return a status integer would be warranted). Or perhaps removing the auto-granting of the permission on attach - though Experiences should still function as normal. Additional viewer support functionality: A UI toast/popup that appears whenever an agent parameter is changed, similar to the ones that show whenever the avatar complexity changes. At minimum, this popup should have a clickable link to a knowledge base article that explains this feature - and most importantly, how to reset it. This toast/popup can also be disabled by the user in Preferences > Notifications. A new menu item " Avatar > Reset agent " to immediately reset all agent params and revoke PERMISSION_CHANGE_AGENT_PARAMS to any unattached objects in the same region (similar to " Avatar > Stop animations "). Also, a " Develop > Render Metadata > Agent Physics Shapes " would be useful for users to visualize the altered (and default) agent physics shapes. Additional land support functionality: A new land option which could disallow changing agent params and/or ignore custom params and only use agent defaults while within the parcel/region (similar to no-fly zones). This would be beneficial to established games which rely on using the agent's default attributes and would consider alterations cheating (similar to the prohibiting of user made movement enhancers). Also consider letting experiences still perform such overrides over allowed land. Justification moved to comments due to 5k character limit...

A new function, llAttachToAvatarTempFromInventory(integer AttachmentPoint, string ItemName) , that allows an already attached object to temporarily attach items from that object's inventory without triggering a permission prompt. Use Case: Currently, HUDs and wearable objects must pre-attach all possible assets or rely on cumbersome rezzing workarounds to swap out attachments dynamically. This leads to performance issues due to high prim counts and complexity. A smoother system would be beneficial for: Modular HUDs: Hide/show different components without inflating linksets. Helps with keeping resources low when the main hud is worn at all time. Handheld Items: A backpack could let a user select and equip objects (e.g., food, tools, toys) seamlessly. App-Based Wearables: A "smartphone" HUD could swap out apps dynamically without needing excessive link changes or manual updates. Why It’s Needed: Better UX: No unnecessary permission pop-ups for already attached objects. More Flexibility: Allows seamless temporary attachments without excessive preloading. Performance Gains: Reduces linkset size and avoids multiple workarounds. Proposed Behavior: If the calling object is already attached, it can attach another item from the object's inventory without requiring a permission prompt. If the calling object is not attached, it must request attachment permissions as usual. If the user sits on an object, it must still ask for attachment permissions, following existing conventions. This function would streamline many workflows and enhance interactivity in Second Life while respecting user control.

Ability to teleport a vehicle like a sim crossing, but to arbitrary grid coordinates. Something Like llTeleportVehicleGlobalCoords(vector global_coordinates, vector region_coordinates, rotation direction ); Should either obey the current allow object entry or a new parcel setting "Allow Remote Object Entry"? . Object should be returned to inventory if the parcel teleported to is set to no entry. Possibly only available if object has a seated avatar? Don't really need teleporting objects. This would probably need to be an experience function. But this could lead to heavy fragmentation and incompatible portals. Seeing as gridwide experiences aren't real, and a script in a vehicle would need to have the correct experience for the land its one etc.... Leave behind avatars that have not accepted the experience? A script could give users that haven't accepted the experience a map link to follow along after.. Mostly this would allow for road tunnels for vehicles to other places, spreading the SL road network and increasing connectivity.

Add a new function LSL function named llRenderText or similar, which allows users to dynamically render text, with limited but flexible formatting, onto the face of their choosing. Concept: // Signature llRenderText(integer face, string text, list params); // Basic example llRenderText(ALL_FACES, "Lorem ipsum...", [ FONT_ALIGN, "right", FONT_WEIGHT, "bold", FONT_FAMILY, "sans serif" ]); Rationale Text is ubiquitous, yet Second Life has no way for users to display text other than uploading a texture, setting floating text using llSetText , or using relatively resource intensive solution such as XyText/Furware/et al. This absence precludes interesting features, such as being able to create a responsive interactive terminal in Second Life, HUDs with dynamic text, etc. A scripted and efficient text solution that displays on the face of a prim/mesh would give Second Life the biggest bang for the buck: Limited in scope (easier to implement than grand UI-creation ideas) Easy to kitbash into existing and new creations For inspiration, you can look to how the Text Display widget is implemented in the Playstation game Dreams. It has limited options: a finite number of fonts and formatting options, but the fact that it can be combined with other content makes it rather powerful. Other details Font color, opacity, glow, etc are controlled by prim properties (Example: setting face color to red sets font color to red) Questions Should the background always be transparent? Creators could put another prim behind the text display face to give it a background, or it could be a property of the render params. Possible Parameters FONT_WEIGHT FONT_STYLE FONT_FAMILY FONT_VERTICAL_ALIGN FONT_HORIZONTAL_ALIGN FONT_TEXT_WRAP FONT_LINE_HEIGHT FONT_SIZE Possible Features Markdown / rich text

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" }