Combat 2.0

Heya, I would like to propose an on_avatar_entry/exit event. Some systems like the medic system care about an avatar entering or exiting a region to keep a list up to date or to rez/derez things. While I am aware we can use agentlists, this is more inefficient to run every minute or so to update a list. Especially when dealing with large amounts of avatars in event spaces, as this will take a lot of memory. This allows for a more passive than active system, causing less load on the region especially if list operations get involved.

[I am posting this on behalf of NiranV Dean, author of the Black Dragon viewer.] General purpose improvements to the way the Viewer locally handles and displays mouselook for the user. Adds an animation that the Viewer uses to modify the avatar's torso rotation to point towards the aiming direction, this in combination with a "holding" animation that objects can trigger normally allows the user to visually see and aim, say a gun around in first person, making the gun follow the aim direction, keeping it on screen, improving overall look and feel of the first person immersion. https://www.youtube.com/watch?v=ttaM7x14DBI Fixes an oversight with animated child prims that causes them to be interpolated while in mouselook, resulting in them lagging behind the root object, for instance when firing a gun that animates parts of it. With the above animation allowing the weapon to stay onscreen this becomes even more of an issue. https://www.youtube.com/watch?v=E2zPkBDWECA Mouselook head position improvements that puts the camera where the eyes of the avatar are, instead of "assuming" where the head is and forcing the body attach to the camera, which often results in the body clipping into the ground or moving around weirdly, this doesn't feel immersive at all and makes it hard if not impossible to line up animations for holding objects. ((Shown in the first video with the test running animation to simulate headbobbing)) Going in tandem with the above are improvements to the way mouselook handles and hides the head of the user while in Mouselook, locally scaling down head bones and including hiding rigged mesh attached to the head slots which were previously missing, this should help eliviate issues with the head clipping into the camera and blocking the view. ((Can be seen in the first video looking down, the shadows show the head being chopped off, something that may or may not be able to be fixed)) [Darksider Alex has provided an additional video to demonstrate the requested feature: https://gyazo.com/6964e720c1b02133d19976d3fa89f60c ]

During today's combat user group meeting, we discussed the possibility of requiring users accept an experience in order to gain access to a parcel. For combat, this means residents could be restricted to a safe parcel until they accept the experience to enter the larger combat parcel. This should behave just like key experiences for region access, but affect only the parcel(s) where a key experience is defined and "anyone can visit" is unchecked.

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.

At the moment, llDamage is throttled to 10 instances of damage over 30 seconds when directed at the same target. Some weapon effects linger and repeatedly cause relatively small amounts of damage to avatars until they take some action like moving away from the damage source. Here are some cases where non-environmental (e.g. not from a land owner) damage over time may hit the throttle if it uses llDamage : Fire (direct contact or being ignited) Poison (from being hit by a dart) Toxic gas clouds Acid or electrified puddles There should be multiple ways to end it. The damage should be able to be modified or stopped by: The script that started it (the target moved away from the fire) A script worn by the recipient (the target is wearing a fireproof suit, or stops to put out the flame) Other scripts (a fire extinguisher puts out the flame) By dying Being able to stop damage over time implies that there would a way to detect it, apart from the individual instances of damage. Should the damage be continuous (like negative health regeneration), or should it occur on a script-defined interval (e.g. every 1-5 seconds)? The llDamage throttle can be avoided by rezzing multiple damage sender objects, or sending higher damage at longer intervals > 3 seconds. The latter workaround may limit creativity for weapons that split their damage between two or more damage types.

Exactly what the name suggests. The problem: In SL, avatar hitboxes are generated according to information relative to the system body. These hitboxes are, when working correctly, a big box that encompasses the entire avatar's view model. The avatar's hitbox immediately becomes non-representative of the avatar's visible size in various conditions: crouching your avatar, wearing an unrigged attachment larger than the system body (or smaller), using deforming animations with avatars that are atypically shaped such as nonhumanoids, hover height, animations that offset the avatar's viewmodel, etc. This leads to issues such as: avatars getting stuck on terrain, or being able to pass through terrain they visibly shouldn't be able to, and avatars in shooter style games not being able to hit their intended target with projectiles as their visual model does not correspond with their hitbox. Proposed solution: Let users manually adjust the hitbox of their avatar. As long as it is just a literal box then letting users simply adjust the size of that hitbox to whatever scale and position they feel is appropriate. Considered issues with solution: Issue: People will intentionally abuse this to give themselves the smallest hitbox possible for an advantage in combat. Answer: People can already use various methods such as offset animations or simply making their avatar as small as possible to try and get this sort of advantage. Many combat sims have their own rules against avatars of a certain scale they enforce locally and are already capable of policing this sort of behaviour themselves. Issue: When an avatar enters a crouch/crouch walk their visual model is smaller and they move slower but their hitbox does not adjust. This solution does not resolve this specific element of the issue. Answer: This concern leads me to think about the relative dissimilarity between crouching animations, and animations in general relative to avatar's singular generic hitbox. Being able to have an adjusted hitbox relative to every form of avatar motion so animation was always representative would be good. Otherwise, I imagine just being able to manipulate the existing hitbox scale would be a more expedient way to resolve a lot of this problem in the short term.

A lot of sims are not primarily combat but would like to be able to dabble in it. It would be nice to have some way to set lower/upper height where combat is enabled. This would allow us to use the full 256/256 play area of a sim without being forced to enable combat even in non-combat areas of the sim.

Add the object name, as projectiles disappear when dealing damage we lose the ability to get its name using llGetObjectDetails. While the rezzer of the object is useful, it doesn't display the name of the 'ammo' since guns can have multiple. This is useful for identification of say different rockets or raycast and non raycast rounds.

Many groups in the SLMC have rules against smaller avatars, this is because their generated hitbox is also smaller based on their shape, this results in advantages such as larger coverage behind obstacles meant to provide a certain amount like sandbags or half wall or other issues such as being less likely to be hit. On the other end larger avatars have a larger hitbox leaving them more vulnerable to colliding with damage objects. Other issues can be that smaller avatars can exploit gaps in the environment. Large avatars might not be able to fit in certain areas such as large ventilation shafts that were designed as part of the combat sim. My proposal is to have a region setting that would normalise avatar hitboxes to the same size. This could be a default set by LL or optionally could be configurable. This proposal is similar but more specific and different to: https://feedback.secondlife.com/combat-20/p/manually-adjustable-avatar-hitbox Other advantages to this setting can be that combat vehicles would be able to expect what hitbox that avatars would have: 1) For example a large avatar in the cockpit wouldn't suddenly be exposed because their hitbox pokes through the glass window. 2) An exposed gunner ontop of a tank, who has a shield at the front of his gun, would have certain designed intent where they can be damaged from (sides, back and top exposed but front is fully shielded)