DieHard Wolfers

[linuxwolf]

If you ever have problems with guards peering through partially open doors you can try the following fix. It works for me.

Replace the red lines with green lines in CheckCoordLine.

::: CODE :::

intercept = yfrac-ystep/2;
intercept = xfrac-xstep/2;
intercept = ((yfrac-ystep/2)-(y<<8))<<8;
intercept = ((xfrac-xstep/2)-(x<<8))<<8;

And add these green lines to CheckCoordLine in the appropriate places which you can tell from the comment lines.

::: CODE :::

            if ((yfrac-ystep/2)>>8!=y)
                continue;


            //
            // see if the door is open enough
            //

::: CODE :::

            if ((xfrac-xstep/2)>>8!=x)
                continue;


            //
            // see if the door is open enough
            //

[Chris]

On the other hand, if a guard sees a door opening, it makes sense that he would react to it (unless he knows it's another patrolling guard). They might be trained to do exactly that. If you close your door in room, and someone opens it, you won't wait until you see a person to notice, so perhaps the original behavior makes sense? Am I understanding this right?

Nice to see this getting it's own thread. I think the posts starting here could either be deleted or merged here now too.

[linuxwolf]

That isn't the intent if you look at the code. From a game design perspective something like that would make sense. I still hold that it is better to have correct code than incorrect code. It matters more if you want to expand upon the game design without a buggy foundation.

I was too lazy to check the DOS source code but I would expect this bug began its life in Wolf4SDL.

Whatever you have planned with merging topics is fine so long as this topic remains intact. I don't want the issues being confused again.

[AlumiuN]

The other problem with that theory is that they don't know who's opening the door, but they don't respond to other enemies opening it, only the player

[Matthew]

linuxwolf wrote:

I was too lazy to check the DOS source code but I would expect this bug began its life in Wolf4SDL.

No, it has always existed.

My original fix was for Wolf4SDL, but the new code I just posted is for 16-bit Wolf3D. I have updated the posts I posted for the SDL version as well. The code is exactly the same for 16-bit Wolf3D and Wolf4SDL.

I have always known about this. I remember noticing in 1999 when I played Armageddon that on Level 1, when you opened the doors to the 1 tile rooms with mutants, the mutants would shoot you when the door had barely started to open. I just assumed that the game didn't take the physical position of the door into account.

I remember reading about this in the map editing guide included with MapEdit ("wolfsod.doc"), which was written by Warren Buss. Here is a quote from it:

Quote:

One of the more critical examples is designing an opening sequence which has the player standing in a room 1 or 2 squares deep and 1 square wide with the a door immediately in front. As soon as the door is opened, and a shot is fired which alerts numerous guards, the player will be overwhelmed. Particularly if the guards are officers or mutants and a better defensive position cannot be taken by moving out into a larger area.

The problem is exascerbated by how doors are programmed to open. As far as the program is concerned, the door is considered open the instant someone (the player or a guard) signals it to open. The program does not wait for the door to physically move far enough so actor and player are visible to each other. The mutant guard shoots so fast that the player won't even see the door start to move before the mutant's shot arrives to kill or maim. There's no defense except to try and kill a guard in the doorway so the door will stay open. But if nothing but officers and mutants arrive first, there is little hope of doing this. Besides, guards don't usually try to enter the room before shooting unless the player is out of sight.

Warren didn't know that this is a bug in the game.

[linuxwolf]

I suppose one issue is that if fixed it may break existing demos. This could explain why it wasn't fixed for so long. For me demo support doesn't matter so much.

[Tricob]

The solution to making progress in some maps isn't always obvious. Self-running demos are an excellent way of giving the player a minor guide without giving away all the challenge and surprises of the level. So there are many times where the self-running demos can be extremely important.

[Robbbert]

Consider what would happen in real life. If you were a guard, and a door opened nearby, you would turn around at the sound and see who opened it. If it was another guard you'd go back to what you were doing, otherwise start shooting. A deaf guard would of course do nothing unless an enemy came into his line of vision.

As for mutants, who knows how they think - they might be unpredictable.

How far should a door be open before bullets can go through? Personally, I think halfway would be reasonable, but of course maybe someone could get a lucky shot through a smaller gap.