• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

Will dead corpses be able to stop/slow down bullets?

I believe so, yes. In UT3 the ragdolls can be affected by weapons, so one would assume they can be made to stop said bullet.

Kind of depends on of ragdolls are handled client-side again or if they are serverside now.
I mean, what's the use of a corpse taking bullets when it isn't in the same place for another player?
Client-sided ragdolls wouldnt necessarily allow them to soak up bullets, server-sided ragdolls are much more likely to do so.
 
Upvote 0
That also brings up using corpses for cover. If you try to hide behind a corpse, that might be an issue if corpses remain client-side. I don't think rag-doll effects can be realistically done server-side, unless the server sends the procedural instructions (initial velocity of the body), so technically the client should animate the rest of the ragdoll, and come up to the same solution as any other client.
 
Upvote 0
Kind of depends on of ragdolls are handled client-side again or if they are serverside now.
I mean, what's the use of a corpse taking bullets when it isn't in the same place for another player?
Client-sided ragdolls wouldnt necessarily allow them to soak up bullets, server-sided ragdolls are much more likely to do so.
Corpses ought to be synced, both trajectory aswell as final location and pose.
If this ragdoll synchronization is properly optimized and lightweight it shouldn't affect network performance.
 
Upvote 0
Yeah, but if a body is given 3 pieces of information by the server to the client:
1) Initial location in the world and direction facing
2) Initial pose (running, crouching, standing, prone, etc)
3) Vector of force (direction and velocity)

Then the client can calculate the rag-doll accurately. It doesn't have to be as time dependent as bullet ballistics, so if it's a little behind, it's OK as the point is to determine where the body lands. If it lands 0.250 seconds behind another client it's not a big deal, as it'll last for several minutes as cover (1 minute vs. 1 minute and 0.250 seconds isn't a big difference)



So this is how I would see it:
1) Server determines a player dies
2) Server sends 3 pieces of information to every client
3) Clients do rag-dolls and place bodies in correct position

Now you can hide behind the bodies.

If the bodies will serve as cover, then the server will also have to either A) Calculate rag-doll landing position, or B) Get an update from one of the clients on where the rag-doll ends up (I'd suggest the dead player's client send that in, as it's not doing a whole lot except dying).
 
Upvote 0
Remember that even with those 3 points of information one ragdoll might roll a bit further, or just fall a bit more down the stairs. Stay up the top of a broken top floor or fall down.

If things can be synched then sure it would be nice to have, but unless the physx system allows it without eating netcode i doubt we would see it in.

I really don't know how the PhysX engine works. I was going with the idea it of non-random physics effects. If the engine uses randomization to make different rag-doll effects, then that would be an issue. But if it calculates the rag-dolls the same for each exact same set of circumstances, then it should be reproducible across the clients. I don't know which way it does it.
 
Upvote 0
remember that roost is already really stressful on servers though. Which is the main issue.
Well, obviously singlethreaded applications (UT2004 dedicated server) in a world which is predominantly ruled by multiprocessor systems aren't really running efficiently.
Remember that even with those 3 points of information one ragdoll might roll a bit further, or just fall a bit more down the stairs. Stay up the top of a broken top floor or fall down.

If things can be synched then sure it would be nice to have, but unless the physx system allows it without eating netcode i doubt we would see it in.
Second Life does this efficiently, object physics are disabled when there is no player/NPC interaction.
When interaction takes place, the physics are re-enabled. So when idling, no FLOPS/MIPS (whatever precision PhysX uses) or Ethernet packets go to waste.
 
Last edited:
Upvote 0
Just thought of something, and that is ragdolls disappearing.
Ofcourse ragdolls have to disappear some time, but it would sure suck to take cover behind a dead guy that just blips away when an enemy starts firing.

That could be handled with a simple proximity detection. Corpses right next to players wouldn't disappear. The problem then becomes what happens when piles of corpses are next to players, and just keeps building up. Maybe the engine could switch the corpses to a low res mesh.
 
Upvote 0
That could be handled with a simple proximity detection. Corpses right next to players wouldn't disappear. The problem then becomes what happens when piles of corpses are next to players, and just keeps building up. Maybe the engine could switch the corpses to a low res mesh.

Yes. We definitely don't need to see a wall of 50 soldiers (especially after a sneaky sapper drops a satchel there). Though that WOULD be entertaining.
 
Upvote 0
just have them disappear after a longer period of time than normal, like a five or 10 mins instead of secs, and also, lower res mesh would be ok... but I want them to show damage of bullets etc, blood and guts splattering all over my face, uniform! haha... oohh I also wanna see bodies get crushed FLAT after being rolled over by a tank... hehe :D
 
Upvote 0
Just thought of something, and that is ragdolls disappearing.
Ofcourse ragdolls have to disappear some time, but it would sure suck to take cover behind a dead guy that just blips away when an enemy starts firing.
The Second Life solution (boolean type physics disabling, true > false) should cover that aswell.
At that point it becomes more of a rendering issue rather than a bandwidth issue.
 
Upvote 0