Vermil Posted July 31, 2011 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. 0 Share this post Link to post
natt Posted July 31, 2011 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. 0 Share this post Link to post
Rizera Posted July 31, 2011 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. 0 Share this post Link to post
Gez Posted July 31, 2011 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. 0 Share this post Link to post
Maes Posted July 31, 2011 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. 0 Share this post Link to post
RestlessRodent Posted July 31, 2011 You forgot ReMooD. ReMooD does the same as Legacy, which I believe does the same as Vanilla in this matter. 0 Share this post Link to post
hex11 Posted July 31, 2011 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 0 Share this post Link to post
Maes Posted July 31, 2011 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. 0 Share this post Link to post
hex11 Posted July 31, 2011 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? 0 Share this post Link to post
Maes Posted July 31, 2011 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). 0 Share this post Link to post
hex11 Posted July 31, 2011 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. 0 Share this post Link to post
Maes Posted July 31, 2011 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. 0 Share this post Link to post
Vermil Posted August 1, 2011 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). 0 Share this post Link to post
wesleyjohnson Posted August 2, 2011 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; } 0 Share this post Link to post
hawkwind Posted August 9, 2011 Risen3D has "fixed" the bug. No ghost monsters. 0 Share this post Link to post