Combat 2.0

  • Search existing ideas before submitting- Use for customer support issues- Keep posts on-topic Thank you for your ideas!
Improved Mouselook for Combat and Immersion
[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. 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. 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: ]
Add REZ_COLLISION_FILTER parameter to llRezObjectWithParams
It would be helpful to replicate the behavior of llCollisionFilter as a parameter to llRezObjectWithParams so that objects can take advantage of that collision filter behavior without requiring a script. A typical use case here is dual guns. Both rez the same bullet object with the same name, and these bullets all occupy the same space in front of the user when fired, typically with some randomized rotation added (a.k.a. spread), so collisions between bullets fired by separate guns can happen. However, these guns are two different objects, so the flag REZ_FLAG_NO_COLLIDE_FAMILY doesn't help. This is not an issue for old-style scripted bullets, which can use llCollisionFilter("bullet", NULL_KEY, FALSE) to avoid colliding with bullets from the other gun. However, having to use scripted bullets to regain this capability defeats the purpose that llRezObjectWithParams was designed for. All types of collision modifications would operate independently from each other. That is, setting REZ_FLAGS, REZ_FLAG_NO_COLLIDE_OWNER | REZ_FLAG_NO_COLLIDE_FAMILY, REZ_COLLISION_FILTER, "bullet", NULL_KEY, FALSE would result is preventing collision with the owner, any other object rezzed by that object, and also any object named "bullet". I thought it would be most flexible to replicate all the parameters to llCollisionFilter, although filtering by a specified UUID isn't particularly useful for the specific use case I described. Simplified example use: list rez_params = [REZ_FLAGS, REZ_FLAG_NO_COLLIDE_OWNER | REZ_FLAG_NO_COLLIDE_FAMILY, REZ_COLLISION_FILTER, "bullet", NULL_KEY, FALSE]; llRezObjectWithParams("bullet", rez_params);

under review

Damage objects should send damage to the nearest recipient
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.


Load More