Combat 2.0

As pitched by Miles Doge in the initial combat 2.0 pew pew thread https://community.secondlife.com/forums/topic/506317-pew-pew-pew-linden-damage-combat-20/page/3/#findComment-2667800 , could we get built in damage falloff mechanics to further round off what we can do with projectiles? Currently doing any form of on the fly damage changes requires either numerous script events, or you could just measure damage from a start vector in on_rez and calculate damage at a prim's end point on hit. REZ_DAMAGE_FALLOFF, float falloff_distance, float falloff_amount_per_meter, float max_falloff Falloff_distance would reflect at what distance from rezzed position a projectile starts losing damage falloff_amount_per_meter would indicate the value lost per meter max_falloff would indicate the minimum value damage could adjust to. For simplicities sake, none of this would need to update on the fly, calling OBJECT_DAMAGE could just reflect the calculations on time of fetching and output the adjusted value and actually inflicting damage could just do a if(falloff values) check upon hitting a damageable entity prior to transfering damage. This would allow us to match the balancing factors present in many first person shooter games associated with "range brackets", beyond changing accuracy values, and allow us to enjoy high lethality combat at close range instead of resorting to making every avatar a damage sponge, without requiring us to make costly script calculations for every projectile and thus invalidating the benefits of scriptless damage projectiles.

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.

[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 ]

Currently there is a bug where if you use Rez Object with Params to set parameters on an object that will then rez without any scripts in it, those parameters are lost when crossing into a new sim. How many of these parameters are lost I am unsure, but the following could be tested and reproduced: For example, in bullets, they lose the Die On Collide parameter and bounce around in the sim it crosses into: https://i.gyazo.com/7e44faf0af789f3431c51e7e73888aa6.mp4

Proposal in 2 part: Passive and Scripted. Passive proposal: Avatar hitbox shape does not change based on any given avatar action. At the very least, the height of the hitbox should be reduced while in the crouching or crouch-walking animation state. In a previous system I had developed, this was accomplished by cutting the avatar's height by roughly 40%. Though ideally, the top of the hitbox should be here the person's camera is located at all times while they are in first person so things such as prone animations can more accurately reflect the avatar's hitbox size. Recommended to include a region setting for this, ie. avatar_hitbox_crouching Scripted proposal: Allows a script to effectively adjust the size of the avatar hitbox while worn via a vector. The avatar's physics interactions would be based on this size and it would disable the Passive hitbox scaling system while active. This will allow the use of larger avatars (giants), avatar-attached mechanized units, etc without the new for a separate physical object to properly represent their hitbox. The appeal being to allow the creation of full 1-to-1 avatar controls without the issue of your hitbox being confined to a tiny space between your legs. This function should be restricted to scripts worn by the person affected and should require permissions, ie. PERMISSION_ADJUST_HITBOX. The avatar's camera position should be moved towards the top of their hitbox whenever z-scaling is adjusted. Recommended to include a region setting for this, ie. avatar_hitbox_scripted

As usually happens with this type of system, weapons are being created that completely block any combat ability, using dazzling effects that chase the avatar, eliminating any possibility of counterattack. Those types of weapons should be out of the system if you want the "match" to be fun by setting limitations on the weapons used, or a way to block or report those type of behavior.

It would be useful to be able to tell if an object implements Combat 2 damage events via llGetObjectDetails. It's possible to discover this using llDetectedType in events that support llDetected* functions, but other events have no good way to get this info. The use case here is something like a raycast-based weapon. These typically execute out of a control or listen event and use a raycast call to detect objects, not a sensor or collision that would have access to llDetectedType. Being able to tell if the object is damageable through llDamage allows for smartly delivering damage this way vs. other methods (e.g. channel message-based armor systems like LBA). OBJECT_DAMAGEABLE would be a simple boolean just like OBJECT_PHYSICS and would return TRUE for the same cases that llDetectedType() & DAMAGEABLE does.

Currently if you cross from one sim into another, your HP is reset to 100. This is a bug and should not happen. Your HP should remain at whatever it was at before crossing.

I think there is a trick missing here to be able to limit Combat2 to Experiences. This would take in the form of a region setting, similar to "allow_damage_adjust" and "restrict_combat_log", but instead of allow/deny having a third option of being able to restrict to scripts with an allowed land-scoped experience. Combat 2.0 is quite exciting but people might be put into a tough place to either restrict scripts or allow them without distinction. Experiences provide an excellent in-between where the trust can be managed by the experience owner or game developers managing damage adjustment themselves for players in their game. Like myself where I am wanting to adjust damage for a dedicated combat game region of my players, compared to the SLMC where you would find two groups pitted against eachother. I might not always be around for moderation of the combat logs or have to be forced to monitor to constantly to prevent other third-party non-game scripts from adjusting damage unfairly. I think the integer boolean environment variables "allow_damage_adjust" and "restrict_combat_log" can be extended into integer constants so that for example "2" would be meant that for restriction to allowed/key experiences. Alternatively adding separate variables such as "experience_damage_adjust" and "experience_combat_log" if not extending the current ones.

invulnerability_time is great! However it has one drawback for our use case, we want to have protection to get killed in that time but still do damage. The use cases are basically: Mines placed before death should still be able to function Other Deployables like autocannons should still be able to function Grenades/weapons fired or deployed right before death teleport should still work I'd like to propose an option for this, so we can choose how this invulnerability is applied. invulnerability_bidirectional with a true or false would work, since I don't really see a use case in the other direction.