Difference between revisions of "Talk:Noclip bug"

Revision as of 15:56, 16 January 2008

I seem to recall that this one also has a broad form, like the "all-ghosts bug". Every once in a great while, I'll be playing a level and a certain teleporter (for example) just refuses to work at all until I exit the engine and restart, at which point it begins to operate normally. I'm not sure how to go about reproducing this in a controlled fashion, though. (Maybe the node builder in WinDEU is a bit wobbly, or is really designed only for vanilla.) Ryan W 22:00, 23 Jun 2005 (UTC)

When I watched the COMPET-N demos for E2M2, this bug seemed to occur with unusual frequency at what our article calls secret #1 (linedef 1491).  I've always been told the bug is garden-variety roundoff error in the computation of the player's x-y position, which means that no linedef is more susceptible than any other, which means that my observation is pure statistical coincidence.  On the other hand, someone with VERY good technical intuition is apparently keeping an open mind.  Not a life-or-death issue, but I thought I'd note it here before I forgot about it.    Ryan W 11:12, 16 September 2007 (UTC)

I'm pretty sure that a linedef will fail to activate if you cross it but never actually collide with it. What I mean is, if you are going at a considerably high speed, you will "skip over" the linedef without activating it. Notice that the bug happens much more frequently if you have turbo set, especially on higher values. Now, why you can't cross impassible lines at very high speeds, is totally a mystery to me. -Wagi

Probably because to cross an impassable linedef, the clipping check would have to fail for *every* tic during which your body intersected the wall (somewhere between 32 and 46 map units of motion), whereas for the noclip bug, it only has to fail once, for the tic after your center point has crossed the line.    Ryan W 22:27, 10 January 2008 (UTC)

I am a little confused by this statement. If Doom checks the latter collision (a teleporter linedef for example) by testing that your center point has crossed the line, this means the engine must remember your center position from the previous tic, and then test to see if there is an intersection between the linedef and the path between the center positions for the two tics, to determine if the linedef was crossed. This means it's impossible for the bug to occur the way Wagi explains it, because his explanation relies on a frame-by-frame collision check. Zack 03:17, 11 January 2008 (UTC)

You're probably right, although I've read that the engine merely compiles a list of which side of each tagged linedef you're on, and updates the list whenever you move between subsectors.

Roundoff error seems to be hard to associate with a specific function in the source, so unfortunately most explanations of this sort of thing end up being nontechnical, not just mine for once.   :D     Ryan W 03:46, 11 January 2008 (UTC)

Zack, I'm saying that maybe it doesn't check it if your bounding box never touches the line. A good way to test this is to see if changing your radius to a very large number makes it less frequent. I've used dehacked to set my radius really low and it made the phenomenon a lot more frequent (it also occasionally allowed me to pass through both impassable and one-sided walls). -Wagi 69.51.157.227 20:56, 16 January 2008 (UTC)