UDMF

[skadoomer]

Very well put Hotwax. Perhaps this needs to be an expanded section of the wiki that de-mystifies UDMF (like what is being done here), since the map format has begun and its already possible to make a map (however limited) in this new format.

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*

I remember that topic, and IIRC, it was put on hold because of ACS's non-existant ability to understand strings, making it a limited implementation at best.

[CodeImp]

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.

Adding custom fields is only really useful in 2 cases:
1) You want to define a field that a newer version of the sourceport supports, but is not included in the game configuration so it doesn't become one of the displayed fields, or
2) You want to add information to the element that can be used by scripting to do something special (like a duration or a message that is shown)
In the first case you actually WANT it to be picked up by the sourceport. Only in the second case it could happen that you use a field name that is going to be used by a later version of the sourceport, but it is unlikely (and even IF it happens, it is no different from how a newer ZDoom version breaks some older maps now, its nothing new) but you can prevent this yourself by choosing a name that is unlikely to be used, by prefixing it with something like this: __lightduration or like script_lightduration.

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.

I find this abuse of namespaces and I discourage this. See above for a more proper solution.

[HotWax]

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"

These are not the same as I was referring to. To my knowledge, that section describes a value that instructs the editor and the game engine what type of map it's reading, so that appropriate changes can be made. For example, randy could put code into ZDoom that checks this, and if it sees that the value is "Skulltag" he could display an appropriate warning that some features may not work. Or he could make it alter some specials to work better in ZDoom. Or whatever.

What I'm talking about is the fact that if, within a sector definition, you decide that you want to put a completely custom field in (i.e. one not currently supported by ZDoom), a future version of ZDoom that implements that same name could cause trouble.

For illustration, here's a convoluted yet real-world example.

Let's say you're defining some kind of CTF mod for ZDoom. You write up an ACS script to handle all the special stuff you want in, and then in certain sectors you add the custom properties "BlueBase" and "RedBase". You can then check the value of these with ACS to determine which areas should be treated as each side's base for whatever purpose you wish for your custom CTF mod. You release it, everything works great, the world moves on.

Then, 6 months down the road, randy or Graf add some kind of support for funky color-related stuff in sectors (hey, I said it was convoluted) and add the sector properties "RedBase", "BlueBase" and "GreenBase" to support this. When you try to run your previously-working map in the new version, ZDoom reads these and expects to find an integer value, but instead gets a boolean. It reports the map format is bad and won't run it, or worse it treats it in an entirely unintended way and causes graphic anomalies that weren't present there before.

Unfortunately, I don't think it's wise to rely on the map authors to police themselves by creating names that are unlikely to be used in the future. It's all well and good if every author out there decided to use stuff like "MyAwesomeCTFMod_03-2009_v1_BlueBase" to prevent future conflicts, but it's just as likely that someone not knowing any better will use stuff like "SlopeAngle", "RedValue" and even "J" instead. This can only lead to trouble, in my opinion.

I don't know if this would have to affect the base UDMF spec or what, or if the engine should be required to enforce it, but it might not be a bad idea for the editor to automatically preface these kind of parameters with "custom." or something. I guess you'd have to allow the user to override that for the purposes of case 1 in CodeImp's post... I don't know, it just seems like this is trouble brewing and it's better to be solved early than later.

[CO2]

Here's a live, working example.
The 'lightcolor' property exists in the zdoom (and zdoomtranslated) namespace. Implementing it in the hexen map format would require changing offsets for bytes in sector defintions, destroying every single map that was made before it (thus changing the format somewhat).

---

This map uses no ACS or DECORATE whatsoever, but some sectors have colors set to them. The screenshots are from a map I made in db, converted to udmf, and then implemented the sector colors by hand in wordpad.

http://wads.co2games.com/UDMFCOLOR.zip

[HotWax]

Ahh, nothing like some good ol' fashioned colored lighting abuse. Say, shouldn't the red and blue lights from those doors escape into the rest of the room and merge into an ugly purple?

But yes, that's a good example of something that UDMF makes easier on everyone. It's much easier to go directly into the properties window of an editor and set the light color of the sector than to have to create a script and find the correct function to set the light colors in an OPEN script.

[Chris]

In the first case you actually WANT it to be picked up by the sourceport. Only in the second case it could happen that you use a field name that is going to be used by a later version of the sourceport, but it is unlikely (and even IF it happens, it is no different from how a newer ZDoom version breaks some older maps now, its nothing new) but you can prevent this yourself by choosing a name that is unlikely to be used, by prefixing it with something like this: __lightduration or like script_lightduration.

Not only that, but proper convention dictates prefixing *all* custom fields with some kind of moniker used by your mod. For example, custom properties in Knee Deep in ZDoom would be something like kdizd_lightduration, kdizd_secondcolor, etc. Personally, I'd discourage using __foo for custom properties.. generally anything starting with two or more underscores is implementation-specific details that isn't supposed to be used externally.

[CodeImp]

Perhaps we can come to an agreement with Quasar (and whoever is interested in UDMF) to use map_ as a prefix for map-specific fields and that no sourceport field may start with this prefix.

And for the nitpickers that fear typing 4 extra letters: DB2 can then automatically have this at the start of the input box when you insert a new custom field, so that you can easily type the name of your map-specific field without having to type map_ or you can delete the prefix if you want to insert a sourceport supported field.

[Graf Zahl]

I think it's best put in the spec. Otherwise some people may just throw any caution into the wind and create a mess. If this is put in the spec any implementation I'd do would strictly enforce it.

[CodeImp]

I have posted this at doomworld, here.

[Geometer]

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)

Yes, this is very is very important feature. However, DB2 doesn't have proper handling for this. What I mean? There is no direct input for vertex/things coordinates. Imagine: you have lines, which intersects in verteces with non integer coodinates and you want to place on this verteces vertex slope things. There is no simple way in Doom Builder to do this. Of course you can edit TEXTMAP lump directly, but in my opinion it is rather doubtful pleasure.

I think if something like this will be added, it will be a very good addition to existing vertex mode.
Also adding non-integer grid sizes may be useful (especially if they will have their own color settings).
And finally I hope that merge geometry for things will be implemented, so verteces can pull them.