Reflections and Aspirations: MBF21 in 2024

[Xyzzу]

Perhaps a way to make monsters attack without invoking A_FaceTarget? Just thought of the possibility of making a hitscanner whose otherwise unavoidable shots you can thwart by simply moving out of the way constantly. It's certainly more elegant than just giving it a fast, tiny projectile...

[Edward850]

On 3/5/2024 at 11:07 PM, realjohnmadden said:

Infinite thing height option (useful for, say, Heretic-style wads or just wads that need it in general) 

Nothing in Doom has infinite height. What you're actually asking for is specific collision handling being added for solid actors which is rather out of scope for simple drop in specifications.

 

There's a lot of logic missing to be able to make solid Z collisions work, namely what to do if a sector moves during this time. There's no simple drop in logic for that as there's a lot of new information that needs to be recorded on actors to manage it.

Edited March 7 by Edward850

[realjohnmadden]

3 hours ago, Edward850 said:

There's a lot of logic missing to be able to make solid Z collisions work, namely what to do if a sector moves during this time. There's no simple drop in logic for that as there's a lot of new information that needs to be recorded on actors to manage it.

I'm no code wizard (most I did is make a full-screen HUD for an ECWolf fork that doesn't work half the time and probably brought down performance 5% on its' own), but there has to be GPL code in Heretic or Hexen for it, and projectiles can already go over and under things - plus, ZDoom has had it for a long while now. You can just make it so if a sector moves, things on top of other things that are in the sector also get moved, and if there's no space, stop moving or crush the things (depending on crusher type, if it's a door, or what have ye). Things treat other things just like they would a regular floor, including flying and whatnot.

 

I suppose an easier addition would be an invisible sector type (similar to the one in PsyDoom). Just make it use the same rendering height as the lowest nearby sector, but with its' own collision. It'd be useful for pulling off things like ROTT platforms or invisible bridges easier, and would be even better than the existing methods as the sector can actually be raised and lowered. (Doom 64 also has a special texture that allows you to fake FOF, and while that would also be nice, it'd probably require an actual hardware renderer due to visplane shenanigans.)

[Edward850]

I wasn't talking about if the code existed, obviously ports have it. I said it's not something you can just drop in. The MBF## spec should be portable as possible; hard-lining it to a particular physics concept that has no easily portable implementation would make it unattractive to use. Keeping in mind that I am talking from experience here.

 

Also if you say "You can just x", you can't "just x".

Edited March 7 by Edward850

[ChopBlock223]

Maybe not all of these would fit just a standard or complevel, but these are things I've thought about for a while, even having griped with. Some are probably more realistic and within scope than others, apologies for that.

• I'd like if UMAPINFO could do some more things which MAPINFO could do, like setting the specific music track for end of level screens and for text intermission screens, separately. Also the ability to skip end of level screens.
• I'd like if I could ExxMxx style map lump naming conventions, rather than being forced to stick with Doom 2's MAPxx convention. This would be much more handy for episodes.
• I think the improved blockmap should be part of a complevel, I want more viability for melee.
• I like the idea of generalized light functions, I would also like to be able to do Doom 64 style strobes. If possible, Doom 64 style overbrightness.
• Duke Nukem style weapon reloading would be fun, I would also like to make enemies be able to reload.
• I also really like the idea of the ability to decouple A_FaceTarget from attacks as to make strafeable hitscanners.
• While I'm at it, the ability to have little decorative bouncing actors which soon despawn, for particle effects like spraying blood and debris, sparks, smoke, ejecting casings from both the player's weapon and the enemy. All without interfering with other actors or causing problems.
• I'd like a new type of text intermission screen where it's formatted within 4:3 for consistency, and the player can scroll it up and down if it's longer than the screen's height.
• The ability to use scaling for sprites would solve a million problems for me. Not sure how this would be applied, but if my given sprite is 30% too big, I could scale it to fit, rather than having to manually shrink down the graphic and repainting it, and its remaining frames (which might not even be an option).
• The ability to link all sectors of a given tag together for the purposes of movement, be that a raising floor, lowering ceiling, a crusher, or an elevator. With a bunch of control sectors you can make an elevator of numerous sectors move up and down in unison, but A, there's numerous ways this can break (Cacos are one), and B, the way sound is handled means that this adds up the number of these sounds and this gets loud. If the tagged sectors can be forced to sync so they don't break apart, this would be cool.
• Something to allow for Doom 64 style shooting dart traps maybe.
• Vertically splitting doors.
• No clue if there's any remotely clean or practical way to do this (I suspect there is NOT), but horizontally sliding doors, splitting or not, would be appealing. They would not have to physically slide, they could just compress to any given side and the texture follows along. This would probably get EXTREMELY fucky if the door isn't flat.
• More an engine thing, but being able to use .ogg files for sound effects, they're clean and compact.
• While at it, add a built in generic VooDoo Doll actor so they can be plopped down immediately and you don't have to redo the player start, and it should be affected by skill level flags.
• Sidedef flag for making midtextures tile vertically.
• Differing levels of translucency for sprites and midtextures (even if just like 10 or 5 predetermined ones).

[zokum]

Work and real life has made it complex for me to spend any time on Zokumbsp the last few years. I've also not had much time for other Doom projects. I occasionally work and write down algorithms and thoughts. There's still some development done, but not a whole lot.

 

I have some hardware problems with my main rig, and until I get that fixed, there's not much I can do. A lot of my more recent stuff is on a Linux VM on that machine. I have set up a mirror of the web page on doom2.no (my domain), and I am working on some new pages and updates for that one, but nothing that is released as of 2024.

 

I still provide 'support' if people ask me on irc, doomworld or mail. I'll bed happy to answer any questions about Zokumbsp and related Doom (2) v1.9 level editing.

[GooberMan]

I've been meaning to drop in to this thread for a while. I'm not ready to offer my suggestions, but I will offer an explanation of the standpoint I'm taking.

 

If you check the Rum and Raisin Doom submit logs, you will notice that the codebase is approaching MBF21+DSDHACKED compatibility. As of right now on my local machine, I can complete a few levels of Eviternity 2 in fact (with glitches and incomplete features that don't hinder progression).

 

What's unique here is that I've been doing this entirely from documentation and descriptions of functionality provided to be my other community members (Altazimuth, Edward850, esselfortium, Quasar, and Xaser in alphabetical order are deserving of the shoutouts here). I'm doing this for a number of reasons, most of which I won't elaborate on here. But it does highlight that from Boom onwards, documenting how a feature works has never been a priority. We have detailed specifications of many things vanilla, both from the old Doom specs text that the community started compiling in 1993 and on the Doom Wiki. This is great for clean room implementations. But there's so much that I haven't been able to ascertain just from reading documentation or observing behavior - the big one I'll never get right from Boom is friction in fact, which is regularly described to me as "magic values" by people familiar with the code. Don't get me started on MBF, that is one big hack according to those in the know. The MBF21 spec is better documented, but defers to patch/diffs of an existing implementation in an annoying number of circumstances instead of a complete description of the behavior (ie a proper spec and not just an upgrade guide).

 

Much of the featurebase we have is dependent on some port's implementation to make sense of what spec is written. UMAPINFO is a notorious example there, where you need a valid Doom or Doom 2 gamestate for any of its features to work. And you can easily break things with episode definitions. I got caught out by Sigil 2 support, in fact, since it's a 100% unspecced behavior (and thus implementation defined) that the episode for any given map is taken from the ExMx map format number rather than clearepisodes/episode definitions in UMAPINFO. And thanks to the very nature of UMAPINFO, any mapset that uses MAPxx format in Doom 1 or ExMx format in Doom 2 means that these assumptions you take that are implementation-defined can very easily break. Oh, and let me tell you about what happens to all of the above when you use the registered doom.wad instead of the Ultimate doom.wad and only have three episodes defined in the WAD.

 

Having behavior exist in a codebase somewhere is no good for people implementing things from the ground up. It's great that we can share GPL code, and I encourage people to take my GPL code too. But it's not great for anyone who chooses to start from the (recently for realsies) GPL release of linuxdoom on id Software's github.

 

tl;dr - Clearly describe behaviors without using code when speccing things, it's a far cleaner way forward.

Edited March 7 by GooberMan

[Scorcher]

Continuing from my previous post regarding fake 3d floors, how about an option for silent moving floors/ceilings, so you no longer have to move a dummy sector really far away to not hear the grinding sound?

[zokum]

13 hours ago, Scorcher said:

Continuing from my previous post regarding fake 3d floors, how about an option for silent moving floors/ceilings, so you no longer have to move a dummy sector really far away to not hear the grinding sound?

A better option would be to have the ability to set which sound you want to use, so that you can vary sounds. Setting it to null or "" should then make it silent.

[ViolentBeetle]

Can we also get an extra bit on generalized floor/ceiling actions to decide if it changes texture and effect at the start or at the end?

It can be done with voodoo dolls, but it does require voodoo dolls.

[Xaser]

I've been playing around a bit with ripper projectiles recently, and there's a flaw with the current implementation in dsda-doom (unsure if shared with vanilla heretic, haven't checked): projectiles won't rip through freshly-killed enemy corpses until they hit their A_Fall state. This isn't always noticeable since enemy height gets reduced to 1/4 immediately on death, but if you fire a ripper at the foot of a monster as they're dying, it don't rip. :(

 

Dunno if this is best handled with a compat option or a new flag, but either way it'd be a demo-compat-breaking change to just fix in place, so "fix it in the new standard" we go. ;)

[JackDBS]

A feature to have certain enemies not count on the kill count as a toggle would be neat.

Edited March 22 by JackDBS

[realjohnmadden]

I wonder if runtime colormaps (as well as just applying colormaps to specific sectors) would be possible? This would be very useful for a lot of maps - yes, you can use line special 242 to make a fake floor/ceiling, but that's a lot of work if you have a lot of sectors. Instead, a better implementation specialized for sector colors would be far more useful and easier to work with. You could add a lump at the end of a map that stores sector colors (a name like SECTRCOL or COLORS would suffice), and have it store data in a format like this:

Spoiler

- Unsigned 16-bit (two bytes) for sector ID

- Unsigned 8-bit for R, G, B, and A (A is saturation, as suggested previously)

Each sector would get 6 bytes, so if you went nuts and applied it to 16,384 sectors, that's 98k, and for a more modest selection of 4096, that would be 24k. A PSX-Doom map would probably have just 128 colored sectors (which is a guesstimate, but it's probably accurate), so just 768 bytes.

 

An alternate format designed for larger maps with lots of sectors that use the same colors would be this:

Spoiler

- Unsigned 8-bit for RGBA

- Unsigned 16-bit for sector IDs, this one repeats until an ID of 0 is hit.

If you had a lot of red-colored sectors and a few yellow ones, it'd look like this:

FF 00 00 FF - color id

00 02 - sector

00 04 - sector

00 07

etc etc...

00 00 - end marker

FF FF 00 FF - new color id

00 03 - sector

00 05

00 06

00 00 - end marker

 

 

Better documentation would absolutely be essential. I hate having to have multiple pages open at once, one for Boom DEHACKED to look at its' flags, one for MBF DEHACKED to look at its' functions, and another one for MBF21 DEHACKED to look at its' functions and flags, all just to make a weapons pack. The ZDoom wiki has everything organized, including things that "shouldn't be specified" due to being from previous standards (Boom flags, pages for original Doom functions, etc) - why not do the same and organize everything? I'm just a modder, but GooberMan also has problems with how unelaborative the documentation is, and they're making an actual source port, not a goofy weapons pack with hodge-podges of assets.

 

Better HUD customizability is an absolute must. LATCHCFG from ECWolf can be used for reference - the format is simple and easy enough to implement.

 

A bunch of ideas I may as well throw at the wall just to see what could stick, in case one of them is actually possible and plausible.

Spoiler

- Intermissions like in ZMAPINFO. It should be part of the spec that animated graphics (ANIMATED/ANIMDEFS) always animate in intermissions, and not resetting whenever an intermission state change happens.

 

- Incorporate ANIMDEFS as part of the standard, along with UMAPINFO, TEXTURES/TX_START-TX_END, and SNDINFO. I'm pretty sure both Woof and Crispy already support ANIMDEFS, but I'm not actually sure.

 

- Useable things. Jump to USE state when player uses thing, and add a function to target the player that pressed USE on the thing.

 

- Player movement customizability for DEHACKED; better control over things like player momentum and whatnot would be great. Wolf-style movement and Quake-style movement would be great for TCs. More specifically: acceleration, deceleration, max-speed for running, and max-speed for walking.

 

- Map-specific lumps. Put any lumps that should be used for a specific map in a marked area (e.g. MAP01_ST-MAP01_EN, E1M1_ST-E1M1_EN), and engines will use those lumps for specific maps, including colormaps and PLAYPALs. This only applies when the map is being played and (optionally as part of the UMAPINFO map definition) the intermission screen. For melt effects and other transitions, when the transition starts and the new map has a different palette, immediately change palette (if need-be) then convert the last frame of the map to the new palette (to avoid the screen suddenly turning into clown vomit and melting when entering a new level). Use a basic palette conversion algorithm that can be agreed-upon.

 

- Better support for hub maps. New line special for teleporting to a new map by using the tag, with variations (i.e normal teleport, silent (no intermission), silent retain position, silent retain rotation, silent retain both position and rotation, silent retain position and rotation relative to the linedef) that would either be separate specials or toggled by flags similar to how SRB2's specials use flags to toggle specific behaviors. These should be triggerable by voodoo dolls, and would retain position and rotation for all players in the case of co-op/deathmatch, although if a player is out of bounds they would get teleported to the middle point of the linedef, facing the opposite direction of where the linedef is facing. Tag would be MAP%# for Doom 2 and E%M#, with % being the first digit of the tag and # being the second digit. For tag IDs 0-9, % is treated as 0, and if in Doom 1, is treated as 1 if zero. # also has 1 added to it in Doom 1, to accomodate for E1M10s and whatnot - so, a tag of 5 would warp to MAP05 in D2 and E1M6 in D1, a tag of 49 would warp to MAP49 in D2 and E4M10 in D1, a tag of 0 would warp to MAP00 in D2 and E1M1 in D1, etc.

 

- Better support for voodoo dolls. A separate voodoo doll object was already suggested, but could be expanded to instantly move on conveyors and whatnot, instead of gradually speeding up to the conveyor's speed. It should also work with MUSINFO, and the MUSINFO delay should also be part of OPTIONS.

 

- Damage types would be useful. Imagine Blood-style burning, or shrinking/expanding enemies like in Duke 3D. Damage types would be an integer, with things having a DamageType parameter. There'd also be a function to jump based on the most recent damage type with a parameter to prioritize non-default types (non-zero), and another one to jump based on which damage type triggered the current state (for pain and death/xdeath).

 

- Scale parameter for things. Fixed-point, of course. Should also be changeable via action functions.

 

- More map flags for things and flags in general, so that you can have one enemy type that can be changed to be faster, or have a special attack, by just ticking "Custom Flag #1" in a map editor. More flags would also be useful for those making custom enemies, as you can make it so an enemy can only use an attack once and other similar stuff (which, while possible already, is far harder to do due to the fact every flag already has a specific use in DEHACKED, and toggling it could mess with behavior).

 

- Give things and weapons a few variables to work with (three signed integers?) so that you can make timers and whatnot. It would also be useful for Duke-style weapon reloads.

 

- Better support for instant specials (instant lowering floors and whatnot), and support for immediately starting, resetting, and stopping the scrolling of tagged lines. You would have 8 specials to start scrolling in 8 directions, and then two to reset and stop, as well as one that uses the texture offset of the control linedef to start scrolling. This would be useful in making fake sliding doors and such.

 

- Custom obituaries for new monsters. Simple enough to do - just give things an OBITUARY property that points to a string in the Strings section.

 

- TITLEMAP.

 

- Camera control, like Doom 64. It would use the sector tag, not a thing tag.

 

- Doom 64 MACROS support.

 

[bofu]

Some additional thoughts I had:

• Fix the buggy R_DrawSprite behavior where large things, such as Spider Masterminds or Mancubi, disappear entirely if the sector their point of origin is in isn't visible to the player even when the vast majority sprite should be. I think this could be done by also checking to see if a neighboring sector is visible to the player, which would alleviate the behavior somewhat, or more ambitiously, calculate it based on the thing's radius (corners?) if the center is not visible. See https://github.com/fabiangreffrath/woof/issues/1537
• Add a new behavior for the complevel (perhaps as a setting) that when monster corpses would move in order to try to slide off of a ledge, they don't do so if the distance between the floor they're on and the floor they'd be going down to is 8 or less. No more monster corpses sliding entertainingly along floor detail sectors.
• Some sort of mechanism for Things spawned by monsters' projectiles that might cause damage (such as via A_RadiusDamage) to inherit the original monster as their owner so that enemies that get damaged by it can retaliate in kind.
• A Thing flag that makes a solid object otherwise able to teleport into another solid object without getting stuck or telefragging it, then unsticking itself as soon as it has room to do so. Would be useful for teleporting enemies when you can't guarantee something else isn't in the teleport destination.
• An option, either as a complevel setting or an additional flag, for DMGIGNORED to only be taken into consideration when the Thing that has it and the Thing that it provokes have the same FRIENDLY flag state. (No more Archviles getting ignored by friendly monsters.)

[DoomGappy]

4 minutes ago, bofu said:

No more monster corpses sliding entertainingly along floor detail sectors.

Why would you ask for this?

[bofu]

22 minutes ago, DoomGappy said:

Why would you ask for this?

Because I hate fun. (Also, had one break a teleport once.)

 

Edit: perhaps it could be timer based instead. It can slide for a few seconds, but it should eventually come to a stop if all it's doing is hugging a linedef.

Edited March 27 by bofu

[Xaser]

1 hour ago, bofu said:

• Some sort of mechanism for Things spawned by monsters' projectiles that might cause damage (such as via A_RadiusDamage) to inherit the original monster as their owner so that enemies that get damaged by it can retaliate in kind.

 

This is intended to already work if you're using MBF21's A_SpawnObject to spawn the sub-projectiles -- if that's not working, there's a bug in the implementation that ought to be fixed and compat-option'd for the next one.

[bofu]

12 minutes ago, Xaser said:

 

This is intended to already work if you're using MBF21's A_SpawnObject to spawn the sub-projectiles -- if that's not working, there's a bug in the implementation that ought to be fixed and compat-option'd for the next one.

Looks like it doesn't work if the spawned object is calling A_RadiusDamage instead of dealing damage in some other way. It actually worked out for the implementation I used it for (projectile leaving behind acid pools - didn't want to make infighting ridiculously easy to trigger).

[Xaser]

Do the acid pools have the MISSILE flag set? If not, that would explain it -- `A_SpawnObject` copies over the `tracer` and `target` pointers if both spawner and spawnee are missiles, but only in that case -- it's specifically meant to support projectiles spawning sub-munitions, but the general case of having monsters do attacks without the +MISSILE flag is kinda undefined-land in general.

 

If that's what's going on, it sounds like a good case for adding some explicit flags to control this behavior (e.g. a pair of "alwaysCopyPointers" and "neverCopyPointers" flags for A_SpawnObject ).

[bofu]

3 minutes ago, Xaser said:

Do the acid pools have the MISSILE flag set? If not, that would explain it -- `A_SpawnObject` copies over the `tracer` and `target` pointers if both spawner and spawnee are missiles, but only in that case -- it's specifically meant to support projectiles spawning sub-munitions, but the general case of having monsters do attacks without the +MISSILE flag is kinda undefined-land in general.

 

If that's what's going on, it sounds like a good case for adding some explicit flags to control this behavior (e.g. a pair of "alwaysCopyPointers" and "neverCopyPointers" flags for A_SpawnObject ).

 

The acid pools definitely do not have MISSILE set, since the intention was for them to linger even when touched and deal AoE damage over a short period of time. I was happy with the behavior in this way and didn't want to change it. I like the solution of explicit flags to toggle the behavior - more options are always better than fewer, so long as they don't overcomplicate things.

[Not Jabba]

22 minutes ago, bofu said:

 

since the intention was for them to linger even when touched and deal AoE damage over a short period of time.

Is it possible to accomplish this by making them rippers?

[bofu]

8 minutes ago, Not Jabba said:

Is it possible to accomplish this by making them rippers?

Maybe! Radius damage worked fine for my needs, so I didn't try it.

[Scorcher]

I'd love to have second weapon slots for 2, 4, 5, 6 and 7. Kinda like how Heartland does it.

 

Also I finally remembered how Doom 64/PSX Doom faked it's 3d floors. The renderer in those games can ignore lowered F_SKY ceilings and allow you to view everything behind the sector. Would it be possible to have something similar in software rendering?

Spoiler

 

[SilverMiner]

On 3/18/2024 at 12:53 AM, ViolentBeetle said:

Can we also get an extra bit on generalized floor/ceiling actions to decide if it changes texture and effect at the start or at the end?

It can be done with voodoo dolls, but it does require voodoo dolls.

I feel adding an extra bit of something would make some structure bloat, and thus the game would use more ram.

I think it's better to do that stuff with voodoo dolls

[redEYE]

This is outside of MBFxx scope but could UMAPINFO have an extension as well? It already has bossaction:

bossaction = thingtype, linespecial, tag

but could there be a more precise action:

thingaction = thing index number, linespecial, tag

OR

thingsgroup = groupnumber, thingnumber1, thingnumber2, ..., thingnumberN
thingsgroupaction = groupnumber, linespecial, tag

(N = a sensible number, maybe not for Okuplok)

So that the action would be triggered when a thing with the index number (= a monster, barrel, keycard, ..) dies, explodes or is picked up. OR the whole group of things has had a similar fate. If you play nomonsters or a skill level, a multiplayer where the thing doesn't exist then ignore it and possibly execute the action right at the start of the level.

 

Using thing index numbers here because in Doom format maps the items can't be tagged. The only way to separate one imp from an other is the thing index number?

[Tiramisu]

EDIT: I've just read a few posts back in the thread and there's someone saying why this specifically is not a good choice for a format feature - but I'll leave this up anyway, just because I think the solutions I've come up with are interesting food for thought.

 

After some thought in the recent weeks, I have another thing to say here - I believe this will be a bit controversial, but I feel like it is time for DOOM to start moving away from infinitely tall actors. I personally consider infinitely tall actors to be the worst among DOOM's bugs/missing features, because it actively and uniquely handicaps the game's potential for verticality in map design - and getting rid of it would lead not only to more interesting layouts, but to better arena designs as well.

 

Currently, there is no single "format" that specifies non-infinitely tall actors. UDMF kind of is one because it's (G)ZDOOM-only and nobody plays that port with infinitely tall actors, but otherwise the option is always left to the player in source ports that support it. If we had a format like this though, it would be possible to map specifically for it without the need to specify "please play this map in Crispy/Nugget DOOM only and turn off infinitely tall actors" each time - which is why I believe this is the right place to talk about this, in the first place.

 

Now, I have read threads with arguments for and against non-infinitely tall actors in general, and I know the problems they bring - most notably, the way they change flying enemy swarm behavior and the potential they give to crowdsurf away from combat. For this reason, I've come up with a set of specific rules that I believe would allow us to have the cake and eat it too, so to speak:

 

• At a basic level, the non-infinitely tall actors work in the simplest way possible (so they don't f.eg. act like moving platforms).
• Monsters still treat each other as if they were infinitely tall. This way the general flow of combat is preserved for flying monsters.
• When Doomguy is standing on top of a monster, he cannot run. This way, crowdsurfing is discouraged as the monsters will always get some hits in.
• When a monster is being stood on by Doomguy, it cannot move. This way, Doomguy can't get stuck on a monster that's faster than his walking speed.

 

That's about it, I guess! Like I said it would be really nice to have this for the map design potential it would unlock, but I understand if it's too big a change or outside the scope of map formats altogether.

Edited April 12 by Tiramisu

[Heretic926]

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!

[Trov]

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).

 

Benefits over the current system (STBAR wider than 320px):

• A little bit more control over what goes into the widescreen side areas of the status bar and how it deals with being cropped
• Allows a wad to remain compatible with Vanilla/Chocolate Doom while also supplying a widescreen status bar for other ports. (An STBAR wider than 320px crashes Vanilla/Chocolate Doom.)
• Allows a widescreen status bar to accommodate ANY aspect ratios or HUD scale option, even extreme cases such as ultrawide, without having to create a super wide STBAR graphic

 

A WAD will specify widescreen status bar graphics by simply containing the following graphics lumps:

STBAR - the unchanged center section, 320px wide to guarantee Vanilla engine compatibility.

STBARL - this section will be drawn a single time to the left of STBAR in widescreen resolutions, potentially being cropped by the edge of the screen.

STBARR - this section will be drawn a single time to the right of STBAR in widescreen resolutions, potentially being cropped by the edge of the screen.

STBARL2 - this section will be drawn to the left of STBARL starting from STBARL's edge, but will horizontally tile until the edge of the screen. If there is not enough room for it on the screen (such as because STBARL is cropped by the edge of the screen) it is not drawn.

STBARR2 - this section will be drawn to the right of STBARR, but will horizontally tile until the edge of the screen.

 

If the STBARL/2/R/2 graphics are not present, the status bar draws as usual, with the default tiling flat. This allows an STBAR wider than 320px (the "standard" before this proposal) to remain working.

If only STBARL or R are not present (no L2 or R2), the usual tiling texture/Woof color fill is drawn after the L and R sections end.

If only STBARL2 or R2 are present (no L and R), they are drawn adjacent to STBAR and horizontally tile forever.

 

If a WAD is loaded after the widescreen-graphics-parts-containing WAD, and that newly loaded WAD only contains STBAR, all of the STBARL/R sections are disabled. This prevents a WAD's STBAR from getting mixed up with non-matching widescreen parts loaded from an autoload folder for instance.

 

Offset considerations for STBARL: (0,0) should be the point where STBARL meets STBAR. This allows STBARL to potentially overlap STBAR if desired, such as to erase a left edge border on the original STBAR graphic.

Offset considerations for STBARR: ditto but for the point where STBARR meets STBAR.

 

Additional, but more complicated enhancements:

STBARL3 - a 'cap' that is drawn a single time on the leftmost edge of the screen. This will be drawn on top of STBARL2. This allows making a leftmost edge of an arbitrarily wide status bar background. If it is too wide to fit in full between the edge of STBAR and the edge of the screen it is not drawn.

STBARR3 - ditto for right side.

 

I might make some mockups later to visually describe the behavior of each part.

 

Maybe, if you want to go even more crazy, this system can apply to all pics such as TITLEPIC or INTERPIC.

 

 

-----

 

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

 

Why? Makes it easier for launching WADs. Let's face it, in 2024 having to separately keep track of an IWAD and complevel for each WAD you have is kind of archaic. This metadata would allow any port to easily do what it needs in order to launch a WAD into a playable state without the user needing to specify anything else. Yes most of this info is included in the idgames .txt that comes with the WAD, but those usually have too much other stuff that make them in many cases unreliable for parsing by a launcher program or Doom engine.

 

This functionality could for instance lead the way towards ports providing in-game WAD loading with as little hassle as possible.

 

-----

 

Otherwise, I agree with providing the ability to define weapons slots for new weapons. I think things like reload and zoom and other such ZDoomisms are way too far for the scope of MFB2_ and I am not sure if most people replying in this thread understand the purpose of MBF2_, but picking a weapon slot number should be comparatively simple.

Edited April 17 by Trov

[Xaser]

This might not even be technically relevant to the new standard, but it's almost in the neighborhood so I'll leave it as a note-to-self for later:

 

Do all (or the vast majority of) MBF21 ports support sector lighting in increments of 8, or still just 16? The vanilla behavior of 16 is a sort-of-bug, so it seems like the sort of thing that ports may have fixed at some point, explicitly or otherwise. There's even a chance I may have accidentally addressed this with dsda's indexed lightmode, presuming it wasn't already handled at some point. :P

 

If that ends up being a Thing(tm) or is at least easily achievable, that may be a good thing to explicitly codify somewhere as part of a new standard, that way maintainers of editors like UDB know to support it in the format.

[bofu]

1 hour ago, Xaser said:

If that ends up being a Thing(tm) or is at least easily achievable, that may be a good thing to explicitly codify somewhere as part of a new standard, that way maintainers of editors like UDB know to support it in the format.

I might be wrong, but I think there's no need to explicitly support it in the map format. Doom format maps already support brightness values that aren't a multiple of 16 (or even 8), and the source port interprets it as it will.

Edited April 18 by bofu