Combat 2.0

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

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.

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.

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.

Outside of damage events, sensors and collisions it's not possible to infer the types of detected object or avatar. I'd like to see an OBJECT_TYPE that returns the integer mask just like llDetectedType does. It was realised because DAMAGEABLE can't necessarily be inferred through OBJECT_HEALTH. DAMAGEABLE is when an object can process damage but health could be 0, such as when it is dead and respawning, potentially causing a false negative as it can't be used as a boolean check. This is a low priority request personally but it might be low hanging fruit if it's easy to implement simulator side.

Combat2 introduced the ability for objects to receive damage. In my testing, when firing a damage bullet at four objects with on_damage in a way that causes all four to be hit in the same physics frame, all four scripts reported the collision, but only the object created first reported receiving the damage. In the event of the bullet colliding with both an avatar and an object in the same frame (such as when someone takes cover behind a relatively thin wall), the avatar takes the damage, and that has long been grounds for complaints within the combat community and empowered abuse. Rider said that the object that receives damage "bubbles up from the physics engine," but so do scripts that fire their collision_start events from non-damaging collisions in the same frame. Note that, using the test script below, collision_start appears to consistently fire before on_damage . If all four objects in that set got the event at the same time, why does the simulator send it only to the oldest object? I propose that the object (or avatar, or child link) whose center is closest to the bullet's position in the frame before the collision should receive the damage (or prevent it, if the bullet has REZ_DIE_ON_COLLIDE ). While this wouldn't be as accurate as a priori collision detection, it could put to rest the long-standing issue of accusations of "prim shooting", or deliberately shooting at a wall or other object between the shooter and close to the target. The test script: default { state_entry() { llSetText(llGetObjectName(), <1,1,1>, 1); } on_damage(integer n) { float totalDamage; while (n--) { list damageInfo = llDetectedDamage(n); totalDamage += llList2Float(damageInfo, 0); } llOwnerSay("Took " + (string)llRound(totalDamage) + " damage"); } collision_start(integer n) { llOwnerSay("Collision from " + llDetectedName(0)); } } On collision detection: Second Life's physics engine uses the a posteriori collision detection model, meaning that, in each physics frame, a physical, moving object "jumps" to the position it should next be in, and any non-phantom objects that it intersects with in that new position is considered a collision. This is in contrast to the a priori collision detection model in which the physical object "slides" to its new position in the coming frame, checking for collisions along the way. The trade-off for using the latter method is that while collision detection would be much more consistent and reliable, it has greater performance demand that may not be feasible for a virtual world filled with user-generated content.

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.

Currently, on the main grid, the checkbox "Allow Damage", when checked, enables damage for the entire region, regardless of individual parcel settings, and allows individual parcels to enable damage (by unchecking "Safe") when unchecked. I propose that this override checkbox be changed to a dropdown menu with the following options: Always on Use parcel settings (default) Always off (new option) This would both reduce the confusion we had during the recent Combat Community User Group meeting and provide an additional override to estate managers who need to quickly pause or end combat activity, without changing the setting of every parcel individually. Additionally, having this setting exposed as a llGetEnv variable such as "allow_damage_override" would be very helpful, as I know that some scripts read parcel flags to check if damage is enabled, but they are unable to determine if damage is enabled at the region level.

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.