Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
MTrop

A Question about ZDoom UDMF Namespaces and Port Compatibility

Recommended Posts

I'm currently writing a Java library that can read/manipulate/write Doom's (and related source ports's) data structures and its different internal formats (Doom, Hexen, and Strife, for a few). It allows reading and writing of Wads and PK3s, Graphic patches (and PNGs), Palettes, Colormaps, node tables, Endoom lumps, Maps, and bunch of other useful stuff and it is almost complete save for one thing: UDMF Support.

Currently, it supports all of the primary namespaces (Doom, Doom 2, Heretic, Hexen, Strife) and provides a means by which additional namespaces can be added either by user or inside the library, but I wanted to support all I can before I release the first version.

My question is concerned primarily with the ZDoom namespace. Even though Skulltag and GZDoom typically support all of the same fields as ZDoom does due to the code base being essentially the same, I also saw that Vavoom has UDMF support. Since Vavoom has close-to-complete ZDoom compatibility even though it does not have the same codebase, is it still compatible with all of the fields outlined in the ZDoom UDMF specs, or does it only support the common namespaces without its own namespace?



(Oh, by the way: to those of you who remember the first time I did something like this years ago, I can assure you that this iteration of the library will be something that doesn't resemble complete crap ;))

Share this post


Link to post

The Vavoom namespace should be considered unsupported. Creating a separate one without releasing any specs is as good as not doing it at all. Functionally it's apparently the same as ZDoom with maybe a few bits missing but nobody can tell.

GZDoom and Skulltag don't need separate namespaces because the only things that are different are outside the UDMF spec's scope (thing numbers and a handful of new line specials only, IOW. stuff that should not block map loading.)

Share this post


Link to post

Cool. Thanks, Graf.

I'm already supporting the "ZDoom" and "ZDoomTranslated" namespaces, so I guess the GZDoom and Skulltag ones are overkill, especially if they don't have their own actual namespace. It does make more sense that they would just use ZDoom.

Also, if I were to create a utility that would convert Doom/Doom2/Heretic/Strife maps to ZDoom/Hexen, where would the translation table information be stored in ZDoom? Is it in the ZDoom PK3 or hardcoded in the source code (and if the latter, what are the files)?

Share this post


Link to post

It's in the xlat directory in the pk3 (and the /wadsrc part of the sourcecode as well, obviously).

Share this post


Link to post

There's a few gotcha's to observe when converting binary Doom-format maps to ZDoomUDMF. Due to required support of some hacks ZDoomDoom and ZDoomHexen work a bit different in some areas and there's one very important thing that's even different between ZDoomHexen and ZdoomUDMF because it was very poorly implemented in ZDoom and I wanted to get rid of the hacks for UDMF and start with s clean slate.

Here's a few things to look out for:

1. When converting a Doom format map to ZDoomTranslated or ZDoom UDMF namespaces every tagged sector needs to get added a 'dropactors = true;' line to remain compatible.

2. For historic reasons there's 2 linedef activation modes in ZDoom called 'laxmonsteractivation' and 'strictmonsteractivation'. In the lax mode monsters can activate some teleporter, door and lift specials without having them flagged to do that. The big problem here is that for years the lax mode was the default so a lot of maps depend on it. As a consequence ZDoomHexen has to default to this.
However, since UDMF supports much more flexible linedef activation semantics than ZDoomHexen format this is of no use in UDMF and the technically correct 'strictmonsteractivation' that only allows monsters to activate lines that are flagged for it is used as the default setting.
This is nothing the map converter should handle automatically because it's settable in MAPINFO, but an option to convert 'lax' maps to 'strict' should be an option in any such converter so if you want I can compile a list of settings where this needs to be addressed.

Share this post


Link to post

At the moment I'm not considering writing any conversion software, but it still would be be nice to have if the time comes when I want to undertake such a project.

Perhaps the ZDoom Wiki would be a better placement for this type of documentation?

Share this post


Link to post

I've released version 1.0.0 of the library at here at my project site, Black Rook Software, so if anybody wants to either write a news entry about it or do some additional testing, go right ahead.

It requires the Black Rook Commons library, so you will need that to link/use the Doom library. All source code for these projects are available, licensed under the LGPL v2.1 license.

Send questions to support (AT) blackrooksoftware (DOT) com.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×