Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
printz

Suggested UDMF namespace

Recommended Posts

This merely starts with the ExtraData capabilities on top of Eternity's. I looked at ZDoom's namespace to pick the new names wherever possible (not everywhere). I didn't add anything else.

This is merely a suggested set of fields. I didn't program anything yet. Actually I did program most of these features in the "udmf" branch, just to be ready in case they're accepted, but they're not set in stone.

Please say what you think. Be on the lookout for settings which might get deprecated.

namespace = "eternity";

linedef
{
    alpha = <float>;
    midtex3d = <bool>;
    firstsideonly = <bool>;
    renderstyle = {"translucent"|"add"};
    blockeverything = <bool>;
    zoneboundary = <bool>;
    clipmidtex = <bool>;
}

sector
{
    damageamount = <int>;
    damageinterval = <int>;

    // These are not available in ZDoom
    damage_leakysuit = <bool>;
    damage_ignoresuit = <bool>;
    // NOTE: ZDoom has "leakiness", which lets you set the probability.
    // Doom 20% damage floor has 5 probability out of 256.
    // Using "leakiness" here too sounds right, but the game code needs to be
    // updated for it.
    
    // Couldn't find ZDoom equivalents here
    damage_endgodmode = <bool>;
    damage_exitlevel = <bool>;
//    damage_terrainhit = <bool>;
    // UPDATED Feb 11 2016
    damageterraineffect = <bool>;

    floorterrain = <string>;
    rotationfloor = <float>;
    xpanningfloor = <float>;
    ypanningfloor = <float>;
    ceilingterrain = <string>;
    rotationceiling = <float>;
    xpanningceiling = <float>;
    ypanningceiling = <float>;
    
    // not in ZDoom because that simply uses dynamically-made colour filters
    colormaptop = <string>;
    colormapmid = <string>;
    colormapbottom = <string>;

    // not in ZDoom
    portalfloor_disabled = <bool>;
    portalceiling_disabled = <bool>;
    portalfloor_norender = <bool>;
    portalceiling_norender = <bool>;
    portalfloor_nopass = <bool>;
    portalceiling_nopass = <bool>;
    portalfloor_blocksound = <bool>;
    portalceiling_blocksound = <bool>;

    // These are in ZDoom. If less than 1.0, then the alpha portalflag is set
    alphafloor = <float>;
    alphaceiling = <float>;
    renderstylefloor = {"translucent"|"add"};
    renderstyleceiling = {"translucent"|"add"};
}

Share this post


Link to post

I did a quick cross-check with ZDoom. You got most of it right, here's the exceptions:

sector
{
// Couldn't find ZDoom equivalents here
damage_endgodmode = <bool>;
damage_exitlevel = <bool>;
damage_terrainhit = <bool>;
}


The first two are not exposed in ZDoom but do exist, so if you expose them, so will I.
The third one should be this:

damageterraineffect = <bool>; // Will spawn a terrain splash when damage is inflicted. Default = false.


And about those:

// These are not available in ZDoom
damage_leakysuit = <bool>;
damage_ignoresuit = <bool>;
// NOTE: ZDoom has "leakiness", which lets you set the probability.
// Doom 20% damage floor has 5 probability out of 256.
// Using "leakiness" here too sounds right, but the game code needs to be
// updated for it.


Your choice. ;) When I refactored that stuff last month I saw no point not generalizing that stuff as it was actually easier to do than the specialized implementation with only 3 states.

If you don't want to change the game code right away I'd suggest to use leakiness with possible values restricted to 0, 5 and 256, then you won't be saddled with 2 redundant properties later.

Share this post


Link to post

The first two are not exposed in ZDoom but do exist, so if you expose them, so will I.

OK, just don't rush up yet. I have merely started this thread without asking others. I hope they have a say on it.

Share this post


Link to post
printz said:

OK, just don't rush up yet. I have merely started this thread without asking others. I hope they have a say on it.



I won't rush anything here.

Another question: Quasar already said he'd want to do UDMF with Hexen-type specials.
So wouldn't it make sense to implement more of them - at least to the point that they cover all what is possible in Doom already?

Share this post


Link to post
Graf Zahl said:

Another question: Quasar already said he'd want to do UDMF with Hexen-type specials.
So wouldn't it make sense to implement more of them - at least to the point that they cover all what is possible in Doom already?

The Hexen-specific fields are already defined in the core specs. I only listed new potential extras here.

Share this post


Link to post

That I understood, I was merely asking how you plan to proceed. The last time I checked the support for Hexen-style specials was still rather incomplete, so if you want to do Hexen-style specials there's probably some work needed here.

Share this post


Link to post

There are lots of static init specials in Eternity which tend to litter the map. Besides Extradata which will be consumed by UDMF, there are the following:
- portals (all kinds)
- attached surfaces
- polyobject setup
- slopes
- Boom fake floors and ceilings, also lights and colours
- sky transfer

Share this post


Link to post
printz said:

There are lots of static init specials in Eternity which tend to litter the map. Besides Extradata which will be consumed by UDMF, there are the following:
- portals (all kinds)
- attached surfaces
- polyobject setup
- slopes
- Boom fake floors and ceilings, also lights and colours
- sky transfer




All of these exist in ZDoom as well. And not all can easily be replaced by direct UDMF properties. For example, the Boom heightsec feature needs the model sector, so do light transfers that do more than setting a fixed light level.

Are you having some other plans with them?

Share this post


Link to post

I'm not having any plans, yet. This is more like a wishlist. Problem is that I'm not a "full-time" map author so I don't know what are the best features to expose. I only discovered the previous list after I made some work in Eternity with lots of advanced stuff.

Share this post


Link to post

Going through the static stuff, here's how I see it:

- portals: Need the anchor so it needs to be in the map by necessity

- attached surfaces: You'll probably need the static method for backwards compatibility, but the primary means in ZDoom for this is a scriptable special that allows to link and unlink at runtime. The static method is also provided, so that the Eternity method can be translated, see the Static_Init special for that.

- 3D Midtextures. In ZDoom only exists as a static init special as well, but with more options.

- polyobject setup. It needs some reference where to collect linedefs from, but ultimately this could also be done with separate properties. Would be more work, though, you already have everything for the current method, so nothing needs to change.

- slopes. The linedef method is by far the most convenient one for mappers, of course there's many other options in ZDoom, including a direct specification of the plane equation in UDMF.

- Boom fake floors: Require a link to the model sector, so static is best.

- Boom lighting: It may actually be beneficial to attach and detach light transfers at runtime, but so far no port has ever implemented it.

- Sky transfer: This can be improved by more dynamic methods, but it'd probably need a well defined low level framework first (which is why in ZDoom nothing has happened yet.) (like with attached surfaces: It got no dedicated special but uses Static_Init in ZDoom.)


Ultimately, though, I think the time that'd be needed to refactor how these get set up is better spent to transition as much stuff as possible to Hexen format specials, then those can be used for UDMF and a lot of compatibility concerns be left behind.

While talking about Hexen specials: I recently went through EE's list of parameterized specials that are only available through Extradata. Since none of them required more than a one-line handler, I added them all to ZDoom's list for completeness's sake. I also removed the byte limitation of 255 specials. so that these don't eat all those valuable low number specials and added some new ACS PCode to make the larger numbers usable there. You may want to adopt this stuff, too.

That'd be the following numbers:
105:Door_WaitRaise(4,5),
106:Door_WaitClose(3,4),

256:Floor_LowerToHighestEE(2, 3),
257:Floor_RaiseToLowest(2, 3),
258:Floor_LowerToLowestCeiling(2,3),
259:Floor_RaiseToCeiling(2, 4),
260:Floor_ToCeilingInstant(1, 3),
261:Floor_LowerByTexture(2, 3),
262:Ceiling_RaiseToHighest(2, 3),
263:Ceiling_ToHighestInstant(1, 3),
264:Ceiling_LowerToNearest(2, 4),
265:Ceiling_RaiseToLowest(2, 3),
266:Ceiling_RaiseToHighestFloor(2, 3),
267:Ceiling_ToFloorInstant(1, 3),
268:Ceiling_RaiseByTexture(2, 3),
269:Ceiling_LowerByTexture(2, 4),
270:Stairs_BuildDownDoom(5),
271:Stairs_BuildUpDoomSync(4),
272:Stairs_BuildDownDoomSync(4),

Share this post


Link to post
Graf Zahl said:

Another question: Quasar already said he'd want to do UDMF with Hexen-type specials.
So wouldn't it make sense to implement more of them - at least to the point that they cover all what is possible in Doom already?

What do you mean by Hexen-type specials? Parameterized, or even with the Hexen/ZDoom (as opposed to the native Eternity) numbering?

Personally, I'd like to keep using the ExtraData line type namespace, while also keeping support for Hexen/ZDoom numbers just for ACS and probably ZDoom translation. So lines in the textmap will continue using the ExtraData numbers. Obviously I'll strongly advise against (and deprecate) all non-static Doom/Boom specials, including generalized (they have the big problem of embedding the trigger type in their definition). Meanwhile, with the tag->args[0] transition, all static initializers will instantly become UDMF-ready, so no need to add new specials just for them. I can even extend them with more args.

Using the ExtraData ("DOOM") set would give me the advantage of being able to define all-new Eternity specials without ever conflicting with equally-numbered ZDoom specials in the future. And I already have a translation layer, just like you do.

As for adding the remaining parameterized specials to Eternity, the ones notably missing are crushing ceilings. Until UDMF, I'm supposed to only import Hexen specials and then ZDoom specials and its extensions to the Hexen ones. The only Doom-like crushing ceiling is Ceiling_CrushAndRaiseDist (and its silent alternative). I guess it's fine to import that, though it's a bit peculiar how it's hardcoded to only slow down for speed=8 (the Boom generalized crushers are also quirky because they slow down even at speed=16). I'd love not to have to import a dozen crushing ceiling specials with slight differences, ideally I'd really like to only have two: one for Hexen and another for Doom.

As a disclaimer, I'm not 100% sure if all I'm saying agrees with Quasar.

Share this post


Link to post
printz said:

Personally, I'd like to keep using the ExtraData line type namespace,


What would be the advantage? That you can keep the Boom specials around?

Of course Eternity is not my engine but so far we have managed to avoid linedef type chaos with Hexen specials, as all ports implementing them have adhered to the existing numbering, it would be a benefit to all mappers if that remained the case. Using the ED-numbers may be easier for you as a developer, but I somehow doubt that mappers would appreciate learning yet another set of numbers - in the end you may just shoot yourself in the foot if the mappers do not come along.

As for the crushers - the real problem is not the many different numbers but to implement a clean underlying worker.
If this is set up like some of the current specials where the special function directly takes care of all initialization I'd agree it'd become a hassle, so my advice would be to outright avoid such a scenario, collect all the different features from the different crushing specials (most are indeed quite minor and are a remnant from a time when this all was far less organized) and then write ONE function that sets all up, and for the special call this one function with appropriate parameters.

This way I was able to add support to ZDoom for all parameterized Extradata specials that didn't have a Hexen equivalent in a handful of minutes. The underlying code already had everything they needed.

Share this post


Link to post
Graf Zahl said:

What would be the advantage? That you can keep the Boom specials around?

No. It's just that if they use matching numbers, for maximum forward compatibility, ports will have to agree with each other where they assign their new specials, so they don't overlap with equally numbered (but different) specials from other ports.

Also:

Graf Zahl said:

but I somehow doubt that mappers would appreciate learning yet another set of numbers

That shouldn't be needed. I will have to release GZDoom Builder, Eureka and SLADE editor configurations with all the numbers already set.

Share this post


Link to post
printz said:

No. It's just that if they use matching numbers, for maximum forward compatibility, ports will have to agree with each other where they assign their new specials, so they don't overlap with equally numbered (but different) specials from other ports.


Where is the compatibility in that system?
Eternity is the only port that mixes Doom format and Hexen format specials that way so it's by definition neither forward nor backward compatible to anything.

Not even ZDoom could read such a map because it strictly goes either/or - you have either Doom-type specials with all implicit trigger semantics (and a run through an XLAT lump) or you have Hexen-type specials (with their original Hexen numbering as they are not translated!) but not both at the same time.

Sweriously, you should start with a clean slate, leaving all the cruft that has accumulated so far behind. I did the same in ZDoom, when I introduced UDMF I just threw any bad semantics from the preceding implementation overboard and just defined sane rules in the spec. That's why ZDoom/Hexen and ZDoom/UDMF have some subtle but important differences - but they ensure that UDMF does not get bogged down by these things and in case some incompatibility is discovered later it can be strictly limited to the binary formats.

Share this post


Link to post

Basically I mean this: one of the goals will be to maintain as good cross-compatibility as possible with ZDoom maps. This means that if I use the same action special numbers, I should stay clear from the numbers occupied by ZDoom if I want to add my own new specials that are exclusive to Eternity or don't fit ZDoom's interests (and if ZDoom wants them too, you can port them without conflicting with your own numbers). Otherwise I risk occupying the spot of a perfectly good ZDoom special that would be worth porting to EE.

Share this post


Link to post

Ok, that's a goal I fully agree with.

Just one question: Is there something right now that isn't covered by a ZDoom special?

The last time I updated the eternity.xlat the only thing that wasn't translated is the two-way portals (what are those anyway, I haven't found a bit of documentation about them), but those could easily be integrated into Sector_SetPortal with a new type.

Share this post


Link to post

If I keep the Hexen/ZDoom numbering, I'll probably define new Eternity specials as starting from a bigger number such as 512.

Graf Zahl said:

Ok, that's a goal I fully agree with.

Just one question: Is there something right now that isn't covered by a ZDoom special?

No, but there are probably a few things I'd like to be more customizable than even in ZDoom. Right now the only thing I think about is customizing the deadly crushing ceilings slowed down speed, for example. There are also some questionable design decisions from the Boom generalized lines that haven't carried over, such as making even the generalized 16-speed crushers get slow on blocking (the vanilla Doom ones don't slow down).

As I see it, I'll probably implement Ceiling_CrushAndRaiseA to implement the exact Hexen behaviour, and Ceiling_CrushAndRaiseDist will be usable for Doom-like crushers. In ZDoom Generic_Crusher doesn't work like in Doom, I believe it's just a clone of Ceiling_CrushAndRaiseA with a useless silence flag (one can just put a sound sequence there for better customization).

The last time I updated the eternity.xlat the only thing that wasn't translated is the two-way portals (what are those anyway, I haven't found a bit of documentation about them), but those could easily be integrated into Sector_SetPortal with a new type.

I think that two-way portals are just non-interactive anchored portals with windows on both sides, not just one. They're like non-interactive linked portals, useful when making impassable horizontal windows (translucent flat overlays can be used here). Like all non-linked portals, Eternity has no line-only special for them, only a copier (type 289) from already existing sector portal to line portal.

EDIT: you asked for the numbers. Here they are. http://eternity.youfailit.net/index.php?title=Portal_linedef_types#Two-Way_Anchored_Portals I didn't realize there are two pages of the same thing :/

Share this post


Link to post
printz said:

If I keep the Hexen/ZDoom numbering, I'll probably define new Eternity specials as starting from a bigger number such as 512.
No, but there are probably a few things I'd like to be more customizable than even in ZDoom. Right now the only thing I think about is customizing the deadly crushing ceilings slowed down speed, for example. There are also some questionable design decisions from the Boom generalized lines that haven't carried over, such as making even the generalized 16-speed crushers get slow on blocking (the vanilla Doom ones don't slow down).


Do you have a full list of differences between ZDoom and Boom here? They'd have to be fixed, but so far nobody ever repeated the problems - I guess because those weren't ever used this extensively in Boom maps.

As I see it, I'll probably implement Ceiling_CrushAndRaiseA to implement the exact Hexen behaviour, and Ceiling_CrushAndRaiseDist will be usable for Doom-like crushers. In ZDoom Generic_Crusher doesn't work like in Doom, I believe it's just a clone of Ceiling_CrushAndRaiseA with a useless silence flag (one can just put a sound sequence there for better customization).


For Hexen you'll need at least these ones, as they were actually defined by Hexen:

42:Ceiling_CrushAndRaise(3,4),
43:Ceiling_LowerAndCrush(3,4),
44:Ceiling_CrushStop(1),
45:Ceiling_CrushRaiseAndStay(3,4),

Ceiling_CrushAndRaiseA is a ZDoom addition. Or do you mean that you'd want to implement those two and then map the others to them?
But also keep in mind here that due to bad historic decisions in ZDoom the different crushing mode of Doom and Hexen is an actual parameter and not an inherent property of the special itself. Until I changed this 8 or so years ago, all crushers operated differently in Hexen than in Doom - and that's why setting a crushing mode of 0 still is game dependent - yeah, the old curse of having to remain backwards compatible...
So, to make it short: You have to be very careful here or you risk creating something that's not fully compatible with ZDoom's messy implementation (don't ever believe I thought this was well defined - it was before my time...)

If you want to do something cleaner and not fully support this mess I strongly suggest to implement these as two new, clean specials that aren't saddled with ZDoom's backwards compatibility concerns. I could easily implement those later so that we have a common ground that does not deviate in level-breaking ways.

I'd suggest anyway to do the implementation so that when it's done, all those other specials can easily be mapped to it by calling the function with appropriate parameters.

Here's just a quick rundown of the internal parameters to EV_DoCeiling, which is the worker for all crushers:

int tag; // obvious
int type; // type of movement (e.g. perpetual crusher, one-time move down, etc.)
fixed_t speed; // downward speed
fixed_t speed2; // upward speed
fixed_t height; // distance to move (only for types that require a distance, all the regular crushers have 0 here)
int crush; // crushing strength (please note that in ZDoom 0 is not exactly 'do not crush', that's -1, but for the high level implementation that's irrelevant.
int silent; // make no movement sound (just the 'clunk's when changing direction.)
int change, // floor type change (does not apply to crushers)
bool hexencrush // 1: continue movement of blocked surfaces (like Doom), 2: halt movement of blocked surfaces (like Hexen), 0: decide based on game (2 for Hexen, 1 for Doom Heretic and Strife)

So that's 9 parameters altogether, 2 of wich are of no meaning to crushers at all, so if your worker supports all these features, plus anything else you may want to add (e.g. movement speed while actually crushing), you only have one set of code and can easily implement all of ZDoom's types with one function.




printz said:

I think that two-way portals are just non-interactive anchored portals with windows on both sides, not just one.


So this means, it only makes a difference when the portal is being copied to a line? I don't really understand what 'windows on both sides' actually means, because I couldn't find anything here that would actually copy the portal over to the place where it links to.

Share this post


Link to post

Two-way portals seem to be something of a relic(?) from the days before anchored portals existed. They're like the non-interactive anchored portals, but anchored in both directions so that the portals view each other, just like a linked portal. I don't think I've ever used them. Maybe I've missed a relevant use case though.

Share this post


Link to post
esselfortium said:

Two-way portals seem to be something of a relic(?) from the days before anchored portals existed. They're like the non-interactive anchored portals, but anchored in both directions so that the portals view each other, just like a linked portal. I don't think I've ever used them. Maybe I've missed a relevant use case though.

I'm pretty sure I have them in one of my WIP. I use them as impassable portals, where I want to connect two sectors vertically by a see-through bullet-proof glass wall. BTW, this makes me want to implement linked portals which work like Doom impassable linedefs, but first I have to implement transparency-masked flat overlays...

See: http://eternity.youfailit.net/index.php?title=Portal_linedef_types

The one-way portals can be assigned both to floors and ceilings. You can thus do stuff such as skyboxes subjected to real parallax effects, better than mere paintings or panorama background pictures.

Share this post


Link to post

Ok. What had me confused is that De Kerker uses the regular anchored portals to do such a setup, so I never saw what the difference would be.

What I do not fully understand is the actual problem that motivated this change. Can you give an example where the simple anchored portals would break?

Share this post


Link to post
esselfortium said:

Two-way portals seem to be something of a relic(?) from the days before anchored portals existed. They're like the non-interactive anchored portals, but anchored in both directions so that the portals view each other, just like a linked portal. I don't think I've ever used them. Maybe I've missed a relevant use case though.


I'm using them for creating a 3D look for stuff that I don't want/need to be interactive. Plus: you can re-use the same anchored portal for multiple occasions (ie. a single skylight used X times for the same room).

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
Sign in to follow this  
×