Damage objects should send damage to the nearest recipient
tracked
Thunder Rahja
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.Log In
Nexii Malthus
I have gained some important insight on the collision penetration issue.
a) My setup is as follows:
- Create a prim floor below you, had one sized at <32, 16, 0.5>
- Create a cube with object health-based damage processing that alerts when damage was processed
- Use gun that shoots high velocity bullets, very thin and 4-5m long. I'm using llRezObjectWithParams with scriptless bullets (e.g. collide on hit flags & damage)
- Look at and shoot down towards cube from ~6-10m, the angle should be enough that it can hit the hit floor if the cube wasn't there
- Cube often fails to register hits
b) Work around:
- Shift+drag the floor out the way which also makes a copy in-place where it was originally
- Shoot at cube again
- Cube registers most or nearly all hits
Notice that the only difference was that the new floor was created after the older cube.
I think this has to with the way the sim goes through the order of collisions and it happens that the list is ordered based on presence in the havok physics engine presumably.
The easiest fix would be to reverse this loop or list through the list of collisions on penetration when looking to apply damage and the collide on die flag.
This is the quickest way to resolve the issues presented in most cases. Albeit not an ideal or permanent fix. This is because most of the oldest objects/physics shapes are those that would part of sim layout, such as a wall, floor, etc. Newer objects are most likely to be avatars, damageable objects, interactive objects, etc.
Kyle Linden
tracked