Scripting Features

  • Search existing ideas before submitting
  • Use support.secondlife.com for customer support issues
  • Keep posts on-topic
Thank you for your ideas!
Request: Region List API
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.
3
·
tracked
Combat 2.1 Teams
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/
10
·
tracked
New LSL llAnimeshEnabled(integer enabled); Toggle Animesh Property on/off
New LSL function that allows scripts to toggle an object’s Animesh property state at runtime. llAnimeshEnabled(integer enabled); ## Overview Currently, enabling Animesh on an object significantly increases its land impact, even when the object is idle. In contrast, a comparable non-Animesh object—especially one with well-optimized geometry and materials—can often remain at a land impact of 1. At the same time, Animesh animation itself is already fully script-driven. Functions like: llStartObjectAnimation(string anim) llStopObjectAnimation(string anim) llGetObjectAnimationNames() allow scripts to control animation playback dynamically. However, these functions only operate after an object is already in an Animesh-enabled state. This creates a structural limitation: creators can control what an object does, but not whether it needs to be Animesh at all at a given moment. ## How Animesh Currently Works Animesh objects function by associating a skeleton with a rigged mesh linkset. When a script plays an animation, the skeleton drives deformation of the mesh. Importantly: An object does nothing by default when set to Animesh Animations must be explicitly triggered via script The visual position of the mesh is driven by the skeleton and active animations, not strictly the object’s base transform This means Animesh is fundamentally an on-demand animation system , but it is currently forced to be always enabled at the object level , regardless of whether animations are playing. ## Problem There is currently no way to: Disable Animesh when no animations are running Return an object to a low land impact idle state Dynamically enable Animesh only when animation is required As a result, creators must choose between: Keeping Animesh permanently enabled (high land impact, unnecessary overhead) Building complex systems involving object swapping, rez/re-rez logic, or duplicate assets ## Use Case There is a strong need for objects that can dynamically transition between static and animated states. For example: A robot or pet that remains dormant until activated Creatures that only animate when a user is nearby Props that “wake up” briefly to perform an action Environmental elements that animate only during interaction In all of these cases, the object does not need continuous skeletal evaluation. ## Expected Behavior enabled = TRUE - Enables Animesh on the object - Allows use of llStartObjectAnimation and related functions enabled = FALSE - Disables Animesh - Stops all active animations - Returns the object to static mesh behavior - Restores lower land impact where applicable ## Benefits Land Impact Optimization Objects only incur Animesh cost when actively animating Performance Efficiency Reduces unnecessary skeletal evaluation on idle objects Cleaner Content Architecture Eliminates the need for duplicate objects or rez-based workarounds Better Alignment with Existing API Design Complements existing animation control functions by adding missing state control ## Additional Considerations State transitions should preserve: - Object transform - Linkset integrity - Script execution state Simulator safeguards may be needed: - Throttling or cooldown on toggling - Permissions checks to prevent abuse Documentation should clarify: - Effects on physics and collision - Bounding box changes - Interaction with pathfinding and attachments
2
·
tracked
Load More