DieHard Wolfers Forum Index DieHard Wolfers
A Wolfenstein 3d Fan Community


  Hosted by: MCS & Areyep.com - Designed by: BrotherTank

Original Yahoo Forum - Die Hard Archives

AReyeP HomepageAreyep Homepage DieHard Wolfenstein BunkerDieHard Wolfenstein Bunker Log inLog in RegisterRegister Banlist FAQFAQ Search ForumsSearch

  Username:    Password:      Remember me       

Bugs & Fixes in the Original Wolf3d Code
Page 1 of 2 Goto page 1, 2  Next
DieHard Wolfers Forum Index -> Code Crackers View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page BottomView Next Topic
Post new topicReply to topic
Author Message
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Fri Jun 24, 2005 10:23 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Next PostGoto Bottom of Posts

Chris: I'll be exploring some bugfix possiblities over the next couple of weeks. There's one bug I haven't mentioned in these forums:

When a saved game is loaded, any Pushwall that's been opened is not read as a floorcode where the pushwall originated.

What I mean is this: Let's say a Pushwall is on Coordinate 9,9 of the map. You push the wall, then save.

Any time you'd load up that game, the walls might appear to be where they should be, and you can move around through the level normally. But there's one glitch. Coordinate 9,9 is still read as a wall (or Invalid, I don't know which yet).

This means that any time a door opens or closes when you're on Coordinate 9,9 of the map, the game can't determine what floorcode you're on. So the code scans *all* the floorcodes at one time, sending all non-Deaf guards after you with the first two shots you fire! This is very problematic when you design heavy attacks where a pushed wall can provide a Safe Haven for the player. It's far too easy to trigger the bug by accident in that case.

I think the fix would be to have the player's current floorcode stored in a variable, then add an IF statement to change it to the value 6A (Deaf Guard floorcode) if the value is below 6A. Not terribly efficient, but it just might work.

I'm going to attempt to do this fix myself. I need to get back into coding again anyway.

Edit: Fixed a Hexadecimal mistake. The floorcode should be "6A", not "8A".


Last edited by Tricob on Sat Jun 25, 2005 6:35 pm; edited 1 time in total
Adam Biser
Utility Developer
Utility Developer


Joined: 06 Jun 2003
Last Visit: 20 Apr 2018

Topics: 46
Posts: 2307
Location: USA
usa.gif

PostPosted: Fri Jun 24, 2005 10:51 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Or you can make a loop similar to the one that removes the ambush markers, but instead sets the floor code for secret areas without a corresponding tilemap value.

Plus there's always this possibility in "Thrust" in WL_AGENT.C:
::: CODE :::
   if ((*(mapsegs[0] + offset) >=AREATILE) && (*(mapsegs[0] + offset) <AREATILE+NUMAREAS))
      player->areanumber = *(mapsegs[0] + offset) -AREATILE;

And then you have your areanumber saved, it's always valid, no more mystery textures on walls... all is good.

_________________
Orb of Dilaaria now has a Facebook page
Star Wars: Bloodlines now has a Facebook page
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Fri Jun 24, 2005 11:26 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
This means that any time a door opens or closes when you're on Coordinate 9,9 of the map, the game can't determine what floorcode you're on.

I wonder if it's caused by the same thing as this bug?

http://games.groups.yahoo.com/group/wolfenstein3dfanclub/message/3191

Most of those bugs were fixed at about the time the Pushwall Distance Mod was posted, by resetting a few states, and saving more pushwall related things into your savedgames in WL_MAIN.C. Also, any invalid floorcode won't alert the guards anymore (similar to what Adam posted). I'd still encourage you to try your hand at this and see what kind of conclusions you come up with though. I've tried saving while a passage starts moving in memboost, then going into another episode (to reset the tilemap/mapsegs) and loading the savedgame again, and the mapsegs always gets the correct floorcode (which was 110, as I was using the brown room in E1L1); but feel free to test it out and see if it works better here. If you press Tab-F, it'll show the tilemap/actorat/mapsegs numbers under your position; and the one under f-1 is the floorcode (usually around 90-127 when they're valid). If it matches with the floorcodes around you, you should be ok.

Speaking of weird pushwall bugs, I like it how sometimes a wall will still be moving when you go to the next level in the original exe too (it was hilarious the first time I saw that, I had pushed a secret wall in E1L1 right before going to E1L2, and then saw a wall in the second room moving in Level 2 for no reason - haha). But, maybe this conversation should be moved to a different thread than "Freeing Up Memory". Laughing
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Sat Jun 25, 2005 8:23 am
   Subject: Re: Bugfix.... Pushwall floorcode
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
When a saved game is loaded, any Pushwall that's been opened is not read as a floorcode where the pushwall originated.


I fixed that problem by adding just one line of code to the "Pushwall" routine in the WL_ACT1.C file, just before the SD_PlaySound call....

::: CODE :::
MAPSPOT(pwallx,pwally,0) = MAPSPOT(player->tilex,player->tiley,0); // Set the floor tile code


so basically your routine would look like:

::: CODE :::
   MAPSPOT (pwallx,pwally,1) = 0; // remove P tile info
   MAPSPOT(pwallx,pwally,0) = MAPSPOT(player->tilex,player->tiley,0); // Set the floor tile code.
   SD_PlaySound (PUSHWALLSND);


All the line does is set the pushwall position to the floor code the player is standing on when they pushed it. If you installed Adam's Mutli-Floor Texture modification to the Texture floors/ceiling it adds the same thing. I found this when I went to install his mods into my current source version and noticed I had already added the same line earlier... lol...

Hope that helps...

Greg
BrotherTank
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Sat Jun 25, 2005 2:18 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Looks interesting Greg. It's cool that we've all already noticed and fixed many of the pushwall bugs. I wonder, has anyone ever figured out how to fix the "gap" bug where you'll see a transparent line sometimes when you look through a corner of a wall? Tricob mentioned something about it here, and Ripper elaborated on it a little:

http://diehardwolfers.areyep.com/viewtopic.php?t=3014&#2

Just another one that could be fun to pinpoint. Smile
I really think our last 5 posts aren't related to the point of this thread though - and deserve their own to avoid confusion (maybe "Bugs/fixes for the original Wolf3d").
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Sat Jun 25, 2005 5:01 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Chris wrote:
Looks interesting Greg. It's cool that we've all already noticed and fixed many of the pushwall bugs. I wonder, has anyone ever figured out how to fix the "gap" bug where you'll see a transparent line sometimes when you look through a corner of a wall? Tricob mentioned something about it here, and Ripper elaborated on it a little:

http://diehardwolfers.areyep.com/viewtopic.php?t=3014&#2

Just another one that could be fun to pinpoint. Smile
I really think our last 5 posts aren't related to the point of this thread though - and deserve their own to avoid confusion (maybe "Bugs/fixes for the original Wolf3d").


Yep... they could be moved... will do shortly... lol...

As to the problem of the gap... Seen this too many times... lol.. And I actually had the problem very bad in the Wolfplus code. The directional sprites exagerated it even worse... and strangely enough, when I switched to the NewWolfClassic Raycastor, the problem has been all but removed. Looking at the code, it probably has something to do with the calculations as to the angles of the walls as viewed by the player. There must be a correction that Darkone caught that wasn't caught in the original source. I have a feeling that it's in the "Transformtile" routine and/or the "WallRefresh" routines in the Wl_draw.c file...

Hope that gives you a little help...

Greg
BrotherTank
Adam Biser
Utility Developer
Utility Developer


Joined: 06 Jun 2003
Last Visit: 20 Apr 2018

Topics: 46
Posts: 2307
Location: USA
usa.gif

PostPosted: Sat Jun 25, 2005 5:06 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

I believe it's in the ray-tracer itself. I believe you can actually see through the gap. I thought Ripper had solved this about a month ago... I'd have to check.

EDIT: Nevermind, I was thinking of this bug when I thought of Ripper: http://diehardwolfers.areyep.com/viewtopic.php?p=34435&highlight=#34435

_________________
Orb of Dilaaria now has a Facebook page
Star Wars: Bloodlines now has a Facebook page
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Jun 25, 2005 6:29 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Greg - Thanks (yet again) for the bugfix. I owe you big time; you've been a ton of help for me lately. Too Cool

Re: wolf3dfanclub thread. There's a catch to using this trick. Since the pushwall was still moving after the level restarted, you can't get a 100% Secret ratio without restarting the level or loading a game. Yet *another* Pushwall bug! Actually, it's pretty easy to fix; a couple of variables just need to be reset when the level is restarted. I can probably do this myself.

Re: Seeing between walls and doors - I'm pretty sure it's in the raycaster, too. Notice how the walls "split apart" when you start to move through them in "No Clipping" mode in SOD.

Now that I think about it, the Windows port of Wolfenstein called "Lone Wolf" actually has the problem fixed. I'll try to find a direct link to the source again, but I can say for sure it's found at a post in the Wolf3D Dome, along with the newest version.

Let me say that Lone Wolf does *not* use OpenGL, so it should run a good speed even if you don't have a 3-D graphics card (and I don't).
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Jun 25, 2005 7:27 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Chris - Does your Memboost code include the bugfix entitled "Sprite Width Size Limit Fix"? The bugfix was done by Darkone.

http://diehardwolfers.areyep.com/viewtopic.php?t=1576
Zombie_Plan
DieHard Wolfer
DieHard Wolfer


Joined: 12 Oct 2004
Last Visit: 07 Jun 2016

Topics: 101
Posts: 1614
Location: A hole in the wall
australia.gif

PostPosted: Sat Jun 25, 2005 10:23 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
Chris - Does your Memboost code include the bugfix entitled "Sprite Width Size Limit Fix"? The bugfix was done by Darkone.

http://diehardwolfers.areyep.com/viewtopic.php?t=1576


It does. I'm not chris, but I have used the source,and it does.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sun Jun 26, 2005 7:15 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Re: Lone Wolf.

Tricob wrote:
I'll try to find a direct link to the source again, but I can say for sure it's found at a post in the Wolf3D Dome, along with the newest version.

Okay, here's the link to the source:

http://www.users.globalnet.co.uk/~brlowe/LW086_src.zip

and the EXE:

http://www.users.globalnet.co.uk/~brlowe/LW086_win32.zip
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sun Jun 26, 2005 10:15 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Re: Memboost. Anyone know how to get the code to compile using 200 ammo instead of 99? The compiler's giving me some sort of Comparison errors after I transferred the Ammo Max code to Memboost.

Thanks. Smile
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Mon Jun 27, 2005 12:25 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Ah, I changed it's max to 128 (as it didn't go above 99 originally).
If you want to change it back, just replace the section in the gamestate structure of WL_DEF.H from the first to the second:

::: CODE :::
   int          health, angle, savecount;
   char      lives, ammo, keys, faceframe;

::: CODE :::
   int          health, ammo, angle, savecount;
   char      lives, keys, faceframe;

Also, I don't mind sharing the source, but it's possible that adding certain features may require you to do something different for a few word-for-word tutorials (nothing major, maybe using a different command or changing the amount for a certain variable). I tried to limit that, but because of some of the changes, I'm sure something will find a way to need a different kind of change (ex: bosses are now called by Deathshead's SpawnBoss routine, spotvis is now 254 on the tilemap, actorat doesn't use pointers anymore, player->angle is now gamestate.angle, etc.). I guess it's up to you to figure out how to alter the source to fit your needs, just like Greg has done with newwolf, but all of the changes are listed in the readme, and I'll try to help out in these cases. Just giving you a heads up about that if you get an error.

I've re-uploaded ^ as an int to avoid confusion though (since it's only 1 byte difference anyway, just like health). So, you're working on an addon Tricob? Smile
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Mon Jun 27, 2005 6:21 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Thanks for the help, Chris. Smile I'll probably stick to the source I had though, at least this time. Altering the new code is definitely not beginner's stuff, and I'm definitely a beginner in the C department. Mouth Shut

OT -

Chris wrote:
So, you're working on an addon Tricob? Smile

Yes. I've tried not to say much about it, although I made a thread about its storyline in the "Tale Tellers" section, and I've posted my Guard Replacement in the Artists' section.

So why have I not said much about it? Basically, because when I say a lot about what I'm working on, it tends to not ever get done. Sad

But, it's pretty much just a "turn-your-addon-into-a-TC" project, with fixes to numerous EXE bugs that kept the original addon from being more popular (not to mention a text file filled with *way* too much information). The addon was called "Operation: Kill BJ!", and I did a small follow-up called either "SOD-RMK" or "RMK-SOD". Both are in the Wolf3D Dome.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Tue Jun 28, 2005 6:50 pm
   Subject: Can't fight OT, so I midaswell join the cult
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Tricob wrote:
I'll probably stick to the source I had though, at least this time.

Ok. Thanks for the feedback anyway. I'll keep working on it in the meantime. Wink

About the addon question, I had a hunch that you might have been talking about "Operation: Kill BJ", and your idea to expand upon it, but I thought it might have been awkward to change the ammo for a game where you've already made the levels with '99 ammo max' in mind (and if adding more would mean that you'd have to adjust some ammo/enemies/strengths accordingly). I guess it's not that unusual if this feature was something that you wanted to do all along though, and 200 seems to look more professionally appealing than 99 - heh. I feel similar in regards to the "talking about things too much" viewpoint you mentioned too.

I actually tried your addon today Tricob, and it's definately been a positive experience so far. The graphics are quite refreshing for me on many levels. If there was a bar between video game style graphics and realistic graphics, and wolf3d was in the middle, I'd say yours definately has that nice oldschool, funner, happier, video game flavour that is absent from most popular addons. The pictures on the walls (like the planets, flowers, and boats) bring out a special imaginative mood, same with the futuristic doors/sides, interesting tetris-ish shapes that connect, and colourful shades on the walls.

Some of the level layouts were very intriguing to watch in action. I started going through each episode a little, and played all of the included savedgames a bit for fun. A few that stuck out well so far were the epic opening hallway of E3L1, and the interactive weirdness of E2L7. That idea you had for E6L6 with the two paths rocks hard; it's crazy how similar it is to what I wanted to do for a weird secret Level 25 in Chokage (where you could access the secret level from two different episodes, each being one side of the level where you can see to the other side via poles/objects as a tease, that would eventually meet up). I'll have to keep playing your addon so I can see even more of these ideas come to life, or even just to find some more interesting layouts.

The story didn't overly catch my attention until the last two sentences; which really made me laugh. I liked reading the saved game descriptions and the level ratios concept in the readme. It's cool that the same bugs we've been talking about on here lately were noted inside too; that was an interesting surprise. I also just checked out the stories you recommended in Tale Tellers, and if the "Master Brain" you have to face is who I think it is (which, coincidently, would have been the same concept as the real "Live Brain" in Chokage if I would have gotten far enough to execute everything); then it is a really freakin' bizarre and mind blowing idea! Especially if you told it in a way that makes the hero start asking themselves the most screwed up questions about themselves, their past, and "Master Brain".

Heh. I just figured out what OT means. So I guess this message would be OTFRS of OT. Very Happy

Tricob wrote:
When a saved game is loaded, any Pushwall that's been opened is not read as a floorcode where the pushwall originated.

I haven't been able to replicate this bug you guys are talking about.
Doesn't a pushwall get called to the correct floorcode when it runs this section of MovePWall?

//
// the tile can now be walked into
//
tilemap[pwallx][pwally] = 0;
(unsigned)actorat[pwallx][pwally] = 0;
*(mapsegs[0]+farmapylookup[pwally]+pwallx) = player->areanumber+AREATILE;


So, other than if you die or switch levels while a pushwall is moving, how does the pushwall floorcode become invalid? Even if it does become invalid somehow when you load/save your game, I don't see how Greg's fix would help anything (as it's only called before the pushwall even starts to move, so any savedgame wouldn't read that code, and the info wouldn't be saved into a savedgame anyway, because savedgames don't keep track of your mapsegs info, only the info from the tilemap and some pushwall states). Am I making sense here? Does this savedgame bug actually exist, or did you guys somehow mistake it for the "died while a pushwall is moving" bug? If not, can someone give me a savedgame/exe when this bug will occur because of savedgames or explain how it works? That would be quite helpful.

@Greg: Thanks for your clues as to where the "gap" bug might be found, and for the info about Darkone's raycastor.


Last edited by Chris on Tue Jun 28, 2005 7:52 pm; edited 1 time in total
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Tue Jun 28, 2005 7:52 pm
   Subject: Re: I can't fight OT, so I midaswell join join the cult
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Thank you for your kind words regarding OKBJ. Very Happy

Quote:
About the addon question, I had a hunch that you might have been talking about "Operation: Kill BJ", and your idea to expand upon it, but I thought it might have been awkward to change the ammo for a game where you've already made the levels with '99 ammo max' in mind (and if adding more would mean that you'd have to adjust some ammo/enemies/strengths accordingly). I guess it's not that unusual if this feature was something that you wanted to do all along though; and 200 seems to look more professional in retrospect than 99 - heh.

Some of my levels in OKBJ seems to be a bit bigged down to me because of the 99 Ammo restraint. In Level 6 of Episode 6 for instance, I had to place hidden groups of ammunition right in the middle of the attack involving all those locked doors, lest the player run out of ammo midway through the onslaught! This map change was really awkward for the gameplay, but since I wasn't ready to re-code the EXE, I didn't have much choice. I also couldn't put in hidden enemies in that level because I didn't have room on the Static Objects List. With the code changes I've made, the level now plays the way I want it to, minus one sequence that I intend to re-do from scratch.

Quote:
That idea you had for E6L6 with the two paths rocks hard; it's crazy how similar it is to what I wanted to do for a weird secret Level 25 in Chokage (where you could access the secret level from two different episodes, each being one side of the level where you can see to the other side via poles/objects as a tease, that would eventually meet up).

The idea for that level was actually inspired by someone I knew who had "Split Personality Disorder". If you knew someone with such a disorder, it would be easy for you to come up with such an idea on your own. Smile

Quote:
It's cool that the same bugs we've been talking about on here lately were noted inside too; that was an interesting surprise.

One bug I left out is one that I never knew how to fix in the code: On Level One of Episode One, the player can move through any enemy standing on the pre-killed guard in the room you start in. This bug exists in the original level too, but in mine it's much more noticable. To "fix" the problem, I changed a debris sprite to that of a dead guard, and used it as a "Dead Guard" substitute. Razz

Quote:
I also just checked out the stories you recommended in Tale Tellers, and if the "Master Brain" you have to face at the end is who I think it is (which, coincidently, would have been the same concept as the real "Live Brain" in Chokage if I would have gotten far enough to execute everything); then it is a really freakin' bizarre and mind blowing idea! Especially if you told it in a way that makes the hero start asking themselves the most screwed up questions about themselves, their past, and "Master Brain".

Hm ... it sounds as though you're at least partly right here. After the Master Brain dies, and BJ learns who the bad guy was in the past, he probably feels a bit guilty (not to mention spooked) for killing all those RIs and their newer forms. And I bet he can't help but wonder what the MB would have been like facing had no RIs or their follow-ups been killed.

Quote:
So, other than if you die or switch levels while a pushwall is moving, how does the pushwall floorcode become invalid?

Well, the bug doesn't show up until *after* you load up a saved game. Let's say you pushed a wall on square (9,9) of the map and saved your game. It will behave normally then.

But, when you *load* the saved game, then should a door open or close when the player is on square (9,9) of the map, *that's* when the bug occurs. Cheesy Grin
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Wed Jun 29, 2005 5:38 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

@Chris.... You are right... I can't remember why I came up with that line originally, but when I went to install Adam's Patchwall tutorial, he also did the same thing. I think the main reason that I did that was because the other line looked like the same as the door operation.. ie open the door and both rooms are assigned the same area code for "makenoise" purposes in alerting gaurds.... The line I added just sets the floors position to the same floor code that the player is standing on.. not the combined area code. Not sure if that makes a difference...

-----------------------
And for the topics sake... Even if you don't install my 64+ tutorial... you should install at least this portion of the code to remove the door in a corner bug (disappering door sides bug):

::: CODE :::

int CheckAdjacentTile (int x, int y)
{  // Part of 64+ Wall Tiles - Make sure within Map Boundaries
   // to fix bug of not allowing 64+ in outer edge of map
   // Checks Adjacent Tile for Bit 7 Set - Door or Pushwall
   if ((y-1 >= 0) && (tilemap[x][y-1] & 0x80)
   || (y+1 <= 63) && (tilemap[x][y+1] & 0x80)
   || (x-1 >= 0) && (tilemap[x-1][y] & 0x80)
   || (x+1 <= 63) && (tilemap[x+1][y] & 0x80))
    return 1;
   else
    return 0;
}

Insert the above function above the HitVertWall function... and then change the following lines in the HitVertWall and HitHorizWall routines:

::: CODE :::
IN THE HitVertWall FUNCTION:

if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit)

REPLACE WITH:

// Fix for door graphic problem with 2 doors in a corner
if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit && !CheckAdjacentTile(xtile,ytile))


IN THE HitHorzWall FUNCTION:


if (lastside==0 && lastintercept == ytile && lasttilehit == tilehit)

REPLACE WITH:

// Fix for door graphic problem with 2 doors in a corner
if (lastside==0 && lastintercept == ytile && lasttilehit == tilehit && !CheckAdjacentTile(xtile,ytile))


Hope that helps...

Greg
BrotherTank
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Wed Jun 29, 2005 6:34 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

BrotherTank wrote:
@Chris.... You are right... I can't remember why I came up with that line originally, but when I went to install Adam's Patchwall tutorial, he also did the same thing. I think the main reason that I did that was because the other line looked like the same as the door operation.. ie open the door and both rooms are assigned the same area code for "makenoise" purposes in alerting gaurds.... The line I added just sets the floors position to the same floor code that the player is standing on.. not the combined area code. Not sure if that makes a difference...

Apparently, it does. I tried it out on my Level 8 of Episode 6, where that bug occured quite often. After entering the line you posted, I could no longer replicate the bug. Excellent work! Smile

With that glitch out of the way, there's one more bug I have yet to fix. If the player tells the door to open, neither he nor the enemies can walk through it when it's opening or closing. However, should an *enemy* signal a door to open, both the player *and* enemies can walk through it before the door is completely open. This even causes an Officer to "disappear" into the same square as the player under certain conditions, much like the dog did in the doorways when using the unmodified Wolfenstein code.

I think the same thing causing this problem is also causing objects marked "BLOCK" (such as a column) to be "transparent" (i.e. you can walk through it like an empty square) if a moving guard is right in front of it at the start of the game. My hunch is that the moving routine for the "Actor" is restarted whenever this actor should signal a door to open.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Wed Jun 29, 2005 8:32 pm
   Subject: Screw OT, this topic title should be embraced now heh
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Ah! I understand what you mean now Tricob. For some reason, I thought you meant that this pushwall bug occured when you save while a pushwall is still moving (as that's when a few bugs I noticed occured), but I just clued in that you meant "saved games that have already been fully pushed". That's quite an interesting situation how the mapsegs has to load the original wall data over the empty pushwall tile! I'm sure that I've come across that bug before (which might have been another reason why I saw the Gray Stone walls). As Adam posted, something that just restricts your areanumber from getting called when invalid would work, or doing a check to replace those blocks for blank tilemaps + pushwall objects in a way similar to the ambush marker removal code (as Adam also already stated). Nice bug catches there Tricob. Smile

Another one to add to the list: The "enemy getting stuck around the corner" bug. When directly around a corner, the enemy sometimes just stands there running, but doesn't move positions. You can't shoot each other until you move, but you can stab him with your knife. This also works with bosses, so a boss can be stabbed until death when you get him stuck around the corner (how cheezy!). Might be a fun bug for us to pinpoint.

BrotherTank wrote:
You should install at least this portion of the code to remove the door in a corner bug (disappering door sides bug).

Yes, I'm using this one too. Pretty cool trick that makes the door sides work right under all conditions. I remember being able simplify the code a little in the 64+ thread so that only vertical/horizontal walls would get called during each function; but I suppose that doesn't matter too much.

Tricob wrote:
One bug I left out is one that I never knew how to fix in the code: On Level One of Episode One, the player can move through any enemy standing on the pre-killed guard in the room you start in. This bug exists in the original level too, but in mine it's much more noticable.

This is another one I haven't been able to replicate yet, but tried a few times when reading your inital post about it (using the E1L1 example). Maybe I'll try getting those mutants to run through the dead guard pile on E2L7 and see if that makes them easier to walk through. Maybe this is also the reason who Octivious described that those mutants are easier to kill in that area on this thread? I gotta play around with your guard/player opening door stuff now too to see the differences you described (which I actually remember going "wtf?" to in a few levels too). Some fun things to explore! Geek Cheesy Grin
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Wed Jun 29, 2005 11:01 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

I've run across that bug as well... When the player opens the door, the door must be fully opened before the player or anything may pass through it, while when an enemy opens the door you can pass through it before it has opened completely.

It might be worth checking to see if the enemies are limited as the player is to a width dimension, and if not, adding something so that the enemy can't start moving until the door is completely opened... It almost looks like the map trick of having a moving guard stuck in a wall trick...

As for Chris's bug... I too have encountered this as well.. and it was one of the things on my list to check out... I wonder if maybe both bugs are somewhat intertwined... I think it might also have something to do with the enemy AI.. in that when they are blocked, they are supposed to choose a new path... but this bug is caused by both the player and the enemy trying to move into an empty space... as such, both are blocked from moving there, and the enemy doesn't stop trying to move into the space and choose a new path because in fact the tilemap shows it as being free to move into.... but neither can move into the open space due to the MINDIST setting...

Hmm... This has got me thinking...

Greg
BrotherTank
Zombie_Plan
DieHard Wolfer
DieHard Wolfer


Joined: 12 Oct 2004
Last Visit: 07 Jun 2016

Topics: 101
Posts: 1614
Location: A hole in the wall
australia.gif

PostPosted: Thu Jun 30, 2005 4:46 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Chris wrote:
Ah, I changed it's max to 128 (as it didn't go above 99 originally).
If you want to change it back, just replace the section in the gamestate structure of WL_DEF.H from the first to the second:

::: CODE :::
   int          health, angle, savecount;
   char      lives, ammo, keys, faceframe;

::: CODE :::
   int          health, ammo, angle, savecount;
   char      lives, keys, faceframe;



I found unsigned char to work better, it works from -255 to 255 (i think, it could be 0-255) and its smaller than an int variable.

Chris wrote:

Also, I don't mind sharing the source, but it's possible that adding certain features may require you to do something different for a few word-for-word tutorials (nothing major, maybe using a different command or changing the amount for a certain variable).

I found this problem when I tried to add Animated Walls (DarkOne) back with EZCODE 3 (hehe, dead now Sad ). Maybe we need a seperate thread specially for Memboost?

Chris wrote:

bosses are now called by Deathshead's SpawnBoss routine


Cool, My stuff is being used. I'm Famous!
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Thu Jun 30, 2005 5:36 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

BrotherTank wrote:
It might be worth checking to see if the enemies are limited as the player is to a width dimension, and if not, adding something so that the enemy can't start moving until the door is completely opened... It almost looks like the map trick of having a moving guard stuck in a wall trick...

Yup. I was looking at this, and there are few interesting things to note in WL_STATE.C. First, if CHECKSIDE sees that the actors destination is a door, it does not return false. Instead, it continues the TryWalk function and moves the actor into the door's position; then runs the door opening routine. If you add a "return" to that portion of CHECKSIDE, it keeps the guard from walking through the door before it opens, but it also won't let you get to the OpenDoor section at all. Only the second step should take place, we need to skip the first one somehow. I think the best way to make this work right would be to add this in CHECKSIDE:

::: CODE :::
#define CHECKSIDE(x,y)                        \
{                                                   \
   temp=(unsigned)actorat[x][y];                   \
   if (temp)                                       \
   {                                               \
      if (temp<128)                               \
         return false;                           \
      if (temp<256)         \
      {                               \
         doornum = temp&63;                      \
         if (ob->obclass != ghostobj &&      \
             ob->obclass != spectreobj)      \
         {                                       \
            OpenDoor (doornum);      \
            ob->distance = -doornum-1;   \
            return true;         \
         }

      else if (((objtype *)temp)->flags&FL_SHOOTABLE)\
         return false;                           \
   }                                               \
}

Then open up WL_ACT2.C, and add this line to the T_Chase/T_Path/T_Schabbs/T_Gift/T_Fat functions:

::: CODE :::
if (ob->distance < 0)
{
//
// waiting for a door to open
//
   OpenDoor (-ob->distance-1);
   if (doorobjlist[-ob->distance-1].action != dr_open)
      return;
   ob->distance = TILEGLOBAL;      // go ahead, the door is now open
   TryWalk(ob);
}

Now the enemies will wait until the door is open to jump into the door's position on the actorat (also eliminating enemies from walking through each other as the door is opening). Oh yeah, and I finally got your "walking through enemies over dead guards" bug to work Tricob (in E2L7). Looks like you can only walk through them while they are moving at the same time as you, which can be pretty tough to duplicate on that level and E1L1 (as they always want to shoot you at close range). I'm guessing this only applies to the dead guards that were already part of the map, and that you didn't kill yourself? Maybe this has something to do with their weird "inert object" tag; which seems to have a few of it's own custom "behaviours" throughout the source.

This brings up another question. Should moving and/or dead guards block moving pushwalls? I can think of a few examples in the original game where it just messed up a perfectly good idea or prevented access/shortcuts on a few occasions. What would be the proper logic, the one of the dead guard being so low and dead that couldn't do anything to stop the crushing, or the one that they are a bump that would prevent the pushwall from moving? Maybe only the intentionally placed dead guards on the map should block pushwalls, and other dead guards should get run over? Any thoughts about that particular situation? Smile


Last edited by Chris on Wed Jun 29, 2016 10:53 am; edited 5 times in total
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Thu Jun 30, 2005 8:55 pm
   Subject: Re: Screw OT, this topic title should be embraced now heh
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Chris wrote:
Another one to add to the list: The "enemy getting stuck around the corner" bug. When directly around a corner, the enemy sometimes just stands there running, but doesn't move positions. You can't shoot each other until you move, but you can stab him with your knife. This also works with bosses, so a boss can be stabbed until death when you get him stuck around the corner (how cheezy!). Might be a fun bug for us to pinpoint.

I've known about this bug for quite a while; I just forgot to mention it. Very Happy I can tell you exactly what's going on.

The "player boundaries" are what I call the area around the player that the enemies are not supposed to move through. These boundaries aren't defined in the shape of a circle; they're defined in the shape of a box. The very corner of this "box" is blocking the way for the enemy, but since the "actor" isn't able to shoot the player yet, the enemy keeps moving. The solution - at least I think - would be to have the enemy enter Ambush Mode when he makes physical contact with the player, so he'll move away instead of endlessly moving against the player. So this solution doesn't actually fix the bug, it just keeps it from occurring. It also makes the enemy seem a little more intelligent.

Quote:
Oh yeah, and I finally got your "walking through enemies over dead guards" bug to work Tricob (in E2L7).

That's one "problem area". The other is in Level One of Episode One, at the very beginning. This occurred for me all the time until I changed my strategy for that level. I'm usually in the habit of charging towards a Brown Guard when he opens a door, firing my first shot as he comes towards me (This saved ammo and increased the accuracy of my aim). I always kept moving through him as a result.

This problem is actually reminiscent of a bugfix to Version 1.0 of the code; in that version, if a guard was killed dead-center of a square in the map, you could move through him. Pre-killed guards however, you could not move through. Id's "dead guard" bugfix actually reversed this situation.

BTW - By "pre-killed guard", I mean that you didn't kill this guard yourself, it was dead when the level started.

Re: pushwalls and dead bodies. Unless you re-wrote the engine so that it looked as though the bodies were actually unveiled by the pushwall - rather than just abruptly appearing right through a wall - I'm afraid it would look like a glitch in the game engine. Neutral
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Fri Jul 01, 2005 7:44 am
   Subject: Re: random
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

quote="Chris"]Only the second step should take place, we need to skip the first one somehow./quote]
Another idea could be to keep the Door on the actorat list until it opens. When a guard opens the door, he moves into that block, so the Door's block changes to his. Gameplay-wise, this seems to work well, as the guard is now going to be ready for you and not flee away (since his only directions to move are forward and backwards). When the block is above 255 though, which is an actor, your movement isn't resticted from the entire block, so you can walk into it until you hit the position restriction of the guard. To make the block stay a Door until it opens, keeping the guard there, you can try adding something like this to WL_PLAY.C:

code]void DoActor (objtype *ob)
{
void (*think)(objtype *);

if (!ob->active && !areabyplayer[ob->areanumber])
return;

if (!(ob->flags&(FL_NONMARK|FL_NEVERMARK)) && !((unsigned)actorat[ob->tilex][ob->tiley] & 0x80))
actorat[ob->tilex][ob->tiley] = NULL;[/code]
code] if ( (ob->flags&FL_NONMARK) && actorat[ob->tilex][ob->tiley])
return;

if (!((unsigned)actorat[ob->tilex][ob->tiley] & 0x80))
actorat[ob->tilex][ob->tiley] = ob;
return;
}/code]
code]
if ( (ob->flags&FL_NONMARK) && actorat[ob->tilex][ob->tiley])
return;

if (!((unsigned)actorat[ob->tilex][ob->tiley] & 0x80))
actorat[ob->tilex][ob->tiley] = ob;
}/code]
You can probably get away without adding the second one (which only gets called when an enemy is completely dead inside the doorway). I've tested it out and it seems to work, atleast so that the player can't walk through the door until it's open. I don't think that restricting the guards tilex/y from being able to walk in the space before the door is completely open would work out, as it ends up causing them to run away more often, when we want them to focus on the player as they open the door (it looks kind of ridiculous to see a door open with no one there half the time; which is partially why I didn't like the solution I posted before - lol). They seem to have a check that restricts them from going beyond a certain point before the door tile changes anyway. Feel free to try this code out though.

To avoid other guards jumping into the door space at the same time now, try adding something like this to CHECKSIDE of WL_STATE.C:

code] if (temp<256) \
{ \
doornum = temp&63; \
if (doorobjlist[doornum].action != dr_closed) \
return false; \
} \

else if (((objtype *)temp)->flags&FL_SHOOTABLE)/code]
Interestingly enough, even in the original game, sometimes actors can walk through each other when one is trying to open a door. This is because their original tile behind the door has been removed (even though the actor is still there, for the most part). That actorat marker behind the door of the guard who is trying to open the door should probably only be removed after the door is open. If we could find where that happends, the last code I posted probably won't be needed.


edit: Took out these other doorfix ideas to avoid confusion.

Tricob wrote:
Re: pushwalls and dead bodies. Unless you re-wrote the engine so that it looked as though the bodies were actually unveiled by the pushwall - rather than just abruptly appearing right through a wall - I'm afraid it would look like a glitch in the game engine. Neutral

Yes, that's an interesting point, but is that really worse then not being able to access an area because the pushwall didn't move enough, or at all, when it was supposed to? I guess you could make it so the dead enemies disappear and/or get removed after the pushwall runs over them, or make it so that the pushwall keeps shoving them backwards (even if they end up inside a wall behind). Depending on how you look at it, though, I guess this annoyance could get the player to be more cautious and add variation to the game.


Last edited by Chris on Mon Jan 16, 2006 11:27 am; edited 1 time in total
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Fri Jul 01, 2005 6:04 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Re: Door/Actor bugfix. Concerning "ambush prevention" when the door is opening, there's an alternative, I think. We might finally put to use that unused "temp3" variable that the code doesn't even touch (WL_DEF.H). We could just set this variable to the actor opening the door (such as Actor #4), adding "1" to its value. The "temp3" variable would then be set back to "0" once the door has finished opening. When the value is not Zero, the actor of this number is not allowed to ambush. Geek

Also, I found a mistake in the WL_STATE.C code. There's one time that "temp" is specified in a routine as "(unsigned)". It should be "int".
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Fri Jul 01, 2005 7:56 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Re: Ambush prevention suggestion. I forgot to add the number of the door being used. Well, it can still be put in the same variable. Just multiply the door number by 151, then add that actor number to it.

So if the door this variable used was Door #4, it would be 604, or 151*4. Then add the actor number (plus 1). If it was Actor #4, you'd add 5 to 604. You now have 609 stored in this variable.
KyleRTCW
DieHard Officer
DieHard Officer


Joined: 30 Jul 2003
Last Visit: 11 Apr 2018

Topics: 45
Posts: 510
Location: Ohio
usa.gif

PostPosted: Thu Dec 29, 2005 6:10 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

The first time I saw this bug was in EoD when I was following the guard on the opening level. Although this isn't really a gameplay threating bug, It is unrealistic.

The bug is that the code checks to make sure if player is close or in sight of an enemy what it doesn't check is when a guard is in patrol, the directions: northwest,northeast,southwest,southeast, so if you are behind a guard and they start going in one of these directions (not facing you of course) they will be alerted even thought they aren't facing you. Razz

_________________
Steam: http://steamcommunity.com/id/stormx312
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:27 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Thu Dec 29, 2005 6:17 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Ah, so whenever a guard is moving diagonally, instead of the code using two routines (one horizontal direction, one vertical) to look for the player, it uses all four (North, South, East, and West).
Jaapio
Can I Play Daddy
Can I Play Daddy


Joined: 26 Nov 2005
Last Visit: 11 Feb 2009

Topics: 4
Posts: 32

blank.gif

PostPosted: Sat Jan 07, 2006 12:21 pm
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

There is an other simple bug in the wolf code, in wl_game.c in function ScanInfoPlane there are some cases that use spawnstand with en_dog as the first parameter. But spawnstand does not contain a case for en_dog. The easy way to fix this is to comment, in the ScanInfoPlane function, the lines starting at case 206: up to including break;
An other way to fix this is to add a the case en_dog to the function spawnstand by copying it from the function SpawnPatrol.
Or make your own states for an standing dog Mr Green
Greetz J.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Mon Jan 16, 2006 11:52 am
   Subject: Re: Bugs & Fixes in the Original Wolf3d Code
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Bottom of Posts

@Jaapio:

Heh. That brings me back some funny memories. I remember when I first started using Mapedit, I tried testing each object to see what it was (as the objlist for v4.1 was very strange and incomplete). One thing I found particularily interesting was how you could put object 0086-0089 near the enemies, and many of them would transform into slow moving dogs once they got alarmed, or it would make dead guards come back to life so you could get over 100% kill ratio. I didn't understand why those objects worked that way at the time, but I just labeled those 4 objects "Dog Transformers" in Mapedit and used them in various strange mapping ideas ever since. It was cool having slower moving dogs in maps, I always thought of them as the wiser/older dogs or something. I think MCS noticed one of my posts about this or seen the effect inside some of my older levels one day, so he PMed me a link to this page. You probably already know the details, but to me it was quite interesting at the time.

@Kyle:

Cool find with the diagonally moving guards bug. Funny how ID forgot about adding the diagonal markers there so the enemies don't get alarmed when they're not looking at you. I guess it's always possible that they didn't check the diagonal markers to speed things up, as you don't see very many guards moving diagonally for that long in the original wolf3d anyway, but who knows. Shouldn't be too hard to add them in with greater or less equations, since their deltax and deltay have already been calculated (where deltax = player->x - ob->x). Here's a diagram for each quadrant you're in to show you what I mean, with the guard being in the middle. So, if the guard is moving northeast, for example, he'll only see you when deltax>deltay is true. Since the first 4 directions are set up to return false when the enemies can't see you, though, you'd could fix the diagonal bug by adding the opposite expressions as the ones for the graph into CheckSight() of WL_STATE.C like this if you wanted:

::: CODE :::
        case west:
                if (deltax > 0)
                        return false;
                break;

        // check diagonal moving guards

        case northwest:
                if (deltay > -deltax)
                        return false;
                break;

        case northeast:
                if (deltay > deltax)
                        return false;
                break;

        case southwest:
                if (deltax > deltay)
                        return false;
                break;

        case southeast:
                if (-deltax > deltay)
                        return false;
                break;

        }

You might notice that in some directions (like while moving Northeast), the guards might get alarmed closer to 45 degrees than 90 when you're on the right side of them, but that's mostly because CalcRotate() isn't drawing the exact frame for each angle perfectly; so you'd probably have to play around with the stuff in that function in WL_DRAW.C a little if you wanted to their rotation frames to display on the screen even more accuarately.

By the way, if anyone was curious, I managed to fix all the bugs mentioned so far in this thread when playing around with WOLF4GW except for the gap on walls bug (all I know so far about that one is that it affects the size of specific vertical lines in the wallheight[] array; possibly coming from some calculation in CalcHeight). If there's any in particular you want a solution for, and can't figure out how I did it from looking at that text file / source code, let me know and I'll post more info here.
Display posts from previous:   
Post new topicReply to topic Time synchronized with the forum server time
DieHard Wolfers Forum Index -> Code Crackers View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page TopView Next Topic
Page 1 of 2 Goto page 1, 2  Next
Jump to:  

Related topics
 Topics   Replies   Views   Last Post 
No new posts Sticky: [Info] Help for newbie coders! C++ Tutorial
Author: Dugtrio17
20 8521 Sun Jan 10, 2010 12:26 pm
Fragstein3D View latest post
No new posts [Info] Tricks - Dogs that shoot - Modifying Behaviour
Author: Guest
19 288 Sat Mar 20, 2004 7:31 am
Dugtrio17 View latest post
No new posts [Info] Alarm Sounding in game?? WSJ...??
Author: Guest
7 309 Tue Jun 17, 2003 10:04 pm
Reivax44 View latest post
No new posts [Info] Silent Gun? - Adding a Silencer
Author: Guest
4 194 Fri Apr 18, 2003 8:34 am
BrotherTank View latest post
No new posts [Info] Adding Locked Doors
Author: Guest
3 243 Thu Apr 17, 2003 6:30 am
Ripper View latest post
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
   You cannot delete your posts in this forum
You cannot vote in polls in this forum


Copyright ©2003-2008 DieHard Wolfers
A Modified subBunker Theme by BrotherTank
Powered by phpBB © 2001, 2005 phpBB Group