[Sangman]

Tested on r8133
I have a sector rotating around a central pivot point, all walls are blocking. There's a raised child sector in it but that doesn't really matter.

It seems that in some very specific cases I can navigate/jump right through the blocking walls. I can't do it every time, seems to be a matter of how the sector is positioned exactly at the time of breakage.

Best case scenario: player just clips through
Worst case scenario: they die for some reason

See video below, and map in attachment

[Vadim Z]

Can it be somehow connected with the diving problem in E4L4 I've described a bit earlier? Diving into the pool with rotating sectors leads to death in versions since r7831.

[Sangman]

Derp:

Attached File(s)

•  ROTATETEST.zip (589bytes)
  Number of downloads: 196

[Doom64hunter]

There are two aspects to this glitch, one is the clipping, and the other is the "player getting killed" part.

The first aspect where the player can clip out of the blocking walls has greatly improved with newer revisions actually. Previously, with revisions as far back as r6500, it was possible to clip through all blocking walls no matter where, and the player went through them like a knife through butter.
Now it takes significant effort for the player to glitch through, and it's become way less easy to do so by accident.

Vadim Z, on 02 October 2019 - 02:07 AM, said:

Can it be somehow connected with the diving problem in E4L4 I've described a bit earlier? Diving into the pool with rotating sectors leads to death in versions since r7831.

The second aspect is indeed the same issue that Vadim mentioned here: https://forums.duke4...roblem-in-e4l4/

To reproduce the problem, have the player stay perfectly still, and simply press the jump button. The momentum of the sector is not transferred to the player, so relatively speaking the sector floor will move away from under him.
The speed of the sector happens to be great enough in order for the player to be able to clip through the wall. However, since the player has not provided any movement input, the game will continue to think that the player is on the moving sector once he has clipped through the wall.
Once the player falls to the height of the floor of the sector he was in previously to clipping through its boundaries, he will end up standing in the air, and move in circles with the sector, despite being far away from it.

From this point on, depending on which revision you are on, 3 things can happen:

• Pre r7582: After landing in the air, once the player presses any movement key besides jump and crouch, he falls off and his position switches to the surrounding sector. From this point on he no longer moves with the rotating sector and his height is corrected.
  
• Between r7582 and r7823 (inclusive): After landing in the air, the player cannot move horizontally in any direction. His movement controls appear to be locked in this state, and he will be stuck moving together with the sector, unless it moves under him again while jumping.
  
• Post r7829: After landing in the air, as soon as the player tries to move he gets crushed as if he was standing in an invalid sector (i.e. OOB). This happens even while jumping.

The revisions I indicated is where the respective behaviors started occurring. Note that revisions r7824 through r7828 fail to compile. The first of the observed behaviors is most likely vanilla Duke3D behavior, although this I haven't tested yet.
It is likely that while underwater, the player clipping with rotating sectors gets even more funky, hence why it has become impossible to go underwater in that section of E4L4 of Atomic Edition.

[Vadim Z]

Doom64hunter, on 04 October 2019 - 09:06 AM, said:

• Pre r7582: After landing in the air, once the player presses any movement key besides jump and crouch, he falls off and his position switches to the surrounding sector. From this point on he no longer moves with the rotating sector and his height is corrected.
  
• Between r7582 and r7823 (inclusive): After landing in the air, the player cannot move horizontally in any direction. His movement controls appear to be locked in this state, and he will be stuck moving together with the sector, unless it moves under him again while jumping.
  
• Post r7829: After landing in the air, as soon as the player tries to move he gets crushed as if he was standing in an invalid sector (i.e. OOB). This happens even while jumping.

Yes, that's it. Between r7582 and r7823 diving into the pool in E4L4 leaded to inability to move horizontally. There also was another effect: in the revisions close to r7823 enemies in that pool ignored Duke while underwater, attacking them caused no damage either.

[Vadim Z]

I've remembered that the same clipping problem can be seen in "Rabit transit" level. When I ride the train and jump in it, very often Duke goes through the wagons wall (and sometimes die).

[Doom64hunter]

Debugging shows that the player does indeed die because sectnum is set to -1 at line 1002 of clip.cpp, inside function clipupdatesector().
The trace shows that it originates from a call to clipmove() inside player.cpp, which triggers as soon as the player moves.

I think the central problem here is that the engine code makes the assumption that the player's containing sector cannot change if he himself does not move.
This assumption is violated by moving sectors, such as the one in Sang's test map where the player has to jump in order to move out of the bounds of the sector, as well as any moving sector underwater, where the player can float above a moving sector.

Knowing this, you can actually reproduce the same problem in other maps. Go to the start of Launch Facility (E1L6), jump on top of one of the "blades" of the turbine right at the start.
Jump again. You will notice that you are now hovering in the air. Jump again until you're standing on one of the other blades. If you try to move now, you'll get instakilled by sectnum -1.

[Doom64hunter]

It turns out that being able to clip through these moving walls, as well as the glitch where the player ends up hovering in the air, are both DOS Duke3D bugs.
However, in DOS Duke3D, the player's sector does not get set to -1 once he moves off the glitched hover state, and instead he simply falls off and moves into the correct sector.
Therefore, the death bug is the only one that absolutely needs to be solved.

To investigate and possibly fix this issue, I have tried to simply comment out line 1002 of "clipupdatesector()" in clip.cpp, so that whenever *sectnum would be set to -1, it instead remains at the previous value.

Index: source/build/src/clip.cpp
===================================================================
--- source/build/src/clip.cpp   (revision 8133)
+++ source/build/src/clip.cpp   (working copy)
@@ -999,7 +999,7 @@
                 bfirst_search_try(sectlist, sectbitmap, &nsecs, uwal->nextsector);
     }
 
-    *sectnum = -1;
+    //*sectnum = -1;
 }
 
 //

This does solve the problem where the player dies when glitching off the platform in Sang's test map. However, while it does also prevent the death in E4L4, it also raises a completely new problem, where the player is now suddenly able to clip through the walls in the pool entirely.
This means that for some reason, entering the water in E4L4's spinning sector area causes the logic in "clipupdatesector()" to completely fail. With the unaltered r8133, this kills the player immediately as the sectnum is set to -1 as soon as he enters the water.

However, if we swim down to the floor of the spinning sector, the player becomes corporeal again, and wall collision applies to him once more. There is something very strange going on with the sector teleportation effect of the water, combined with the rotating sector floor contained in it.

Even more curiously, by removing the assignment shown above, we actually also directly address the issue where actors cannot pass TROR barriers, as described here: https://forums.duke4...-tror-barriers/
With regular r8133, the Enforcer simply gets stuck on the seam of the slope and can no longer be shot -- with the above commented out, his sprite disappears for a split second, but otherwise he's able to pass it unhindered again.
So in summary, the death bug reported in this thread, the death bug in E4L4, as well as the issue where actors cannot move across TROR edges all seem to stem from the same function "clipupdatesector()" (or at least from what's occurring in clipmove())

[Sangman]

Still problematic in r8413 though I haven't been able to die yet

[Doom64hunter]

Sangman, on 08 December 2019 - 01:53 PM, said:

Still problematic in r8413 though I haven't been able to die yet

For the record, the death issue was fixed with revisions r8241 to r8245 (which also addressed the E4L4 death bug), and the player is now less prone to clipping through the walls shown in this test map, though it is still possible.

However, in DOS Duke 3D, clipping through these walls is also possible, so at least we achieved accuracy to vanilla Duke 3D.