[Poll] What standard would you like to see next?

[Nikku4211]

1 hour ago, Dragonfly said:

I don't know if this is the place for a request necessarily, but I'd personally love to see support for per-map palettes, if that's even feasible. Perhaps as part of the UMAPINFO feature set?

Yeah, in fact, it should be a ZMAPINFO and EMAPINFO feature, too, since it doesn't look like it's currently possible there. I know the original ZDoom is discontinued, but it'd still be a cool feature to add in GZDoom for the people who play in paletted software mode for that authentic VGA mode Y aesthetic.

 

By the way, I'm not talking about COLOURMAPs, and I don't think Dragonfly is either. I'm talking about custom PLAYPALs, which are different. The former merely remaps to colours within the existing palette, but the latter specifies a new, completely different palette entirely.

 

It would certainly make changing themes for different episodes from within the same WAD really feel more different, and would make it easier to use Heretic, Hexen, and Strife graphics in Doom WADs as well.

53 minutes ago, floatRand said:

Being able to pick colormap per-map would be wonderful. It is not frankly a compat-level feature since it doesn't affect game behavior itself and could be umapinfo thing. 

Yeah, it'd be awesome to be able to use a foggy colourmap for some levels in PrBoom+ and a not-so-foggy colourmap for other levels in PrBoom+ without having to line special 242-force my way into it and use a new tag for every different sector(Hey, here's an idea: 2 Sectors 2: Boom Edition featuring custom COLOURMAPs!).

15 minutes ago, Tango said:

• hub support (can exit to arbitrary maps, at arbitrary starting points, with map state preserved)
• custom damage types for both player and monsters

Yeah, custom damage types would be cool. I'd like to be able to define different deaths for enemies depending on which weapon you used on them, Shadow Warrior style. In fact, I don't think it might be possible in Decorate. No idea about ZScript, though. Haven't made ZDoom actors in a long time.

 

Imagine being able to recreate Hexen in MBF 22.04.

17 minutes ago, Tango said:

• [super longshot here] support for compile-time lightmaps ala Strife Veteran Edition

An awesome idea that I don't want to be hardware renderer-locked. It'd give Ola-QRAD a new meaning.

6 minutes ago, MattFright said:

i really don't want to see it stuck in this cycle/self-fulfilling prophecy of "well GZDoom is already an option, so why bother?!" causing it to never get any love from non-ZDoom based ports, and i really hope i'm not the only one who sees this.

I agree. I really don't like this 'ZDoom exists, who cares?' self-fulfilling prophecy either. ZDoom and its derivatives are already a dime a dozen. I'd get more into vanilla Heretic if there was more effort directed towards support for mouselook in Chocolate and Crispy Heretic, since this thread exists.

[Aurelius]

There's been some good suggestions here for MBF22, so I'll drop in a few ideas that I don't think were mentioned yet.

• A codepointer for checking whether a thing's hitbox is obstructed by another solid thing. This would make it possible to have monsters whose SOLID flags are removed and then later returned (say, an enemy temporarily submerging into water or a resurrecting zombie like monster from Quake) without having the risk of them getting stuck into each other or the player. It could function similarly to the Jump functions, where the thing would jump into a specific state if it was blocked (or not blocked).
• Support for randomized sounds, possibly similar to how the hardcoded randomizations work for sounds like POSIT and PODTH.
• Extended RandomJump with the ability to jump to as many states as the args can handle with equal probability.
• Some way (a flag?) for projectiles to not induce pain state on impact if they have speed (stationary projectiles interestingly do nothing). This could be used for environmental and gore effects that require the thing to die on impact to the ground (support for a Crash state would also remedy this).
• I'm not sure if this could already be "fixed" for MBF21, but the homing projectiles actually hit lower than regular projectiles. For example if you make the rocket launcher homing, in Plutonia MAP01 the perched Archvile is much harder to hit with it than it would be without the homing property. Is this intended behavior? It feels odd that the homing projectiles would target a lower point than regular autoaim.

 

@dmdr Like kraflab said, A_JumpIfTargetCloser should be enough to emulate "A_JumpIfTargetFurther" just by setting it up properly. For example, if you wanted to have A_JumpIfTargetFurther(sniper, 640.0) with the close range attack being the next state should the jump check fail, just use A_JumpIfTargetCloser(closerange, 640.0) and set the next state to be the sniper state. It achieves the same thing.

[Tango]

2 hours ago, Nikku4211 said:

In fact, I don't think it might be possible in Decorate. No idea about ZScript, though. Haven't made ZDoom actors in a long time.

 

indeed you can in decorate! a good number of ZDoom gameplay mods make use of this feature, I think. it really nicely complements usage of A_JumpIfTargetCloser for branching death animations

[Dragonfly]

6 hours ago, Nikku4211 said:

 

By the way, I'm not talking about COLOURMAPs, and I don't think Dragonfly is either. I'm talking about custom PLAYPALs, which are different. The former merely remaps to colours within the existing palette, but the latter specifies a new, completely different palette entirely.

 

Nailed it! That's exactly what I mean. 

[Gwarl]

In my opinion some progressive things to do would be:

 

Make all the codepointers for Heretic and Hexen available for doom, since they have more mechanically interesting monsters.

 

Adapt Hexen format for doom maps like ZDoom did and bring us polyobjects and ACS, it opens up whole new avenues of mapping.

 

Implement UDMF doom namespace, and make an mbf21 namespace to extend it.

 

I'm not going to hold my breath on those last two, but can you do the first one?

 

[Gwarl]

14 hours ago, kraflab said:

Crispy and dsda-doom support heretic / hexen but don't have advanced modding capabilities.

So hexen features in doom like ACS and polyobjs wouldn't be totally out of the question?

[TheNoob_Gamer]

4 hours ago, Aurelius said:

I'm not sure if this could already be "fixed" for MBF21, but the homing projectiles actually hit lower than regular projectiles. For example if you make the rocket launcher homing, in Plutonia MAP01 the perched Archvile is much harder to hit with it than it would be without the homing property. Is this intended behavior? It feels odd that the homing projectiles would target a lower point than regular autoaim.

So essentially, a player's homing projectile attack is more ineffective than traditional autoaim? That sounds like an important issue.

[Graf Zahl]

57 minutes ago, Gwarl said:

So hexen features in doom like ACS and polyobjs wouldn't be totally out of the question?

 

The main piece of work here would be backporting a huge number of line types from ZDoom because Hexen itself is missing a lot of stuff Doom uses, but the basics are already there for Hexen and it shouldn't be too hard to reroute the code as needed. Of course Hexen's ACS interpreter is ill suited for modern use of ACS so it would make sense to borrow one either from ZDoom or Eternity to get a full feature set.

 

14 minutes ago, TheNoob_Gamer said:

So essentially, a player's homing projectile attack is more ineffective than traditional autoaim? That sounds like an important issue. 

 

The homing code tries to home in on the target's center. Yes, this can occasionally mean that a target is harder to hit with a homing missile because by trying to home in it hits some obstacle instead. But that's an issue with real-life homing missiles as well. If you have a straight line to a non-moving target a direct attack will always be more effective because nothing can make the missile go off course.

[Aurelius]

12 minutes ago, Graf Zahl said:

The homing code tries to home in on the target's center. Yes, this can occasionally mean that a target is harder to hit with a homing missile because by trying to home in it hits some obstacle instead. But that's an issue with real-life homing missiles as well. If you have a straight line to a non-moving target a direct attack will always be more effective because nothing can make the missile go off course.

 

I don't think this quite touches the issue at hand. Yes, what you say about homing missiles possibly hitting obstacles is true, but since auto-aim is its own form of "homing" behavior, I consider these two should behave similarly in situations where the homing effect does not make a practical difference. In other words, if you're shooting directly at an immobile target, both methods should yield same results.

 

Below is a video clip of a comparison between a vanilla rocket launcher vs. a homing variant against an immobile Archvile. The difference is pretty easy to see.

 

Spoiler

 

 

In the MBF21 documentation, it is stated that Heretic's seeker missile logic was used as a base for the A_SeekTracer function. I wonder if the "discrepancy" originates from there?

[TheNoob_Gamer]

1 minute ago, Aurelius said:

video clip

Minor question: Is the lack of sound intentional?

 

Also, part of me wonder what it would be like if the player stood at a different position - the homing effect might be clearer and better that way.

[Graf Zahl]

9 minutes ago, Aurelius said:

 

I don't think this quite touches the issue at hand. Yes, what you say about homing missiles possibly hitting obstacles is true, but since auto-aim is its own form of "homing" behavior, I consider these two should behave similarly in situations where the homing effect does not make a practical difference. In other words, if you're shooting directly at an immobile target, both methods should yield same results.

 

 

Ah, now I understand.

 

The seeker code works so that if a homing missile is within the target's z range it won't affect its vertical trajectory, even if that means it can hit the ground or ceiling instead. This is actually a vital part of how a player can evade seeker missiles.

 

ZDoom ran into the same problem a long time ago. Here you can find some info: https://forum.zdoom.org/viewtopic.php?f=7&t=25534&p=487350

 

This problem was ultimately resolved by offering two seeking modes - the one present in Heretic and one that is a bit smarter and does alter its vertical trajectory to be more precise. Just doing this unconditionally adversely affected Heretic and had to be reverted again.

I think what DSDA should do is copy that functionality and offer both modes as both have their use.

[Mystic 256]

would it be possible in mbf22 to add something similar to the bridge thing / invisible bridge object (from zdoom) so we can make better midtextures bridges without having to use raising and lowering invisible floor trickery

 

not true 3d floors but the mid texture bridges with the bridge things / invisible bridge objects, if its possible

[Graf Zahl]

Bridge things require proper height clipping against sprites. This does not exist in any of the more traditional ports and surely won't be added because it'd essentially a complete second path for collision detection that's more like ZDoom's code (also used by Eternity when playing advanced content)

 

I honestly do not see this happen for a port like DSDA.

 

[Bauul]

6 hours ago, Gwarl said:

Implement UDMF doom namespace, and make an mbf21 namespace to extend it.

 

Support for UDMF maps (if that's what you meant) would be a bigger development than almost anything else listed here IMO.

 

A UDMF map that runs on a PRBoom-derived source port would be pretty revolutionary in the options it would open up.

[ChopBlock223]

4 hours ago, Mystic 256 said:

would it be possible in mbf22 to add something similar to the bridge thing / invisible bridge object (from zdoom) so we can make better midtextures bridges without having to use raising and lowering invisible floor trickery

 

not true 3d floors but the mid texture bridges with the bridge things / invisible bridge objects, if its possible

I think an easier approach would just be to copy how Doom 64 does bridges, which has its own limitations, but still looks quite good.

 

 

[Nikku4211]

11 hours ago, Gwarl said:

Make all the codepointers for Heretic and Hexen available for doom, since they have more mechanically interesting monsters.

 

Adapt Hexen format for doom maps like ZDoom did and bring us polyobjects and ACS, it opens up whole new avenues of mapping.

 

Implement UDMF doom namespace, and make an mbf21 namespace to extend it.

So basically turn PrBoom+ into early ZDoom?

 

Hexen itself requires the proper height collision that Doom doesn't have, so a lot of things that make sense in Hexen format stop making sense, and like Graf said, implementing that would start making the physics more like ZDoom's, which would require a completely new compatibility setting. I guess -complevel 22 would make even more sense now.

Still, you might as well make mods for ZDaemon or Odamex. I know they're multiplayer, but you can use their source ports to play single player levels anyway and you can use DeHackEd and DEHSUPP(the latter of which is actually not supported at all by modern ZDoom-based source ports and later versions of the original ZDoom now).

 

Then again, I guess that potential MBF22 would be a good trojan horse for bringing back DEHSUPP support.

11 hours ago, Gwarl said:

So hexen features in doom like ACS and polyobjs wouldn't be totally out of the question?

I don't know, but this does feel like something straight out of the Eternity engine.

 

Eternity already supports UDMF, Polyobjects, ACS, and it has EDF for you to be able to make your own enemies and perhaps even use Heretic and Hexen thing types.

 

Then again, EDF might be a bit too much like Decorate...

 

I get the point of DeHackEd is to creatively work within limitations, but this does bring me back to how MBF21 and this proposed 22 are odd extensions when you go back to this purpose.

 

Oh well, at least they'd have demo compatibility between versions.

10 hours ago, Graf Zahl said:

Of course Hexen's ACS interpreter is ill suited for modern use of ACS so it would make sense to borrow one either from ZDoom or Eternity to get a full feature set.

It is ill suited for modern use of ACS, but I think that should be what separates MBF22 from ZDoom and Eternity: more limitations to creatively inspire you.

 

Knowing PrBoom+ mappers, if anything actually important's missing they'll probably end up using voodoo dolls, but if it can't be done in voodoo dolls, then it does not need to be implemented for MBF22 ACS.

5 hours ago, Bauul said:

 

Support for UDMF maps (if that's what you meant) would be a bigger development than almost anything else listed here IMO.

 

 A UDMF map that runs on a PRBoom-derived source port would be pretty revolutionary in the options it would open up.

Yeah, it'd be a huge development, and depending on how its done, it could end up promoting the practise of making 'Boom-format' and 'MBF-format' maps in UDMF.

 

Then you'd end up having maps in UDMF that actually do specify in the WAD that they do use the 'Doom' namespace, which has Boom and MBF line specials too.

 

If PrBoom+ ends up having its own namespace, what would it have in UDMF over the Doom Boom Gloom namespace? Aside from differences in how the line specials work?

4 hours ago, ChopBlock223 said:

I think an easier approach would just be to copy how Doom 64 does bridges, which has its own limitations, but still looks quite good.

How does Doom 64 do it any differently from the typical fake 3D bridge trick in Doom-format maps?

 

As far as I know, it just changes sector heights to a specified position, which is analogous to combining the 'advanced lifts' trick with self-referencing sectors(vanilla, limit-removing)/transfer heights(Boom and up).

 

Also, compared to how Hexen and ZDoom and even Eternity does it, it does not work at all in multiplayer. Then again, I think nobody plays PrBoom+ multiplayer, so we're all good.

 

Now that I think of it, Eternity seems to have started the trend of actual 3dMidTex collision that does not use thing collisions at all, so perhaps MBF22 can take some inspiration?

 

Just kidding, unless...?

[Graf Zahl]

9 hours ago, Nikku4211 said:

Hexen itself requires the proper height collision that Doom doesn't have, so a lot of things that make sense in Hexen format stop making sense, and like Graf said, implementing that would start making the physics more like ZDoom's, which would require a completely new compatibility setting. I guess -complevel 22 would make even more sense now.

 

Should that ever be done it should of course be a game-independent layer that carefully merges the features of all games.

TBH, in that case you might just incorporate ZDoom 2.8.1's play code with some adjustments to strip out the problem parts and pure modding features.

 

However, if you wanted that it might make more sense to just fork ZDoom, and develop a demo-centered port from that - I do not really think that this would really make sense for DSDA.

 

 

 

9 hours ago, Nikku4211 said:

Then again, I guess that potential MBF22 would be a good trojan horse for bringing back DEHSUPP support. 

I don't know, but this does feel like something straight out of the Eternity engine.

 

There's really no need for that anymore. DEHSUPP has nothing to offer DSDA cannot already do with its unlimited actors and states. The whole point of it is to map additional content into the modifiable set Dehacked can use - in case of ZDaemon that mainly means accessing Heretic assets (AFAIK Hexen wasn't even finished when it forked off.)

 

 

9 hours ago, Nikku4211 said:

 

Eternity already supports UDMF, Polyobjects, ACS, and it has EDF for you to be able to make your own enemies and perhaps even use Heretic and Hexen thing types.

 

Then again, EDF might be a bit too much like Decorate...

 

The main issue with EDF is that it is an all-in-one solution not just for new actors but for all kinds of resources. It may be a bit too complex.

DECORATE as-is also won't be the right solution as it depends on some of ZDoom's internal workings.

If we ever get a high level definition language it might be based on DECORATE's syntax but be something a little bit different to better match the underlying architecture.

 

 

9 hours ago, Nikku4211 said:

 

Oh well, at least they'd have demo compatibility between versions.

It is ill suited for modern use of ACS, but I think that should be what separates MBF22 from ZDoom and Eternity: more limitations to creatively inspire you.

 

 

Nah, it doesn't work that way. Hexen ACS has one major limitation (special arguments are bytes, in ZDoom and Eternity they are full ints - you'd need that for UDMF!) and this has led to some ugly design in Hexen and early ZDoom days. I wouldn't want to see this mistake repeated. Of course you need the original ACS VM for Hexen demos, but I wouldn't use it for expanding the engine, it's just not good for that.

 

 

9 hours ago, Nikku4211 said:

 

Knowing PrBoom+ mappers, if anything actually important's missing they'll probably end up using voodoo dolls, but if it can't be done in voodoo dolls, then it does not need to be implemented for MBF22 ACS.

Yeah, it'd be a huge development, and depending on how its done, it could end up promoting the practise of making 'Boom-format' and 'MBF-format' maps in UDMF. Then you'd end up having maps in UDMF that actually do specify in the WAD that they do use the 'Doom' namespace, which has Boom and MBF line specials too.

 

While these namespaces were defined, I do not think that any tools exist that support them, so it may actually be a lot easier to extend the action special set by ZDoom's types and have full feature support for Hexen format specials instead of hoping for the tools to catch up.

 

 

9 hours ago, Nikku4211 said:

 

If PrBoom+ ends up having its own namespace, what would it have in UDMF over the Doom Boom Gloom namespace? Aside from differences in how the line specials work?

 

You'd need the new namespace because the Doom namespace has been explicitly limited to Boom line types. It is essentially feature-locked. If you want to extend it you need a new namespace. But then I'd name it by the feature standard it wants to support, not "PrBoom+". ;)

 

9 hours ago, Nikku4211 said:

How does Doom 64 do it any differently from the typical fake 3D bridge trick in Doom-format maps?

 

As far as I know, it just changes sector heights to a specified position, which is analogous to combining the 'advanced lifts' trick with self-referencing sectors(vanilla, limit-removing)/transfer heights(Boom and up).

 

I think you got that right - it is mainly two things:

1) a rendering trick with not drawing the sky over two-sided linedefs.

2) using scripts to move the sectors around and change their textures.

 

I wouldn't want to subject any mapper to such an approach. It also needs a bit support in the renderer to not glitch out which would most likely make it a no-go.

 

9 hours ago, Nikku4211 said:

 

Also, compared to how Hexen and ZDoom and even Eternity does it, it does not work at all in multiplayer. Then again, I think nobody plays PrBoom+ multiplayer, so we're all good.

 

Neither do Boom's fake bridges so there's nothing gained, nothing lost.

 

 

9 hours ago, Nikku4211 said:

 

Now that I think of it, Eternity seems to have started the trend of actual 3dMidTex collision that does not use thing collisions at all, so perhaps MBF22 can take some inspiration?

 

 

That's something that's surely doable and not even that much code to add. I'd list this as one of the more useful things an MBF22 standard could add.

 

[Nikku4211]

4 hours ago, Graf Zahl said:

DEHSUPP has nothing to offer DSDA cannot already do with its unlimited actors and states.

Yeah, I was just thinking more of how GZDoom could start supporting this MBF22 if it already brings Hexen and Heretic codepointers to DeHackEd.

4 hours ago, Graf Zahl said:

The main issue with EDF is that it is an all-in-one solution not just for new actors but for all kinds of resources. It may be a bit too complex.

DECORATE as-is also won't be the right solution as it depends on some of ZDoom's internal workings.

Oh, okay. EDF too complicated and Decorate too Z-pendant.

4 hours ago, Graf Zahl said:

Hexen ACS has one major limitation (special arguments are bytes, in ZDoom and Eternity they are full ints - you'd need that for UDMF!)

Oh, ints are needed for UDMF's format.

4 hours ago, Graf Zahl said:

this has led to some ugly design in Hexen and early ZDoom days. I wouldn't want to see this mistake repeated.

Ugly design? What do you mean?

O_O

4 hours ago, Graf Zahl said:

While these namespaces were defined, I do not think that any tools exist that support them, so it may actually be a lot easier to extend the action special set by ZDoom's types and have full feature support for Hexen format specials instead of hoping for the tools to catch up.

Well, you can fork Ultimate Doom Builder. I don't know what other level editors people use for UDMF, though.

4 hours ago, Graf Zahl said:

You'd need the new namespace because the Doom namespace has been explicitly limited to Boom line types. It is essentially feature-locked. If you want to extend it you need a new namespace.

So anything MBF21 and 22 would need its own namespace, but anything meant for -complevels 11 and under could use the standard Doom Boom Gloom namespace if it's meant to only work in PrBoom+ anyway?

4 hours ago, Graf Zahl said:

Neither do Boom's fake bridges so there's nothing gained, nothing lost.

Yeah, nothing lost.

4 hours ago, Graf Zahl said:

That's something that's surely doable and not even that much code to add. I'd list this as one of the more useful things an MBF22 standard could add.

Oh cool. Yeah, that's definitely something that I'd mess with in a map.

 

THREE-DEE F'ING MIDDLE TEXTURES!

[Graf Zahl]

4 minutes ago, Nikku4211 said:

Ugly design? What do you mean?

 

Actions that take weird parameters mostly, and some redundant ones postfixed with Times8. Since it had to shoehorn things into 8 bits many values have to use weird multipliers to get a usable value range. Unfortunately there's not much that can be done about it these days.

 

 

4 minutes ago, Nikku4211 said:

O_O 

Well, you can fork Ultimate Doom Builder. I don't know what other level editors people use for UDMF, though.

 

Someone has to make it work first. I was just saying that it might be easier to extend the engine to support Hexen specials, including the full set from ZDoom, than the editor.

 

 

[boris]

The UDMF namespace is just a setting in the game configuration files in the DB2 family, no code changes needed.

[Nikku4211]

6 minutes ago, boris said:

The UDMF namespace is just a setting in the game configuration files in the DB2 family, no code changes needed.

Oh, okay.

 

They still need to be a standardised feature included by default if MBF22 releases.

 

[Gez]

42 minutes ago, Nikku4211 said:

Oh cool. Yeah, that's definitely something that I'd mess with in a map.

 

THREE-DEE F'ING MIDDLE TEXTURES!

They're still gonna have the fundamental problem of 3D collision in the Doom engine, namely that an actor below the bridge can block an actor above the bridge, and vice-versa.

[Misty]

I voted for Heretic(if only I could pick Hexen too), because Heretic and Hexen is like middle child, gets least attention. Creating new standard for those game would help revitalise already small user base, besides focusing on other games after Doom seems only logical step for me. If we look wider, Doom already has plenty of options when comes modding and editing, just pick your favourite one. Not much for Heretic or Hexen, stuck between vanilla/udmf and nothing in between. Doom can wait a bit, especially when new standard is few months old. 

[TheNoob_Gamer]

1 hour ago, Nikku4211 said:

I don't know what other level editors people use for UDMF, though.

Unless I'm misinterpreting your comment, Slade also supports UDMF.

[HavoX]

I know this may seem like a stupid question, but can we have more quit messages in the next standard, or is that out of the question due to way it is hard-coded?

[Alper002]

3 hours ago, Misty said:

I voted for Heretic(if only I could pick Hexen too)

You can actually vote for more than one entry in this particular poll, I picked both myself.

[Nikku4211]

7 hours ago, TheNoob_Gamer said:

Unless I'm misinterpreting your comment, Slade also supports UDMF.

I forgot Slade has a map editor.

 

Do people use it?

[NiGHTMARE]

Something I'd love to see become a cross-port standard is ZDoom's TEXTURES lump.

[MattFright]

2 hours ago, Nikku4211 said:

I forgot Slade has a map editor.

 

Do people use it?

 

Yes, it's definitely the best alternative to UDB/GZDB

[HavoX]

15 hours ago, MattFright said:

 

Yes, it's definitely the best alternative to UDB/GZDB

especially if you can't get GZDB/UDB to run or your machine is unable to run it at all

 

...personally, I didn't test SLADE's map editor, since I've just gotten used to the way UDB works. How is SLADE's different, if it is?