Tag: Combat User Group

The following notes were taken from the Thursday, May 9th, 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.
  • Discussion topics, requests, etc., can be found on the SL Feedback Portal Combat Board.
• Additional details are available via the SL wiki.

Work In Progress

• Rider has updated the simulator side of the combat system. This includes:
  • The most recent updates to Leviathan Linden’s Game Control event work for game controllers (see below).
  • Message changes in RegionInfo. There is now an optional CombatSettings block that can be seen by the viewer, it has all the region settings such as regen rate and damage throttle (this requires a viewer-side update to be visible, which is currently in the works).
  • Bug fixes, including for one in which being slammed into the ground is bad for your health and bypasses the damage functions. Also see: Allow Region To Modify Physical Collision Damage Factor.
• llDamage is in the process of being updated to reflect the work in this project.
• It is hoped that more detailed documentation on “Combat 2.0” will be produced.
• There is now a UUID / name for the combat log: COMBAT_LOG_ID or Brigadier Linden.

Comments and Requests

• A request was made to add onto the existing llSensor functions (or created a new function) that would allow the option to do an llCastRay (i.e. llSensorNew( string name, key id, integer type, float radius, float arc, float rate, list options )), plus, and when using raycast options, to just return the llDetected events based on successful hits.
  • This would allow an object to detect Agent or other Objects that is in full view of the object calling the Sensor event, and was seen as helping the likes of “wall safe” melee attacks and explosions all in one call.
  • The idea was favourably received by Rider and several at the meeting.
• There was a question on whether triggering llDamage at a target on safe land, would it trigger on_damage? The answer was no, it would just fail, and also a damage enabled object colliding with something on safe land will not cause damage.
• There was some confusion as to which has priority within a region: does the region’s Damage Allowed setting override the Safe setting at parcel level, or vice-versa – and exactly what the “Damage Allowed” actually does (“allowed” does not necessarily mean Damage is “enabled” on setting it).
  • Rider indicated that within the Camber updates he is writing for the viewer, the term has been changed from “Damage Allowed” to “Enable Combat” – which is clearer as to intent, but again, not necessarily indicative that setting it automatically sets the entire region to Damage “enabled”).
  • A suggestion was made to make the setting directly more granular at region level via a drop-down, e.g. “Always On”; “Use Parcel Settings”; “Always Off”.
  • This may become the subject of an additional discussion on the SL Feedback Portal Combat Board.
  • Rider also indicated that as follow-on work to the current project he intends to allow overriding things like the damage throttle and health regen on a parcel level.
• A request (feature request pending) was made for a damage over time function that doesn’t require additional objects.
• A general discussion on llRezObjectWithParams and potential improvements – these will be recorded as / when actual changes are made.

Game Controller Support Update

• This is a separate, on-going project by Leviathan Linden to provide better support for game controllers (such as X-Box controllers) in Second Life, and exposes input from game controllers to LSL.
• It is generally reported on in the weekly Simulator User Group meetings.
• Current status:
  • The feature has been merged into the same server code as Combat2, as noted above.
  • The viewer is still undergoing work, but a further pre-release viewer (for those on the SL Discord server) should be available in week #20.
  • The viewer-side work will eventually surface in a project or RC viewer.
  • Leviathan is additionally overhauling the Flycam options / Preferences tab as well – no details as yet, but updates will be appearing in a future version of the Game Control viewer updates.

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.

 

The following notes were taken from the Thursday, April 11th, 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 has updated the simulator running on the Aditi combat test regions (Thermopylae and Gallipoli). In particular:
  • The combat log events so that it will provide up to 1020 bytes of data at a time.
  • The single JSON object becomes an array, which will hopefully address the issues of overflowing the listen event.
  • A fix a possible exploit wherein rezzing a prim with damage in a non damage area then shooting it into a damage area would cause damage. To prevent this, the object becomes TEMP and DIE_ON_COLLIDE with no damage. This will be extended to regular damage to prevent situations such as people sniping at opponents from “safe” zones.
  • The issue of physical objects with damage (via llSetDamage or REZ_DAMAGE) not causing damage to objects with no sitters should now be fixed.
  • Setting up a well known sender for those so llListen can filter them is coming soon.
• Rider is currently working on region settings for what happens when someone “dies” in combat.
• Rider proposes setting up two combat-specific region on Aditi (the Beta grid), specifically for testing output from this work / project.
  • Names are TBC, but will likely be something along the lines of “Waterloo”.
  • These will hopefully be up and running in about a week.
• In terms of initial work, Rider is looking to “knock off” the low-hanging fruit:
  • First will be llGetHealth.
  • Second will be damage transfer across regions (e.g. damage transfer is not going to 100% when you cross a region boundary).
• The above will be followed by work on the on_damage() event, key to much of the rest of the work.
• New documentation accompanying the events and capabilities will be posted the to LSL Wiki.

Comments and Requests

• To new requests under consideration:
  • Volume detect objects should discard incoming damage from llDamage.
  • Add SIT_FLAG_NO_DAMAGE to llSetLinkSitFlags for LLCS2.
  • The thinking is to use both of the above to allow for current and new vehicles (built in respect of the LLCS-2 updates).
• This led to a discussion on damage distribution when a vehicle carrying sitters is hit (Rider’s approach being if a vehicle carrying four avatars is hit, then each would receive 25% damage), and how llDamage should be handled (e.g. if called from within a vehicle  – one avatar shooting another – damage goes to the avatar; if llDamage called from outside the vehicle, it goes to the vehicle and the vehicle determines how the damage is applied to those sitting on it).
• As a result of the discussion, a new function – llDetectedTarget – was seen to be increasingly desirable. This would allow specific avatars riding a vehicle to be targeted (e.g. the driver).
• The meeting time may be changing to allow more US attendees. 3:30 SLT is being considered – although this could then exclude those from Europe.

The following notes were taken from the Thursday, February 22nd, 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

• Feedback from the previous meeting has been written-up in the form of Github / Canny items by Rider Linden. However, they are not open to public viewing, due to being part of the server repo.
• However, general feedback on Combat 2.0 can be found in this Canny board. This is seen as the place to raise any issues or suggestions as we go on, as Rider can monitor it pretty.
• Rider proposes setting up two combat-specific region on Aditi (the Beta grid), specifically for testing output from this work / project.
  • Names are TBC, but will likely be something along the lines of “Waterloo”.
  • These will hopefully be up and running in about a week.
• In terms of initial work, Rider is looking to “knock off” the low-hanging fruit:
  • First will be llGetHealth.
  • Second will be damage transfer across regions (e.g. damage transfer is not going to 100% when you cross a region boundary).
• The above will be followed by work on the on_damage() event, key to much of the rest of the work.
• New documentation accompanying the events and capabilities will be posted the to LSL Wiki.

Comments and Requests

• A request was made on whether combat capabilities could be made so unobtrusive, they could be “always on” unless specifically disabled through region / parcel setting.
  • This was seen as a non-starter on a grid-wide basis, due to the diversity of uses to which SL is put, and the need for combat to be opt-in, not opt out as a result.
  • In terms of Mainland, any such arrangement would be under the remit of the Product Operations group under Patch Linden.
• A user proposal has also bee submitted to the Combat 2.0 section of Canny to address damage caused by physical collisions, for review.
• It was suggested that there should be some permanent regions set up to demonstrate combat in SL, as these could be useful for demonstrating to new users what sort of experiences are out there, as well as showing off how the combat features can work.
  • An adjunct to this was a suggestion the the SL Combat Communit(y/ies) get(s) totgether and promotes activities via the Second Life Community Exhibition at the Welcome / Motown Experience gateway.
• There was a general discussion about having the ability to parcel region vertically (e.g. by altitude). However, this is not a part of this project – or something the Lab has on its roadmap, as it raises a lot of complications.
• More discussion on teleporting on death / respawning and allowing defined re-spawns by group or similar, along much the same lines as the previous meeting.
  • Rider indicated that he is not going to tie spawning (or combat capabilities) to the SL Experience system, BUT existing experience functionality can be used to extend them.

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.