View Issue Details

IDProjectCategoryView StatusLast Update
0004994The Dark ModPhysicspublic23.02.2019 13:43
ReporterSTiFU Assigned To 
PrioritylowSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product VersionSVN 
Summary0004994: Mantling sometimes allows to clip through solid objects
DescriptionWhen mantling some moving entities, e.g., an elevator, the player may does not properly collide with the entity when the mantla is finished. This results in either one of these two situations:
1. If the entity is going down, the player will hover over the entity, not going to walking state. This goes on until the entity comes to a stop
2. If the entity is going up, the player will not move and start clipping into the entity. When the player moves, he weill fall down until he collides with the floor.
Steps To ReproduceIn the "New Job" mission, to to the tavern with the elevator.
1. Stand near the elevator on its upper level.
3. Toggle the switch to make the elevator move up or down.
4. Mantle onto the wooden ledge above platform (it is moving too).
5. Once the mantle is finished, notice the behavior described above.
TagsNo tags attached.

Relationships

related to 0004509 resolvedSTiFU Mantling a moving entity may make the player clip into world geometry when the mantle animation is finished 

Activities

STiFU

STiFU

21.02.2019 17:48

developer   ~0011638

Ok, I have investigated the remaining issue and it is kind of weird.

-It happens only with the ledge, not with the elevator platform itself.
-It happens only while the elevator is moving.
-As long as it does, AirMove() will be called.
-When the elevator stopped, WalkMove() is called.
-WalkMove() is generally only called when the boolean "walking" is true.
-CheckGround() is responsible for setting the boolean "walking". It is called twice in MovePlayer(), once before WalkMove() and once afterwards. -The call afterwards periodically sets walking = true because it finds groundcontacts
-The more important call before WalkMove() resets walking = false because apparently there are no ground contacts at that time. This repeats periodically until the elevator stopped.

So the questions for further research are:
Why are there no groundcontacts when calling from the top? What happens between the last and the first call to CheckGround() that changes induces the change of groundcontacts? And why does it happen only with that Ledge and not with the platform.
STiFU

STiFU

21.02.2019 17:48

developer   ~0011639

Reminder sent to: Springheel

Springheel, you have created NewJob. Is there anything special about the elevator platform (its base) compared to the beam / ledge at the top of the elevator? I opened the map in DR, but couldn't find anything special about it.

This is not necessarily directed at you, but I also wonder whether this issue is specific to that model or this map, or if it can be reproduced in multiple ways? Does it also happen with brushwork elevators? Does it happen in some other maps?
STiFU

STiFU

21.02.2019 17:48

developer   ~0011640

Reminder sent to: stgatilov

I have made some further observations and you have been working on portions of the code lately, so you might know what is going on here.

- When taking the elevator down and mantling the ledge, the player will sort of float on the ledge, not switching to "walking" state.
-> When increasing CONTACT_EPSILON from 0.25f to 1.0f, this issue does not appear, but the player wobbles up and down. The wobbling only happens going down when mantling the ledge, not the platform.

- When talking the elevator up and mantling the ledge, the player will clip into the ledge after mantling and remain still (not being pushed up by the elevator).
-> The method CorrectAllSolid() gets the player unstuck, when he is stuck. I noticed that altering it such that it moves the player up, regardless of whether in fixClipping_DarkModMantlePhase or not, makes the upward clipping issue disappear: The player is properly transported upwards.
-> Reverting CorrectAllSolid() to its original state and removing your fix as of rev. 6818, does not solve the issue, but I notice something else: Right after a mantle, the player is not stuck, so the mantle phase resets to "none" and the player is not moved. In the next iteration, the player IS stuck, but we are not in fixClipping_DarkModMantlePhase, so the player isn't moved up anymore.

It is as if the ledge never really registers as a ground entity while it is moving and so ground physics are not activated, i.e., the player is not transported upwards with the "ground" or slides endlessly downwards with the ledge until it comes to standstill and the ledge properly registers as a ground entity.
STiFU

STiFU

21.02.2019 17:48

developer   ~0011641

I have a feeling that the ledge might be identified as a slope and therefore doesn't interact with the player like ground does. It would be great if a mapper could assist here in trying to reproduce this behavior with varios types of elevators.
stgatilov

stgatilov

21.02.2019 17:48

administrator   ~0011642

This code is dangerous to change =)

Note the mantle animation is "on-rails", meaning that it is computed and checked on the initial time moment, and after that player moves along the schedule no matter what.
CorrectAllSolid was a hack for the case when player ends inside something after mantle. I don't remember exactly why it was necessary, but without it player can get stuck even in static case, I guess.
The reason for not calling CorrectAllSolid indefinitely is that in a dynamic situation it can easily cause player to infinitely levitate through walls, which is completely stupid. Better leave him stuck: he can usually get away with a new mantle.
All of this magic might depend on tolerances, so if you change some epsilon, you can cause some sort of troubles in simple static cases =(

To be honest, I don't get what is your problem. Mantling to the ledge is not working while mantling to other parts does?
STiFU

STiFU

21.02.2019 17:48

developer   ~0011643

Last edited: 21.02.2019 17:50

View 2 revisions

It is not 100% "on-rails" as the mantle end position is computed relative to the mantled entity and if that mantled entity moves, so does the mantle end position.

Anyway, mantling the base platform of the moving elevator works properly. However, that little beam above the elevator (i.e. the ledge) exhibits the bug mentioned before. It results in different behavior depending on movement direction of the elevator.

Unless Springheel can give some advice, I think I am going to drop this follow-up issue as I already spent 4 hours debugging this and the reason for this bug seems to be nested deeply in the physics code.

nbohr1more

nbohr1more

21.02.2019 23:09

developer   ~0011646

While you're looking into mantling, can you offer a judgement on the mantling issue in "Cleaning up the Neighbourhood"

Position: 194.9, 803.54, 194.32 : -0.12, -90.96, 0

(Back window of the main Inn\Tavern)

I was afraid your new changes did this but it seems to be
this way in standard 2.07.
STiFU

STiFU

23.02.2019 12:29

developer   ~0011649

Last edited: 23.02.2019 13:43

View 2 revisions

I tried it and sometimes, the mantle animation actually takes you floating into the air (behind you) and returns you back to the pipe, where you started, instead of the target point of the mantle. I have verified that the target point of the mantle has been computed correctly in world coordinates. These coordinates are transformed afterwards such that they are relative to the origin of the mantled entity. Either, something is going wrong with those entity-relative coordinates, or there is an issue with the mantle animation itself, which I highly doubt. In any case, this is a different issue than the one reported in this tracked issue.

Issue History

Date Modified Username Field Change
21.02.2019 17:48 STiFU New Issue
21.02.2019 17:48 STiFU Issue generated from: 0004509
21.02.2019 17:50 STiFU Note Edited: 0011643 View Revisions
21.02.2019 17:50 STiFU Status new => confirmed
21.02.2019 17:51 STiFU Relationship added related to 0004509
21.02.2019 23:09 nbohr1more Note Added: 0011646
23.02.2019 12:29 STiFU Note Added: 0011649
23.02.2019 13:43 STiFU Note Edited: 0011649 View Revisions