Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Vermil

How do the various ports handle the ghost monster bug?

Recommended Posts

Pretty much what the thread title states; how do the various ports handle the ghost monster bug?

Which ports retain it, fix it, have options to enable/disable it. What do they do with it?

I know that Doomsday features a compatibility option to allow the user to enable/disable the bug occurring.

I know that G/ZDoom enables the ghost monster bug for famous maps which are known to use the bug for game play purposes, but otherwise, it's always disabled.

What does Boom, Chocolate Doom, EDGE, Legacy, Odemax, PrBoom, Risen3D, Skulltag, Vavoom, ZDeamon etc do with the bug.

Share this post


Link to post

Boom and descendants fix the bug, with a compatibility option that is toggleable (and automatically switched when an original demo is loaded).

Chcolate Doom behaves exactly as Doom does wrt ghost monsters.

Share this post


Link to post
natt said:

Boom and descendants fix the bug, with a compatibility option that is toggleable (and automatically switched when an original demo is loaded).

Chcolate Doom behaves exactly as Doom does wrt ghost monsters.


Really? So can we run Plutonia 2's MAP32 and still avoid the Nazi Ghost fountain?

I didn't know that option.

Share this post


Link to post

Skulltag is based on an older branch of ZDoom and at the moment merely fixes the bug, no special hidden compatibility mode for any map.

Share this post


Link to post

I don't :-p

Interestingly, it worked just as intended in Mocha Doom (aka like the original) without me taking any special steps. It's actually a bug due to a very "clean" code mistake, not some pointer voodoo, and as such it's easy to fix, one willing.

Share this post


Link to post

SDL Doom keeps this bug/feature. In fact, I don't think it has any changes from linuxdoom except:
- use SDL for audio/video
- add some stuff to make it work on BeOS and Win32

Share this post


Link to post

Well by now it's obvious that LinuxDoom is like vanilla regarding bugs...plus many of its own that need to be fixed in order not to get sub-vanilla functionality.

Share this post


Link to post
Maes said:

Well by now it's obvious that LinuxDoom is like vanilla regarding bugs...plus many of its own that need to be fixed in order not to get sub-vanilla functionality.


The only one I've noticed is the non-animating switches in Ultimate Doom E4. Is there a list of other bugs?

Share this post


Link to post
hex11 said:

The only one I've noticed is the non-animating switches in Ultimate Doom E4. Is there a list of other bugs?


Speaking purely for LinuxDoom here. Unless SDL fixed the distinctions between TNT/Plutonia, then yeah, there are tons of others, plus some ugly bits (e.g. pressing F1 during gameplay will cause the status bar to become "dirty", since there's no code restarting/cleaning it afterwards).

Share this post


Link to post
Maes said:

Speaking purely for LinuxDoom here. Unless SDL fixed the distinctions between TNT/Plutonia, then yeah, there are tons of others, plus some ugly bits (e.g. pressing F1 during gameplay will cause the status bar to become "dirty", since there's no code restarting/cleaning it afterwards).


I would have noticed the F1 thing very quickly, but it doesn't happen in SDL Doom, and yet I don't see any changes in the st_* files, except to include m_swap.h (which just has some endienness fixes). Maybe some other files were changed, or the fix happened as a side effect of using SDL?

I'm not much of a fan of the Final DOOM IWADs, so I wouldn't know where to begin looking. I guess if those have bugs it's not terribly important to me. I'm more concerned about Ultimate Doom and Doom II bugs.

Share this post


Link to post
hex11 said:

I would have noticed the F1 thing very quickly, but it doesn't happen in SDL Doom, and yet I don't see any changes in the st_* files


A fix would have more likely been done by manipulating the firsttime boolean, or forcing a "clean" reloading externally in a similar way.

hex11 said:

I'm not much of a fan of the Final DOOM IWADs, so I wouldn't know where to begin looking.


Finale texts are an excellent place to start. In general, LinuxDoom did very poorly at keeping certain IWAD-specific hacks, like different texts, missing lumps etc.

Share this post


Link to post

Well, my reason for asking this question was because I've made a small, HOM's aside, Vanilla map, that has a very specific setup (that I don't think can be altered without making it unworkable), that's very very likely to cause the ghost bug.

It is in turn, very likely to mess things up if it occurs. The issue is that anywhere a Mancubus can move to, an Arch Vile can (size wise).

Share this post


Link to post

This is the code from DoomLegacy that the vile uses to revive a monster.
Killing a monster reduced the height in a standard way (height >>= 2),
except after crushing.
Viles try to reverse the operation in a standard way.
The fix restores proper initial values instead.

if( demoversion<129 )
{
// original code, with ghost bug
// does not work when monster has been crushed
corpsehit->height <<= 2;
}
else
{
// fix vile revives crushed monster as ghost bug
corpsehit->height = info->height;
corpsehit->radius = info->radius;
}

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×