UDMF

[InsanityBringer]

Other than that, i don't see any other advantage in it.

There's ton. In fact, some of the features you mentioned are pretty much all results of the advantages of it

In fact, the text format is pretty much the biggest if you think about it.

[Chris]

Currently you don't, because there is no format (not even UDMF) that allows a Z value for a vertex (but I suppose Graf/Randy could add it for the slope height).

It should actually have two Z value, Zc and Zf.

Couldn't it actually have more, since a vertex can be part of a number of sectors that each have it's own [floor/ceiling] heights?

[esselfortium]

Currently you don't, because there is no format (not even UDMF) that allows a Z value for a vertex (but I suppose Graf/Randy could add it for the slope height).

It should actually have two Z value, Zc and Zf.

Couldn't it actually have more, since a vertex can be part of a number of sectors that each have it's own [floor/ceiling] heights?

The problem with supporting that is the fact that sector numbers, vertex numbers, line numbers, and whatnot don't remain constant when the map is edited...

In any case, though, there'd have to be separate Floor Z and-- oh nvm, Gez already got it

[Hirogen2]

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)

This reminds me of true Bezier-curved linedefs. Then there would be no need to spend nearly as many vertices for a round corner as it is done today.

[Hirogen2]

Yes, I completely agree that co-ordinates are the only map properties of a vertex. That was the basis of my illustration in my last post.

I wholeheartedly disagree about that. In GL at least, vertexes can have a color. Starting from this idea, you can define sector properties based upon vertex properties, such as light level, color, fog density, friction, wind force, and so on, and the engine then calculates the value of the property for the spot you are standing on by interpolation.
Well, just a thought.

[ReX]

I wholeheartedly disagree about that. In GL at least, vertexes can have a color. Starting from this idea, you can define sector properties based upon vertex properties, such as light level, color, fog density, friction, wind force, and so on, and the engine then calculates the value of the property for the spot you are standing on by interpolation.

Interesting notion. I had not thought about the possibilities inherent in assigning attributes other than co-ordinates to a vertex. Why don't you post this idea on the Feature Suggestions page?

[Hirogen2]

It would seem like a humongous task to code, esp. so for the the software renderer.

[Eriance]

Just a general question, is this new format still BSP-based or not? If not, would it allow for Duke-3D style real moving sectors?

[Gez]

The map is still treated the same way internally by the engine. So unless you use a port that's not BSP-based (does such a thing exist?)...

[Graf Zahl]

UDMF only exposes existing engine features. Currently it doesn't implement anything that can be done by other means.

[skadoomer]

Given what i've read about UDMF and its storage of extra data, does this allow for the elimination of control sectors for certain special linedefs? Also, is there the ability to make custom field properties? That would be incredibly useful with a corresponding ACS function like GetSectorInfo(int udmf field), or something of the like.

[CodeImp]

Also, is there the ability to make custom field properties? That would be incredibly useful with a corresponding ACS function like GetSectorInfo(int udmf field), or something of the like.

Yes, you can add any number of fields to any map element yourself and give it any basic datatype supported by UDMF (int, float, boolean, string) or a more meaningful datatype supported by DB2 (texture, flat, linedef action, sector effect, angle, and more) which is stored in UDMF as a basic type but remembered by DB2 for your convenience. I have suggested ACS functions that allow reading these fields from map elements, but I'm not sure if they are implemented in ZDoom already.... *looks at Graf/Randy*

[Graf Zahl]

Given what i've read about UDMF and its storage of extra data, does this allow for the elimination of control sectors for certain special linedefs?

No. Most effects using a control sector need that sector to work so nothing has changed.

[HotWax]

I think many people in this thread are missing the fundamental reason that UDMF will completely obsolete the original format for new maps.

Within ZDoom, randy and Graf can add as many features to vertices, linedefs, sidedefs, sectors and things as they want. They can increase the storage space within the EXE indefinitely, meaning if there's call for a new thing flag, or new line flag, they can add it. Whether that means increasing the storage capacity of a single member variable or adding an entirely new one, not a problem. The bottleneck comes in the outdated mapping format that has been in use since Doom 1.666's release. The map format is strict, defining a certain amount of space for data to be stored for each feature. It cannot be expanded, so up until now if the developers wanted to add a new line flag, they had to create a new line special to indirectly set that flag at run-time. Now it's as easy as adding support in the EXE and expanding the UDMF format (which is infinitely expandable) to support a new entry for that flag.

Naturally this also means existing features are more directly-accessible. You no longer have to use a line special just to make a line translucent; just set it in the line's properties directly. And future features will be made much more convenient since they won't bother to support the line special method. The developers will simply add them as a new UDMF property. Of course this also means that the old binary format will become more and more obsolete as such features are added, but that's progress.

So, from a developer perspective, UDMF allows much more freedom and ease of coding when adding new features and supporting old ones. From a mapping perspective, it allows you to use existing features more easily and provides support for new features that mappers wouldn't have been able to use with the old format. For players, they will largely benefit from the new features that will be added because of UDMF's expandability. So, the short answer might be "Right now it doesn't do much different" but going down the road I think you'll quickly find out why the developers made the push to start supporting it.

Now, I have a question on custom properties being entered for these structures. CodeImp, you mention that DB2 allows a user to specify their own property freely, and certainly the UDMF format allows this (it is part of the format that the EXE ignore any property it doesn't recognize), but I can see that as trouble going down the road if the developers want to add a new property tag and some mapper has already used it in their custom map. Shouldn't there be a convention established for custom namespaces so this doesn't happen?

[Gez]

It's already taken care of, since there are already namespaces. See, for example, ZDoom UDMF.

ZDoom supports all namespaces defined in the base specification and adds two new ones:
"ZDoom"
"ZDoomTranslated"

So it could be possible, in case of troubles, to create new namespaces for new versions of port-specific extensions. Let's say ZDoom v.3.0.0 adds a thousand new properties and stuff, the "ZDoomThree" namespace could be created so as to be sure not to break any map with custom fields made for the ZDoom namespace.