Share this post

Link to post

One other difference in ZDoom that doesn't seem like you can undo: rocket jumping. In vanilla, explosions always blow you backwards. In ZDoom, however, seemingly regardless of compatibility settings, explosions have a chance of flinging you into the air. This is rare, of course, but I've had it happen before. When I was standing on a ledge above a cyberdemon, a rocket flew up and impacted with me, and kicked me high enough into the air that I was unintentionally able to grab an item from a platform above me. It's like a miniature arch-vile jump. This would never happen in vanilla.

They should actually really remove this, or at least put a toggle for it. While it looks funny if you hit demons on a ledge with a rocket so they actually jump, it can have unwanted side effects... you can reach areas I you aren't supposed to get to until a lot later. It's kinda (unwanted) cheating.

Share this post

Link to post

It's definitely gotten better in the past few years, but it still defaults to ZDoom behavior for backwards compatibility, and that's what the majority of players are going to experience. If you're making a vanilla wad and you care about that, you can force the compatibility options in mapinfo.

Actually it's the opposite, the compat flags reintroduce bugs that old mods may rely on. The defaults are what we believe provides the best play experience for users. Especially mod authors, since many of the bugs fix things to make logical sense. (Like the melee range.)

I guess "bugs that old mods may rely on" just refers to game behavior that makes Doom play like Doom?

I was specifically referring to ZDoom behavior being kept when it's flat-out, no questions wrong in that post. Not bug fixes, just arbitrary gameplay changes, like the partial invisibility powerup, decorative things blocking your shots, being able to shoot monsters off tall ledges for no particular reason, etc. None of this is providing a "better" play experience for anyone, the latter two actually make the gameplay in most maps worse.

At least if it's being kept default for backwards compatibility, I can kind of understand that.

Share this post

Link to post

I was specifically referring to ZDoom behavior being kept when it's flat-out, no questions wrong in that post. Not bug fixes, just arbitrary gameplay changes, like the partial invisibility powerup, decorative things blocking your shots, being able to shoot monsters off tall ledges for no particular reason, etc. None of this is providing a "better" play experience for anyone, the latter two actually make the gameplay in most maps worse.

None of these was made for 'no particular reason'. They were all side effects from adding new functionality.

The invisibility thing comes from implementing Heretic's shadowsphere as the same effect as the invisibility sphere but when it was separated again there were already some mods depending on it so it had to be optioned.

The ability to shoot monsters off tall ledges is a side effect of adding scrolling floors to the engine and to make it stable while preserving the old behavior actually required the addition of specific code to handle this one situation.

The blocking decorations came from having to give them a proper height because otherwize true 3D collision detection like in Raven's games wouldn't work. And again, bringing back the original behavior required adding some specific code. id had just been lazy and never bothered to give their decorations a proper height - this has never been an explicitly implemented gameplay property.

I think the biggest mistake that had been done here is not ZDoom's fault alone, Boom made it too - namely to enable all those potentially game-breaking new features by default instead of adding some kind of manifest that declares what added features a mod intends to use. It was mostly a result of inexperience.
Of course - again - it's a bit too late for that, there's already far too many mods out there for a vast set of engine configurations.

Share this post

Link to post

Totally agreed on Boom, I've mentioned that before, ZDoom gets too much shit for changes when Boom was just as bad about forcing changes on by default, and didn't even give level designers a way to specify the behavior their maps needed. Thanks for the explanations, too. I knew about the other two, but was never aware that monsters getting shot off ledges was the result of adding scrolling floors.

Maybe I worded my post a bit too strongly, I think we see eye-to-eye on this stuff. I'm fine with ZDoom keeping its defaults see to what works best for ZDoom mods. It was Blzut3's post that made it sound like those defaults weren't for compatibility reasons at all.

Share this post

Link to post

It was Blzut3's post that made it sound like those defaults weren't for compatibility reasons at all.

I guess to try to clarify my post: There are a handful of options that probably would be on by default if it wasn't for the design mistakes Graf mentioned. The most obvious probably being the missile height option since we have an adequate solution and it doesn't complicate mod authoring. However, as Graf stated, we now have years of mods that were developed for the new behavior so we can't just change the defaults. Be it ZDoom's fault or Boom's.

On the other hand, more strict options which serve to reintroduce minute bugs for the handful of mods designed around them simply don't make sense to have on by default. All the the changes related to introducing a true Z axis would fit in this category as well as the before mentioned melee change which facilitates larger monsters more transparently.

In any case, there's definitely a logical reason for everything. There's no thread in the developers forum discussing what we should randomly change next! :P

Megamur said:

Another minor yet obnoxious bit of ZDoom behavior for vanilla enthusiasts: DoomGuy's face. If you hold the fire button down long enough, DoomGuy will start gritting his teeth as he unleashes a torrent of bullets. However, his facial expression seems to be tied to the actual button press in ZDoom, where in vanilla, it seems to be tied to the animation frames of the weapon instead. Why does this matter? Because holding down the fire button for rapid fire reduces the accuracy of your shots. In vanilla, if you saw DoomGuy gritting his teeth, you know your accuracy is reduced, and you have to let go of the trigger for it to reset itself. Once DoomGuy's face is back to normal, the next shot will be accurate. But in ZDoom, if you let go of the fire button at any time, even in the middle of a weapon animation, DoomGuy will go back to his normal expression, even if he's actually still in the middle of a reduced-accuracy, rapid-fire rampage. A really tiny detail, but it still throws me off sometimes.

This changed a long time ago. It was before my time so part of this is a guess: The input system was probably being re-factored and the variable for if the attack button was down was removed. In its place checking the button itself was used and not much thought was likely given to the change in behavior. My next best guess would be when the altfire stuff was added it became more convenient to check the button directly.

Since I'm now aware of the change in behavior, I've fixed it. (I didn't commit the fix to the 2.7.x branch since I feel like the one line change may over correct, but I'm fairly sure that's the only condition it resets in vanilla.)

Share this post

Link to post

This changed a long time ago. It was before my time so part of this is a guess: The input system was probably being re-factored and the variable for if the attack button was down was removed. In its place checking the button itself was used and not much thought was likely given to the change in behavior. My next best guess would be when the altfire stuff was added it became more convenient to check the button directly.

Correct guess. But it not only caused this problem, but others as well so the original variable had to be added back in later. Apparently some uses of it weren't discovered when this was changed back.

Share this post

Link to post

I think the vertical thrust from explosions and mouselook are my favourite zdoom features (aside from mapping features). IMO, all of the huge jumps and combos make zdoom rocket jumping way more interesting than vanilla (especially old zdoom physics / zdaemon / odamex).

Share this post

Link to post

Totally agreed on Boom, I've mentioned that before, ZDoom gets too much shit for changes when Boom was just as bad about forcing changes on by default, and didn't even give level designers a way to specify the behavior their maps needed.

I think one reason ZDoom takes flak where Boom doesn't might be that by and large everyone who still plays and maps for Doom uses an engine that supports removed limits and Boom features, but there is a significant minority who don't use ZDoom as their primary engine. Thus, most players don't notice Boomisms (indeed Doom+ aka limit removal could be considered one huge Boomism) but this minority of non-ZDoom users are sensitive to Doom/Doom+/Boom maps that turn out to only work in ZDoom, and complain loudly about them. Those whose primary engine is Chocolate Doom aren't sufficiently numerous or vocal enough to fill up the forums with complaining about wads that don't work with it. :)

The "classic trio" of ZDoomisms (i.e. by far the three most common types, common enough for PrBoom+ to have implemented workarounds; implicit manuals, implicit passuse, and hanging solid bodies in tall sectors - the latter of which to be fair is not ZDoom-specific but appears in any engine that does proper thing height clipping) are all changes that are on by default in ZDoom but require some effort to achieve in Boom (e.g. by deliberately turning the passuse flag on, or using the right type of generalized linedef). It can and has been argued that their appearance in maps is due to poor testing on the part of the map designer, but I believe ZDoom could do more to help him there. On the other hand, as Graf Zahl says, there are wads that depend on these behaviours being on by default (tautologically, those wads which have ZDoomisms...)

I think another reason why ZDoom takes flak might be that it is here, now, currently evolving, and its developers are here, now, and you can moan at them; whilst Boom has become a "standard", set in stone by not having changed much at all since 1998 (save for a few things like increased limit removal and support of ZDBSP nodes, Boom game physics as a standard has remained more or less untouched; PrBoom's compatibility levels and Eternity's demo version numbers exist to enable additional features without affecting the "core").

Dragonsbrethren said:

Thanks for the explanations, too. I knew about the other two, but was never aware that monsters getting shot off ledges was the result of adding scrolling floors.

I've toyed with the idea of only allowing ledge dropoff when the monster is being moved by a conveyor floor or affected by wind or something. I can't think of any reason why this wouldn't work but haven't actually tried implementing it anywhere yet. On the other hand any such change would have to go into a new compatibility level, so nobody would use it. ;)

Share this post

Link to post

I think another reason why ZDoom takes flak might be that it is here, now, currently evolving, and its developers are here, now, and you can moan at them; whilst Boom has become a "standard", set in stone by not having changed much at all since 1998

An offshoot of the demo compatibility needs. Having to preserve backward demo compat means that any change to core physics will either make the codebase more cluttered with branches of near-duplicated code, or simply be rejected entirely as being more trouble than they're worth. ZDoom by choosing to ignore that constraint is a lot freer to make changes and additions to the core physics.

Share this post

Link to post

On the other hand any such change would have to go into a new compatibility level, so nobody would use it. ;)

And here we go again with the same old problem: Boom and its ofshoots do not have any configuration lump like MAPINFO that lets the mapper set these flags. Of course this means that stuff won't get used.

Share this post

Link to post

An offshoot of the demo compatibility needs. Having to preserve backward demo compat means that any change to core physics will either make the codebase more cluttered with branches of near-duplicated code, or simply be rejected entirely as being more trouble than they're worth. ZDoom by choosing to ignore that constraint is a lot freer to make changes and additions to the core physics.

Quite. I've lost count of the number of times I've thought things like "Demosync is a millstone/ball and chain/albatross around the neck/etcetc" and I'm always an inch away from throwing it out of my own engine, but never quite manage to.

Graf Zahl said:

And here we go again with the same old problem: Boom and its ofshoots do not have any configuration lump like MAPINFO that lets the mapper set these flags. Of course this means that stuff won't get used.

Well I meant for demo recording, no-one uses anything but complevels 2/3/4(Doom) or 9(Boom), so even if there was a new one that fixed bugs, mappers wouldn't target it. But point taken. The Boom developers seemed insistent on keeping everything within the map definition, e.g. doing sky transfers by linedefs instead of an external text lump or what have you. Perhaps they might have done a mapinfo-alike for Phase II if they hadn't all fallen out with each other after Phase I :)

Share this post

Link to post

The Boom developers seemed insistent on keeping everything within the map definition, e.g. doing sky transfers by linedefs instead of an external text lump or what have you.

Well, even then, they could hack their way around. Have an "option init" line special, and use the frontside linedef's texture fields to input options. If you use them as hex values, each texture name gives you a 32-bit field, so you have 96 bits to play with. Double that if you also use the backside textures. Alternatively, use 8-char options names, put them in the top texture to set them, and the bottom texture to unset them, use one linedef per option.

That would have been hacky enough to be allowed for Boom, wouldn't it? :p

There's plenty more MAPINFO-like things you could hack in this way: lump names have the same lengths and restrictions as texture names, so: a "set exits" line special, upper texture for normal exit, lower texture for secret exit. A "set music" line special. A "set name" line special (use several linedef if your map's name is longer than 8 characters, using the value of the lower texture to sort them out in the right order). Sure, it'd be awful hacks, but it would all be contained within the map structure itself.

Share this post

Link to post

I would love the possibility to define your own complevel with a MAPINFO-like lump in prboom+. I would base it on complevel 2 but add sky transfers, unlimited length for automap names and maybe some other cool stuff I can't think of at the moment.

Share this post

Link to post

I would love the possibility to define your own complevel with a MAPINFO-like lump in prboom+. I would base it on complevel 2 but add sky transfers, unlimited length for automap names and maybe some other cool stuff I can't think of at the moment.

MAPINFO-like lump, you mean besides DEHACKED? MBF can load an OPTIONS lump which can contain anything that a *.cfg file has, compatibility settings included, but the equivalent feep has never made it into PrBoom or PrBoom-Plus. This has been discussed over in the PrBoom-Plus thread recently, and it sounds like it's not likely to happen. Oh well!