MBF21 Specification v1.2 Release

[GoneAway]

Yep, as already mentioned it's way too late to request anything 😄

 

This won't be the end of progress though 😉

[Biz!]

ignore

Edited August 8, 2021 by Redoom

[TheMightyHeracross]

3 hours ago, Redoom said:

I would like to see some colored lighting abilities, and Doom 2 Monsters for Doom 1, maybe some way to stop sliding too.

I thought Boom already had colored lighting?

 

And IIRC you can have Doom 2 monsters in Doom 1 if you just include sprites. The only thing you can't do is use the SSG, I think.

[Biz!]

On 6/9/2021 at 12:54 PM, TheMightyHeracross said:

I thought Boom already had colored lighting?

 

And IIRC you can have Doom 2 monsters in Doom 1 if you just include sprites. The only thing you can't do is use the SSG, I think.

ignore

Edited August 8, 2021 by Redoom

[Danfun64]

5 hours ago, kraflab said:

Yep, as already mentioned it's way too late to request anything 😄

 

This won't be the end of progress though 😉

Dammit. I've been away from the doom community for too long, just saw this today.

I would have requested the ability to record chat in demos as well as respawning items in coop. It annoyed me that those features weren't featured in any of the previous standards.

[ViolentBeetle]

An idea I had today (Might be hard for scope of the project) - synced linedefs.

Essentially, a linedef could have a flag that makes it share its triggered status with every other linedef with the same flag, tag and type.

 

This would be useful for two things:

- A switch could now consist of multiple linedefs that change at once, such as curved linedef or one of those floating cubes some mappers have.

- A booby-trapped sector surrounded by multiple linedefs that makes ambushes by means other than doors won't click multiple times when you run through it. Especially if linedefs are short and numerous, like a circle.

 

Also silent type on sectors, so they don't produce sound when moving, no matter what. Might be mostly redundant if linedefs can have it, but could still be useful.

[Gez]

For the second, it might be simpler to port the concept of "sector actions" from ZDoom?

[SilverMiner]

3 hours ago, TheMightyHeracross said:

I thought Boom already had colored lighting?

 

And IIRC you can have Doom 2 monsters in Doom 1 if you just include sprites. The only thing you can't do is use the SSG, I think.

Boom makes it possible, but in very crutchy way, so it needs to be a new feature that is just bound to linedef action that just applies a custom colormap to tagged sectors. The easier thing to implement that I'd ask is to make it possible to apply a colormap to whole the map bound to fadetable entry stored in UMAPINFO or in other lump that is read upon a map's init, like a map marker lump

[WashingMachineEnthusiasts]

4 hours ago, SilverMiner said:

Boom makes it possible, but in very crutchy way, so it needs to be a new feature that is just bound to linedef action that just applies a custom colormap to tagged sectors. The easier thing to implement that I'd ask is to make it possible to apply a colormap to whole the map bound to fadetable entry stored in UMAPINFO or in other lump that is read upon a map's init, like a map marker lump

This would be limited but still useful, especially in creating Hexen-style fog. Seconded.

[punch you in the face man]

Melee range might be bugged. I set it to 68 for a pinky and it wouldn't attack me, even going to 128 it just never tried to byte.

[GoneAway]

9 minutes ago, punch you in the face man said:

Melee range might be bugged. I set it to 68 for a pinky and it wouldn't attack me, even going to 128 it just never tried to byte.

Guessing that you're trying to set a fixed point field, doom's way of storing fractional values. In that case 65536 is equal to one unit. Then 68 would be 4456448. Tools can take care of that conversion for you, if you don't mind waiting for them to be ready - otherwise you can take care of the math by hand too.

[punch you in the face man]

Sweet, thanks. This also exposes a bug (I believe so at least, could be me blaming user error on bugs again) in DecoHack that I've raised as an issue on its GitHub.

[Warden]

On 5/29/2021 at 7:41 PM, Xaser said:

• Granular control over monster infighting and projectile/splash damage susceptibility (e.g. you can make barons and knights infight, or make imps immune to cacodemons and barrels, and all sorts of funky combinations)

This is cool, now you can make proper Doom 64 style Lost Souls that A_Explode when spawn blocked without damaging the Pain Elemental or other Lost Souls.

[Alper002]

I've been tinkering with the OPTIONS lump, and noticed that the description for the "monkeys" setting in the specifications is dead wrong.

It implies that it lets monsters jump down like dogs do when "dog_jumping" is on. However, it instead lets monsters use steep stairs, assuming "comp_ledgeblock" is off.

This is, to say the least, a pretty important distinction!

[GoneAway]

https://www.doomworld.com/forum/post/2339262

 

Support is now officially available in woof 🎉

[Krull]

.

Edited September 2, 2023 by Krull

[JXC]

Will there be a demo wad that demonstrates MBF 21 sector and dehacked features?

[TheNoob_Gamer]

Just now, JXC said:

Will there be a demo wad that demonstrates MBF 21 sector and dehacked features?

Well, there already is one, at least in terms of map stuff.

 

[GoneAway]

Xaser is working on a comprehensive demonstration wad right now.

[maxmanium]

I thought of something that may or may not be useful: adding a bit field for generalized sectors that allows\disallows the "leaky radiation suit" random damage effect. If I'm not mistaken it's still limited to 20% damaging floors, and always on for them as well.

[ChopBlock223]

WiII you be taking more feature suggestions some day in the future? I figured I'd write down a bunch of other ideas I had in case you do, most which aren't too complex (in my perception, anyway, implementation and compat may say otherwise).

[Graf Zahl]

As I am currently implementing the standard in GZDoom I'd like to give some feedback.

 

The vast majority of features was no problem, but there's one thing in here that I have to consider a major portability hassle for an open standard and that's the 3 functions for setting and checking the flags (A_JumpIfFlagsSet, A_AddFlags and A_ClearFlags.)

 

Here's a list of problems with this, some are only relevant for ports that changed things under the hood, others are general issues, applying to all ports:

 

* the set and clear functions make no checks for special flags like NOBLOCKMAP and NOSECTOR. Just flipping these will most definitely cause problems with actors not being unlinked/relinked into the proper chains.

* No checks are being done to mask out undefined/non-universal flags. It just performs a binary comparison of the flag words, requiring each port which wants to implement this feature to replicate these words bit by bit. As an example I'd use MF_SLIDE. ZDoom, for example, removed MF_SLIDE long ago as it was not used for anything useful. Another one would be MF_TRANSLUCENT or MF_TRANSLATION. Again, this is not how more advanced ports would handle translucency - it's very limiting and if a port handles this differently, having these flags among the checkable ones may be a major issue for robustness, resulting in undefined behavior of the A_Jump... function.

* The args are only 32 bit so this covers all the Heretic flags in the second flag word but only half of the MBF21 flags that would be of actual interest. It also misses several important high flags in the first flag word.

 

With this in mind, is there still a chance to revise these 3 functions so that they work in a truly portable fashion by only allowing to check a well-defined set of flags that other ports can easily implement without having to compromise their implementation of the underlying features - and by making sure that they can actually access all relevant flags and not miss a significant portion by not allowing to check the higher bits?

 

 

[GoneAway]

Super happy to see this coming to gzdoom! 🙂

 

It's expected that a port will convert the value in dehacked into a value that makes sense internally. For instance, dsda-doom has "flags2" actually covering heretic and the mbf21 stuff, similar to how you mentioned, but the value of the flags2 field in dehacked is based on the mbf21 spec. So, the dehacked file may have "2" meaning SHORTMRANGE, but the dehacked parser converts this to 0x00200000 (MF2_SHORTMRANGE) for dsda-doom when it reads the file. Depending on how a given flag is (or isn't) implemented, some may require different implementations from the basic one present in dsda-doom (e.g., having flags3 internally, or needing to set values instead of flags on / off).

 

Completely agree about specifying the allowed flags for the first argument as well to prevent possible misuse and confusion with these fields.

 

Also agree we need 64 bit to cover the extra mbf flags. I'd say that's an oversight in the spec and not intended. Assuming we limit the flag options based on the ones that make sense, 32 bits is probably still enough for the field in dehacked at least.

 

@Xaser and @MTrop what do you think?

[Graf Zahl]

Ah, ok, I missed the part where the flags are being translated. It was a bit off the path where I was looking. This already clears things up a lot.

Seeing how your checker works, I don't think you can simply go 32 bit, as you want to check the higher bits as well.

 

That just leaves some of the flags in the first word

 

22 minutes ago, kraflab said:

Also agree we need 64 bit to cover the extra mbf flags. I'd say that's an oversight in the spec and not intended. Assuming we limit the flag options based on the ones that make sense, 32 bits is probably still enough for the field in dehacked at least.

 

No idea how you want to handle it. Currently the args array is 'long', which means the size is not consistently defined - it's 32 bit on Windows but 64 bit on Linux. If it's supposed to be 64 bit it needs to be 'long long'. Considering how your code performs the checks you definitely need 64 bit words here to do it right.

 

But the flag functions truncate the value to 32 bit, losing all the upper flags, even if the args were 64 bit so this definitely needs to be fixed.

 

Plus handling MF_NOBLOCKMAP and MF_NOSECTOR properly. AFAIK this can cause crashes if you clear these without unlinking the actor in the process.

 

 

 

[GoneAway]

Thanks for catching that, we must have only tested it out with the lower flags.

[GoneAway]

Okay, I think I finally understand what's going on in d_deh. The correct mapping for the first flag variable is here: https://github.com/kraflab/dsda-doom/blob/master/prboom2/src/d_deh.c#L1875

 

That's 32 bits and is the standard as far as I can tell. It's a mistake in the dsda-doom implementation that the wrong bit translation array is being used for the flag-related code pointers specifically, which can just be patched. Since that's a mistake in the port, the spec itself is correct.

[Graf Zahl]

Got it. Although it was a lot of work to get this supported in GZDoom I think it's complete now.

Just have fun looking at that mass of code once I commit the last part later today - the flag stuff is more than 300 lines of code, not to mention the changes elsewhere... :D

 

 

[Blue Phoenix]

Don't know if this is right place to post, but I think I found a bug in MBF21.  A_JumpIfTargetInSight doesn't seem to check if target is dead or not, the monster will continue firing at the corpse.  I've tried Dsda-Doom and Woof both have same behavior

[GoneAway]

I'm not sure I'd call it a bug so much as an unintended consequence. Maybe there's a workaround for this though? I don't know enough about all the code pointers available, but maybe @Xaser or someone else has an idea :^)

[Xaser]

I can't give much advice without knowing exactly what it is you're trying to do with the codepointer -- it does just what it says on the tin.