You can now make UDMF maps in Eternity

[printz]

I've decided to post this now. You can now make UDMF maps in Eternity. Goodbye extradata! If you're on Windows, there is a Doom 2 / UDMF format configuration for Eternity available.

How it works:

1. It supports ACS. The ACS format is ZDoom, so you have access to all those goodies in ACS introduced by the ZDoom devs. The editor already provides that
   
2. Nodes are built with ZDBSP (the only UDMF way). The editor already provides that.
   
3. Linedef specials and sector specials use the same namespace as in ZDoom, so if you're used to ZDoom, you already have the same specials in mind.
   

Some things to watch out for:

1. GZDoom Builder has a hardcoded interface for UDMF. This means that you're gonna see the same huge dialog boxes as in ZDoom mode. Not all features will be available, but a lot of them are.
   
2. This is of beta quality! This being said, please report any bugs and post any feature requests on this forum!
   
3. Watch out for any errors in the GZDoom-Builder EE-UDMF configuration. For a large part, I copy-pasted data from other configurations. Hopefully whatever is important will work.
   
4. Be sure to look in the last tab of object (thing, linedef etc.) properties! I've added a few features which aren't covered in the main tabs!
   

Some stuff different/new from ZDoom:

1. besides ZDoom, new linedef properties: lowerportal (boolean), upperportal (boolean), portal (integer), tranmap (string).
   
2. sidedef offsetx and offsety can be set in floating-point, not just integer (unfortunately editors may not support this)
   
3. sector heightfloor and heightceiling can be set in floating-point as well
   
4. sector properties not (yet) in ZDoom: friction (integer value like a straight Boom linedef length), damage_endgodmode (bool), damage_exitlevel (bool), colormaptop (string), colormapmid (string), colormapbottom (string), floorid (int), ceilingid (int), attachfloor (int), attachceiling (int), portalfloor (int), portalceiling (int)
   

Now. Most linedef specials are now doable in ways that ZDoom has already implemented. But here are some exceptions:

1. Portals. You don't use Sector_SetPortal (actually it's there, but not recommended). You use Portal_Define (300). Arguments are:

• portal ID: a unique portal number, independent on linedef or sector tags.
  
• portal type: select one from the dialog box. Same kinds as in Doom format.
  
• anchor line ID: only for anchored/two-way/linked portals. It's the line against which to make the portal reference. It must have the same orientation if it's a linked portal, but can be rotated if it's an anchored/two-way portal.
  
• Z parameter. Has different meanings depending on portal:
  - anchored or two-way: visual Z offset from this line to the anchor line.
  - linked: vertical displacement of linked portal from how it would normally appear. Useful for through-portal elevators.
  
• anchor is flipped? True/false value which should be true if the anchor linedef is flipped compared to current linedef.
  

This Portal_Define special will just define a portal. How do you apply it?

• For sectors: select all sectors near the current linedef and set their "portalfloor" (or "portalceiling") property to the portal ID you just gave. Then, if it's a two-way or linked portal, select all sectors near the anchor linedef and set their "portalceiling" (or "portalfloor") property to the negative of the same ID. So if you have bottom layer connected to a top layer, and the portal setup (300) linedef is below, with a portal ID and line ID both set to 1, the anchor linedef placed above will have tag 1, and the sectors below will have "portalceiling" set to 1, while the sectors above will have "portalfloor" set to -1.
  
• For linedefs: select any linedef and set its "portal" property to the portal ID you defined. Again, if it's two-way or linked you can put negative portal ID for the opposite direction.
  

Alternatively, just for linedefs, you now have Line_QuickPortal. It only supports linked (default) and two-way portals. How to use it: select two linedefs (of equal length and -- if linked -- equal orientation, but flipped), give them the same tag, and set them special #301. The first parameter, if 0, will result in a linked portal, and if 1 will result in a two-way non-interactive portal.

Line portals will work with polyobjects. If the sector "inside" the polyobject is of different height than the area outside the polyobject, the portal linedefs will get lower and upper textures as set in the editor on the polyobject linedefs.

Edge portals (new kind of portals). Currently these are veeeery beta. Anyway, they can be set up by applying the "Lower/upper part copies backsector's portal" flag to the linedef in the editor. It will only work if the linedef's backsector is a portal, and (if linked or two-way) its corresponding line from the other side will have "portal" set to the same value as the corresponding sector's plane "ceilingportal" or "floorportal". Another limitation: lines with portals must match in length.

You no longer need to place buffer sectors behind linked portal lines. But if it somehow still gives you trouble, please mention it here, and in the meantime use buffer sectors anyway.

2. Attached surfaces: there is neither Sector_SetLink, nor Static_Init (static_init is only for MBF skies). Instead, the classic-format "set floor control, set ceiling control" specials has been replaced by the sector "floorid" and "ceilingid" properties. And the "attach floor to control" and "attach ceiling to control" specials have been replaced by "attachfloor" and "attachceiling" properties. And if you want to "attach mirror X to control", use negative ids in "attachfloor" or "attachceiling".

I think this is enough for now. Any problem you have, please say it. There may be lots of them right now.

[Altazimuth]

Here's a test map demonstrating the new portal type (the ones here) and the flags: http://s000.tinyupload.com/index.php?file_id=00684991521611107327

MAP02 of this WIP wad contains both new portal lines in use: http://s000.tinyupload.com/index.php?file_id=17986653271624341164

I will be making a pull request to SLADE3 (I've been updating a fork to keep parity with EE) so you can expect support in that soon as well.

EDIT: Pull request made https://github.com/sirjuddington/SLADE/pull/625
It contains vital config changes, as well as adding proper rendering of things like flat offsets, flat scaling, slopes, etc.

EDIT2: Pull request accepted.

[Fonze]

Haha nice; good job getting this implementation finally added; I really look forward to seeing some really cool, advanced maps come out for Eternity; hopefully this addition will help attract more and more talented mappers to the light side :)

Cheers fellas!

[Graf Zahl]

printz said:

You no longer need to place buffer sectors behind linked portal lines. But if it somehow still gives you trouble, please mention it here, and in the meantime use buffer sectors anyway.

I tried that in ZDoom and in the end decided against it. It was causing some really nasty problems with PIT_CheckLine with players being able to squeeze through some imaginary holes at the portal boundary because PIT_CheckLine did not properly catch all edge cases.

With a buffer sector you have the guarantee that both sides of the portal are clean and this cannot happen.

[Hell Theatre]

Nice to see this finally happening. Let's see if this will help Eternity - although I have some doubts.

These have nothing to do with Eternity's features, but if you look at the popular ports out there, they all either have a hardware renderer or at least a variant port with a hardware renderer.

Eternity is the only one of the major ports that is still exclusively software rendered and I am wondering if this is part of the reason why its user base doesn't seem to grow.

[Graf Zahl]

It's hard to say how important hardware rendering is. One thing I discovered long ago is that inside the Doom community the attitude towards it is highly different than for casual players.

With most casual players it appears to be very important that they can have somewhat 'improved' visuals - where 'improved' has a wide range - from being able to use hires texture and/or model packs or just having smoother color gradients.

Within the community, on the other hand, there seems to be far more focus on a faithful representation of how the game originally looked, and here on Doomworld that focus seems to be even stronger.

Don't get me wrong - you will definitely find people from both camps here and among casual players, but it very different proportions.

[kb1]

Great job, guys! Wow, your hard work is showing. Eternity is a powerhouse, and getting better all the time. Awesome! I can't wait to see some of the crazy architecture possible with all of these new tools. A new era of Doom mapping possibilities!

[boris]

When I try to apply a linked portal to a polyobj I get HOM on the opposite side. I.e. I can look into the polyobj, but not through it (WAD: http://88.198.197.45/boris/doom/polyportal.wad):



If I'm removing the polyobj stuff I don't get any HOM (when I'm looking at the now defunct polyobj in its source sector).

printz said:

You use Portal_Define (300).

[...]

Alternatively, just for linedefs, you now have Line_QuickPortal.

So I assume the preferred way to do line portals is Line_QuickPortal?

[edit]
The portal id and anchor tag/id do not seem to be related (i.e. they can be different). Is it considered best practice to keep them the same anyway?

[Mordeth]

Is there a conversion tool available somewhere to port EE-Doom to EE-UDMF format? And from what GZDoomBuilder build number is this supported?

[Altazimuth]

Boris: I'll make sure to flag this up with printz, as I ran in to the same issue earlier today whilst I was expanding that portal testing map I sent you the other day.

Mordeth: Not yet, and I don't know what plans there are to deal with that. I'd strongly suggest the most recent builds of GZDB as anything older than a few days will be using a few renamed words.

[printz]

boris: very interesting. I will know when I have access to download your map. Away from PC now.

Why I have separate and independent portal id from line id: normally you'd say that anchor line id is enough to identify a portal; unfortunately there are portals without anchors (plane, horizon, sky box) so there is a need for the portal id.

Since modern editors have no visual aid for new stuff such as portal id, it's probably best for you if you use the same portal id as the anchor line id for anchored/two-way/linked portals, while for plane/horizon/sky box portals you use some big number, hard to reach by incrementing linedef tags.

[printz]

boris: I got why the problem happens. It's because of a current design limitation (easily workable in the editor, but maybe not obvious): the box sector holding the polyobject prototypes must be "audibly" connected to the main area. Do this by placing a tiny sector at the corner of the box, then making it be the same sector as one from the gameplay area. Do not make the entire box sector the same as one from the gameplay area, however!

Second problem: do not allow a polyobject with portals to butt any wall from the game area. You will see HOM from the inside. Always keep a distance. Right now, after I fix the sector reference, I'll get HOM to the west from inside the polyobject box, while the poly is at the spawn position.

[Mordeth]

Altazimuth said:

Here's a test map demonstrating the new portal type

Both tinyupload links give warnings about hidden virus/malware in firefox..?

[Altazimuth]

Mordeth said:

Both tinyupload links give warnings about hidden virus/malware in firefox..?

Really? I get no such warnings in Waterfox.

https://dl.dropboxusercontent.com/u/36523265/baremin.pke
https://dl.dropboxusercontent.com/u/36523265/PortTest.wad

EDIT: Now I'm getting the warnning but I just ignored them; but I suppose you don't have the benefit of knowing exactly what the file is so yeah.

[Mordeth]

Weird, gone. Probably tinyupload having fits.

[boris]

So I've started to add UDMF support to my GZDB portal helper plugin. However, Doom format and UDMF portal definition are quite different, and some design decision I did in the plugin don't work too well with UDMF. So I'm actually thinking (99% chance) to ditch support for Doom format and focus on UDMF. Since there doesn't seem to be anything in development for EE anyway and UDMF is the future not much should be lost.

Any thoughts on this?

[Altazimuth]

boris said:

So I'm actually thinking (99% chance) to ditch support for Doom format and focus on UDMF. Since there doesn't seem to be anything in development for EE anyway and UDMF is the future not much should be lost.

Any thoughts on this?

Well, as long as you keep the original uploaded somewhere then I don't see why ditching Doom format support would be a bad thing. There's the old version for those who are using Doom format, and the new version for those working in UDMF. I can't imagine that there will be any people working for multiple EE projects that use different map formats. I can't speak on behalf of those working with Doom format and ExtraData though, as all my projects are now in UDMF.

EDIT: Don't abuse the word "obvious", kids.

[printz]

boris said:

Any thoughts on this?

A mod whose name is associated with Doomworld itself still has Doom format levels in progress, and will continue to do so until someone (probably someone from us) makes a Doom-to-UDMF converter for EE that's foolproof.

[Mordeth]

boris said:

Since there doesn't seem to be anything in development for EE anyway

*COUGH*

[Lüt]

Mordeth said:

*COUGH*

Double-COUGH.

printz said:

A mod whose name is associated with Doomworld itself still has Doom format levels in progress, and will continue to do so until someone (probably someone from us) makes a Doom-to-UDMF converter for EE that's foolproof.

Good call, thanks.

By the way, I suppose this is as good a place to post this as any: I just wanted to say I appreciate all the excellent work you've done with Eternity lately.

I've been gone for quite a while, and though I've only begun exploring your latest updates, it's exceptionally amazing for me to finally have the functionality I've been waiting on for over a decade.

You know, when I'm making WADs that are meant to be the next step up from Doom E4/Heretic E4+E5 in terms of difficulty, the biggest challenge should not have been walking up a staircase into a linked ceiling portal.

Now that I've got some life obstacles out of the way and am going to get more involved around here again, this is honestly the best thing I could ever have expected to come back to.

I'd been making some maps for Eternity, because I grew addicted to its portal features and had a hard time imagining how to make maps without them anymore. But, due to the malfunctionality of portals and the fact that those bugs hadn't been fixed over the course of maybe a decade, I always had this lingering sense of futility hanging over my head, that my maps would never be able to be played correctly, and that often put me off from working on them entirely.

So, this is really exciting, and now I can't wait to get back at it.

[esselfortium]

Welcome back, Lüt!

Lüt said:

I'd been making some maps for Eternity, because I grew addicted to its portal features and had a hard time imagining how to make maps without them anymore. But, due to the malfunctionality of portals and the fact that those bugs hadn't been fixed over the course of maybe a decade, I always had this lingering sense of futility hanging over my head, that my maps would never be able to be played correctly, and that often put me off from working on them entirely.

I know this feeling well. It's incredible to have printz, Alta, and Edward on board making awesome things happen for EE. After so many years of delays, there was a part of me that didn't expect to ever see portals actually completed (let alone UDMF), so I mostly gave up hope of my maps ever being releasable and just started doing other projects instead. Now that EE development is active again and with most of the things I wanted being complete and usable (plus a bunch of things I never imagined having, like edge portals), I'm looking forward to doing some serious EE project development again in the near future, starting with a clean slate and taking advantage of the new functionality. Though currently I'm a bit preoccupied with the other projects that have accumulated in the meantime...

[Mordeth]

Holy hell, he's alive..!

[Edward850]

Lüt said:

[Lüt]

esselfortium said:

Welcome back, Lüt!

Thanks :)

esselfortium said:

I know this feeling well. It's incredible to have printz, Alta, and Edward on board making awesome things happen for EE. After so many years of delays, there was a part of me that didn't expect to ever see portals actually completed (let alone UDMF), so I mostly gave up hope of my maps ever being releasable and just started doing other projects instead. Now that EE development is active again and with most of the things I wanted being complete and usable (plus a bunch of things I never imagined having, like edge portals), I'm looking forward to doing some serious EE project development again in the near future, starting with a clean slate and taking advantage of the new functionality. Though currently I'm a bit preoccupied with the other projects that have accumulated in the meantime...

Yep, sounds like we've both been at the same place these recent years, in terms of project development at least. Have your other projects been for Doom, or something else? I got caught up in Zelda Classic about a year and a half ago. It basically takes the original NES game and gives it the ZDoom/Eternity treatment. It came with a game editor, and I got carried away with it - I finished one game over a year ago and am currently working on another one, this time assembling an absurdly expanded tileset for public release in the process. The devs are pretty active over there too, so I've been getting involved with features/suggestions/bug reporting as well. But now I'm going to have to split time between the two, because my testing of these new EE builds is coming along very nicely so far.

Mordeth said:

Holy hell, he's alive..!

Oh come on, I don't die that often.

[Gez]

Lüt said:

Zelda Classic

Oh, so you must have be familiar with ZScript then! ;)

[Lüt]

Ohhhh gawd.

Yeah, scripting is one of those deep dark corners of the human soul that I never peer into.

Or any kind of coding for that matter :P

I mean, some people have kindly written some for me, and I can use them just fine once they give me the in-game configurations and arguments, but I can only cry when I open the .z files.