Eternity now supports UDMF!

EDIT: The DRDTeam build isn't up so here's an exe for windows (requires VS2013 redist, probably). http://s000.tinyupload.com/index.php?file_id=67910146317611485159

As of today the UDMF branch has been merged into master, meaning that next time the DRDTeam builds update, you too will be able to enjoy not needing to use ExtraData any more!

Now, mapping for UDMF in Eternity currently has to be done using recent builds of SLADE3, because GZDoomBuilder has a lot of hard-coded behaviour (that I personally don't know how to tackle really).

Any help with getting support for GZDB or improving my SLADE3 config is much appreciated. I know some people might have some issues running my SLADE config so if you're at all knowledgeable with SLADE (specifically in the area of troubleshooting) then any help is really useful.
Some lines specials might have slightly incorrect args (this is inherited from the ZDoom config, I'll be trying to clear up all errors and work from the ground up for a better less messy config), so please consult the ZDoom wiki for its documentation on action specials. Additionally a speadsheet of what specials are working currently is available at: https://docs.google.com/spreadsheets/d/141vVQ6a7QMHkK0MkhNRn9hIhFOWJ7Y3U-9Pal_psOx8/edit#gid=202516284.

Find my most recent build of slade.pk3 below (please back up your current version of slade.pk3 and place this new file in the same folder). The source is available at the following link: https://github.com/altazimuth/slade.

Things are subject to change. Don't make a serious map if you don't intend on coming back in the near future to fix things that may have changed.
UPDATED slade.pk3: http://s000.tinyupload.com/index.php?file_id=05581846458088729740

Additionally, here is a build of my branch of SLADE3 (which I plan on making a pull request some time soon), which makes it so setting things like flat offset actually appears when in Eternity UDMF config (requires VS2013 redist): http://s000.tinyupload.com/index.php?file_id=63254735994378042119

Massive kudos to printz, who did all of the real heavy lifting.

Are there any spec doc about the Eternity namespace(s)?

Not yet, as objects and properties are still under construction. Done so far is:

* Coordinates which were still integer (sector height, texture offset) can now have decimal dots. This was missed from the original UDMF definition.
* Use equivalent ZDoom property names where equivalent features exist
* I added some properties such as sector friction (no more need for control linedefs) or linedef tranmap (Boom)
* Linedef specials use the familiar Hexen/ZDoom namespace. I also added some more specials such as Door_LockedOpen (I know how ZDoom does it but it's not Hexen compatible). Completing this is needed right now. People with Eternity levels in progress may want their maps converted without gameplay change.

printz said:

* Linedef specials use the familiar Hexen/ZDoom namespace. I also added some more specials such as Door_LockedOpen (I know how ZDoom does it but it's not Hexen compatible).

What kind of incompatibility are you talking about?

ZDoom treats delay 0 as "open and stay", whereas in Hexen (and I believe Eternity as well) the delay wraps around to 0xFFFFFFFF (see the vertical door thinker's function). Also, I think having Door_LockedOpen is more symmetrical, fitting with Door_Open, just like how Door_LockedRaise fits with Door_Raise.

printz said:

ZDoom treats delay 0 as "open and stay", whereas in Hexen (and I believe Eternity as well) the delay wraps around to 0xFFFFFFFF (see the vertical door thinker's function). Also, I think having Door_LockedOpen is more symmetrical, fitting with Door_Open, just like how Door_LockedRaise fits with Door_Raise.

How long is 0xFFFFFFFF, though? Having 0 seem to stay open forever but then eventually close after a long delay is totally counterintuitive and useless/nonsensical behavior, and I can't imagine it being used intentionally, whereas it would be guaranteed to annoy and confuse the hell out of mappers and players.

A quick question: is setting light values separately for lower/upper textures, floors, ceilings, and actors possible/planned?

Da Werecat said:

A quick question: is setting light values separately for lower/upper textures, floors, ceilings, and actors possible/planned?

Setting separate values for floors and ceilings is implemented, and you can choose whether or not the values provided for those fields are absolute or additive. As for lower/upper/mid textures being individually lighted I'm not too sure about that. It seems like something that should be feasible, but bear in mind that a sidedef still only has one offset. When talking about UDMF fields actor lighting didn't come up, but I don't see why it couldn't be implemented in future. Currently I'm working on other things, as is printz though.

I don't know about the others but I'm finding balancing what I consider high priority (e.g. EDF inventory and Heretic support in my case), but also not burning out focusing solely on those priorities, quite difficult. I will certainly keep your suggestions in mind though, as they are all good ideas, but I can't promise being able to get to them too soon.

I've provided a small demonstration wad that uses individual floor and ceiling lighting, as well as being absolute, in the following link : http://s000.tinyupload.com/index.php?file_id=56512841253613563667.

esselfortium said:

How long is 0xFFFFFFFF, though?

Really super long. That's over four billion tics. You'll have to stay in the same level for 1421 days in real time (so, three years and ten months) for it to run out.

The probability that the difference between "0 means forever" and "0 means nearly four years" will actually matter in real play: 0%, rounding up.

esselfortium said:

How long is 0xFFFFFFFF, though?

Almost 4 years.
Also, Hexen DOES use delay = 0 for doors that are supposed to remain open. You find the first one on MAP01.

Seems they turned a bug into a feature...

In any case, since there's already some other specials that have a special vanilla Hexen mode, I'd say that'd make sense here, too, instead of adding pointless clutter to the list.

For UDMF you don't even need 'locked' specials anymore because (in ZDoom at least) there's a 'lock' property which can be applied to all existing specials, so my decision always would be to leave the few old special cases alone and not bother with them any further than keeping them operable.

Altazimuth said:

I don't know about the others but I'm finding balancing what I consider high priority (e.g. EDF inventory and Heretic support in my case), but also not burning out focusing solely on those priorities, quite difficult. I will certainly keep your suggestions in mind though, as they are all good ideas, but I can't promise being able to get to them too soon.

There has been a discussion recently about this, but it boiled down to something fundamental: Without UDMF many things the engine supports have to be implemented with crutches in maps, the biggest of them Extradata.

Gez said:

The probability that the difference between "0 means forever" and "0 means nearly four years" will actually matter in real play: 0%, rounding up.

Absolutely correct, but there's one tiny little difference: The 'nearly 4 years' method will keep the thinker alive, while ZDoom deletes it after opening the door (so that other effects can be used on it later.)

With things like this one has to ask the question what is more important? The lone stray Hexen map that may unintentionally abuse this fact or better feature compatibility with ZDoom? (because I absolutely can see some ZDoom maps trying to close such a door later, which then would fail in Eternity.)

What I see developing here is putting the focus on the less important one of the (slightly) conflicting reference implementations.

Graf Zahl said:

With things like this one has to ask the question what is more important? The lone stray Hexen map that may unintentionally abuse this fact or better feature compatibility with ZDoom? (because I absolutely can see some ZDoom maps trying to close such a door later, which then would fail in Eternity.)

Bleh, this convinced me to remove the Door_LockedOpen special and maintain Hexen compatibility with Door_LockedRaise only if P_LevelIsVanillaHexen(), while otherwise it has the more familiar ZDoom behavior.

printz said:

Bleh, this convinced me to remove the Door_LockedOpen special and maintain Hexen compatibility with Door_LockedRaise only if P_LevelIsVanillaHexen(), while otherwise it has the more familiar ZDoom behavior.

Thank you.

Thank you as well. Emulating such a quirk is a lot easier if it is uniform across engines.

Doombuilder 2 already has some Eternity support built in. Would porting UDMF support to that be possible, or would it run into the same problems as GZDoomBuilder?

I personally have looked into this and I have a rudimentary config (that is not really good enough). After talking to boris he stated it would be possible via the use of a plugin, but I lack the expertise to carry this out (and honestly I'm already juggling enough things as is).

Yeah. Personally I'm a bit frustrated that we yet need to learn GZDoomBuilder programming before UDMF Eternity has a chance to become accessible. I hoped I could just tack the Eternity configs in a text file.

The GUI is not much more than a wrapper around the ZDoom UDMF fields. You can set all Eternity related UDMF fields through the "Custom" tab of each map element. That's not too convenient, though.