I have been made aware that Doom Builder 2 has launched containing a speculative (and therefore totally incorrect) configuration that allows the creation of UDMF maps under the Eternity namespace.

This is a warning that any such maps made will NOT function correctly with Eternity once we complete implementation of UDMF. Eternity's line special system is being rewritten to accomodate complete streamlining of Doom/Heretic/Strife with Hexen in a manner similar to ZDoom, and this will involve the elimination of non-parameterized line specials in UDMF, as well as a complete reassignment of specials to line numbers in that format.

Again, this is just a warning to avoid something that was not produced or approved by us and will therefore not work in the future. Note that this only applies to maps created with an alleged Eternity namespace - UDMF maps created by a compliant editor for Doom/Heretic/Hexen/Strife maps should function as expected in EE once support for the map format and those respective games has been implemented.

Quasar said:
and this will involve the elimination of non-parameterized line specials in UDMF, as well as a complete reassignment of specials to line numbers in that format.

... and even I didn't go that far and provided a Doom-line-format option for UDMF - although my main motivation was to be able to convert maps using ZDoom in Doom format directly to UDMF without having to do further conversions for line and sector specials.

Quasar said:
Eternity's line special system is being rewritten to accomodate complete streamlining of Doom/Heretic/Strife with Hexen in a manner similar to ZDoom

I suppose the line special numbers will be the same as ZDoom? It would be nice to be able to make a map in Hexen format or UDMF that could be played in both Eternity and ZDoom. It would have to avoid features that are exclusive to just one port, but there are enough advanced features in common to justify it.

ExtraData will still be supported in concert with the Doom format, and so long as it happens naturally, new features will continue to be exposed through it. But its use will be naturally discouraged because UDMF does everything it does and it does it way better.

You can add your own fields to UDMF quite easily, just by using field names that start with "user_". Here's an example:

code:thing
{
// other stuff...
user_isthebigbad = true;
}

Now, whether or not you can actually USE this information is up to the implementing source port. UDMF implementations are required to at most ignore things they do not understand. As for Eternity, everything it does not recognize will be stored in a hash table, and these properties will be reflected into the Aeon API where you will be able to retrieve them by name from an ECMAScript array, like so:

code:// Strictly an example. It may not work exactly like this
// when all this stuff actually gets defined...
function HandleTheBigBad()
{
var isthebigbad = this.mapthing.UDMFProps["user_isthebigbad"];
if(isthebigbad)
// start up the health bar or play a
// fullvolume sound or close all doors tagged
// 999 or whatever...
}