Lindens Rider Linden Posted August 27 Lindens Posted August 27 (edited) This proposal has been locked in favor of this proposal: I Combat 2 Team Respawning As I mentioned in SLUG on Tuesday, this is a proposal and I'm looking for comments. One of the features that did not make it into the first cut of Combat2 was team based spawning locations. A way to teleport players on their death back to the base. These functions would allow a script to assign a spawn location to a player based on whatever criteria is desired. On death, the player would be teleported to that location. If no spawn location is set the behavior will revert to whatever death behavior is set for the region. In order to prevent someone from wearing a script that would set their respawn location to where they are standing once every second, land managers may restrict which scripts may set a spawn location. Once set the respawn location will persist with avatar until they either enter a non-combat region or they sign out of second life. (*A quick note on phrasing. I like to write proposals as though the feature is already done, it makes turning the proposal into actual documentation much easier... In other words none of this work has been started yet and is open to change.) Proposal Combat2 must support multiple respawn locations for team based play. To facilitate this, the following new functions have been added to LSL. llSetRespawnLocation(vector position, rotation facing) llSetRespawnLandmark(string inventory_name) llClearRespawn() llHasRespawnSet(key agent_id) When death occurs, if a respawn location has been set the agent will be teleported to the specified location. If no respawn location is set, the region's default death behavior applies (for instance teleport home, or teleport to telehub) The agent's respawn point survives region crossing and death teleports, but is cleared when the agent makes an inter-region teleport or logs out of Second Life. There is also a new region setting. allow_open_spawn_point_set. If this value is true then any script running on the region may set an avatar's on death spawn point. If this value is false then only scripts owned by the land owner, or compiled as part of an experience running on the land may set the spawn point. This value defaults to true and may be changed from the region console by the land owner or an estate manager. Functions llSetRespawnLocation(vector position, rotation facing) Sets an agent's respawn point. If the agent's health drops to 0 the agent will be teleported to this location and be facing the indicated way. position The position in the region to teleport the agent. facing The direction the agent will be facing when they arrive at the spawn point. If the agent teleports outside of the region, the spawn point will be cleared. This function requires PERMISSION_TELEPORT which may be granted either through an Experience or through a call to llRequestPermissions llSetRespawnLandmark(string inventory_name) Sets an agent's respawn point to a particular landmark located in the inventory of the prim. inventory_name The name of a landmark in the prim's inventory. If the agent teleports outside of the region, the spawn point will be cleared. This function requires PERMISSION_TELEPORT which may be granted either through an Experience or through a call to llRequestPermissions If inventory_name does not specify a landmark an error is shouted to the debug channel. llClearRespawn() Removes any previously set spawn point on an avatar. llHasRespawnSet(key agent_id) Checks if an agent has a respawn point set. If they do this function returns TRUE, if there is no respawn point or the object is not an avatar in the same region this function returns FALSE Edited September 27 by Rider Linden Abandoned this proposal. 1 2
Quistess Alpha Posted August 28 Posted August 28 2 hours ago, Rider Linden said: There is also a new region setting. allow_open_spawn_point_set. If this value is true then any script running on the region may set an avatar's on death spawn point. If this value is false then only scripts owned by the land owner, or compiled as part of an experience running on the land may set the spawn point. This value defaults to true and may be changed from the region console by the land owner or an estate manager. I think 'false' would be a better default here, especially for mainland where landowners can't easily petition for a change on their region. That or possibly parcel-scope instead of region scope. 2 1
Nexii Malthus Posted August 28 Posted August 28 (edited) It would be great to be able to set respawns to follow an objects position and facing rotation llSetRespawnObject(key object_id) When a respawn occurs, the agent will be teleported directly above that prim as follows: position = prim position + (prim scale / prim rotation).z/2 + agent size.z/2 See: https://gist.github.com/Martin-Pitt/fd40476d1ef086d6051b273e6ac972d1 facing = prim rotation Or alternatively just simply at the prim position directly position = prim position, although would need to make sure the prim's physics doesn't get in the way. (Which is why I wanted to take into account the agent size) The prim could be part of a linkset btw, such as a deployment/respawn pad within a large structure or a moving vehicle that uses KFM. So this for example would allow usecases such as targetting spawn pads in a cargo elevator in a big structure, deployable spawn pads that attach to a surface, a passenger seat prim on a train's carriage that is slowly moving around the sim via llSetKeyframedMotion or a gunship hovering over the battlefield that carries droppods to act as respawn locations without having to frequently poll the location constantly and getting out of date quickly due to movements. There could be an issue if the object doesn't exist on that sim anymore, so perhaps llSetRespawnLocation could act as a fallback? EDIT: I realise my "above that prim" math is off, since prim scale would be just one of the corners, here is a script that calculates the top of the rotated bounding box: https://gist.github.com/Martin-Pitt/fd40476d1ef086d6051b273e6ac972d1 (effectively trying to put agent ontop of an axis -aligned bounding box / AABB) Additionally, setting respawn location to an object can be much more convenient and simple at times. As this means you can set the respawn location once and then just simply move the object, instead of having to suddenly go through about say ~30 agents and updating each one with the new respawn locations, it is easier to update the location of one, two or a few objects. Edited August 28 by Nexii Malthus 2
Lindens Rider Linden Posted August 29 Author Lindens Posted August 29 On 8/27/2024 at 8:34 PM, Nexii Malthus said: It would be great to be able to set respawns to follow an objects position and facing rotation llSetRespawnObject(key object_id) I had considered allowing the script to set the respawn to an object, or in some way flagging a prim as a respawn controller. The issue is that this is meant to work between regions and targeting objects in that way across regions is not generally possible.
Lindens Rider Linden Posted August 29 Author Lindens Posted August 29 On 8/27/2024 at 6:50 PM, Quistess Alpha said: I think 'false' would be a better default here, especially for mainland where landowners can't easily petition for a change on their region. That or possibly parcel-scope instead of region scope. I actually have plans to parcel scope most of the combat regions in the future. 1
Quistess Alpha Posted August 29 Posted August 29 5 minutes ago, Rider Linden said: The issue is that this is meant to work between regions On 8/27/2024 at 7:00 PM, Rider Linden said: llSetRespawnLocation(vector position, rotation facing) perhaps add a region name parameter? World vectors would also work, but they're a bit annoying to use. Triggering a HTTPRequest on death that expects a position to respawn at might be a bit overkill, and not especially idiomatic for LSL. But it would be cross-region compatible.
Tactical UwU Posted August 31 Posted August 31 I had achieved similar functionality using an experience but being able to do this natively will be a huge boon. My only concern is being able to audit or restrict who can use this function and where it is allowed to be executed as it takes away agency from region administration.
Nexii Malthus Posted August 31 Posted August 31 On 8/29/2024 at 5:12 PM, Rider Linden said: I had considered allowing the script to set the respawn to an object, or in some way flagging a prim as a respawn controller. The issue is that this is meant to work between regions and targeting objects in that way across regions is not generally possible. Hmm, it's still a very, very valuable function to have regardless even with the caveat it doesn't work across regions. I still think that this should be implemented with the caveat. Is there no way to make it work across regions? Guess it's a pain, assume it has to do with teleporting to regions requiring a given predefined vector location as a parameter and having to add in a mechanism for teleports which can target a UUID key instead might be annoying — but honestly also sounds kinda neat in a general sense? Targetting UUID keys would be more precise and flexible. Would it be possible to add UUID keys as optional teleport parameters for locations to the protocol? The vector location could still be required as a fallback, but if the UUID key exists then to rez the agent at that object. Anyways, llSetRespawnObject with caveat that it doesn't work on region crossings would be fine.
Nexii Malthus Posted September 10 Posted September 10 Would be good to have a status update on this as I'm working on respawn systems atm
Lindens Rider Linden Posted September 27 Author Lindens Posted September 27 After the feedback I've gotten so far, I've decided to abandon this proposal as written. Instead please see the linked post and let's move the conversation there. @Nexii Malthus (I'm also going to be locking this thread)
Recommended Posts
Please take a moment to consider if this thread is worth bumping.