Currently the combat log collects some logs up to a second before system-generated messages are sent, however for high priority messages like on avatar death this causes issues around response time.

The sim should and/or:

1) only start collecting depending on activity in the COMBAT_CHANNEL. Like have it's own threshold to follow where collecting logs becomes more efficient. I think you can figure this out somewhat mathematically or re-use the threshold mechanism. E.g. after 6 logs per second or something.

I think most messages only fit 2–3 events at most due to all the UUID keys causing it to hit close to the 1024-byte chat message limit. So holding back messages to only add one extra after up to a whole second after a high priority DEATH message was generated is a bit much.

2) (Recommended) send out any message containing a DEATH event immediately.

--

The issues I'm faced with is a experienced-based single script respawn teleporter system.

This teleporter relies on the death_action to be set to No Action on the region settings. With the intention to avoid double-teleports and re-engage people back into combat at ideal locations of the game designers/developers choosing.

There are very noticeable delays when agents die and before they can be teleported out of combat. I wanted to opensource this system because otherwise, honestly it is great, it is incredibly simple and efficient. It is non-invasive and event-based (only waiting for and parsing DEATH messages via substring pre-checks). The simplicity means that one can focus on important things, like game design, where should people respawn and why.

However the delays of receiving DEATH message mean an alternative is required, such as a complex management system of temp-on-attach scripted attachments that can receive on_death events instead, which are known to be instantenous. The problem is that people can detach these to cheat or just don't understand what it might be for. The script complexity also sky rockets, now you have to poll llGetAgentList at a high frequency to make sure you don't miss out on new arrivals and also poll to check whether any of the temp-on-attach attachments were detached (temp-on-attach just dies, so can just check if it still exists) and to force a re-attach (meaning to rez another one, tell it to temp-on-attach via scripted communications, …). If the checks are done too slowly then someone could easily cheat in combat, detach -> jump into combat -> giving them up to several seconds of complete immunity before the system notices and re-attaches.