 |
This causes the mantling bug to return. Replication: 1) Install mission "Swing" 2) Climp the ladder at the beginning of the mission 3) Before you reach the mantle distance for the first platform, keep trying to mantle 4) You will find that sometimes you are able to mantle before you should 5) When this happens you will be embeded into the platform and you wont be able to jump It may take a few tries to replicate this. |
 |
I can't identify the problem just yet. I uploaded a video on youtube with my experience. It's working like that for both x87 and sse compiles. https://www.youtube.com/watch?v=g5H8HBLgTng How is working for you? |
|
|
The replication involves mantling from the ladder to the platform. You are mantling from a swing to the platform. Climb the ladder, when you approach the top of it turn to face the platform. Keep trying to mantle early (before you are over the threshold where you should be able to climb off the ladder onto the first platform.) |
|
|
New video at https://youtu.be/6aq6t8aBQpo Still can't repeat. |
|
|
After you mantle, are you able to jump? |
|
|
Tried again - I can jump after mantle 5 times out of 5. |
|
|
Possible issue: underground basin in Somewhere Above the City. Not possible to pull up to the ground above it. |
|
|
Perhaps do this in the game\physics classes: #if defined(_MSC_VER) && _MSC_VER >= 1800 && !defined(DEBUG) // greebo: switch off function inlining for this file in VC++ 2013 release builds // Function inlining seems to cause lighting bugs (triangles are drawn very dark or black) #pragma optimize("t", off) #endif |
|
|
Additional info for the the example above: Player can't mantle up from water when closely touching the basin wall. After moving a little away from the wall it mantles as usual. |
|
|
Same issue reproduced in the x64 build (32-bit binary). As expected. |
 |
In this particular scenario, there is the ledge you mantle to is located at coordinates Y=7616, Z=3424. Now there are two cases: 1. Mantling with hands involved. Then trace collision point is (* 7615.75 341?.?), and mantle endpoint is (* 7615.75 3424.?). In such case player does not get stuck. 2. Mantling without hands. Then trace collision point is (* 7616 3424), which is exactly on the ledge. Then the idClip::Translation is called (player vs world) in order to check if this point is suitable for ending mantle position. Since player with Z=3424 prefectly touches the platform, any result is acceptable, and collision manager returns "no collisions" verdict. So the point (* 7616 3424) is accepted as "end mantle" point. Now the bad part is: when mantling ends, player has position (* 7616 3423.97???), which is a bit lower than platform. This leads to player getting stuck, and he cannot jump. |
|
|
Now the question is: why isn't player's position exactly equal to mantle end position when mantling is over? As it turns out, mantling animation (method MantleMove) is called each frame during mantling. It checks fraction of move which is already complete (var timeRatio), and sets player position depending on this fraction. The problem is: MantleMove is last called with fraction = 0.98, it is NOT called with fraction = 1.0, because UpdateMantleTimers changes phase before modelling last bit of animation. As a result, both position and viewangles are not set exactly to their final values when the mantle is over. There is already a fix for viewangles in UpdateMantleTimers done by greebo. It sets roll precisely to zero. I have added a fix for endpoint here too: it sets player's position exactly to mantle endpoint. This change fixes the issue. |
|
|
Now the question is: why is it so critical if mantle finishes a bit inside solid? You might remember that in the old versions of TDM, there was a very funny bug: player started to float up after a mantle, sometimes going through a wall (see e.g. 0000652). This behavior was caused by the special code supposed to fix any collisions present at the end of mantling. It is located in method CorrectAllSolid, and it was written by SophisticatedZombie in the very beginning. It checks if the player clips into something, and if yes, then it lifts player up by delta = 0.2. Since this hack was applied continually, it sometimes made player levitate through wall. In order to fix this issue, Ishtvan committed a change in revision 2970 (back in 2008): possible fix for infamous 'rising issue' : levitation code in CorrectAllSolid is only executed if we clip something after a mantle However, that fix was buggy. It sets a special phase fixClipping_DarkModMantlePhase after mantling, but then changes it to notMantling_DarkModMantlePhase immediately, without even getting out of UpdateMantleTimers. I have fixed that: allowed to get out of the loop in UpdateMantleTimers if phase is fixClipping_DarkModMantlePhase. Then the "push-player-up" starts working (called only once after mantle), and the issue is resolved. |
|
|
Now I have two working fixes for the issue, each alone is enough to fix this particular scenario. A good question is: how is it related with FPU/SSE switch? It is hard to answer. I looked through the code which checks for collision, and it is very tight in its handling of floats. Note that in this case all important coordinates are integers, i.e. they are perfectly representible as float32 numbers. Also, player's collision model is checked against the platform he perfectly touches. The internal code (TestTrmInPolygon) seems to not apply any tolerance (i.e. epsilon) when checking for collision. All of this means that the outcome of touching collision query is very unstable and depends on the arithmetic used. A more consistent arithmetic (SSE) is more likely to have various quantities equal, which may lead to verdict "no collision". The only potential issue with precision I see is that collision code uses Pluecker coordinates for lines passing through edges (FromLine, FromRay, InnerProduct). They are similar to cross product, i.e. they have components like x1*y2-x2*y1. Since we have coordinates of magnitude about 10^4 here, these products can lose precision when evaluated in 32-bit floats (product is 10^8, so error can be around 10). Maybe converting something to double precision values here may help. But it feels like gambling. |
|
|
How about closing this issue, since it covers a vast set of issues and no single issue in particular? We can create a "precision" tag to mark all issues related to this. |
|
|
Agree |
|
|
I mark it as "not fixable" because there is no particular issue to be fixed here. The true reason would be "too broad" =) |
- Anonymous
