UDMF common namespace, first draft

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.

 

Share this post


Link to post

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?

Share this post


Link to post

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.

 

 

Share this post


Link to post

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.

Edited by Xaser

Share this post


Link to post

@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 ;)

Share this post


Link to post
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.

Share this post


Link to post

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?

1 person likes this

Share this post


Link to post

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

 

 

Share this post


Link to post
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"?

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now