UDMF

[Enjay]

UDMF is in its infancy right now but trust me, in the future, when UDMF features get used extensively, WA maps will look old.

Is it possible to get some discussion going to let us end-users know the kinds of things that UDMF will make possible? The discussions to thrash out the format over at DoomWorld were (and still are) pretty technical and didn't obviously translate to what some mapping hack like me might be able to do with it. Seeing as how it is a train that seems to be gathering speed without a significant number of well known, experienced mappers on board (yet), it makes sense for information about UDMF to be available in a more mapper-friendly format.

[Phobus]

Hmm, so far all I've heard is that UDMF is the new thing. I know what it stands for and what that entails to a point, but I have absolutely no idea what that means for me as a mapper. I'm presuming it will support all of the old features one way or the other from the various ports that are affected?

[Cutmanmike]

Yes please since this will most likely put the final nail in the coffin for WA users hoping to use the latest ZDoom features. I should hope it's worth it

[esselfortium]

Hmm, so far all I've heard is that UDMF is the new thing. I know what it stands for and what that entails to a point, but I have absolutely no idea what that means for me as a mapper. I'm presuming it will support all of the old features one way or the other from the various ports that are affected?

The base standard for Doom in UDMF is essentially Boom capabilities (with Heretic, Hexen, and Strife in UDMF's base specs representing the basic vanilla features of each respective game), and that is the common thread that all UDMF-compliant ports must be compatible with.

Different sourceports can then extend UDMF in their own ways, adding new flags, specials, fields (i.e. Floor_XAlign or some such thing), and the like to allow mappers convenient usage of their features. This means that port features that Doom and Hexen formats can only support through either scripting or control lines and dummy sectors can now be specified directly in the thing/line/sector properties, just as easily as you can set a sector's floor or ceiling height now.

For now, it means that features that already exist will be much more easily accessible to mappers (and more possible for editing software to natively support; for example a Doom Builder 2 plugin could allow you to align, rotate, and scale flats in 3D mode). In the future, it will mean that new features will be developed that wouldn't have even been thought of before, because there was never previously any decent way to make them usable in maps. What those features will actually be, for ZDoom and other ports, can't really be determined yet

[Graf Zahl]

Here's a list of the base spec's features and ZDoom's additions.

http://mancubus.net/svn/hosted/zdoom/zd ... s/udmf.txt
http://mancubus.net/svn/hosted/zdoom/zd ... _zdoom.txt

Just to give a quick overview.

[CodeImp]

Those are technical specifications, but I think the purpose of this topic is to discuss what UDMF is for the end user, how it helps them and what can be done with it.

Doom Builder 2 will help editing in UDMF significantly even though it does not yet support ZDoom features in Visual Mode. Here is an example of what you get;

The Properties tab on that dialog contains the normal controls you know to edit the sector properties (floor/ceiling texture, heights, brightness, special effect) and the Custom tab, as you can see in this screenshot, provides numerous additional properties that you can simply set by clicking on them and entering a value or click the button next to it to help you creating a value. Note how you can simply scale and rotate the texture, set individual light levels and colors, change the gravity, etc. In this screenshot I set a double gravity (2) a 128 brightness for the floor and I'm about to set a light color for the sector.

Eventually, if people care to help me programming it, there could be a plugin that also reflects these effects in Visual Mode and even allows you to edit things like texture scale and rotation in Visual Mode.

Also, UDMF uses floating point values for vertex and thing coordinates, which allows more accurate mapping (I don't want to encourage 1 mappixel sized sector details, but it also helps with more accurate splits where 2 diagonal lines cross each other)

[Cutmanmike]

Well I can see that being very handy. Makes a whole lot of specials and things redundant!

[CodeImp]

Not redundant really. You still need scripting to make such special effects happen dynamically.

[ReX]

Doom Builder 2 will help editing in UDMF significantly even though it does not yet support ZDoom features in Visual Mode. Here is an example of what you get...... Also, UDMF uses floating point values for vertex and thing coordinates, which allows more accurate mapping (I don't want to encourage 1 mappixel sized sector details, but it also helps with more accurate splits where 2 diagonal lines cross each other)

That was a very good illustration of what UDMF allows. However, I still don't see how older map editors will become obsolete. The examples you gave are all available through the various specials, which can be implemented via older editors.

Now if you were to tell me (as Graf implied in this post) that these specials will eventually be removed from ZDooM's and GZDooM's code, then I can understand how older editors will become obsolete. As DB2 appears to be the only map editor under on-going development, I'm guessing it will also be the only editor that can handle UDMF.

Incidentally, on numerous occasions I have tried to learn the ropes of map editing using DooM Builder. Unfortunately, I apparently lack the patience necessary to "unlearn" the techniques of one tool and learn those of a new one. The one thing I find myself doing a lot is editing raw data in WA. Is there something comparable in DB? I haven't been able to find it. Also, in DB2 will there be a mapping option to create sectors directly (both square and polygonal) instead of via linedefs? If that's the case, it'll be more of a gem than what I've heard it will be. Regardless, once I have some spare time I am going to practice with DB. (And no, it's not because of Graf's contant nagging.)

[Phobus]

I see... I think CodeImp has explained to me roughly what's going on now. In which case this really is changing Doom.

I forsee many badly lit, ugly maps coming until people get used to these features though

[Cutmanmike]

Not redundant really. You still need scripting to make such special effects happen dynamically.

I know but I'm pretty sure most of the time people use colors and fades for decorative purposes.

The one thing I find myself doing a lot is editing raw data in WA. Is there something comparable in DB?

What in the raw data are you editing? Most of what wadauthor sees as "raw data" is actually basic data that can usually be found in many of DB's editing windows. For example, thing numbers can be changed in the window you get when you double click on a thing.

[Gez]

Now if you were to tell me (as Graf implied in this post) that these specials will eventually be removed from ZDooM's and GZDooM's code, then I can understand how older editors will become obsolete.

Nothing's going to be removed. It'd be insane to stop supporting the binary map format in which the IWADs themselves are written.

What he meant was that any new map feature (like a new linedef property) will only be available in UDMF. This is not just out of a desire to force people to adopt the new format; this is mostly because there's no room left for extension in the old formats (both Doom and Hexen). For example, you have a new linedef flag you'd like to see implemented? Unfortunately, there's no flag available left.

UDMF is a format that can be infinitely expanded, the Doom and Hexen map formats have to follow certain constraints that makes it impossible. For example, the arguments that linedefs and things can have are stored in a single byte in Hexen format, so you can only have integral values from 0 to 255. Theoretically, nothing prevents an UDMF map to have a special with 320, -40, 999.57 and "Hello World" as parameters.

[Cutmanmike]

So really from a player's perspective, there's really not much new to see... is there?

[Ghastly_dragon]

From what I understand, it's the new Hexen format with most features much more readily accessable.

Though, it's a little jading hearing that different source ports will be implementing different features for UDMF. Since part of the acronym is 'universal', I assumed it would be completely universal between the modern source ports (and replace Boom format entirely (for the newer source ports, at least ) ).

[Gez]

So really from a player's perspective, there's really not much new to see... is there?

Just like there wasn't really much new to see in the ZDoom "Doom in Hexen" format, at first... Just wait until DB2 gets an official release and more and more modder start exploring what it can do and getting ideas for new features.

Though, it's a little jading hearing that different source ports will be implementing different features for UDMF. Since part of the acronym is 'universal', I assumed it would be completely universal between the modern source ports (and replace Boom format entirely (for the newer source ports, at least ) ).

The format is universal, in that its syntax and the ways it can be expanded have been agreed upon by, well, not all port-or-editor developers but all those who bothered to join the conversation.

It's just that different ports have different features. So either UDMF allowed only the features that are common to all the participating ports, or it allowed ports to have their own extensions to the format covering their own exclusive features. Or, but let's be serious, every port would have had to first implement all the exclusive features of all the others. I'm sure many users would have liked that, but that really wasn't the point.