 |
|
|
|
Another good place to test this in the Training Mission is at: 1169.84 -807.46 757.25 41.6 -90.3 0.0 Walk (not run) and jump, and then mantle onto the bridge. Attached screenshot. Left circle: Tends to have fall damage. Right circle: Is more likely to have fatal fall damage. Good for testing death animation on mantle. The Painter's Wife mission is another good mission for testing. |
|
|
The attached patch has fixed this issue for me, and I haven't noticed any other issues. This patch will need a good review, though. Some things to consider while reviewing: 1. There are different types of mantling, such as a short push, long push, or hang. Does it behave correctly and look right? 2. There's also taking fatal damage from the fall when entering a mantle. Does it cancel the mantle? Is the player death animation correct, including their body falling to the ground? 3. Does a regular mantle still feel the same as before the patch? In my testing, everything felt correct. r10261-fix-delayed-fall-damage-on-mantle.diff (727 bytes) |
|
|
Bikerdude was very kind and made a test map for this. Good thing, too. Because it exposed a difference in falling damage with the above patch. With the above patch, there's slightly more damage inflicted on the player on mantle. I imagine that difference is due to the damage being calculated with the player being slightly lower to the ground. Without the patch, the damage is calculated with the player's feet on the platform rather than the player's feet dangling below the ledge, if I understand correctly. Can't just be a single line fix, huh? |
 |
Damn, how do you even reproduce this thing? =) I managed to get this once out of 10+ attempts. And on two attempts I simple died, although ordinary fall does not kill me. I think the exact amount of damage of ledge-grabbing is rarely an important thing and nobody depends on it. Ordinary fall damage is another thing: mapper can specifically tune some height to make player barely survive. But fall with mantle rarely happens naturally, and is too difficult to pull off (and should not reduce damage compared to ordinary fall). UPDATE: it is much easier to reproduce on the exact location specified in this issue. |
|
|
Hmm... isn't 50 damage closed to what player receives for falling from that height than 18 damage that he gets on mantle with trunk code? I see that in idPlayer::Damage: savedVelocity.z = -860 that's how fast player is falling currentVelocity.z = -150 on trunk currentVelocity.z = 0 with the patch I wonder where this -150 comes from, but most likely it should be 0 and thus get more damage? |
|
|
One thing that might be wrong is that the velocity of the object you fall down onto is not taken into account. Not in the case of boat, but in general. If you fall onto an elevator going down, the velocity difference is lower than if the elevator was standing still. |
|
|
Here is where -150 comes from: // FIXME: if they can't slide down the slope, let them walk (sharp crevices) // make sure we don't die from sliding down a steep slope if ( current.velocity * gravityNormal > 150.0f ) { current.velocity -= ( current.velocity * gravityNormal - 150.0f ) * gravityNormal; } Basically, it is totally meaningless. Also, I see that at the end of mantle velocity is reset to zero. I'm pretty sure the proposed fix is good. The only thing that's probably worth investigating is when we fall+mantle onto a moving elevator. On ordinary fall, player's final velocity and damage depends on the velocity of the elevator. On fall+mantle, it does not depend both on trunk and with the patch. |
|
|
If someone wants to take velocity of the mantled entity into account, then it was to be done in idPhysics_Player::UpdateMantleTimers as well. That's the place where velocity is zeroed. However, I don't see any info about mantled entity there =( Given how rare fall+mantle is, probably just ignore the problem. I think we should just commit the proposed patch. |
|
|
Fall mantling is commonly used by veteran Thief players, and that technique can be seen a lot in YouTube videos. And, I've been experiencing this issue a lot. I wonder if a mapper has created a fall mantle scenario that is just above getting damaged (without the patch). So, with the patch, the player will now get damaged. I hope a mapper hasn't done that! During your investigation, did you find a way to make the fall damage match what the player would have received before the patch? |
|
|
No, but I found that reduced damage on the current trunk makes no sense. Better get rid of it than reproduce it. |
 |
Keep in mind that the mission "The Rift" relies on things like "jumping down from very high locations to land in the water". I believe that some of the mitigations against full fall damage were implemented after a TDM update broke that mission. I don't recall any other missions relying on this stuff but it's something to consider. |
|
|
There is no change to damage for an ordinary fall. What is changed is the damage you get after a fall ends with a mantle. On current trunk is is reduced, as if the impact velocity is diminished by 150, and this is quite arbitrary number which has nothing to do with falls and mantling. |
|
|
I committed the patch as svn rev 10263. |
|
|
I feel uneasy about this change, because it makes the game harder and could potentially break a route used by players in a mission. When a player ghosts a mission, they are not allowed to take any damage, for example. Even though the -150 doesn't make sense, it's part of the game mechanics now. So, I think that -150 needs to be reproduced somehow. |
|
|
That would be "Bug for bug compatibility". Something we should do when we have to, but not more often then that. I believe the current behavior of lower damage was never intentional (maybe not even present in the first release). Also, I think most people usually fall from high height on their foot, so it is unlikely this is critical for any mission. In the current state it is a bug, and if someone uses it, then it is an exploit. I might recall a similar case. In older TDM versions, picking a lock did not end when player moved away from the door. The player could start picking a lock, go to another end of the level, then return and continue picking from the same place where he left, as long as he held the button all the time. And that could easily be used to make gameplay easier: you can pick a bit, then hide from the guard, then return and continue. Anyway, leaving it in place did not make sense. If you think this is a big deal, we can wait until there are people complaining about how it makes some part of some mission worse. Also, it might make sense to delay this for after 2.11: committing some changes that changes again shortly afterwards is not very nice. |
|
|
Yeah, I checked Blame: the 150 thing was a hack applied in 2018 in order to fix damage on "uncapped FPS" mode. So that's not the original TDM behavior =) |
|
|
That's good news: re 2018 hack. And, "The Rift" came out in 2010. I guess my vote is to keep rev 10263 and watch for complaints. The difference in damage is pretty negligible anyway, so hopefully it won't make a difference during actual gameplay. |
|
|
Thank you for all of the investigating! This issue is much easier to understand now. =) |
- Anonymous
