Second Life Combat User Group: February 8th, 2024 summary

Credit: Rider Linden

The following notes were taken from the Thursday, February 8th, 2024 Combat User Group meeting (also referred to as the Combat Committee User Group or CCUG, an abbreviation also used by the Content Creation User Group, and which I’ll not be using in these summaries to reduce the risk of confusion between the two). They form a summary of the items discussed, and are not intended to be a full transcript.

Meeting Overview

  • The Combat User Group exists as a forum to discuss improvements to the Linden Lab Combat System or LLCS to better support combat in Second Life.
  • The meetings are the result of a proposal document on improving the native damage system in SL, written by Rider Linden, and which is the focus for both the meeting and any work arising from them.
  • These meetings are conducted (as a rule):
    • By Rider Linden, with the support of Kyle Linden.
    • On alternating Thursdays (rotating with the Content Creation User Group) at 13:00 SLT. Meeting dates are recorded in the Second Life Public Calendar.
    • Initially in text, although voice might be included in the future depending on feedback from those attending.
    • At this location.
  • Additional details are available via the SL wiki.

Proposal Responses

  • Rider’s proposal has received broadly favourable feedback, particularly the following:
    • The new region / parcel additions (Damage Limit, Regeneration Speed, consequence of death (e.g. teleport victim home as per current LLCS or to a telehub  / landing point or take no action).
    • The proposed new on_damage event (and notably the damage adjustment capability to account for intervening elements which may result in less severe damage being caused).
    • The new Region Combat Event Log (details still to be finalised).
  • The idea of having region / parcel controls that specifically relate to damage, spawn points, etc.,  were welcomed as they are seen as both allowing core combat elements to be more effectively curated and managed by those managing the region / parcel(s) where the combat is taking place, whilst the LSL events allow the maximum in flexibility for specific purposes.
    • This is seen as important, as it allows weapons creators to continue to choose how they wish to script the operation and capabilities of their weapons whilst allow combat operators precise what those weapons can do in terms of damage, etc.,  within their combat environments, rather than having to rely solely on the scripting within the weapon (or the combat system for which it has been developed).
  • Rider noted that:
    • Accessing and modifying the new region / parcel combat controls might be provided through llGetEnv.
    • The on_damage event is likely to be a difficult element of work, as it marks the first time an event only triggers after it has fired in all relevant scripts.

Comments and Requests

  • There as some difference in opinion in how much control should be exposed through the simulator, with some noting that implementing too many “combat rules” at the region / parcel level could prove counter-productive and restrictive if used to try to limit “cheating”, particularly given many  / most combat environments have staff well versed in dealing with those trying the cheat. The countering view, as noted above was that better control at the region / parcel level potentially removed reliance of combat meter systems and the need for weapons geared for those systems.
  • Request: make the health  / regeneration capabilities accessible to LSL for setting them, rather than being simulator-side additions (thus allowing for health  / recovery pick-ups or boosts).
    • This is something that Rider hadn’t considered for the first pass of improvements, and something he might consider adding.
  • Request: add a region setting (and / or Edit / Build floater option) to check and enable avatar invulnerability when an avatar is sitting on a object such as a tank or other armoured vehicle, to eliminate the need for additional extra hitboxes using volume detect.
    • Rider noted that the proposed on_damage event would allow for this by allowing a function to be called to distribute a defined amount of damage (e.g. none) to the vehicle sitters. This would not only neutralise damage being passed on for armoured vehicles, it could be used to increase the amount of damage passed on (e.g. as a result of the vehicle “exploding”).
    • He further noted that an upcoming feature (contained within the Hearts & Flowers simulator maintenance update to let a scripter set a flag on a seat to make the avatar non-collide, which will also play into this as well.
  • Request:  allow all the combat stuff to run even on non-damage land (but without TPing people home), to assist weapons / meter developers test their systems even if their in-world workspace is on a No Damage region.
    • This is unlikely to happen, as it opens the door to potential griefing within No Damage regions.
  • Request: allow alterations to avatar speed (e.g. limiting the avatar to walking pace if carrying a heavy / unwieldy weapon), perhaps linked to scripts in the item itself, tied to an experience.
    • Rider noted that avatar speed is something he would like to address at some point; however, it was left out of the current proposal so that it could remain focused on managing damage.
  • Request: allow manual / custom spawn points rather than teleporting the “dead” home  /forcing people to reset that Home Position so as to remain in the combat region.
    • It was pointed out the proposal already has this in the ability to set teleport hubs / landing points – although how this might be managed so that opposing combatants are sent only to their own side’s spawn point might be open to question, unless they are defined by specific group or similar.
    • As an alternative, the suggestion was made to allow a scripted “respawn” prim, which when touched by an avatar automatically set their spawn point it to wherever the prim is located (thus allowing opposing sides to have their own spawn points, which could then be easily relocated as required. This is something Rider indicated he would add to the proposal.
    • It was also suggested that “killed” avatars should have some form of animation triggered on dying, rather than simply being teleported to a spawn point; a) Rider pointed out this is possible in the proposal; b) the suggestion resulted in a slightly off-tangent discussion over how such animations should be implemented.
  • Request: block the use of Mouselook (unclear why) – forcing visual parameters on users is not a popular idea within LL, as it could potentially impact ease of access to the platform for some.
  • Request: allow llGetHealth(key id) for anyone in the region, so you aren’t wasting a charge on someone who’s already at full health. Rider agreed this would be a good addition.
  • Request: allow a damage fall-off for weapons )e.g. a pistol’s ability to inflict damage would drop off over distance more than that of a rifle, while a long-range weapon (sniper rifle, for example) should have very little drop-off over distance.
    • One idea for this has already been written-up in the forum thread for the proposal.
  •  Request: make the combat log readable in real-time via a chat channel, to help deal with issues around people trying to cheat or review disputes. This is actually Rider’s plan for implementing the log, as well as having it recorded.
  • Request: have to combat log automate some of the administration concerns (e.g. someone using a scripted means of “fast healing” or using a weapon that is inflicting unfair damage) and have it alert region / combat admins  and/or force a re-spawn for the offending avatar, rather than waiting for human intervention based on reading the log.
    • Rider felt this is better dealt with via specific scripting, as it would be very hard to determine if someone is actually “cheating” in an given situation. Plus scripting would allow greater use-case refinements than a simulator-side set of parameters.
  • Request: to have something like “llVisualizeRay”, which allows a scripter to define a ribbon particle that traces along raycasts from a raycast weapon as visual “projectiles”, so the weapon does not need to rez actual projectiles – Rider asked that this be submitted in a detailed Canny feature request.
  • There were various thread going on through the meeting discussing armour and armour systems (such as LBA), damage calculations, etc. However, these were primarily being attendees at the meeting, rather than comments or requests directed at Rider Linden for consideration, as so fall outside the scope of these notes.