Duke3D: New swinging door behavior can prevent map progression
This is related to #61 but I'm opening a new issue to bring more attention to it.
The swinging door behavior introduced with ed5d2265 changes the behavior such that a swinging door that is blocked by an actor will automatically close. This makes the assumption that each swinging door can be activated repeatedly, however, this need not be the case. If a swinging door is operated by an activator which can be used exactly once (for example a keycard switch), then there is exactly one chance for it to fully open. If it is then blocked by an actor, it will close and stay locked forever.
The original DOS behavior did not have this problem, as the door would take priority and push everything out of its way or crush actors in the process. The previous revision of these doors in eduke32 (see: 4c4fdd1f) changed the DOS behavior such that a swinging door waits until the actor moves out of the way, and only afterwards completes its movement. This prevented crushing but otherwise still ensured that the door could eventually fully open.
The new behavior makes no such guarantees, and thus may break old usermaps. In fact, any map that uses activator-operated swinging doors could be rendered incompletable simply through an actor being in front of such a door at the wrong time.
The following map demonstrates the issue: swinging_door_bug.map