Reflections and Aspirations: MBF21 in 2024

UDB's config files have a field that controls what the "step" value is when adjusting lighting in the editor. ZDoom-y configs have it set to 8, but everything else has it at 16 since it's unclear which ports support steps of 8. Making it an explicit part of the next standard would remove all the ambiguity.

It's a bit like adding support for a new line special -- technically you don't have to do anything to the map format to support it, it's just a new number you can type into the editor whenever, but ports need to agree on what the value does in order for the editor to justify adding it to the config.

8 hours ago, Trov said:

I would like to propose a simple standard for widescreen status bar graphics, to allow for accommodating ANY aspect ratio and more complex filling of the widescreen area, without scripting or definitions files of any kind (just supply properly named graphics). 

We rather already have a wide-screen hud standard set by the official and community ports.

Essentially, any hud graphic is fixed to the center of the screen and allows expanding out past the sides. Basically it's center aligned to the screen rather than from the left.

Yes it's not vanilla strict compatible, but it's the standard already used, and it's also used for other widescreen graphics types. Strife VE also uses this standard for intermission graphics, with the software renderer slightly modified to allow for offscreen "drawing".

Also considering this is talking about MBF which is already explicitly not vanilla, it's redundant to try and apply that.

a universal custom hud standard would be great. we currently have these proprietary formats for ports like nugget doom, woof, zdoom, etc. however a universal standard for custom hud layouts would make it far easier than to create each one individually.

5 hours ago, Edward850 said:

We rather already have a wide-screen hud standard set by the official and community ports.

Essentially, any hud graphic is fixed to the center of the screen and allows expanding out past the sides. Basically it's center aligned to the screen rather than from the left.

And most of them fall apart when you play on an ultrawide monitor because they aren't wide enough, or you a play a port that scales down the HUD.

The proposed NEW standard, as I'll call it here to be specific for you, will let a status bar work at any arbitrary width or scale, even something like GZdoom's default tiny scale size, without having to make something absurd like a 1280px wide bar or wider or design for any particular width. The goal is to do the work one time to support any size, rather than having to do the work again later if another aspect ratio becomes common.

I never said there was no standard; I explicitly called it "the current system". I proposed a better one, which is one not hoping that the current in-vogue aspect ratio remains so in perpetuity.

The vanilla compatibility is a bit of a backdoor add. While it doesn't make sense for an MBF2_ WAD to be vanilla compatible, the uptake of a newer MBF2_ by practically all modern ports that includes the theoretical new non-STBAR-overwriting method would allow even non MBF2_ WADs to get the benefit of a widescreen bar that doesn't crash vanilla.

All your proposed standard will do is complicate matters. Right now it's easy: No matter how wide the statusbar is, it will be centered.

The more red tape you add, the more likely it is that mappers will just ignore it or forget the finer details.

All you really need is a center part of arbitrary width and a repeatable filler piece that can be added at both ends to fill out the space.

Edward is right, all relevant ports already align status bars to the center, there's really no need to go back again to what was done before. Besides, you again need to convince all port authors to adopt it, and the most likely answer will be the same you already heard.

41 minutes ago, Graf Zahl said:

All you really need is a center part of arbitrary width and a repeatable filler piece that can be added at both ends to fill out the space.

This is what I did in one of my mods before widescreen assets were standardized. One 320-wide graphic for the center, and one 320-wide graphic tiled a few times on both sides. Simple, effective, no fuss.

Trov's proposal feels very wheel-reinvention-y, to be honest.

On 1/23/2024 at 11:53 PM, Antroid said:

I honestly just want a port that is like DSDA but with the full DECORATE functionality for full freedom with custom monsters and objects. If I want to make a largely classically styled wad with purely prboom+ format maps but slightly more advanced custom monsters that aren't possible with the limited functions we have, I have to jump to gzdoom with all the problems and expectations that that imposes on me. Though I realize that it would probably be a monumental amount of work replicating everything that decorate has.

Expectations? What? Adding a DECORATE lump doesn't immediately mandate that you fill every map with complex scripting and purple lighting. Just use the features you want (BOOM maps, the occasional custom critter) and ignore the ones you don't care for. It worked for Tarnsman's Projectile Hell, it can work for you!

11 hours ago, Kinsie said:

Expectations?

I've seen people express that if they check out a gzdoom-only project, they want the gzdoomness to be fully warranted instead of mostly a limit removed project with a few extras. Though maybe the times have changed. It feels a little silly to limit myself out of using scripts and udmf and stuff too, since nobody is going to care that the maps were done under this self-imposed limitation while they're still gzdoom-only, but that's the choice I made. But it would be validated if there was a prboom+decorate source port %)

1 hour ago, Antroid said:

I've seen people express that if they check out a gzdoom-only project, they want the gzdoomness to be fully warranted instead of mostly a limit removed project with a few extras.

Fuck 'em. Do whatcha wanna do, whatever makes you happy.

19 hours ago, Graf Zahl said:

All you really need is a center part of arbitrary width and a repeatable filler piece that can be added at both ends to fill out the space. 

If you actually read my proposal, that's pretty much what it is, plus a part that goes between the center part and repeatable filler part.

The purpose of the 'in between' part being a separate graphic is so that you can have some kind of transition between the 320px center area and the repeatable filler piece, without doing so by having a wider STBAR that would crash vanilla doom.

Consider this example based on the unused widescreen bar provided in Eviternity:

Looking through all the widescreen bars I have made or found, almost all of them follow this pattern to some degree (even if the 'transition' part is usually just a couple pixels wide border of some kind.) so I strongly feel that just having a repeating filler alone is not sufficient to adapt the bars for arbitrary width.

If all the other crap in my proposal about origins/overlapping were discarded how do you all feel about just this above?

Quote

Besides, you again need to convince all port authors to adopt it, and the most likely answer will be the same you already heard.

That goes without saying and applies to everything in this entire thread.

Since theres some UMAPINFO suggestions, I'd like to request a few things from ZMAPINFO;

• Adaption of the ResetHealth and ResetInventory fields, so we can move away from awkward death exits that can sometimes fail to strip gear and health, enabling pistol start via the UMAPINFO lump itself
• Add the ability to set custom intermission music; in its current implementation there is 'InterMusic', but it instead defines the text screen music, instead of being called InterTextMusic to go with InterText and InterTextSecret. I was unable to accurately fully port Valkiriforce's Doom Core Trilogy from ZDoom family to UMAPINFO family due to being unable to replicate said wad's intermission music that changes depending on the chapter.
• The implentation of the second sky and sky scrolling, like what Hexen has
• Instead of having to painstakingly figure out exactly what each default boss level needs for the boss trigger actions, just add 'E1M8Special', 'E2M8Special', 'E3M8Special', 'E4M6Special', 'E4M8Special' and 'Map07Special' to automatically activate them for ease of use, needed for stuff like Master Levels PS3 and DTWID Lost Episodes E6, where lots of boss trigger levels occur outside of the default slots and need manual activation. Also let them stack, so things like Doomsday of UAC can function

On 4/18/2024 at 7:28 AM, Trov said:

Next proposal: A simple WAD metadata lump. The metadata here should be the bare minimum requirements that the WAD needs to function.

The metadata should specify:

• WAD display title
• What IWAD the WAD needs.
• If it doesn't have a whole UMAPINFO definition: what episode or maps it replaces.
• Desired complevel

Two of those already exist in the lump called GAMEINFO, its ZDoom family only right now, but other ports using it and expanding on it could work..

I already add a GAMEINFO lump to all my patches, so im somewhat invested in this, heh.

Idea for previously discussed movement copepointer. A_Strafe. Following arguments:

• Angle_min, angle_max: Set angle deviation from -315 to 315 to establish range. I assume it would be a bad idea to allow non-45 degree angles, but I can't prove it
• Attack roll: Boolean to set if attack should still happen
• Mirrored: boolean, randomly reverse the angle, yes by default. One might want to draw different sprites for moving left and right, or might not
• Turn: boolean, should monster face the movement direction or should keep facing original direction

some ideas concerning lighting: chop the sector brightness into 2 8bit values that would represent what would otherwise be the -2048 to +2047 range (because lots of renderers renders brightness in steps 16 and also who needs anything outside of that range) so that theres separate ceiling/floor brightness so people wouldnt have to do the light transfer bs; also use the last 4 bits on linedefs flag as deviation from mid level brightness so people dont have to draw extra sectors to make light gradients on linedefs that would otherwise be in the same sector

some other ideas: some primitive compression method for things lump, for the slaughter wads  actually no this isnt necessary at all

also some way to turn off damage rng would be great

4 hours ago, besus said:

some ideas concerning lighting: chop the sector brightness into 2 8bit values that would represent what would otherwise be the -2048 to +2047 range (because lots of renderers renders brightness in steps 16 and also who needs anything outside of that range) so that theres separate ceiling/floor brightness so people wouldnt have to do the light transfer bs; also use the last 4 bits on linedefs flag as deviation from mid level brightness so people dont have to draw extra sectors to make light gradients on linedefs that would otherwise be in the same sector

Not a good idea. Maps have been abusing the light level clamping for effects that depend on values larger than 255.

Not to mention that light level differences of 1 are very often used to force clip mid textures to floor and ceiling.

Besides, with UDMF it can already be done.

On 4/19/2024 at 11:02 AM, Trov said:

 so I strongly feel that just having a repeating filler alone is not sufficient to adapt the bars for arbitrary width.
 

In that case you make the center part wider. These are absolute edge cases that really do not warrant making the common use case more difficult.

5 minutes ago, Graf Zahl said:

Not a good idea. Maps have been abusing the light level clamping for effects that depend on values larger than 255. Besides, with UDMF it can already be done.

Then make it an OPTIONS lump feature so that it's optional (or otherwise make it optional in some other way), and have UDB clamp it to 255 in the MBF21 configuration. Also, not everyone is going to use UDMF.. this is MBF21, a standard mainly designed for source ports that use the Doom format for maps, not UDMF or even Hexen.

1 minute ago, Graf Zahl said:

In that case you make the center part wider. These are absolute edge cases that really do not warrant making the common use case more difficult.

It's an edge-case, sure, but making widescreen assets part of the main WAD for vanilla compatibility makes it easier for the end-user, and for the WAD maker it's not hard to deal with at all - just crop the image and save it as multiple lumps.

9 hours ago, Graf Zahl said:

Maps have been abusing the light level clamping for effects that depend on values larger than 255.

Not to mention that light level differences of 1 are very often used to force clip mid textures to floor and ceiling.

Yes I'm aware of maps that uses light level larger than 255 because I use them myself. That is why I said it would represent -2048 to +2047, that is, a difference of 1 would represent what used to be a difference of 16 if this ever gets implemented.

For the differences of 1 force clip midtex, the range could either be reduced to -1024 to +1023 so the extra bit would help with the light level differences smaller than the software renderer step, that is a difference of 1 would represent what would otherwise be a difference of 8.

The only effects that I'm aware of that uses light level larger than 255 are those involving the timing of sector effect 8 and -1024 +1023 is already a decent range that would accomodate most cases. Do point out other cases that I'm not aware of that needs at least half the +-32k range to function properly.

Also these are just proposals within the doom format. idc about udmf.

On 4/19/2024 at 5:24 AM, Devalaous said:

• Adaption of the ResetHealth and ResetInventory fields, so we can move away from awkward death exits that can sometimes fail to strip gear and health, enabling pistol start via the UMAPINFO lump itself 

How about an explicit death exit line special or umapinfo definition?

I was playing Earthless Prelude and on MBF21 its death exits (map05, map10) don't work (at least in the MBF21 pioneering ports such as DSDA and Woof). The player telefrags the Icon of Sin and a pile of barrels, but only the Icon Of Sin actually gets telefragged and the barrels don't explode.

It seems with cl9 (carrying over into MBF21) there is some limitation on telefragging more than a certain number of actors at once (possibly that number is exactly 1) that are at the same origin coordinates. I couldn't find a compat flag that avoids this. Vanilla Doom 2 compatability has no such limitation.

Anyone know what's going on here & whether MBF24+ should have some kind of either fix or compat option for this behavior? I don't think there's any case where a mapper would want a player to be stuck in a killable object forever when taking a teleport.

17 hours ago, Graf Zahl said:

 

In that case you make the center part wider. These are absolute edge cases that really do not warrant making the common use case more difficult.

 

Given the number of high profile WADs that want vanilla compatability (e.g. BTSX) I don't think wanting a widescreen compatible HUD that doesn't crash vanilla is a tiny absolute edge case.

But I'll concede this discussion as having little relevance to MBF24+. I mainly mention it as a "while we are discussing new standards for ports to adopt" sort of bonus.

On 4/18/2024 at 2:07 AM, Xaser said:

Do all (or the vast majority of) MBF21 ports support sector lighting in increments of 8, or still just 16?

I made a test wad for this a few months ago. It had full white walls and floors and all light levels 0-256.

On 4/16/2024 at 12:29 AM, Heretic926 said:

I don't really know if that's possible, but I would love to see synchronized variants of sector effects 8 (Light Glows) and 17 (Light Flickers). Maybe even generalized light effects. It would allow so many possibilities for advanced lighting in maps!

Pulsating (glowing) lights are sort-of synchronized.

Their maximum light value is the pulsating sector's own light level. The min light level is the darkest neighboring sector's light level. 

As far as the difference in between the pulsating sector's own light level and the darkest target sector light level is the same, the lights of the various pulsating sectors oscillate at same frequency. You can use dummy sectors for that!

But having sync version of type 1 random blink and type 17 random flicker would be cool. You could use them to create more cohesive larger areas. At the moment every sector with type 1 or 17 blink and flicker at it's own rate.

On 4/21/2024 at 6:30 AM, besus said:

Yes I'm aware of maps that uses light level larger than 255 because I use them myself. That is why I said it would represent -2048 to +2047, that is, a difference of 1 would represent what used to be a difference of 16 if this ever gets implemented.

For the differences of 1 force clip midtex, the range could either be reduced to -1024 to +1023 so the extra bit would help with the light level differences smaller than the software renderer step, that is a difference of 1 would represent what would otherwise be a difference of 8.

The only effects that I'm aware of that uses light level larger than 255 are those involving the timing of sector effect 8 and -1024 +1023 is already a decent range that would accomodate most cases. Do point out other cases that I'm not aware of that needs at least half the +-32k range to function properly.

Also these are just proposals within the doom format. idc about udmf.

You still need to answer the important question here: How is the engine supposed to detect which light value format is being used? MBF21 does not make any changes to how existing map fields are being interpreted, and there are no good facilities to flag a sector using a different format for an existing field.

On 4/20/2024 at 8:56 PM, realjohnmadden said:

Then make it an OPTIONS lump feature so that it's optional (or otherwise make it optional in some other way), and have UDB clamp it to 255 in the MBF21 configuration. Also, not everyone is going to use UDMF.. this is MBF21, a standard mainly designed for source ports that use the Doom format for maps, not UDMF or even Hexen. 

This is not an option. OPTIONS is not a standard, not all ports use it. You have to solve this problem within the map format itself and not via some tacked-on switches in a control lump (no, not even MAPINFO!) that change how certain fields are being interpreted.

You might be better off placing a special thing type in the sector and use some of its fields to set such additional properties than making a potentially breaking change to the sector data.

3 hours ago, Graf Zahl said:

OPTIONS is not a standard

Then why is it specified in the MBF21 standard as well as in the original MBF standard? That's kinda stupid, isn't it?

3 hours ago, Graf Zahl said:

You have to solve this problem within the map format itself and not via some tacked-on switches in a control lump (no, not even MAPINFO!) that change how certain fields are being interpreted.

Then use the sector bitflag feature? You know, the one introduced by Boom and that MBF21 already expands on?? There's still about 3 bits up for grabs, so assign one to "alternate lighting mode".

5 hours ago, Graf Zahl said:

You still need to answer the important question here: How is the engine supposed to detect which light value format is being used? MBF21 does not make any changes to how existing map fields are being interpreted, and there are no good facilities to flag a sector using a different format for an existing field.

Compatiability levels. MBF11 already had different light calculations that made boom maps with light transfer look different that carried over to MBF21, so not a lot of reason to expect maps to look or function correctly when you have the wrong compatiability.

54 minutes ago, besus said:

so not a lot of reason to expect maps to look or function correctly when you have the wrong compatiability.

I can imagine what happens then:

"I just started Doom2.wad with complevel 24 and all lighting looks wrong. What's up?"

If you need a flag to switch this on the only realistic option would be a per-map UMAPINFO flag.

2 hours ago, Professor Hastig said:

 

I can imagine what happens then:

  

"I just started Doom2.wad with complevel 24 and all lighting looks wrong. What's up?"

  

If you need a flag to switch this on the only realistic option would be a per-map UMAPINFO flag.

 

 

 

Is this a thing that happens? I would think that, if people know what complevels are, they would know why Doom 2 might not work right on a new complevel.

4 minutes ago, Blast_Brothers said:

Is this a thing that happens? I would think that, if people know what complevels are, they would know why Doom 2 might not work right on a new complevel.

Rest assured - it will happen. There's really no thing inconsequential enough that it WON'T happen.

Compared to some things I witnessed over the last 20 years while developing GZDoom that hypothetical reaction is almost 100% guaranteed, just like I got countless reports of "I ran xyz on Doom (strict) and that passage was blocked", caused by running a ZDoom map with infinitely tall actors.

The chance this will cause false reports is close to 100% unless the feature trigger is part of the map itself, like the proposed idea of using one of the free sector flags for it.

I'd like to start out by saying massive thanks to you guys for creating the mbf21 spec, as it is super awesome and useful. I have many thoughts about things that would be really useful in the next spec. Now, I don't really know how realistic some of these requests are, also many of them are probably repeats of things others have suggested, but I figured that I would jot them down anyways.

1. A generalized way to add new weapons without having to replace the existing slots. Just a way to define a weapon, select a number slot for it, and it would be stacked on top of whatever weapons are already in that slot.

2. Better support for bouncy things. The current implementation of the BOUNCES flag is jank due to relying on the presence or absence of the MISSILE flag to determine the behavior of the bouncing. When you have a projectile with the BOUNCES flag but without the MISSILE flag, which is the combination that provides the grenade-like behavior, they do not function properly with the missile codepointers. It would be nice to have a better working way of doing bouncing things.

3. Require the implementation of the umapinfo and musinfo lumps (and maybe dsdhacked but idk about that one) in the standard so that when you are working on a project, you can use them without having to worry about a couple of ports that don't support them. It also makes it so when you release a project, you don't have to say something like "runs on ports that support mbf21 and umapinfo."

4. Speaking of umapinfo and musinfo, there are a few things that I think could be improved about them. For umapinfo, it would be nice to be able to use the ExMy system for a Doom 2 wad. I feel like this helps the flow of episodic wads more, especially if they have episodes that are not 5 maps each. In addition, it would be nice to be able to set the intermission stats screen music per level instead of globally. And for musinfo, it would be nice to be able to trigger a music change using a linedef instead of a thing, allowing it to be triggered by voodoo sequences and such. Perhaps the tag on the linedef could be the index for the song to choose in the musinfo for that map. Perhaps, the musinfo definitions could even be moved to the umapinfo map definitions.

5. Speaking of voodoo dolls, one feature idea I had was introducing an entity flag called "Triggers Lines" that will trigger walk over lines like voodoo dolls do, so that we don't need to use multiple player starts anymore, which would be in my opinion a cleaner way of doing things.

I realized I forgot something when writing this yesterday. This would be a big useful one. A codepointer called A_Move or something which is the same as A_Chase, but it does not call A_FaceTarget first, and has parameters for x y z movement amounts relative to the enemies rotation. This would allow for much more versatile movement control that doesn't rely on only moving towards the target. Also I just wanted to say I really like another idea I saw in this thread which is to have counters on things that can be incremented and decremented with codepointers and can be checked with jump conditionals

Another UMAPINFO-related issue - a gap between dsdhacked thing indices and bossaction definitions. Current UM spec only defines up to dehextra entities.

I'm not a seasoned coder, and by absolutely no means am I saying this should be the basis of work that's done, but I was able to get a fork going of DSDA-Doom that implements a rudimentary MBF24 complevel with a few basic features. I strongly encourage, when the time comes for whatever the next complevel is to be seriously developed, the wholesale lifting and cleaning of any or all code that I made here.

There are only a few basic features here. A few quick notes:

• The draft complevel, 24 (or mbf24, per COMPLVL lumps), also implies mbf21 so as to preserve MBF21 functionality.
• I have not done more than simple demo playback testing with MBF21 demos in MBF21 wads, but I haven't had any desyncs so far. I gated all the new logic behind checks that the MBF24 complevel is set.

As for what's there so far:

New Thing Flags: These can be defined in a similar manner to MBF21 thing flags by using the "MBF24 Bits" field.

• NODAMAGE: Thing can still be shot at if the SHOOTABLE flag is enabled and can enter its pain state, but it does not lose hit points.
• NOCRUSH: If Thing is a corpse, it will not turn into gibs when crushed. If Thing was dropped by a monster, it does not get destroyed when it is crushed.
• PUSHABLE: Thing can be pushed around by other things.
• CANNOTPUSH: Thing does not push other things with the PUSHABLE flag.
• ANTITELEFRAG: When another thing would teleport into the same space as this thing, instead of this thing being destroyed, the other thing is destroyed.

Updated Thing Codepointers: Increasing the number of arguments of these code pointers hasn't broken MBF21 compatibility in my testing (since the args would have never been consumed previously anyway), but more testing is necessary.

• A_AddFlags/A_RemoveFlags: a third arg has been added for MBF24 actor flags to add/remove. This arg is ignored in MBF21.
• A_JumpIfFlagsSet: a fourth arg has been added for MBF24 actor flags to check for. This arg is ignored in MBF21.

At present, there is a simple test wad linked in the readme that tests the NODAMAGE, PUSHABLE, and ANTITELEFRAG flags.

New Thing Codepointers:

• A_JumpIfTargetHigher: A parameterized check to jump to a state based on vertical distance between the caller and its target. Can be configured to only check distance below, only check distance above, or both (default).

Note that this is entirely a proof of concept and more of a springboard for the actual MBF24, and I'm sure my code isn't really up to standards/conventions. I don't have the bandwidth to oversee an entire standard being developed, and there are people much more suited for that anyway, judging by how much I struggled to get everything to build in my environment. I would be glad to contribute what I can, however.

https://github.com/SirBofu/dsda-doom-mbf24

There's a couple of recent-ish maps that rely on Final Doom's funky teleporter behavior, turns out:

IMO it'd be worth adding an explicit comp_ flag to the OPTIONS lump, let folks toggle it on if they really need it.

Beside the "transfer sector brightness" and "modify sector brightness by height", we could also use "add/substract front sector brightness". Which would, naturally, add or substract brightness of the sector in front of the linedef to tagged sectors. This should cover most "Blinking light across multiple sectors" needs.