Difference between revisions of "Combat Log"
(Still need work but not so stubby) |
m |
||
(2 intermediate revisions by one other user not shown) | |||
Line 15: | Line 15: | ||
== Message Format == | == Message Format == | ||
Combat events are JSON-formatted, and multiple events may be combined into a single chat message (organized in an array). | |||
Each event always has an "event" property to describe the type of the message object, such as <code>DEATH</code> or <code>DAMAGE</code>. | |||
The schema of the different objects are as follows: | |||
{| {{Prettytable}} | {| {{Prettytable}} | ||
Line 124: | Line 128: | ||
==Example Messages== | ==Example Messages== | ||
Below is an example of a system generated combat log message, featuring a <code>DAMAGE</code>event | Below is an example of a system generated combat log message, featuring a <code>DAMAGE</code> event followed by a <code>DEATH</code> event: | ||
<syntaxhighlight lang="json"> | <syntaxhighlight lang="json"> | ||
Line 159: | Line 163: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
A <code>DAMAGE</code>event which features a damage adjustment: | A <code>DAMAGE</code> event which features a damage adjustment: | ||
<syntaxhighlight lang="json"> | <syntaxhighlight lang="json"> | ||
Line 188: | Line 192: | ||
You can use [[:Category:LSL JSON|JSON]] functions to help parse the messages: | You can use [[:Category:LSL JSON|JSON]] functions to help parse the messages: | ||
// Script example with a listener and showing how to filter for death events | |||
<syntaxhighlight lang="lsl2"> | |||
default | |||
{ | |||
state_entry() | |||
{ | |||
llListen(COMBAT_CHANNEL, "", COMBAT_LOG_ID, ""); | |||
} | |||
listen(integer channel, string name, key identifier, string message) | |||
{ | |||
list payloads = llJson2List(message); | |||
integer index = 0; | |||
integer count = llGetListLength(payloads); | |||
for(; index < count; ++index) | |||
{ | |||
string payload = llList2String(payloads, index); | |||
string eventName = llJsonGetValue(payload, ["event"]); | |||
if(eventName == "DEATH") // Set here which type of event we want to filter for | |||
{ | |||
// We can now parse the event message | |||
// For example if we want to extract the damage type and source: | |||
integer type = (integer)llJsonGetValue(payload, ["type"]); | |||
key source = llJsonGetValue(payload, ["source"]); | |||
} | |||
} | |||
} | |||
} | |||
</syntaxhighlight> | |||
===Lookahead optimisations=== | |||
Parsing JSON is fast but not as quick as simply trying to find a substring, so instead it's possible to do a performance optimisation by looking ahead using substring matching before actually committing to fully parsing out the message via the JSON functions. | |||
This depends on what you are specifically looking to accomplish. If you wish to only parse messages containing <code>DEATH</code> events, we can simply try to find that exact string is present. Here is how we add a lookahead check at the beginning of the listener event: | |||
<syntaxhighlight lang="lsl2"> | <syntaxhighlight lang="lsl2"> | ||
// | listen(integer channel, string name, key identifier, string message) | ||
{ | |||
if(llSubStringIndex(message, "\"DEATH\"") == -1) return; // Stop processing if there is no "DEATH" string in the message | |||
list payloads = llJson2List(message); | |||
integer index = 0; | |||
integer count = llGetListLength(payloads); | |||
</syntaxhighlight> | </syntaxhighlight> | ||
However if you are actually looking to filter by death events of a specific agent such as the owner for example, you can instead filter by the UUID in the message. There are likely to be less combat log messages related to a single agent than filtering by all death events, and you can also combine it with the above check to further refine it like so: | |||
<syntaxhighlight lang="lsl2"> | <syntaxhighlight lang="lsl2"> | ||
// | listen(integer channel, string name, key identifier, string message) | ||
{ | |||
if(llSubStringIndex(message, "\"" + (string)llGetOwner() + "\"") == -1) return; // Stop if the owner's UUID key is not present anywhere | |||
if(llSubStringIndex(message, "\"DEATH\"") == -1) return; // Stop if there is no "DEATH" event | |||
list payloads = llJson2List(message); | |||
integer index = 0; | |||
integer count = llGetListLength(payloads); | |||
</syntaxhighlight> | </syntaxhighlight> | ||
For example we could now efficiently try to check for any <code>DEATH</code> events that the owner was responsible for within the for loop. | |||
Latest revision as of 14:41, 5 September 2024
LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
The Combat Log has been added as part of the Combat2 update which allows for auditing and useful usecases.
- Combat Log messages are sent region-wide on the channel: COMBAT_CHANNEL
- Records all damage events, damage adjustments and kills
- System generated messages by a specific ID that scripts may filter to: COMBAT_LOG_ID
- Scripts may write to this channel if not restricted by the region, check via:
llGetEnv("restrict_combat_log")
System generated messages can be delayed up to 1 second as the sim collects messages to send them in bulk at a time.
Unless you want to intentionally listen to object generated messages it is recommended to set your listener to filter by COMBAT_LOG_ID, e.g. llListen(COMBAT_CHANNEL, "", COMBAT_LOG_ID, "");
This is because your script may end up unnecessarily receiving and processing custom messages that it was not designed to handle and ends up ignoring.
Message Format
Combat events are JSON-formatted, and multiple events may be combined into a single chat message (organized in an array).
Each event always has an "event" property to describe the type of the message object, such as DEATH
or DAMAGE
.
The schema of the different objects are as follows:
Key | Value | Description | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
"event" | "DAMAGE" | ||||||||||
"damage" | JSON_NUMBER | Float of final damage applied | |||||||||
"initial" | JSON_NUMBER | Float of initial damage before adjustment | |||||||||
"type" | JSON_NUMBER | DAMAGE_TYPE_* or any number defined by the scripter of the damage source | |||||||||
"source" | JSON_STRING | UUID key of damage source | |||||||||
"target" | JSON_STRING | UUID key of damage target | |||||||||
"owner" | JSON_STRING | UUID key of damage source owner | |||||||||
"rezzer" | JSON_STRING | UUID key of damage source rezzer | |||||||||
"modifications" | JSON_ARRAY | Array of damage adjustments
|
Key | Value | Description |
---|---|---|
"event" | "DEATH" | |
"type" | JSON_NUMBER | DAMAGE_TYPE_* or any number defined by the scripter of the damage source |
"source" | JSON_STRING | UUID key of damage source |
"source_pos" | JSON_ARRAY | Array representing the position of the damage source |
"target" | JSON_STRING | UUID key of damage target |
"target_pos" | JSON_ARRAY | Array representing the position of the damage target |
"owner" | JSON_STRING | UUID key of damage source owner |
"rezzer" | JSON_STRING | UUID key of damage source rezzer |
Example Messages
Below is an example of a system generated combat log message, featuring a DAMAGE
event followed by a DEATH
event:
[
{
"damage": 100,
"event": "DAMAGE",
"initial": 100,
"owner": "75078730-ebc8-4a80-adb9-1cfd2d95b5ca",
"rezzer": "7061ebe8-6919-49fd-8d9e-06983ada3108",
"source": "4daf361b-5912-e8f6-455c-ea9cdf0f0422",
"target": "75078730-ebc8-4a80-adb9-1cfd2d95b5ca",
"type": 102
},
{
"event": "DEATH",
"owner": "75078730-ebc8-4a80-adb9-1cfd2d95b5ca",
"rezzer": "7061ebe8-6919-49fd-8d9e-06983ada3108",
"source": "4daf361b-5912-e8f6-455c-ea9cdf0f0422",
"source_pos": [
52.5,
210.2584991455078,
1001.904296875
],
"target": "75078730-ebc8-4a80-adb9-1cfd2d95b5ca",
"target_pos": [
52.88808059692383,
210.6649627685547,
1001.1831665039062
],
"type": 102
}
]
A DAMAGE
event which features a damage adjustment:
{
"damage": 15.000000953674316,
"event": "DAMAGE",
"initial": 25,
"modifications": [
{
"events": [
{
"new_damage": 15.000000953674316,
"script": "Damage Adjustment Testing"
}
],
"task_id": "9d980b7e-9c74-a790-001c-bb852f95c16e"
}
],
"owner": "75078730-ebc8-4a80-adb9-1cfd2d95b5ca",
"rezzer": "75078730-ebc8-4a80-adb9-1cfd2d95b5ca",
"source": "daf3a6cb-8a56-afa9-5ebf-2156272dde16",
"target": "75078730-ebc8-4a80-adb9-1cfd2d95b5ca",
"type": 102
}
Parsing Messages
You can use JSON functions to help parse the messages:
// Script example with a listener and showing how to filter for death events
default
{
state_entry()
{
llListen(COMBAT_CHANNEL, "", COMBAT_LOG_ID, "");
}
listen(integer channel, string name, key identifier, string message)
{
list payloads = llJson2List(message);
integer index = 0;
integer count = llGetListLength(payloads);
for(; index < count; ++index)
{
string payload = llList2String(payloads, index);
string eventName = llJsonGetValue(payload, ["event"]);
if(eventName == "DEATH") // Set here which type of event we want to filter for
{
// We can now parse the event message
// For example if we want to extract the damage type and source:
integer type = (integer)llJsonGetValue(payload, ["type"]);
key source = llJsonGetValue(payload, ["source"]);
}
}
}
}
Lookahead optimisations
Parsing JSON is fast but not as quick as simply trying to find a substring, so instead it's possible to do a performance optimisation by looking ahead using substring matching before actually committing to fully parsing out the message via the JSON functions.
This depends on what you are specifically looking to accomplish. If you wish to only parse messages containing DEATH
events, we can simply try to find that exact string is present. Here is how we add a lookahead check at the beginning of the listener event:
listen(integer channel, string name, key identifier, string message)
{
if(llSubStringIndex(message, "\"DEATH\"") == -1) return; // Stop processing if there is no "DEATH" string in the message
list payloads = llJson2List(message);
integer index = 0;
integer count = llGetListLength(payloads);
However if you are actually looking to filter by death events of a specific agent such as the owner for example, you can instead filter by the UUID in the message. There are likely to be less combat log messages related to a single agent than filtering by all death events, and you can also combine it with the above check to further refine it like so:
listen(integer channel, string name, key identifier, string message)
{
if(llSubStringIndex(message, "\"" + (string)llGetOwner() + "\"") == -1) return; // Stop if the owner's UUID key is not present anywhere
if(llSubStringIndex(message, "\"DEATH\"") == -1) return; // Stop if there is no "DEATH" event
list payloads = llJson2List(message);
integer index = 0;
integer count = llGetListLength(payloads);
For example we could now efficiently try to check for any DEATH
events that the owner was responsible for within the for loop.
Writing to Combat Log
If a region allows writing to combat logs it's recommended to pass messages in the same format as a JSON array of objects.
string exampleEventObject = llList2Json(JSON_OBJECT, [
"event", "MY_CUSTOM_EVENT"
]);
list payloads = [exampleEventObject];
string message = llList2Json(JSON_ARRAY, payloads);
llRegionSay(COMBAT_CHANNEL, message);
If your messages are more auxiliary/extra it might be better to send them on COMBAT_CHANNEL - 1
as there is no easy way to filter types of messages without parsing each (or otherwise only listening to system-generated messages) if you wish to make sure all scripts that listen on the combat log are responsive and not parsing unnecessary messages.
A useful message to send into the combat log could be an OBJECT_DEATH
message. DAMAGEABLE objects don't generate system messages when their health is reduced to 0 as the health is entirely managed and responsibility of the script with the damage processing events.
The OBJECT_DEATH
message should look the same as a DEATH
message:
Key | Value | Description |
---|---|---|
"event" | "OBJECT_DEATH" | Object-generated message written into the COMBAT_CHANNEL declaring that the object had died |
"type" | JSON_NUMBER | DAMAGE_TYPE_* or any number defined by the scripter of the damage source |
"source" | JSON_STRING | UUID key of damage source |
"source_pos" | JSON_ARRAY | Array representing the position of the damage source |
"target" | JSON_STRING | UUID key of damage target |
"target_pos" | JSON_ARRAY | Array representing the position of the damage target |
"owner" | JSON_STRING | UUID key of damage source owner |
"rezzer" | JSON_STRING | UUID key of damage source rezzer |
Generating and sending the message taken from an example object-based health script:
// deadlyDamage is the number of the damage that caused the object to die in final_damage when health <= 0
// Generate synthetic object death event as per https://wiki.secondlife.com/wiki/Talk:Combat_Log#Damageable_Object_Deaths
vector sourcePos = llDetectedPos(deadlyDamage);
vector targetPos = llGetPos();
llRegionSay(COMBAT_CHANNEL, llList2Json(JSON_ARRAY, [
llList2Json(JSON_OBJECT, [
"event", "OBJECT_DEATH",
"owner", llDetectedOwner(deadlyDamage),
"rezzer", llDetectedRezzer(deadlyDamage),
"source", llDetectedKey(deadlyDamage),
"source_pos", llList2Json(JSON_ARRAY, [sourcePos.x, sourcePos.y, sourcePos.z]),
"target", llGetKey(),
"target_pos", llList2Json(JSON_ARRAY, [targetPos.x, targetPos.y, targetPos.z]),
"type", llList2Integer(llDetectedDamage(deadlyDamage), 1)
])
]));