Dedicated event and functions for combat log (Combat2 2024-03-26.8430092094)
under review
Thunder Rahja
Under the current Combat2 testing version, COMBAT_CHANNEL can get very spammy, especially when there are multiple sources of damage over time present in a busy combat sim. An excess of messages can cause scripts to drop events off the end of the queue. Most residents/scripts will most likely be interested in only a few events:
- Damage my objects (or my specific object) caused that were modified by the recipient
- Damage my objects caused that resulted in a death
- What damage source resulted in my death
Therefore I propose a dedicated "combat_log" event that functions similar to listen using whitelist filters. The three types of events I have observed are "MODIFY", "DEATH", and "DAMAGE", typically occurring in that order as applicable, but there seems to be at least one more event, where scripts can send a message on COMBAT_CHANNEL to be added to the log (we could still listen on COMBAT_CHANNEL to pick up that). The fields the first three have in common are "event", "owner", "rezzer", "source", "target", and "type". The event signature could look something like one of these:
- combat_log ( integer handle, string data_json );
- combat_log ( string event, key owner, key rezzer, key source, key target, integer type, list params );
Params could vary with the event type, but for any and all of the other fields, there should be a way to set filters to avoid firing the event too often and slowing/blocking other events. The option to enable multiple filters would be ideal with a signature looking something like this, where the function returns an integer containing the filter's handle (like llListen):
- integer llCombatLogListen ( list rules );
- llCombatLogListenRemove ( integer handle );
Some examples of rules that could be used to filter for desired events (from the top of this post):
- [ COMBATLOG_EVENT, "MODIFY", COMBATLOG_OWNER, llGetOwner() ] - damage my objects caused that was modified
- [ COMBATLOG_EVENT, "MODIFY", COMBATLOG_SOURCE, llGetKey() ] - damage this object caused that was modified
- [ COMBATLOG_EVENT, "DEATH", COMBATLOG_OWNER, llGetOwner() ] - my objects resulted in a death
- [ COMBATLOG_EVENT, "DEATH", COMBATLOG_TARGET, llGetOwner() ] - someone's damage resulted in my death
- [ COMBATLOG_EVENT, "MODIFY" ] - for region/estate owners to monitor for undesired damage adjustments, i.e. cheating
- [ ] - accept all
Unlike listen, an empty string or NULL_KEY should not be treated as a wildcard, since parameters can be omitted.
Log In
Kyle Linden
under review
Thunder Rahja
With the recent changes to CombatLog, which now provides a collection of events instead of a single event per message, I think we're at a good "wait and see" point where only intensive testing will answer the question of whether the current
listen
event will suffice.Due to the lack of helpful filters to reduce the number of unwanted events, I recommend scripters use a dedicated listener script that forwards relevant events via link message.
Wulfie Reanimator
I'm also pretty wary of even moderate combat causing script event queues to spill over, even if the script's only job is to listen/process events.
In "oldschool" combat this might not be an issue because avatars tend to die in one hit. The potential future looks like avatars receiving multiple hits in combat, often in quick succession, with each damage instance getting adjusted by at least one armor script. This means there will be at least 2 simultaneous events per hit. Possibly a 3-4 if the avatar is sitting in a vehicle. Possibly one more if the avatar dies from the hit. Multiply this by the number of avatars engaged in combat.
Even if the sustained rate is manageable, there will be bursts of events and scripts may not reliably catch them all.