Technical answer required: why must corpses be non-solid?
- MartinHowe
- Posts: 2088
- Joined: Mon Aug 11, 2003 1:50 pm
- Preferred Pronouns: He/Him
- Location: East Suffolk (UK)
Technical answer required: why must corpses be non-solid?
Please refer to these threads:
http://forum.zdoom.org/potato.php?t=11792
http://forum.drdteam.org/viewtopic.php?t=2253
It appears to be a fundamental limitation of the DOOM engine in general that corpses MUST be non-solid and it MUST always be possible to walk/fly through them, rather than stepping/flying up-then-down over them as with normal obstacles. Why? Given this, why does A_NoBlocking bother to set a monster to be non-solid; I mean, why not just call it A_DropItems?
Please note that I would like a detailed technical answer to this, ideally from one of the programmers (Randy, Graf, Grubber, etc) who is intimately familiar with the guts of the engine. In other words, I would like to know exactly why is this needed, with references into the source code if necessary.
For example, what would break if corpses were allowed to have the "solid" flag respected and why would it break?
http://forum.zdoom.org/potato.php?t=11792
http://forum.drdteam.org/viewtopic.php?t=2253
It appears to be a fundamental limitation of the DOOM engine in general that corpses MUST be non-solid and it MUST always be possible to walk/fly through them, rather than stepping/flying up-then-down over them as with normal obstacles. Why? Given this, why does A_NoBlocking bother to set a monster to be non-solid; I mean, why not just call it A_DropItems?
Please note that I would like a detailed technical answer to this, ideally from one of the programmers (Randy, Graf, Grubber, etc) who is intimately familiar with the guts of the engine. In other words, I would like to know exactly why is this needed, with references into the source code if necessary.
For example, what would break if corpses were allowed to have the "solid" flag respected and why would it break?
- MartinHowe
- Posts: 2088
- Joined: Mon Aug 11, 2003 1:50 pm
- Preferred Pronouns: He/Him
- Location: East Suffolk (UK)
In some cases you want that to happen.Nash wrote:the screen would appear to bump upwards when you step on a corpse because it was solid
True, but what if you want stacking where it would be safe to do so, such as in an open area?Hirogen2 wrote:Imagine a narrow hallway that is only 56 units high. Doomguy would pass through that, but as soon as you gib a monster, the available height would decrease, making it impossible to walk through. Plus they would stack and stack.
In other words, both points are valid in general, but neither is a valid reason for the engine to just assume that corpses MUST be non-solid, because that is what A_NoBlocking (in their death states) is for; therefore the engine should not need to "force" them to be non-solid.
In any case, the engine deliberately overrides an explicit call to A_SetSolid, so it must be something more fundamental than that.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49235
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Kristus wrote:Legacy got solid corpses as a feature, so no it's no limitation. It's just silly.
But Legacy's physics code is much buggier due to such 'features'. This is one of the cases where you have to consider what is important. And in this case it is more important to avoid glitches in standard situations. Programming around the problems only causes other issues which in this case are not worth the hassle. The vertical movement code is bad enough as it is and doesn't need complications that only serve to avoid issues in extreme situations that very rarely occur. And this is one such situation.
- David Ferstat
- Posts: 1113
- Joined: Wed Jul 16, 2003 8:53 am
- Location: Perth, Western Australia
- Contact:
My question would be:
How difficult, and what are the possible complications of, solid corpses as either:
a) a compatibility flag in the menu, or
b) an option in the MAPINFO?
As I understand the current operation of the code, when a monster dies, it runs through the death sequence in the frame table (just talking traditional Doom here) where one of the code pointers is the one enabling "dead body mode". The effect of this code pointer is to 1) make the actor drop the appropriate item (ammo, weapon, etc) and 2) clear the blocking flag.
So, how difficult would it be to add a test to code for "dead body mode"? Specifically, if "solid corpse" is selected, the engine skips clearing the blocking flag.
Consequences? Well, in at least some of the id maps, and, presumably, many maps built afterwards, you'd run the risk of having corpses pile high enough to block passageways. So, if if you were to have solid corpses as a menu option, players would have to play at their own risk. Mind you, this is the same situation with jumping and crouching; their use in maps not designed for them runs the risk of breaking things, so user beware.
On the other hand, I can think of situations where solid corpses could be fun. Imagine, kill that cyberdemon in the right spot and you can jump on its corpse, then jump onto that ledge where there's, say, a megasphere, or a switch to open up a shortcut through the map, and past a large bunch of monsters.
How difficult, and what are the possible complications of, solid corpses as either:
a) a compatibility flag in the menu, or
b) an option in the MAPINFO?
As I understand the current operation of the code, when a monster dies, it runs through the death sequence in the frame table (just talking traditional Doom here) where one of the code pointers is the one enabling "dead body mode". The effect of this code pointer is to 1) make the actor drop the appropriate item (ammo, weapon, etc) and 2) clear the blocking flag.
So, how difficult would it be to add a test to code for "dead body mode"? Specifically, if "solid corpse" is selected, the engine skips clearing the blocking flag.
Consequences? Well, in at least some of the id maps, and, presumably, many maps built afterwards, you'd run the risk of having corpses pile high enough to block passageways. So, if if you were to have solid corpses as a menu option, players would have to play at their own risk. Mind you, this is the same situation with jumping and crouching; their use in maps not designed for them runs the risk of breaking things, so user beware.
On the other hand, I can think of situations where solid corpses could be fun. Imagine, kill that cyberdemon in the right spot and you can jump on its corpse, then jump onto that ledge where there's, say, a megasphere, or a switch to open up a shortcut through the map, and past a large bunch of monsters.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49235
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
There won't be a compatibility flag and there won't be a MAPINFO option. Solid corpses can get the player stuck in places where he isn't supposed to and that alone is reason enough to disallow it.
See here:
http://forum.zdoom.org/potato.php?t=11484
Everything I posted there applies here as well.
See here:
http://forum.zdoom.org/potato.php?t=11484
Everything I posted there applies here as well.
- Ixnatifual
- Posts: 2287
- Joined: Fri Dec 12, 2003 6:44 pm
- Contact:
Also take in account, that the solid corpses not only would block the player, but also other monsters as well, wich would result in an utter mess IMO.
While jumping and crouching may be able to get you to places you are not supposed to be in non-jumping maps, the solid corpses would be able to "break" a map by simply shooting monsters wich is the main task in this game.
If you know, that a map isn't designed for jumping you can simply refuse to use the feature.
In this manner, adding solid corpses as a menu option is pointless IMO, as it would only be useable in maps specially designed for it (and I suspect there would be many maps of this type at all)
And then there would STILL be the risk of blocking yourself or a necessary path, unless the map just consists of one large open area!
I disagree!Mind you, this is the same situation with jumping and crouching; their use in maps not designed for them runs the risk of breaking things, so user beware.
While jumping and crouching may be able to get you to places you are not supposed to be in non-jumping maps, the solid corpses would be able to "break" a map by simply shooting monsters wich is the main task in this game.
If you know, that a map isn't designed for jumping you can simply refuse to use the feature.
In this manner, adding solid corpses as a menu option is pointless IMO, as it would only be useable in maps specially designed for it (and I suspect there would be many maps of this type at all)
And then there would STILL be the risk of blocking yourself or a necessary path, unless the map just consists of one large open area!
Jesus Christ, is it that hard to believe a TC could use this feature to a useful purpose? Something as simple as using an ACS script to remove corpses after a certain duration could easily avert any problems with solid corpses.
This would affect vanilla Doom by an exact factor of not at all. All of the Doom monsters already use A_NoBlocking in their death sequence. On the off chance that somebody has created a monster that doesn't (which is really their fault anyway) a simple compatibility flag would deal with all of these circumstances.
Honestly, I don't know why we need to keep stifling creativity and needlessly limiting what can be done all in the name of preserving vanilla Doom bugs.
This would affect vanilla Doom by an exact factor of not at all. All of the Doom monsters already use A_NoBlocking in their death sequence. On the off chance that somebody has created a monster that doesn't (which is really their fault anyway) a simple compatibility flag would deal with all of these circumstances.
Honestly, I don't know why we need to keep stifling creativity and needlessly limiting what can be done all in the name of preserving vanilla Doom bugs.
I've got a solution that can be summed up in two simple words: Actor Flag. Therefore, there's no chance of this unintentionally breaking any original Doom maps since you'd need a custom monster to do so. If the situation calls for it, the Replaces keyword can always do in case a wad author specifically wants the original monsters to have blocking corpses. I can see for a few cases that this might come in handy for something, and wouldn't keeping it as a DECORATE flag avoid any compatibility problems? A MAPINFO flag wouldn't be customizable enough, and a compatflag makes it too easy for the user to break other wads, but being able to manually set solid corpses to specific monsters through DECORATE makes a lot more sense. 
So therefore, this still seems like a needless argument. If somehow someone still views this as flawed logic, then sue me.

So therefore, this still seems like a needless argument. If somehow someone still views this as flawed logic, then sue me.

- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49235
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Sigh... Why are so many people so intent on pushing the engine beyond its limits and refuse to accept any explanation why there is a restriction or something else that prevents something from working?
Again:
Because the vertical movement code is utter shit. It is way beyond being fixable. The only thing that could resolve this mess is a complete rewrite of the entire movement code from scratch! The thing is, you can't just randomly dump solid objects in a map without causing serious problems. Just read the things I wrote in the linked thread (especially the one sentence about any potential way around the problem.) With solid corpses the same problems would appear (and in fact have appeared in the few versions of ZDoom where corpses were solid by accident.)
Again:
Because the vertical movement code is utter shit. It is way beyond being fixable. The only thing that could resolve this mess is a complete rewrite of the entire movement code from scratch! The thing is, you can't just randomly dump solid objects in a map without causing serious problems. Just read the things I wrote in the linked thread (especially the one sentence about any potential way around the problem.) With solid corpses the same problems would appear (and in fact have appeared in the few versions of ZDoom where corpses were solid by accident.)
OK, I re-read the thread. It's talking about the very severe issue that because horizontal and vertical movement are separated, it's possible for the engine to allow the player into a space where they can't fit (heightwise) and get stuck. I understand that issue.
However, a map author using this feature can work around that limitation. If used sparingly and only in certain places where the corpse can't cause this kind of issue, it would work fine. If they use it abusively and the level breaks because of it, that's their problem. The important facts are:
1) This would allow mappers to be more creative.
2) This would not effect the vanilla maps or any other maps already created in any way. (Incidentally, I like Xaser's idea because it makes absolutely certain it won't change any already existing maps)
There are plenty of things that have already been added to ZDoom that will gladly break the engine if abused. While I understand that the physics code for Doom is piss-poor in this area and side-effects could happen, I think a map author who is aware of these side effects would be able to work around them.
However, a map author using this feature can work around that limitation. If used sparingly and only in certain places where the corpse can't cause this kind of issue, it would work fine. If they use it abusively and the level breaks because of it, that's their problem. The important facts are:
1) This would allow mappers to be more creative.
2) This would not effect the vanilla maps or any other maps already created in any way. (Incidentally, I like Xaser's idea because it makes absolutely certain it won't change any already existing maps)
There are plenty of things that have already been added to ZDoom that will gladly break the engine if abused. While I understand that the physics code for Doom is piss-poor in this area and side-effects could happen, I think a map author who is aware of these side effects would be able to work around them.