Second Life Combat User Group: May 23rd, 2024 summary

Credit: Rider Linden

The following notes were taken from the Thursday, May 23rd, 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 core items discussed and responded to by Lindens, 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 Combat2 page.

Work In Progress

  • The current iteration of Combat 2.0 support on the server-side is due to be included in the Summer Fun simulator update. This is targeting a June 2024 release. However:
    • No date has been as yet given for when this update will commence deployment on the the main grid.
    • Any target dates given ahead of time are subject to final QA check-through and code clearances.
  • In preparation for the code going into the Simulator update, Rider is planning to freeze his own updates to the code in the week commencing Monday, May 27th, 2024.
  • This will very much be a release to find out exactly what works and what doesn’t for the Combat community/ies in Second Life and will be iterated upon going forward.
  • There are a couple of functions that might not make it into the initial release, although Rider is going to try to slip them in before QA freezes the Summer Fun code in preparation for deployment. These are:
    • Two additional parameter for llRezObjectWithParams – one that will set the collision filter on rez and a second that will make it derez if it’s rezzer goes away.
    • A new function – provisionally called llMedea (a reference to Greek mythology and vengeance), which will let an object unrez/kill something it has rezzed (hence the mythology reference).
  • The request for an llSensor function to check for objects with health has been acted upon. It is available in the Combat 2,0 sandboxes on Aditi and tests for “damageable” objects.

Comments and Requests

  • There were three Combat-related regions available to simulators on the Teen grid: Lexington, Concord, and No Man’s Land. These were seen as meaningful for many in the Combat community/ies, and a request has been made that, if possible, to bring them back to simulators on the main grid.
    • Rider passed this request directly to Product Operations, who were able to bring up all three regions after they had been off-line for 10 years 7 months (+some days, hours, minutes).
  • The request made at the previous Combat meeting for a possible new llSensor function has been written up – see Creation of llSensorwithParams.
  • A request was made to add a “fast” parameter to llRezObjectWithParams which would allow objects to rez at a reduced delay, thus allowing higher rates of fire for some weapons without the need for additional rez nodes. The issue here is that any such parameter could open up griefing vectors, as such it needs to be handled cautiously – if at all.
    • It was suggested the parameter could be managed at region owner / estate level (e.g. so only enabled where specifically required).
  • A further request for additional estate managements tools was made: one to disable the rez queue where required, as it is seen as causing major interruptions in combat scenarios.
  • There have been requests (including a feature request) for the first-person shooter improvements that have been added to the Black Dragon viewer to be considered for official implementation. This is a viewer-side feature, so would a) require a code contribution; b) would have to be considered for implementation by the viewer team.
  • A question was asked about avatar orientation / rotation (larger a viewer-side function) as whether it could be made more granular to determine where an avatar may have been hit with a projectile, rather than just getting a hit yes / no response.
    • Rider indicated he has some ideas for improving the handling of avatar rotations (e.g. force rotation, and / or determine rotation); however, it is going to take further research and testing before anything is made available.
    • Such a capability would have applications beyond just Combat.
  • There was a general discussion on RezObjectWithParamater bullets (and possibly “regular” bullets) colliding with an avatar / mesh on the same tick and not damaging the avatar (see related request here). Rider indicated there is no fix for this in the initial updates.
  • A request was made if there might be improvements to help with melee combat situations, to which Rider replied:
As a matter of fact yes. We’re going to have to hold off on collision type combat (just because of the way that works right now on the simulator) BUT you can use the technique of doing a quick sensor scan in the arc of your weapon and then applying damage directly to what you hit with llDamage.
  • An informal request was made for the Combat Log (Brigadier Linden) to record death positions. Rider felt this could be quickly added, and requested a formal Feature Request via the Feedback Portal. This was done, and he is now working on it.
    • A suggestion was added to this to also include the position of the damage object’s owner at that same instant. since people seem to be worried about auditing for cheating.

Have any thoughts?

This site uses Akismet to reduce spam. Learn how your comment data is processed.