Open Cptcuddlybuns opened 2 years ago
I believe the most likely explanation of this issue is that the ragdoll can be in a slightly different position server-side to client-side. the client will assume it has hit a weak point over armor. but the server will see it hit armor instead based on the actual position of the limbs.
Your client predicts (as to not wait for it to take effect a very visible time later, such as when you see it "Rubber band") predicts the damage before receiving the actual creatures health and afflictions from the server.
That makes a certain amount of sense. It doesn't seem to happen often on creatures that are standing still, and it happens most often on the creatures that are the fastest. So if it's a desync between the models on the client and server it tracks that the things moving faster would have a bigger gap. If that is the issue, is there any way to mitigate it? Or is it just an unfortunate side effect of the netcode?
Likely an unfortunate side effect of the netcode as it sends position updates for the main collider (the position of the character) and not strictly where every individual limb is. some creatures (Say, a fast mudraptor) have directional armour plating on their limbs, which may make pixel-level differences between the two cause a jumpy health bar. the game is server-authoritive for many things, your game actually sends the controls you press to the server (the inputs) and the server does the same actions you did with your own character, replicating it server side. not the actual act of shooting a specific limb but the direction you aimed, holding the aim button and pressing fire and such.
Im not sure if there would be a good method of mitigating this. either you see no change when you hit the target, or potentially the right (or wrong) change before the server updates it.
The above being also how you can get stuck behind a door server-side but not client side in some rare occasions.
This is only tangentially related, but a similar affliction netcode issue. I've noticed in vanilla multiplayer when using things like exploding coilgun ammo you can occasionally manage to damage yourself somehow, but this can happen even when no shells are landing anywhere near you and no explosion or other audio/visual indication except for the fact that your character will suddenly have burn & explosion damage then it will go away a few seconds later.
( Also your character does not get 'knocked off' a periscope by the damaged unlike normally. )
Should be remedied to some extent by the fix implemented for https://github.com/Regalis11/Barotrauma/issues/10878
Apparently this still happens very frequently after the fix, moving back to Bugfixes
Still a solid issue in 1.0.8 On a 10-player vanilla server yesterday we had lot of issues were crawlers had been shot with harpoons, damage was deducted from the health bar and almost instantly the healthbar flipped back up again to the previous state. Damage of the hit negated. Very annoying.
https://steamcommunity.com/sharedfiles/filedetails/?id=3329396988 Some potential solutions in this mod (?)
Disclaimers
What happened?
When an enemy takes massive damage (headshot from a handcannon, railgun shell, pulse laser) their health will drop, then rapidly snap back to full/almost full. It seems to happen most often with the hand cannon, but I've watched a Spineling take a laser shot to the head, burn to a crisp and ragdoll, then lurch forward again with 2/3rds of its health back.
The issue doesn't repeat on the same creature often, usually another shot finishes the job. Occasionally it becomes egregious with a crawler tanking six handcannon rounds to the skull and still coming.
It could be lag as I only play online with my crew, but I'm the host and I still see it constantly. I don't recall it ever happening when we would do mission rounds, only during campaign.
Reproduction steps
Bug prevalence
Happens regularly
Version
0.18.15.1 / 0.18.15.2 on macOS
-
No response
Which operating system did you encounter this bug on?
Windows
Relevant error messages and crash reports
No response