Combat 2.0

It would be nice to have timestamps implemented for when something is received for the on_damage event and when it is officially posted to the Combat Log if available. It has been recently found that a script can be written with a sleep within the on_damage that can not only sleep the entire script, but can completely delay a user's death for however long a user inputs. Example: default{ on_damage(integer num_detected){ llSleep(5.0); } } This also completely delays the death being reported to the combat log, and there's no sufficient way to tell if anything had delayed damage or death with the current information in the time log. initial_time: the time that the damage would be received to the user before processing. post_time: the time in which it's posted to the combat log.

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.

I was considering scripts writing into the Combat Log that there might be issues in recognising event order and there was no timestamp available with the events to re-order on auditing reviews or recognising user-generated data in relationship to system generated messages. Listening to and exporting combat log data to a server also has issues with precision. So I'd like a timestamp or known sequence to be added with the event payload. Something accurate to subsecond precision, milliseconds, and/or server frames. * Ideally a subsecond float would be nice and convenient, something simple like region up time. Unfortunately there is no subsecond precision float llGetRegionUpTime(). llGetRegionTimeOfDay() CAN get region up time OR day of time whichever is smallest -- but would get annoying around cycles and also historical data would suck to manage * llGetEnv("frame_number") would be highly precise in terms of understanding sequence of events * string llGetTimestamp() is millisec precise but annoying to parse for LSL but might be fine when uploading bulk data to a javascript web app for later parsing back to number/date (not LSL friendly, not optimal, sim has to convert time to string which needs to be put back into a number -- awful ping-pong conversions) Keeping the future in mind , Luau like JavaScript (and thus JSON) both have Number types which is a double-precision floating type -- so should ideally settle on millisecond timestamps (millisec since epoch). ±285k years is pretty good long run and milliseconds are a perfectly fine precision for realtime applications such as Second Life. LSL's 32-bit integer unix timestamps on the other hand are doomed to the Year 2038 problem -- that is just 14 years away now. Wow. So choices are: Add string timestamps but this creates an additional parsing cost for Luau and external tools, painful for LSL especially as well which doesn't have 64 bit types for subsecond precision timestamps regardless. I think the sim also have to convert the timestamps internally to string right? So it's wasting time converting a number to a string that will later be parsed back to some number anyway. Add millisec timestamps in JSON as a Number, which makes it future proof for Luau and external tools. But you may need to add a LSL friendly JSON function for parsing these. Something like being able convert a json date to a integer precision timestamp (albeit doomed to 2038) and -- what I am actually looking for: a function for converting it into a subsecond precision float relative to a close landmark time. (Maybe the subsecond precision since llGetEnv("region_start_time")?) Add a frame_number, which allows precise ordering for any script. Users could record timestamps matched to a llGetEnv("frame_number")'s manually themselves for time-matching, but may lose precision for in-between frames depending how frequently [frame_number + timestamps] are collected and exported. (However order generally guaranteed) Options 2) or 3) seem best here. 3) seems fast and cheap. 2) is more work to implement to figure out LSL friendly option. Of course you could have both 2) and 3) too if you don't mind bulking the data. 3) is useful for scripts writing into the combat log because they can do it directly as: payload = llJsonSetValue(payload, ["frame_number"], llGetEnv("frame_number")); 2) I'm not sure what the LSL equivalent would be like, leave it up to the readers imagination to fill the blanks.

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)

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.

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

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 we can set a damage throttle in Combat 2.0 regions. So if we set it to 50, 100 damage bullets will do 50 damage and require 2 bullets to kill the avatar. The problem is that this comes with a per second bug where if the avatar is hit with 3-5 100 damage bullets in a 1 second window, they will only take 50 damage one time. This is very bad and should be removed. We do not want to limit how much damage can be applied per second. This makes the throttle system functionally unusable. It should be damage per hit.