ZDoom

It will. After I fixed this E1M3 worked perfectly. After all, that's what I used to find it.

Yay, maybe my phantom E1M3 bug that no one else seems to have will finally be fixed. :)

Thanks for finding that. After fixing it, the problem goes away, so I can use the faster blockmap-based sight checks after all.

	for (count = 0 ; count < 64 ; count++)
	{
		if (!P_SightBlockLinesIterator (mapx, mapy))
		{
			return false;	// early out
		}

		if ((mapxstep | mapystep) == 0)
			break;

		if ( (yintercept >> FRACBITS) == mapy)
		{
			yintercept += ystep;
			mapx += mapxstep;
			if (mapx == xt2) mapxstep = 0;
		}
		else if ( (xintercept >> FRACBITS) == mapx)
		{
			xintercept += xstep;
			mapy += mapystep;
			if (mapy == yt2) mapystep = 0;
		}
// added this for checking
		else
		{
			Printf("P_CheckSight failed\n");
			break;
		}

	}

Regarding the sight check, after being told that in E1M3 of Doom this error occurs I did some checks and what I found was quite surprising:

It's neither a blockmap bug nor is the blockmap sight check algorithm inaccurate. I think this qualifies as a genuine bug. P_PathTraverse has the same problem which I was able to confirm with a few tests.

[code]
for (count = 0 ; count < 64 ; count++)
{
if (!P_SightBlockLinesIterator (mapx, mapy))
{
return false; // early out
}

if ((mapxstep | mapystep) == 0)
break;

if ( (yintercept >> FRACBITS) == mapy)
{
yintercept += ystep;
mapx += mapxstep;
if (mapx == xt2) mapxstep = 0;
}
else if ( (xintercept >> FRACBITS) == mapx)
{
xintercept += xstep;
mapy += mapystep;
if (mapy == yt2) mapystep = 0;
}
// added this for checking
else
{
Printf("P_CheckSight failed\n");
break;
}

}
[/code]

The problem is that the function occasionally runs into the 'else' branch with the Printf I have added for testing. This happens when the trace wants to change both the x- and y- blockmap coordinate at the same time. Normally *both* adjoining blocks should be checked in this instance. This code just screws up, however. What I find most disturbing in this instance is id's 'fix' to limit the iterations of this loop. Somehow I get the feeling that somebody was fundamentally unaware what he was doing (not that it surprises me with Doom's source. :( )

Theoretically this bug should make it possible in rare situations to shoot through walls although I never managed to do it.

Thanks a lot, Randy! :)

Okay, fixed them both. For 1, I put back the BSP-based sight traversal that came with the Doom source. It can be slower than the blockmap-based version that Heretic and Hexen used, but it's more accurate. For 2, I changed the check so that it won't load STCFN121 unless STCFN120 and STCFN122 are also present.

[quote="Bio Hazard"][quote="Nanami"]600 cybs[/quote]

then maybe massmouth 3 might come out sooner :D[/quote]

Heh. That would be awesome! I'd also look forward to void2.wad and Project X II (Heh, Just kidding there). :)

[quote="Nanami"]600 cybs[/quote]

then maybe massmouth 3 might come out sooner :D

[quote="HotWax"]Are you sure that's not by design? The cubes are set to go through walls, so maybe the spawner is set to see through walls as well.[/quote]
I made a large level with five spawners in the exact same spot once. Sometimes, halfway through the level (not even anywhere near the room where the spawners are), one would wake up, but not the others.

No, the brain shooter uses the same A_Look function as all the other monsters. If it can look through walls there is most likely a blockmap problem. Try to rebuild it using different node builders and see what happens.

[quote="Destroyer"]I noticed this in my TeLeFrAgGeD 1337-type map as well: The Icon of Sin demon spawners can see you no matter where in the map you are, as long as you're within what would be their line of sight, they'll always wake up regardless of whether you are in their actual LOS or not.[/quote]

Are you sure that's not by design? The cubes are set to go through walls, so maybe the spawner is set to see through walls as well.

I noticed this in my TeLeFrAgGeD 1337-type map as well: The Icon of Sin demon spawners can see you no matter where in the map you are, as long as you're within what would be their line of sight, they'll always wake up regardless of whether you are in their actual LOS or not.

I figured it was something like that (especially in Mock2 where normal Doom limits are certainly exceeded... 600 cybs anyone?), but wasn't sure if it could be fixed.

Reject has nothing to do with this. Reject is used only to determine non-visibility. If this can't be determined a full visibility check is performed. Othewise empty rejects wouldn't work.

What about the REJECT table (which is zero as per ZDBSP's -r option)? AFAIK it enables/disables "monster sees/hears(?) player if in sector..." something?