"Safe" ZDoom/Boom features in a Doom map

I have heard* of the possibility of using certain ZDoom/Boom features for aesthetic purposes in Doom format maps, but I have never seen an example or a level actively do this. I asked around and Googled about, but nothing come up of note.

Are there any WADs/maps out there that exploit this? Slopes/translucency/scrollers etc? And how far have these features been pushed? And on top of this, is there a list of "safe" features that would not break Doom maps?

*I remember discussion on IRC about it, but couldn't remember what it was about specifically.

Line types are handled by giant switch cases which don't have a default label causing an error (contrarily to sector types when the player visits them). As a result, unknown line types are silently ignored by the engine, whereas unknown sector types will cause the engine to bomb back to DOS if the player enters them. (It should be relatively safe to use unknown sector types in areas that the player isn't ever supposed to reach, such as a dummy sector. Only relatively safe, because obviously people are wont to idclip where they're not supposed to.)

As for examples of this, I remember there was one Freedoom map that featured decorative slopes, but I'm pretty sure this has been expunged since.


Pictured: slopes in MAP07 from Freedoom 0.7rc1


The same level in Eternity, slopeless

Even though the player can climb up the slopes in this case, gameplay isn't significantly changed compared to when the ramps are just at the same height as the stair steps instead of being sloped. (I mean, sure, it'd probably break demo compatibility between ZDoom and other ports if such a thing existed, but it doesn't, so who cares.)

I've used sky transfers and transfer heights as aesthetic bonuses in cl2 maps without consequence in prb+, I'd also be interested to hear if these things break horribly in other ports.

I wonder why Eternity isn't supporting those slopes now?

Csonicgo said:

I wonder why Eternity isn't supporting those slopes now?

Because Eternity never cared about Doom format linedef action compatibility with other ports that have a Boom superset. It just used all the numbers for its own purposes and all that stuff is hard coded at the moment so unless some significant refactoring is done it just has no easy way to do it.

That's why ZDoom ships an Eternity xlat, so that if someone wants to try out an Eternity map, it still works to a certain degree instead of assigning all the wrong linedef actions.

All this has one very unfortunate consequence: NONE of ZDoom's or Eternity's extensions are really safe, because both ports have nothing in common beyond plain Doom and may interpret them differently - unless ZDoom gets started with '-xlat xlat/eternity.txt' or the translation is explicitly altered in MAPINFO, in which case most Eternity extensions could be used in both.

Graf Zahl said:

Because Eternity never cared about Doom format linedef action compatibility with other ports that have a Boom superset. It just used all the numbers for its own purposes and all that stuff is hard coded at the moment so unless some significant refactoring is done it just has no easy way to do it.

You mean the standard that only exists in ZDoom, right? I can't think of any other ports that aren't ZDoom based, at the very least.

Edward850 said:

You mean the standard that only exists in ZDoom, right? I can't think of any other ports that aren't ZDoom based, at the very least.

Are EDGE and Legacy ZDoom-based now?

EDGE I'll concede; But Legacy? That barely supported Boom.

Edward850 said:

EDGE I'll concede; But Legacy? That barely supported Boom.

Correct, but it never clashed its line specials with other ports, except for #272, which it inherited from SMMU.

Legacy, ZDoom and EDGE always deliberately used their own separate number ranges, so with shared features they could support each other's types.

What if I add new specials in Eternity and ZDoom adds something new with the same number because they didn't check my commits? And vice versa.

^ Wasn't the concept of UDMF namespaces (in fact, UDMF itself) created exactly to resolve that, and wasn't it meant to be used instead of adding any new Doom format specials?

This was about Doom format special, and what has been broken more than 10 years ago cannot be made unbroken after so many years.

If someone really wants to use enhanced features in a Doom format map, the only way to support both ZDoom and Eternity would be the Eternity numbering, because ZDoom can easily translate that - of course it requires an additional bit of MAPINFO, but no big deal overall.

If you want to add a new Hexen/UDMF special, the best way to avoid problems is to make a pull request for ACC, adding the new special to zspecial.acs. That way it immediately gets into the one file that can be considered the master list, as it not only contains ZDoom's but also GZDoom's and Zandronum's specials. Once it's there, the number is taken and won't be reused for anything else.

The reverse should also be true. If you want to add something, that file should be considered the ultimate reference which numbers are taken for what. Whatever is free on that list is available.

(And in case you ask: Lines with commented out specials mean that these are map-only specials, not that these numbers are available.)

@scifista:

The point of UDMF namespaces is to detect compatibility requirements.
The Hexen action special namespace is not part of the UDMF spec because it's also used by Hexen format maps. And of course, since to this day it has been free of clashes (if you discount a moderate number of specials taken by Skulltag which were later discarded and completely removed from the engine), the minimal added effort should be taken to keep it that way. It'd avoid a lot of trouble for everyone.

Your idea about zspecials.acs sounds nice, but leaves me with a questioning thought... Basically you have the power to reject anything I try to add there, if it doesn't fit your vision.

Example: ZDoom has Line_SetPortal. However, I don't really want to support the incompletely linked portals yet (which avoid some features to be more flexible otherwise), and I also don't like the way you're required to apply the special to both linedefs and give those linedefs different tags (it takes longer than in the classic format), so I want to roll my own line portal special. And I also want a different special too, for simple portals (plane, horizon, skybox) on lines.

Sector_SetPortal is also a heavy mess that would better be separated into roughly four dedicated specials.

printz said:

Your idea about zspecials.acs sounds nice, but leaves me with a questioning thought... Basically you have the power to reject anything I try to add there, if it doesn't fit your vision.

Technically yes.

But as long as you do not deliberately pick conflicting numbers, there are no reason to reject additions of new specials on the list even if these specials aren't of use for ZDoom.

Suppose you want to add a Line_GiveIceCream action to number 292, well, all you need to do is check that nothing is already using number 292. If there's no conflict, then Graf has no reason to oppose adding it. And even if he rejected it you could appeal to Randi or Blzut anyway.

I would have thought the point about the Zandronum specials would have clued you in that it's not just about ZDoom features...

printz said:

Sector_SetPortal is also a heavy mess that would better be separated into roughly four dedicated specials.

Maybe. But look at the amount of free numbers below 256. Right now there really is no room to be that generous, especially if it's only for a subtype with such limited use.

I was thinking about using Static_Init for the real Eternity type, but would that really have made things better?

And the only reason the rest of this looks a bit messed up is the need to make this work in Hexen format maps as well, that alone pretty much necessitated the line ID chaos in the special.

Graf Zahl said:

Maybe. But look at the amount of free numbers below 256. Right now there really is no room to be that generous, especially if it's only for a subtype with such limited use.

Well there you go. That <256 range is a scarce resource to be fought for. I guess I can ignore it however, since Hexen format is not important for Eternity other than for vanilla Hexen.

Line_SetPortal was implemented before the expansion, though.

BTW, to get support for 2 byte special values in ACS, don't forget to add the PCD_LSPEC5EX and PCD_LSPEC5EXRESULT´ instructions.