Combat 2.0

Currently if you use llDamage to apply damage to a target, you can only do so 10 times within a 3.1 second window to the same target before getting a script error. I do not think there should be a throttle at all, seeing as how we did not have one with the basic llSetDamage before. It seems like something people that do not do combat wanted to impose on us, but they don't have damage enabled in their sims anyway, so I would prefer to allow us to set our own terms like we have been able to with llSetDamage. If not, at least make this throttle less agressive. We can't even do damage over time effects like fire or barbed wire without getting script errors.

After some testing the combat communities in SL have noticed that having only one spawn in every sim that people automatically teleport to on death is not very ideal for most use cases. Our collective feedback to improve Combat Respawns is this: We can currently "Set Home" coordinates where allowed. Then on death, we get teleported to that typically. But instead, we could have a separate "Set Respawn" function that allows us to set a second set of coordinates if the parcel allows it, which would set the coordinates to wherever the owner of that parcel wants you to respawn. This should also allow the parcel owner to set multiple respawn points on the same parcel, and when you "Set Respawn", your Combat Respawn would be set to the nearest one to your avatar. It would be up to the sim owner to place signage to let players know where these are. This would allow us to set multiple respawn points in one sim and also in one parcel. This new Set Respawn function should not require the user to join a group. Then if a sim has Combat Respawns enabled on death, the player would teleport to their currently active Combat Respawn in whatever sim and parcel it is set to anywhere in SL. This way, players could "Set Respawn" in Lexington or Concord and always teleport back to that location on death in any of the sims. No Mans Land would not have Set Respawn coordinates set, but still have Combat Respawn on death enabled, so you still teleport to your Combat Respawn in Lexington or Concord on death. If there is any concern about having to add new buttons to each viewer to set this new Set Respawn function, you could also have an LSL function that allows avatars to set their Combat Respawn by clicking an object in world. In addition, you could leave the public auto respawn, but the Set Respawn would override it. For instance, No Mans Land could have the free for all style auto respawn enabled, but have a players Combat Respawn point override it if they have one set and Combat Respawn is enabled in the sim. I believe that would make Combat Respawns much more flexible and precise for any use case. This way people can keep their home points set to whatever skybox or linden home they own, auto respawns can still be a thing, and their Combat Respawn would be set separate from that which would override the auto respawn if the sim allows it. If you need any clarification, I'm always available. Contact me (Grave Resident) in world or at Gravefromsl on Discord.

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.

At present (2024-04-11), llDamage is throttled to a rate of 10 hits per 30 seconds when targeting the same recipient. This throttle may negatively impact some relationships where abuse is unlikely: Attachments and the wearer Vehicles/objects and their sitters Objects owned by the land owner and residents on that land Objects owned by an estate manager and residents in that estate Use cases that may be negatively impacted by the throttle: A backpack that steadily regenerates the wearer's health in absence of region-defined health regeneration A vehicle that catches fire and slowly burns its inhabitants until they exit An environmental damage source, such as radiation or toxic pools, placed by the land owner or estate manager, that slowly hurts avatars in the area of effect I request that the throttle be disregarded for cases such as these. I believe that throttles for llDamage used in other cases are still necessary to reduce the potential for abuse.

Related: Allow region to modify physical collision damage factor Avatars that collide with an unscripted object or terrain at high speed take damage. This damage does not trigger on_damage , final_damage , or CombatLog events, and therefore cannot be modified, negated, or even tracked. As I mentioned in the related suggestion, HUD-provided dodge functions frequently cause avatars to collide with objects and terrain at high speed, occasionally resulting in unintentional death. Some weapons take advantage of this by repeatedly pushing avatars down against the ground until they die, producing no "hit" report for the recipient. This is a source of damage that appears to have been overlooked. For a demo, click the red box labeled "A HUD that kills you with collision damage" in my case demos area in Thermopylae . Despite including an on_damage event to tally the damage received, the event never triggers for physical collision damage on the specified simulator version.

After playing with the new lsl functions with my pathfinding bot I found a use case in which I could have for example a combat npc and a medic npc. Objects can be given a default health primitive param value of 0.0-100.0 at the moment this only works for agents but I see no reason for it not to work on objects. llGetHealth(llGetKey()); Health management could be param based and easlily called and modified as needed. Object health regen could be scripted on a timer or a loop of some sort. llSetLinkPrimitiveParamsFast(0,[PRIM_HEALTH, float healh_value]); list info = llGetLinkPrimitiveParams(0,[PRIM_HEALTH]); Allowing objects to detect the health values of another object: list info = llGetObjectDetails(object_id, [OBJECT_HEALTH, link_num]); With this my medic npc can detect if a nearby npc needs health and attempt to go over and render aid. Or could be used to set the health of various components of a vehicle like tank treads etc. This would also cut down on the amount of llRegionSay() and listen events required for such a system to exist.

With today's rollout of Summer Fun to RC Bluesteel regions, I noticed a couple of issues with the default settings it ships with. The most obvious change is with health_regen_rate being set at 1, where previously health regeneration was at a rate of 1 point per 6 seconds, or 0.166667 per second. I believe that this setting should be preserved at its old (current) rate. The more concerning change is damage_throttle set to 100, which seems innocuous when the target is avatars, but against objects, this new limit severely limits creativity, and should be set to 0 as default. In combat regions where the de facto standard for damage from a bullet is 100 (an instant kill to an avatar), a more powerful weapon such as a rocket or grenade needs to express that it does more damage than that to an object. At present, the highest damage an object can be set to (via llSetDamage or its ROWP equivalent) is 100, which is good, but llDamage can be any valid float and that is key to the Combat2-oriented object health system I am developing. As an alternative to changing the default, damage_throttle should instead apply only to avatars and not to objects receiving the damage.

invulnerability_time is documented as a mechanism that stops both incoming and outgoing damage from a resident who recently died from reaching 0 health. However, in my testing of this setting, I found that outgoing damage is not blocked, regardless of estate manager status. Here is a script that demonstrates the issue: // This script tests the effect of invulnerability_time on incoming and outgoing damage. // Set invulnerability_time to 4 seconds or more. You and a volunteer set home on non-safe land. // Displaying seconds in your local chat timestamps is recommended. key volunteer = "1b3f651d-4e24-53c5-805d-3932540e283e"; // enter the key of someone in the region integer timerNum; integer messageNum; default { state_entry() { llListen(COMBAT_CHANNEL, "", COMBAT_LOG_ID, ""); } touch_start(integer n) { if (llDetectedKey(0) != llGetOwner()) return; float invTime = (float)llGetEnv("invulnerability_time"); llOwnerSay("invulnerability_time is set to " + (string)invTime + " seconds"); if (invTime < 4) { llOwnerSay("invulnerability_time is too short to test!"); return; } else if (llKey2Name(volunteer) == "") { llOwnerSay("Volunteer is not present or not defined in script!"); } timerNum = 0; messageNum = 0; llSetTimerEvent(1); } listen(integer channel, string name, key id, string text) { integer n; string eventJson; while ((eventJson = llJsonGetValue(text, [n++])) != JSON_INVALID) { key source = (key)llJsonGetValue(eventJson, ["source"]); if (source == llGetKey()) { string type = llJsonGetValue(eventJson, ["event"]); string targetName = llKey2Name((key)llJsonGetValue(eventJson, ["target"])); if (type == "DEATH") // this fires before DAMAGE, as expected { llOwnerSay((string)(++messageNum) + ": " + targetName + " was killed"); } else if (type == "DAMAGE") { integer amount = (integer)llJsonGetValue(eventJson, ["initial"]); llOwnerSay((string)(++messageNum) + ": Caused " + (string)amount + " damage to " + targetName); } } } } timer() { timerNum++; if (timerNum == 1) { llOwnerSay((string)(++messageNum) + ": Sending 100 damage to you to start your invulnerability timer"); llDamage(llGetOwner(), 100, 14); } else if (timerNum == 2) { llOwnerSay((string)(++messageNum) + ": Sending 11 damage to you, and 12 to " + llKey2Name(volunteer)); llDamage(llGetOwner(), 11, 14); llDamage(volunteer, 12, 14); } else if (timerNum == 3) { llOwnerSay((string)(++messageNum) + ": Sending 13 damage to you, and 14 to " + llKey2Name(volunteer)); llDamage(llGetOwner(), 13, 14); llDamage(volunteer, 14, 14); } else if (timerNum == 4) { llSetTimerEvent(0); llOwnerSay("Test complete"); } } } I feel I should point out that invulnerability_time , if it functioned as documented, would be a trade-off. For instance, a grenade thrown or a trap deployed before the owner's death would be incapable of dealing damage if detonated during the seconds of invulnerability given, making it very difficult to plan for in organized combat regions.

This flag would stop damage from being applied the sitter on that prim. A use-case I run into is in combat vehicles that need to track their own damage and, because of the unknown order of on_damage events, rely on final_damage to see how much damage ended up getting through. Any leftover damage in final_damage must not be applied to the sitter, otherwise they will most likely just die instead of the vehicle absorbing said damage into their own hitpoints.

With the addition to Object Health. A method of detecting object with Object Health would need to be implemented. Adding the flag OBJECT_HEALTH to a llSensor event would enable the creation of AOE explosive munitions that would do damaged to said objects. Currently with the vehicle health systems, you need to call a llSensor with SCRIPT and filter by object description to detect them. This method is server resource heavy in some conditions. That would lower the results count down and would encourage to use one llSensor call for AGENT|OBJECT_HEALTH and allow for lower the resource utilization scripts to go the intended results.