Search In
• More options...
Find results that contain...
Find results in...

# Best way to avoid "no clip" glitch without slowing player down? [linedef skipping]

## Recommended Posts

Anyone have any input on the best way to avoid the "no clip" bug in vanilla, while still allowing the player to race into the linedef at max speed? I've had some moderate success by splitting the linedef in question into 3 or 4 segments and then bowing or arching the linedefs towards the direction the player would be coming from.

Would a better way be to place 2 or more linedefs with the same tag/action far enough apart so they could not be passed in the same game tick? If so, what would be the minimum distance between them?

Not trying to be pedantic, but for clarity's sake I assume you're referring to linedef skips (walkover linedefs failing to activate as the player crosses them).

Multiple lines make linedefs much harder to skip, even if they're all close together (even a few pixels will do). Making the linedef diagonal rather than, as is common, perpendicular to the walls also tend to help. I think three diagonal linedefs in a row is fairly foolproof, outside of tool-assisted speedruns.

My knowledge on linedef skips is pretty minimal, so someone might have to step in and correct me, but I've been told that lines at odd angles (i.e. not 90 or 45) are the most reliable and skip-proof.

esselfortium said:

My knowledge on linedef skips is pretty minimal, so someone might have to step in and correct me, but I've been told that lines at odd angles (i.e. not 90 or 45) are the most reliable and skip-proof.

It has to be true from a purely mathematical standpoint. The more acute the angle is between the player's anticipated path of travel and the direction of the line, the more of the line that is contacted, and for a longer amount of time it remains in contact with portions of the player.

In order to be activated, a single move of the player's body must detect that his centerpoint will change classification of sidedness with respect to that special line during the current move. The set of candidate special lines are ones within the crossed blockmap cells which the centerpoint moves through (with various bugs in the original engine's implementation, as you can always expect).

I don't understand this tbh: no matter what the angle is, you will cross the line only once and only in a single point, no?

Thanks, guys. I think I found something pretty foolproof. At least I've not been able to invoke the no clip bug yet by playtesting.

I've got 3 linedefs, all with the same WR trigger, set up something like this:

------

--
-- --

--
- -
- -

Memfis said:

I don't understand this tbh: no matter what the angle is, you will cross the line only once and only in a single point, no?

Maybe it's like the possibility of projectiles passing through walls when their speed is higher than their radius.

The DoomWiki page for the bug mentions that activate-once lines will no be able to trigger when the bug happens, which I find pretty odd, since that implies that the crossing has been noticed somehow.

boris said:

The DoomWiki page for the bug mentions that activate-once lines will no be able to trigger when the bug happens, which I find pretty odd, since that implies that the crossing has been noticed somehow.

That's not right, AFAIK. Either it's activated or it's not.

In the linked demos for the "Noclip bug" Wiki article:
The first demo (E3M1) shows the player skipping the line (53) and then activating it on the way back.
The second demo shows the player skipping the exit line and ending up trapped down a hole.

In both those demos, the player crosses the lines without activating them (the actions are not triggered and not used up).

It mentions tags can simply fail every so often but there are specific reasons for this i.e.
Something is blocking a sector movement.
Something is blocking a teleport destination.
Something triggered the line earlier (monster or projectile).
In these cases the action will fail to trigger and will be used up but that is because the line isn't skipped (so not a "Noclip bug").

marineController said:

It mentions tags can simply fail every so often but there are specific reasons for this i.e.
Something is blocking a sector movement.
Something is blocking a teleport destination.
Something triggered the line earlier (monster or projectile).
In these cases the action will fail to trigger and will be used up but that is because the line isn't skipped (so not a "Noclip bug").

Right. That's a completely separate phenomenon. The wiki article is incorrectly conflating them. We deal with this kind of thing all the time. If somebody else doesn't fix it, I'll do it later.

I dislike the name "noclip bug". For all gamers noclip means walking through walls, etc so I don't understand why it is used here. If there is noclip bug in Doom then it is the "all ghosts" effect, not this.
"Linedef skipping" is much better and more clear.

I strongly agree.

Memfis said:

If there is noclip bug in Doom then it is the "all ghosts" effect, not this.

Or the way mancubus fireballs (and -fast imp fireballs, etc.) can pass through walls, or maybe the way the player can pass through walls map10-style or void-glide style, or (arguably) map21-style.

But yes, not this!

At least some of these problems can be gathered under "Clipping bugs" title. Or something.

I've had a map where (3?) lines (1 real, 2 "failproof" duplicates) were all skipped due to wall running. I forget if they were angled. So maybe move a vertex 1 pixel to see if that breaks wall running. Or if what you're doing is having dummmy player 1s scrolling over lines fast on conveyer belts, slow them down and make the lines closer together. I think the linedef skipping doesn't occur in zdoom. Not sure if boom cl9 handles it better than complevel 2.