UDMF common namespace, first draft

[Graf Zahl]

The ZDoom/Eternity namespace is probably not suitable for including more ports, as it contains all features common to both ports which includes things that 3DGE does not implement.

 

What this needs mostly is

 

1) careful review by Eternity devs that the listed set of features is doable

2) implement everything not yet present in Eternity

3) agree on a proper namespace name.

 

Note that I left a few cosmetic render features in for GZDoom like reflective flats which should be a no-op on non-implementing renderers.

 

[Death Egg]

But if 3DGE were to add such features wouldn't it then be fine for it to implement it? What all would it need to add for it to work?

[Graf Zahl]

You have to ask the 3DGE developers for that. But keep in mind that portals are part of the spec!

First this needs to be implemented, though. In ZDoom all I need to do is add a check for the new namespace, so any further development depends on Eternity.

 

 

[Xaser]

For Hacx 2.0 itself, 3DGE is likely technically possible, but one troublesome thing with the current project is that actor definitions need to be double-defined between ZD and EE, and I don't wish to complicate the situation further by putting DDF into the mix.

 

Perhaps retroactively (or if this DECOLITE idea catches on), but not at present.

[Coraline]

@XaserI would be willing to write the DDF/RTS/COAL definitions for Hacx 2.0 and embed them, with your permission of course. Does the new Hacx implement game-code solely with DECORATE or Dehacked? I can port from practically any language (and it might help me expand some stuff that would seem clunky). Just let me know -- and I can collaborate with the team on any questions I have about actor behavior. Linetypes/sectors aren't a big deal because I can create new ones via DDF/RTS quite easily. 

 

@Graf Zahl When you say portals, do you mean the current linked portal architecture shared between GZDoom and Eternity? As we know 3DGE has portals currently, but they are "detail only" (and of course, the code currently in place for them really needs total reworking as you know). Just want to be totally sure.

 

@Death Egg: We are looking into expanding UDMF for 3DGE and adding even more features to bring it up to date with GZDoom and Eternity (we really don't want to be left behind on any current/possible spec changes either). We have all of the basic/intermediate features of UDMF currently implemented in 3DGE (see for yourself by loading UDMF-FEATURES.wad in the Devbuilds, including WIP PolyObjects) -- so we want to definitely go all the way, at least to a point where all but the most obscure/specific features will be left out as to be compatible as possible with other ports (namely GZDoom). It's a big mission of the team to bring the port up to date with what the Doom community currently expects from a feature-rich content-definition port. ;)

 

Offtopic - I'm still working on the 3DGEWiki and bringing it up to date (so we can replace the very outdated specs on both Andrew's EDGE site and Lobo's EDGE documentation portal) -- big personal goal of mine ;)

[Graf Zahl]

17 minutes ago, Coraline said:

 

@Graf Zahl When you say portals, do you mean the current linked portal architecture shared between GZDoom and Eternity? As we know 3DGE has portals currently, but they are "detail only" (and of course, the code currently in place for them really needs total reworking as you know). Just want to be totally sure.
 

 

Of couse I mean the linked portals which are currently supported by both ports.

Of couse they are not really a feature of UDMF itself but added in a list of supported line specials.

[printz]

Personally I like the ZDEE name, it's funny. Let's see what others think of it.

 

I can try this: let Eternity treat the ZDEE namespace the same way as "eternity". If anything Eternity-only is still parsed as valid, then consider it undefined behaviour subject to change (mappers mustn't rely on it), just until I move on to specifically disable it in the code. I'm saying that it would be easier for me to just add support for the zdee namespace, than also nitpicking for all disabled stuff.

 

Is Xaser's project depending on this?

[Graf Zahl]

For a first step that's ok. Have you also verified that everything that's listed is implemented?

 

 

[Blastfrog]

21 hours ago, printz said:

Personally I like the ZDEE name, it's funny. Let's see what others think of it.

Heh. Is it pronounced "Zee dee"?

[printz]

You put it like that? Then it sounds like just ZD, no "EE" heard. I pronounce it zdee instead, so I wouldn't notice this problem.

[Blastfrog]

Well, I was thinking of it rhyming with "three dee". "Dee" prefixed with the letter Z. I dunno, heh

[Xaser]

Zeddy.

 

On 5/20/2017 at 5:43 PM, Coraline said:

@XaserI would be willing to write the DDF/RTS/COAL definitions for Hacx 2.0 and embed them, with your permission of course. Does the new Hacx implement game-code solely with DECORATE or Dehacked? I can port from practically any language (and it might help me expand some stuff that would seem clunky). Just let me know -- and I can collaborate with the team on any questions I have about actor behavior. Linetypes/sectors aren't a big deal because I can create new ones via DDF/RTS quite easily.

I'm interested! Thanks for the offer.

 

At present, the actor behavior is still in flux, pending finalization of the enemy & weapon behavior, and there's at least one big portal scene in one particular map, just as a heads-up. Should we open up a dialogue via PM? May be best.

 

Right now, the DECORATE definitions are "canon", though they'll likely be translated to ZScript in the near future. This is secretly a good thing though, I think; since ZScript is a lot closer to the source, the extra features that get coded in will look pretty damn close to any native code required to implement them, I'll bet. Though DDF probably has us covered already on that front. :P

 

@printz This isn't holding up the project, timeline-wise, but it'd certainly make life 200% easier. I'm quite keen to oust all the hacked-in (...hacxed-in?) XLAT/ExtraData stuff with some sane feature support.

[Altazimuth]

Silly thought: I kinda like the namespace "EEZD", because then it sounds like "easy dee". Not only does it guarantee one port's name doesn't eat the other when talking about it (as in spoken word) , but it kinda sounds like the "easy Doom" format.

 

This does make me wonder though, stuff will get confusing if (hopefully when) we incorporate an 3DGE+ZDoom+Eternity format. 3ZDEE? 3EZ? 3EZ5ME? '3', 'E', and 'Z' all sound too similar (in English at least) to feasibly use in an initialism/acronym.

 

Maybe just "zdoom-eternity" (or "eternity-zdoom", doesn't matter) would just be a better namespace.

 

I want to make it clear, I don't want to bikeshed on this issue too much, I just want a long-term name that makes clear the ports it's aimed at regardless of how it's pronounced.

[esselfortium]

Just don't call it DEEZ.

[Gez]

"Advanced Bunch of Common Doom Extra Features", or ABCDEF.

[Danfun64]

On 5/25/2017 at 1:24 PM, esselfortium said:

Just don't call it DEEZ.

Or worse... GEEZ (Graf Enjoys Eternity ZDoom)

[Death Egg]

Why not a name that makes it so other interested ports could adopt it in the future as well?

[Gez]

10 hours ago, Death Egg said:

Why not a name that makes it so other interested ports could adopt it in the future as well?

Isn't that what I proposed? :p