Hitscan attacks hit invisible barriers in large open areas (vanilla bug)

For starters, here's a demo of the bug in question, in case someone isn't familiar with it already. I'm trying to document this bug for the Doom Wiki, so any information you can give about it would be useful.

Here's what I know about the bug already:
-The bigger the open area is, the more likely hitscan attacks are to hit the "barriers". There are only a few areas in the IWAD levels that are big enough to cause these problems, probably the worst being E3M6. A good way to properly test the bug is to create a level with one huge sector and fire the chaingun around the sector to find the sections with the barriers.
-The bug has been fixed in most source ports.
-And a wild guess: the bug has something to do with blockmaps.

There is a hard-coded limit of 2048 units for hitscan attacks. Could that be the cause of this effect?

From p_local.h:

#define MISSILERANGE  (32*64*FRACUNIT)

Is this the bug that causes you to run into invisible barriers in the large room at the end of E1M7 when the automatic doors are closed?

I'd guess this might have something to do with linedef 0 being considered to be in every block of the blockmap. (See P_BlockLinesIterator.)

In the example you give, the effect occurs when the line along which you are shooting intersects linedef 0 (it's behind you). I can't get this to happen when that isn't the case. If you check the other examples of this you have found, and it turns out that in each case the shot is towards/away from linedef 0, I'd say we have a prime suspect.

Ajapted said:

There is a hard-coded limit of 2048 units for hitscan attacks. Could that be the cause of this effect?

No. Watch the demo I linked to and you'll see that this has (most likely) nothing to do with that limit.

It's a nodes error. I used to get these things all the time when I used Wadauthor's internal nodes builder. They can be fixed by using a different nodes builder or changing the map in some way (like flipping a linedef) and rebuilding the nodes.

Edit: Are nodebuilders also responsible for constructing the blockmap? If so then the problem could lie there.

Stphrz, you're right that errors from ancient node builders are a possibility but I don't believe Ultimate Doom E3M6 suffers from that kind of error.

I think there's pretty conclusive evidence Grazza is right, it's the ancient "linedef 0 is in every blockmap square" problem. Apply the following patch to prboom to see which linedef is getting shot:

Index: src/p_map.c
===================================================================
--- src/p_map.c	(revision 2465)
+++ src/p_map.c	(working copy)
@@ -1486,6 +1486,10 @@
 
     P_SpawnPuff (x,y,z);
 
+    // print the line number of the line that was just hit
+    lprintf(LO_DEBUG,"%d: shot line %d at %d,%d,%d\n",
+        gametic, li - lines, x>>FRACBITS, y>>FRACBITS, z>>FRACBITS);
+
     // don't go any farther
 
     return false;

then run prboom -iwad doomu -nosound -nodraw -timedemo E3M6hsb.lmp and you get this:

336: shot line 0 at 299,2153,-92
350: shot line 0 at 281,2127,-92
364: shot line 0 at 270,2109,-92
378: shot line 0 at 272,2113,-92
392: shot line 0 at 268,2106,-92
406: shot line 0 at 271,2111,-92
420: shot line 0 at 267,2105,-92
434: shot line 0 at 271,2112,-92
448: shot line 0 at 268,2106,-92
462: shot line 0 at 268,2106,-92
510: shot line 0 at 269,2108,-92
527: shot line 0 at 269,2109,-92
544: shot line 0 at 269,2109,-92
561: shot line 0 at 269,2108,-92
578: shot line 0 at 267,2105,-92
595: shot line 0 at 268,2106,-92
612: shot line 0 at 268,2107,-92
629: shot line 0 at 268,2107,-92
646: shot line 0 at 267,2104,-92
663: shot line 0 at 266,2103,-92
680: shot line 0 at 268,2105,-92

I don't see this as a bug, bullets don't move through infinite distances neither in real life. Okey, same should happen with Rockets, but they look better the way they are in game.

Vegeta said:

I don't see this as a bug

I'd view it as a quirk, along with a lot of other oddities in the Doom engine, but in programming (and "game-logic") terms it is absolutely a bug. Note that we're not talking here about some deliberate restriction that causes projectiles or bullets to have a finite range in a consistent or logical way. What we have here:

Linedef 0 is included in every block of the blockmap. Clearly unintended, and no reason why one should suppose there is any benefit to be had from this. It also makes intercepts overflows more likely (when this occurs, it often results in a crash or the "all-ghosts bug").

Bullets can hit a piece of mid-air (not an invisible sector or an impassable linedef - pure space that the player and other objects can pass through unhindered), sometimes right in front of the player. And why? Because (and only because) the linedef with the number 0 happens to be behind him, possibly quite some distance away in some other part of the map.

The length of linedef #0 is the limiting factor, you'll notice in E3M6 that it's very long (3579 units), causing an overflow with the FixedMul in P_PointOnDivlineSide().

Wow, I thought I was the only one that saw this.

This bug is in map2 of Nilla Doom when played with Doom2.exe! Me hates it.

Well, at least you now know how to avoid the problem.

Grazza said:

I'd guess this might have something to do with linedef 0 being considered to be in every block of the blockmap. (See P_BlockLinesIterator.)

In the example you give, the effect occurs when the line along which you are shooting intersects linedef 0 (it's behind you). I can't get this to happen when that isn't the case. If you check the other examples of this you have found, and it turns out that in each case the shot is towards/away from linedef 0, I'd say we have a prime suspect.

Heh, Grazza is close to a coding of own engine if he can explain such things so easily :)
prboom++ soon

Sadly I quit programming when I was a teenager. It's like a foreign language to me nowadays. :(