Second Life Combat User Group: April 25th, 2024 summary

The following notes were taken from the Thursday, April 25th, 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 core idea is to provide additional events and capabilities which sit on top of LLCS to provide combat creators with better tools with which to create better combat systems for their specific scenarios.
• 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.

Work In Progress

• Rider is currently fishing up the regions settings for what happens on the “death” of a player in a combat scenario – what happens on death (teleport to spawn point, etc.), hit point regeneration, maximum DPS, options for writing to the combat log, etc.
• llGetEnv has been updated to allow all of the options to be read from a script (e.g. ALLOW_DAMAGE_ADJUST, RESTRICT_COMBAT_LOG, DEATH_ACTION (0 = Teleport home 1 = Teleport to parcel landing point. 2 = Teleport to region telehub. 3 = No action), etc.).
• At the time of the meeting, his hope was to have ta simulator version supporting all of this running on the Aditi combat test regions (Thermopylae and Gallipoli) by COB on Friday, April 26th.
• Rider is also working on a UI mock-up for the new combat options in the viewer, which will have to be vetted / changed / approved by the UI team.
• Also on his list of work are: OBJECT_HEALTH, SIT_FLAG_NO_DAMAGE, a UUID for the combat log, and some selective unthrottling for llDamage. Once these items are ready, he hopes the simulator code will be set for passing over to QA to poke at.

Comments and Requests

• A request was made for the new viewer region console settings for the above to be written-up, which will be done – although the variable names will be the same as the llGetEnv key names.
• It was asked if death_action could be made more flexible – making it possible for  more than one respawn point settable either by this mechanism or by some script intervention? for example, move to point A if in some designated group(s) and point B otherwise.
  • Rather than complicate the options, Rider’s plan has been to let the local combat HUD handle such requirements.
  • This led to the question: what happens if the region setting is something else (e.g. teleport to landing point) but HUD on_death teleports somewhere else? which one wins?
  • Rider’s view was that in such cases, the region setting would win, as the simulator has no idea as to what the HUD may try to do. Therefore, in such situation, Teleport to Telehub should be set, or (possibly) an Experience should be set, so as to enforce the HUD’s settings (although this was seen as both a lot of work for limited return, and off-putting to users who are put off by the Accept Experience dialogue box).
  • There is also the idea of sending people to different locations based on active group. However, Rider is unclear how this can be made to work, so it has been pushed onto a back burner, in case a suitable solution can be identified later.
• Clarification was requested for OBJECT_HEALTH, with Rider replying:

Basically it would allow a remote script to look at an object and get an idea about how damaged it is. It would just be an integer and it would be up to the script in the object to keep it updated (and to decide what the number means). Default =  0. The object itself won’t monitor or do anything at all with that number. It will be entirely up to the scripts about how to use it.

• The above led to a wider discussion on damage, hit points, object health and agent health + reporting. In particular a request was made for direct sensor-based identification of objects with health  (e.g. an OBJECT_WITH_HEALTH flag), and feature Request for this was requested.
• There was also further discussion on the idea of vehicle linkset having multiple hit points, allowing for variable damage to be scored (e.g. the front of a tank has 400 HP, but its rear only has 50, allowing a rear-end hit to brew it more easily than a frontal hit (as is generally the case with tanks). This is something Rider would like to achieve, but he noted that there isn’t a clean way to get object details of a specific link of another object.