Which source ports all plan to implement UDMF?

I recently added a section for source ports compatible with the UDMF format to this page, knowing that QZDoom, GZDoom, Zandronum, and Eternity all support it, and Doomsday and 3DGE both plan to in the future. I also struck off Chocolate Doom, Crispy Doom, and prBoom+ for all not likely adding support for it. Are there any others on this list that have confirmed they're adding support/won't add support?

3DGE is actually in the process of implementing it now, from what I understand. It hasn't hit the master branch yet, though.

I've been trying to help out with 3DGE mostly focusing on pulling in features that will make it a little more mainstream - and easier to use, for the average ZDoom/Eternity player.

I don't know who's working on the UDMF support, but I may end up lending them a hand if things don't work out well for them.

DelphiDoom since v. 1.1.5 as an experimental feature. Offcial support is going to be added as since as I will understand and support fully all assets of the UDMF specs.

ReMooD.

Although, I somewhat dislike the idea of having namespaces specific to a single port, I would prefer a namespace that is compatible across some ports.

RestlessRodent said:

Although, I somewhat dislike the idea of having namespaces specific to a single port, I would prefer a namespace that is compatible across some ports.

It's perfectly possible to have that.

But first you need to have several ports that can read UDMF maps (until recently, there was only ZDoom derivatives, plus Vavoom). Then they need to have additional features in common, that work the same way (or close enough). And only then you can have these ports' developers define a common namespaces for a set of common features.

So it's something that may yet happen, but for now it's still too early.

In the meantime, though, shouldn't it be possible to use the Hexen name space, since as a feature set (as far as I am aware) both Eternity and GZDoom support it?

Eruanna said:

In the meantime, though, shouldn't it be possible to use the Hexen name space, since as a feature set (as far as I am aware) both Eternity and GZDoom support it?

I would mean talking about features that are more common among these source ports, but with more things than Hexen. ReMooD is going to use functional line triggers, instead of numbers lines would be represented by actions. In the map format, the number format is pretty magical and antiquated. So instead of say "7", I will be going for something such as "door(speed=turbo, autoclose=true, closeafter=default)".

Currently in Doom, line trigger handling is basically just a giant switch. Boom lines are just decoding some bit fields. But in ReMooD, line actions will be objects that perform their given function. Mapping between Vanilla's magical format would just return objects that mimic the functionality of a line.

As such, I hypothesize a kind of mapping where lines can be given scripts directly (in this case FraggleScript) rather than shoving off those script IDs in a scripting file and then setting the line to a given number which activates that script.

This would also allow for stuff such as when a line is bumped into by a player, if a player lands on a given sector's floor, ceiling, or other such things.

Eruanna said:

In the meantime, though, shouldn't it be possible to use the Hexen name space, since as a feature set (as far as I am aware) both Eternity and GZDoom support it?

That seems dangerous and ambiguous. Is "Hexen" the game or the inherited format? Is it supposed to ever be loaded with non-HEXEN.WAD?

It would be great to see a new UDMF namespace encompassing the features shared between ZDoom and Eternity. I'd hope to see it become a viable target for some modern semi-advanced wads like Ancient Aliens that right now still have to arbitrarily limit themselves to the ancient Boom or MBF feature sets in order to be both demo-friendly and playable in popular ports.

printz said:

That seems dangerous and ambiguous. Is "Hexen" the game or the inherited format? Is it supposed to ever be loaded with non-HEXEN.WAD?

That part is undefined, but keep in mind that namespace "Hexen" means strict limitation to Hexen features, even if loaded in Doom. ZDoom clears all non-Hexen action specials when loading such a map.

esselfortium said:

It would be great to see a new UDMF namespace encompassing the features shared between ZDoom and Eternity. I'd hope to see it become a viable target for some modern semi-advanced wads like Ancient Aliens that right now still have to arbitrarily limit themselves to the ancient Boom or MBF feature sets in order to be both demo-friendly and playable in popular ports.

I fully agree that such a thing should be done. If the Eternity devs are interested I'm ready to discuss it. The one thing I am not sure about is, whether Eternity is still adding features that might become part of such a namespace - I don't expect the ZDoom side to add to this in the near future as my focus right now is elsewhere.

Of course this namespace needs to be somewhat explicit so that it spells out all features in detail, even supported action specials to avoid problems.

Graf Zahl said:

I fully agree that such a thing should be done. If the Eternity devs are interested I'm ready to discuss it.

I would be very willing to discuss such a thing.

What sounds tempting to me is to check if Eternity can play ZDoom 1.22 levels. I know it still can't do free-form fade and colour filters (Sector_SetFade and Sector_SetColor), but those aren't critical for gameplay and may be implemented at some point. Maybe start establishing a common feature set from ZDoom 1.22, if Eternity really works with wads such as KZDoom*. Granted, there have been common stuff added since then to ZDoom that Eternity also has now.

Some things that immediately come to mind as features that could probably be part of a shared standard between Eternity and ZDoom:
Slopes (incl. vertex slopes)
Polyobjects
Portals (incl. skyboxes and interactive portals)
Attached surfaces
Flat scaling, rotation, and alignment
ACS scripting
Parameterized line actions
3dmidtex line flag
Thing actions (i.e. triggers activated on monster death)

Mappers targeting this shared format would also be able to make use of some shared features that aren't dependent on the map format itself, such as:
Texture/flat mixing
PNG graphics support

I think this would be a fantastic start already, and I'm probably forgetting some other shared features that already exist. And of course other things could be added to the standard in subsequent revisions depending on the additional shared features implemented in the ports :)

I wouldn't tie this to a specific ZDoom version, especially not such an old one - I know that Eternity supports lots of things of much never versions so it'd be a bit too limiting. It may be better to make a checklist with all action specials, all ACS functions and all UDMF properties, plus other common features and see what stuff can be used and what not.

Sector types, I think, are mostly compatible. I know Eternity defines two more bit flags but I believe both are about features which ZDoom supports so adding those would certainly be possible.

The first and most important thing is to get the 3 above groups of features sorted, I believe. If you want I'll make a spreadsheet where these points can be checked if implemented or, if implementation is planned, this be noted. Any format you prefer?

printz said:

What sounds tempting to me is to check if Eternity can play ZDoom 1.22 levels... Maybe start establishing a common feature set from ZDoom 1.22

Agreed. If Eternity supported ZDoom 1.2x features then we could have (somewhat) advanced levels that play in ZDoom, Eternity, Vavoom, Odamex, and ZDaemon.

Of course, a modern ZDoom + Eternity set would also be wise.

Might it make sense to add a version number for the namespace then?

As much as it makes sense to add one for ZDoom. It will need occasional updating but as a whole the assumption would be to use the latest version of both engines as baseline of what's a common feature.

Versioning may be nice but it also would degenerate into a constant hassle for anyone involved and create more frustration than anything else.

Each namespace would require explicit support in both ports, properly masking out the unsupported features, and separate editing configs and what not. Let's better not go there - in the end it's just the same old story of "Read the text file, otherwise don't complain if stuff doesn't work."

Here is where I disagree: A common namespace for Eternity and ZDoom would be feasible even without versioning.

If not that, then how about just allowing either port to pick up a map in the others' namespace, interpreting it, and just grabbing whatever functions it can use? For the most part level-functional specials can easily be commonly implemented in both engines and that is usually enough to at least play the maps even if they don't look their best.

There's a point where strict adherence to a spec makes sense. But I think there is a point where strict adherence goes a little too far. And you are not even going to consider mappers who will want to make their maps work in both engines with the flexibility afforded by UDMF features. Already mappers have proven they can handle converting between DECORATE and EDF, both of which can be included in the same archive.

How do you imagine that to work? ZDoom contains lots of features which Eternity lacks and Eternity also contains features which ZDoom does not have.

In a few cases some special settings would have to be activated to play maps for the other port.

And on top of that it all needs to be properly documented. The namespace is at least needed to filter out unwanted content and print proper warnings.

I will certainly add an Eternity namespace reader to ZDoom eventually (once a proper spec exists, that is), but that will dilligently output anything it finds that is considered an unsupported feature of the engine. With a common namespace it will get really murky. And it won't solve the problem of having to document the common feature set.

I've stated before about my want for a cross-port UDMF namespace. I am 100% supportive of this idea, and willing to try and get this working for Eternity; in addition, I am more than happy to work with other source port devs towards this goal.

Whilst this would probably provide challenges of many kinds (e.g.: as coordinating this sort of thing becomes more complex as more ports gets UDMF with their own features), I personally would love to see a bunch of advanced source port devs working together for the benefit of the community.

The hardest thing initially would be setting up group communication channels. I'll go for any communication platform that isn't outdated like AIM or ICQ. If you guys can think of any reasonable solution to this that we can all agree on doing then I am more than willing to give it a try. I would suggest Discord due to being able to arbitrarily view and search the history, but know that some might not have an account for it.

You and the Eternity authors can share a text file that does something like the following, in defining custom name spaces:

#:Name(args):ZDoom(args):Eternity(args)
1:PolyObj_StartLine(po,mirror,sound,lineid):1(po,mirror,sound,lineid):1(po,mirror,sound,lineid)

The # is the number found in the UDMF file. The Name(args) is basically giving the special a name (for the text file maintainer's benefit, only, really), plus arguments that will be expected. The following entries after that implement the special by its special ID and the arguments (by name) passed to the engine. Obviously, each port only reads its own unique entry on that line.

This file could be read by each port, and for updates would only have to be dropped into each port's specific data file (i.e. /eternity/base or gzdoom.pk3).

The source file would ideally be in a repository you both have write access to, or could be shared on a wiki. Whenever a port implements a feature they are aware of the other having, they write in their code to support the special along with its expected arguments to make it work. The respective ports can then parse the file as a translator for the common namespace, using the specials provided within the file to implement it as their own.

That is only one way, though - I am not sure it is the most ideal way, but it could be an idea that can be expanded upon.

Features like texture stretching and/or color manipulation could be written in similarly, possibly by including #section directives in such a file - simply translating a commonly-named directive to whatever the target port expects the directive to be called.

I honestly think that right now is the worst time imaginable for thinking about merging some namespaces. No matter what will happen in the end, it's certainly better to leave a separate one to Eternity, considering that they are in a heavy feature addition phase.

Once that is through may be better suited. Ultimately allowing all existing namespaces to pass is easier than having to run a cleanup operation on a messed up namespace.

What is important right now is to get the common ground properly defined.

Altazimuth said:

The hardest thing initially would be setting up group communication channels. I'll go for any communication platform that isn't outdated like AIM or ICQ. If you guys can think of any reasonable solution to this that we can all agree on doing then I am more than willing to give it a try. I would suggest Discord due to being able to arbitrarily view and search the history, but know that some might not have an account for it.

I'm currently only on Skype and Telegram, but could of course register at Discord as well.

But far more important is to set up some shared docs somewhere. Can any of you access Google Docs? It seems to be the most suitable online option.

I've Skype but no Telegram (I'd be willing to set up an account if that's what others want to use). I also have access to Google Docs, and I'd be rather surprised if at this point a person didn't have a Google account. I still use it occasionally for tracking UDMF specials, and it was an important part of the planning phase.

I am probably one of the few holdouts still using Skype. It's just easier for me and the interface feels a lot more homely and friendlier than Discord. But then again considering how long I've used it - I think at this point I am just resistant to change. (Trust me, I am still kicking and screaming about using Discord)

Thanks for posting that link, it basically solves one of the three issues I was listing and will save me quite a bit of work.

esselfortium said:

Portals (incl. skyboxes and interactive portals)

Beware that I added different specials in Eternity for portals, also helped by new UDMF fields. I wanted an easier model than whatever is inherited from the Doom format into ZDoom. I was also uncomfortable porting Line_SetPortal when its parameters are too focused on the ZZYZX flexible portals. The idea of having portals which trade completeness for flexibility doesn't sound robust to me, even if it can in turn be used to make unbelieveable mazes. Even now I didn't add half-linked portals to EE.

Eternity actually has the Sector_SetPortal (probably complete) and Line_SetPortal (only the classic format compatibility model, the others don't work) specials, but they're barely documented, if at all. You're supposed to use Portal_Define + UDMF properties, or Line_QuickPortal.

Are you sure you want to make levels which lack both 3D floors and local portals? :(

Slopes (incl. vertex slopes)

Vertex slopes are definitely in the "slopes" branch, fortunately.

Attached surfaces

Again, I preferred to preserve the Eternity code and to use dedicated UDMF properties, instead of overloading Static_Init like ZDoom did. Let's have some well-defined ground, OK? And there's no Sector_SetLink in Eternity.

Static_Init still exists, but it's only used for MBF sky transfers, and I used it before I woke up and realized my mistake. I'm even still considering adding "Transfer_Sky" for it.

As for specifications, well I didn't even want to spend time drafting/writing a plain text thing. The specification is in the source code, e_udmf.h and I'd like to have it in the wiki sometime. Since it's all on master and everyone advertises that EE has UDMF by now, they can no longer change.

Eruanna said:

I am probably one of the few holdouts still using Skype. It's just easier for me and the interface feels a lot more homely and friendlier than Discord. But then again considering how long I've used it - I think at this point I am just resistant to change. (Trust me, I am still kicking and screaming about using Discord)

Skype is shit, I only need it to chat with my boss when he's not at the office and needs to use his smartphone. The entire client is just one fucked up piece of bad software with all its ads and crap.

Telegram is a nice, lightweight piece of software, sadly not the most well known one, and I still got to check out Discord. It seems to become quite popular from what I hear

printz said:

Again, I preferred to preserve the Eternity code and to use dedicated UDMF properties, instead of overloading Static_Init like ZDoom did. Let's have some well-defined ground, OK? And there's no Sector_SetLink in Eternity.

Static_Init still exists, but it's only used for MBF sky transfers, and I used it before I woke up and realized my mistake. I'm even still considering adding "Transfer_Sky" for it.

As for specifications, well I didn't even want to spend time drafting/writing a plain text thing. The specification is in the source code, e_udmf.h and I'd like to have it in the wiki sometime. Since it's all on master and everyone advertises that EE has UDMF by now, they can no longer change.

Static_Init owes its existence solely to the fact that the original value range was too limited to sacrifice more values for this stuff. You'll need it if you want to support older ZDoom/Hexen-format maps using these features.
I fully agree that it's a bad way to do stuff but it was still better than wasting 4 or 5 numbers on these features that, aside from the sky transfer are rarely used.

The sector linking through Static_Init was only done to allow translating the Eternity linedefs, the preferred method to handle this stuff is Sector_SetLink, because that not only allows attaching but also detaching.

For a shared namespace I'll also have to add some of your new portal definition stuff and the attached surfaces properties to keep things easier to handle. Is there any documentation for those?

Graf Zahl said:

For a shared namespace I'll also have to add some of your new portal definition stuff and the attached surfaces properties to keep things easier to handle. Is there any documentation for those?

Portal_Define and Line_QuickPortal are explained in the Eternity wiki (eternity.youfailit.net Detailed parameterized linedef specification, link). Most notably, the latter uses the tag, because I wanted a very easy way to make wall portals.

But still, why not just use the ZDoom specials in a common namespace? I can try adding the non-restrictive interactive portals to EE if you seriously totally insist; I'm just not very enthusiastic. I'd have all or nothing.

Attached surfaces have the following sector properties (all integer), and they basically do the same thing as the old linedef specials inside the code:
* floorid, ceilingid: the id of current sector's floor or ceiling respectively, as an attachment source.
* attachfloor, attachceiling: attach floor (ceiling respectively) to the floor or ceiling with this id. Or if negative, then attach to the floor or ceiling with the absolute value of this id, but by moving in the opposite direction (mirrored).

printz said:

I can try adding the non-restrictive interactive portals to EE if you seriously totally insist; I'm just not very enthusiastic. I'd have all or nothing.

In case this is directed at me: When I mentioned interactive portals above, I didn't realize that that was the term being used for an alternate type of portal. I just meant linked portals.

printz said:

But still, why not just use the ZDoom specials in a common namespace?

The least I wanted to do is to check them and if it makes sense to add them as well.

printz said:

I can try adding the non-restrictive interactive portals to EE if you seriously totally insist; I'm just not very enthusiastic. I'd have all or nothing.

You don't have to. A common namespace will have to restrict some features of some specials, the same would currently also be needed for the 'target' parameter of the level exit specials.

printz said:

Attached surfaces have the following sector properties (all integer), and they basically do the same thing as the old linedef specials inside the code:
* floorid, ceilingid: the id of current sector's floor or ceiling respectively, as an attachment source.
* attachfloor, attachceiling: attach floor (ceiling respectively) to the floor or ceiling with this id. Or if negative, then attach to the floor or ceiling with the absolute value of this id, but by moving in the opposite direction (mirrored).

Hm. More properties to maintain. Should be doable but will be a bit more work than I imagined.