
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.