View Issue Details

IDProjectCategoryView StatusLast Update
0003633The Dark ModPhysicspublic05.03.2017 07:27
ReporterAluminumHaste Assigned To 
Status newResolutionopen 
Platformx64OSWindowsOS Version7 Ultimate
Product VersionTDM 2.01 
Summary0003633: Can't use doors when pressed up against them
DescriptionSomething new with doors. You can't use them when pressed right up against them. You can highlight them but frobbing does nothing. Backing up just a little works. This makes it impossible to run through doors that are opening as they stop opening when you touch them and don't work until you move away.

This is definitely new behaviour.
Steps To ReproduceWalk right up to a door that's partially open, move the player right against it and try to open it. It doesn't matter if the door opens away from the player, it won't move.
Additional InformationYoutube video:
TagsNo tags attached.


related to 0004435 closedduzenko Investigate fp-precision related issues 




28.12.2013 04:06

administrator   ~0006326

As per discussion, this seems to be related to getting caught on the door handle itself.


28.12.2013 04:07

developer   ~0006327

Last edited: 28.12.2013 04:08

View 2 revisions

EDIT: Possibly yes, but the door handles didn't cause issues in 1.08.

I wonder if just making the door handles non solid would stop this from happening without having to go crazy with searching for code changes?



02.01.2014 03:42

viewer   ~0006341

I tried this in 1.08, 2.00, and 2.01, in the Training Mission, using the same door.

For me, it behaves the same way in each rev.

You can stop an opening door either by frobbing it or touching it. When it stops, it registers that it was opening, and the next frob is going to try to close it. So when you push against the stopped door and frob it, it can't close because you're touching it. The next frob is going to try to make the door go the other way. This time it might make a little progress, but since you're pushing against the door, it soon registers you're there, and stops. By repeatedly frobbing the door, I'm always able to get through, because the door opens a little bit at a time on those frobs that want to make the door more open. (Every other frob.)

So I'm not seeing the problem.

The door stopping when it's swinging away from you and you touch it is incorrect behavior. The code ought to be smart enough to know you're really not blocking it and it's still free to move. That should eventually get fixed.

Frobbing a moving door to make it stop makes sense, however.


02.01.2014 04:34

developer   ~0006343

That's what I'm saying:

"The door stopping when it's swinging away from you and you touch it is incorrect behavior."

That's what I was reporting, you just wrote what I was having trouble getting across.

It didn't do this in 1.08, but in 2.01 or maybe even 2.0 it does. Downloading 1.08 again on this computer, I'll try and get another video.


02.01.2014 04:59

viewer   ~0006344

I thought what you were saying was that the door wouldn't move at all and you couldn't get through. That's what I saw in the video.

If the behavior is the same in 1.08, 2.00, and 2.01, then--though the behavior is not very nice--I think it can wait for 2.02. We're trying to keep 2.01 fixes at a minimum so we can get the critical ones out there quicker.


31.03.2014 09:09

reporter   ~0006485

Last edited: 31.03.2014 09:42

View 2 revisions

Confirmed. I can reproduce it in about 1 in 3 attempts to run through a door now I've got the hang of it. It's not just every-other-frob that fails to move the door. Once the player gets stuck against the opening door, both come to a stop and the door won't move again in either direction until the player backs off, whether or not the player continues to "push".
I caught the moment this happens in the debugger. The player's clip model is intersecting the door which triggers a push check (can the door push the player) which returns false and both come to a halt. Further attempts to move the door trigger the same check until the player backs off. There's an assumption in the way this works, that if an opening door has a collision, the colliding object must be in the door's way. But that's not the only place this problem could be tackled. I haven't yet investigated the logic for the push check.



09.04.2014 09:15

reporter   ~0006517

Both tests that are giving an unhelpful answer -- the collision check and the push check -- are embedded in the physics used by all rotating movers. I'm finding this problem is highly reproducible on certain doors (without handles) but never reproducible on others, which explains the different diagnoses above. I haven't yet worked out the difference in clipmodel or fulcrum or whatever it is between the two cases, but that gives us a third potential place to tackle the issue with less chance of side-effects.


27.08.2014 00:51

administrator   ~0006900

Last edited: 14.12.2014 02:09

View 3 revisions

Don't know if this helps, but I've encountered this several times in Cleighmoor...I would be crouched and open a door, then push into it as it's opening away from me, which would stop the door(and me). At least one of the doors had a handle.

edit: have been noticing this quite a bit recently when opening a door and trying to run through it before it fully opens. Running into the door stops it. All the doors in question had handles.



14.12.2014 16:54

developer   ~0007257

That was the original issue, I wasn't sure if they had handles or not, thank you for confirming.
In my experience I didn't need to touch the handles to make the door stop.

Issue History

Date Modified Username Field Change
27.12.2013 19:25 AluminumHaste New Issue
28.12.2013 04:06 Springheel Note Added: 0006326
28.12.2013 04:07 AluminumHaste Note Added: 0006327
28.12.2013 04:08 AluminumHaste Additional Information Updated View Revisions
28.12.2013 04:08 AluminumHaste Note Edited: 0006327 View Revisions
02.01.2014 03:42 grayman Note Added: 0006341
02.01.2014 04:34 AluminumHaste Note Added: 0006343
02.01.2014 04:59 grayman Note Added: 0006344
12.01.2014 23:16 Springheel Target Version TDM 2.01 => TDM 2.02
29.03.2014 17:45 SteveL Assigned To => SteveL
29.03.2014 17:45 SteveL Status new => assigned
31.03.2014 09:09 SteveL Note Added: 0006485
31.03.2014 09:09 SteveL Status assigned => confirmed
31.03.2014 09:42 SteveL Note Edited: 0006485 View Revisions
09.04.2014 09:15 SteveL Note Added: 0006517
04.05.2014 23:59 SteveL Target Version TDM 2.02 => TDM 2.03
17.08.2014 15:40 SteveL Target Version TDM 2.03 =>
27.08.2014 00:51 Springheel Note Added: 0006900
14.12.2014 02:09 Springheel Note Edited: 0006900 View Revisions
14.12.2014 02:09 Springheel Note Edited: 0006900 View Revisions
14.12.2014 16:54 AluminumHaste Note Added: 0007257
15.02.2017 04:39 grayman Assigned To SteveL =>
15.02.2017 04:39 grayman Status confirmed => new
05.03.2017 07:27 duzenko Relationship added related to 0004435