Let's talk about mbf+ / a new complevel

[GoneAway]

MBF added a lot of customization of compatibility options but has basically been "frozen" by complevel 11. Some mappers want pieces of boom and mbf but aren't happy with either. There are also some notable bugs that would be nice to fix.

 

I'd like to talk about resolving these topics with a new complevel.

 

Some things I would propose (on top of what is already in mbf):

 

1) Add a lot more comp_* options. These are toggles configurable by the OPTIONS lump in a wad that switch changes between different old complevels on or off. I'd like the new complevel to essentially wrap up all the changes between boom and mbf so you can configure your own "custom complevel" that is demo compatible within the settings, reproducing boom, mbf, something in between, or something beyond ("you" meaning the mapper - the config would be determined by the wad).

 

2) Fix boom generalized crushers (https://github.com/coelckers/prboom-plus/issues/57).

 

3) Fix 3key doors.

 

4) Allow longtics when recording.

 

5) Add a line that is "block non-flying monsters".

 

---

 

The scope here is not unlimited - I wouldn't consider adding the advanced features available in zdoom / eternity, because those ports already exist. This is about continuing the doom / boom / mbf vision of classic / conservative gameplay with more customization and fixes available to mappers.

 

What would you like to see in such a complevel?

 

PS: posting here instead of the source ports forum because I'm more interested in what mappers want. Feel free to move it. cc @fabian

[Snikle]

I do personally love the idea of a "block non-flying monsters" line like you mention. There are a lot of times in maps I'd love to have that. Maybe a "block player and non-flying monsters" line too.

[Alaux]

The concept of configurable toggles sounds pretty attractive to me. While not much related to mapping, could there be a toggle to fix the pesky error with A_CheckReload?

[skillsaw]

All five of the above are great and would help resolve the biggest issues I have with complevel 11. The three-key doors bug and the generalized crushers bug both caused me lots of grief with Valiant. And being able to override the awkward MBF infighting behavior with OPTIONS is also really nice.

 

I'll also add that I'm curious if any further DeHackEd expansion is on the table (I ask because I'm not sure if that discussion falls under "MBF+" compat or something else). If so, I have a long wishlist there, but I'll keep it to myself unless it's within scope for this topic.

[Xaser]

+1 to Skillsaw's post: to sorta expand a bit on the DEH thought, DEHEXTRA is brilliant, but there's a handful of things that it seems like you should be able to do, but can't (e.g. have a monster fire an entirely new projectile) because there's no code pointer for it. I'd like to add a small handful to shore up the biggest gaps in the set.

 

This is actually something I was kinda planning on coding myself at some point and pitching it for inclusion, but hey, as long as we're talking a new small set of features, sounds like a good fit. :P

 

[EDIT] Here's the list of 'pointers I was planning on adding (where function params are dehacked's misc1/misc2 fields):

• A_MonsterProjectile(type, angle) -- Generic monster projectile attack pointer; spawns an actor of type, at angle. Always sets the tracer field on the spawned object to the actor that fired it, so Revenant-style homing missiles with A_Tracer are possible without any extra fudging.
• A_PlayerProjectile(type, angle) -- the above, but for player weapons. If this codepointer is on a state, misc1/misc2 will not set the weapon offset (did some research and this is trivial to do in PR+, and it's by far the most modder-friendly way of adding this in). Will not consume ammo.
• A_MonsterBulletAttack(damage, accuracy) -- Generic monster bullet attack pointer; fires a hitscan at an angle between (-accuracy, accuracy) for damage. Probably would make the damage use Doom's 1d3 calculations for consistency, I suppose.
• A_PlayerBulletAttack(type, accuracy) -- the above, but for player weapons. Same rules as A_PlayerProjectile re: misc1/misc2 and lack of ammo usage.
• A_ConsumeAmmo(type, amount) -- consumes amount units of ammo type (using the same numbers dehacked uses to refer to ammo types). Having this as a separate parameter type is essential to allow for shotgun-type weapons that use multiple attacks, and having the ammo type explicitly defined allows for greater flexibility.

 

There's definitely plenty more useful things that can be added without stretching any of the existing DEH "limits" (2 misc params, etc.), but these are the most important missing items. DEH will never be quite as flexible as EDF, DECORATE, or ZScript, but its current state can be vastly improved and you can get a lot of mileage from the above.

Edited March 21, 2021 by Xaser

[Tarnsman]

I would love all five of those things. Especially the block non-flying monsters.

[printz]

4 hours ago, kraflab said:

5) Add a line that is "block non-flying monsters".

You can already do that in vanilla DOOM by placing a thin pit sector without lower textures and hidden from the automap. Ground monsters will avoid crossing this pit, while flying monsters and players will ignore it, and you won't see it.

[Xaser]

The trouble with the pit approach is that it depends on whether or not a certain compat option is set (comp_dropoff I think)? Without the option set, monsters will not walk across the gap, but player attacks can push the monster over the line (and they'll get stuck :P ). Big benefit of the line is it'd prevent player weapon pushing.

 

Also relevant to DSDA-Doom (though maybe not so much in the context of a complevel discussion :P ) is the Maulotaur from Heretic. They'll happily dash into pits, unless you explicitly use a Block Monster line. Would be nice to have a line type that stops it without also stopping flyers (GZDoom doesn't even seem to have this, as far as I know).

[Deadwing]

Gimme more flexibility in creating new enemies and/or projectiles. Loved Xaser suggestions.

 

Maybe also more flexibility regarding secret exits, episode size, etc? IDK if that would make things too similar with mapinfo, though, probably too much out of scope.

Edited March 21, 2021 by Deadwing

[Xyzzу]

Same, and I second "block players" even more than "block non-flying monsters".

[Altazimuth]

OK I'm going to break things down from an EE-centric point of view (what a shock):

1. OPTIONS is obviously already supported by EE given its lineage. I forget if config is read/saved during MBF demos though. It might be worth looking at EE to see what comp_ options it has already added, as some might be useful here.
2. Sounds good to me. I don't know if Eternity already does this but it should do so if not (as a comp_ setting).
3. Same as 2.
4. Wait are demos not longtics in MBF? Yeah that should be a thing.
5. This is doable but not stepping on existing flags might be troublesome. Eternity already uses the 1024 bit for 3D midtextures, and the 2048 bit is reserved. Anything else should be fair game. For those not aware Ultimate Doom E2M7 has 0xFE00 masked into about 1000 linedefs; the 2048 is checked and if it's set to 1 then all flags higher than the 256 bit are cleared. That means the lowest flag usable for EE is the 4096 bit (and overall leaves 5 usable new bits). I don't know if ZDoom complicates this at all.

 

[ReaperAA]

4 hours ago, kraflab said:

What would you like to see in such a complevel?

 

I am no mapper. But as a player, this thread makes me happy because I really want to see that we finally move past the old-as-heck Boom/MBF standards.

 

What I would like to see in this "MBF+" complevel would be:

• Expanded Dehacked modding features and limitations (pretty much like what Xaser mentioned)
• Bugs from Boom and MBF fixed, especially the bugged infighting (pretty much what Kraflab mentioned)

 

[maxmanium]

I just want to thank you for this post because I was literally mulling over this yesterday -- we're stuck with obnoxious bugs in both complevels 9 and 11.

 

If you didn't say it already, OPTIONS support in PRB+ would be great.

Edited March 21, 2021 by maxmanium

[dew]

49 minutes ago, ReaperAA said:

Bugs from Boom and MBF fixed, especially the bugged infighting (pretty much what Kraflab mentioned)

It is important to understand that this is actually not a bug, but a feature - MBF offers a different way of infighting logic. This is a toggleable setting that is "frozen ON" by complevel 11 becoming the defacto MBF standard. On the other hand, there are many such MBF features that are available but not used, because they're "frozen OFF". cl11 is a hot mess and keeps dragging down MBF mapping, so don't think of this as "MBF+" but more like "actual MBF + fixes", heh.

[Bridgeburner56]

1 hour ago, printz said:

You can already do that in vanilla DOOM by placing a thin pit sector without lower textures and hidden from the automap. Ground monsters will avoid crossing this pit, while flying monsters and players will ignore it, and you won't see it.

This does work relatively well but monsters can get pushed over them when they are it which makes it kinda not viable for things like stopping monsters falling into deep death pits and killing a UV max run (this is the most common time that I feel like this would be a useful feature)

[Spectre01]

All of this sounds great. At the moment, MBF = "play in GZDoom" for me due to infighting changes. -longtics are also nice for more casual recording, FDAs, Ironmans, etc.

[maxmanium]

Wait, question. Are we all deciding on one new complevel standard, or will it be a complevel which is always configurable by the wad author?

 

If it's the latter, I think it'd be pertinent to allow the use of some cool MBF enemy features (like backing away from melee attacks).

[Xaser]

Another quick line special feature gap, while I'm thinking of it:

 

I'd like to see a variant of line special 255 ("Scroll Wall Using Sidedef Offsets") that you can apply to a control linedef w/tag, and it'll scroll all lines that share the tag using the control linedef's offsets (i.e. not the destination linedef offsets).

 

Some details: For structures made of multiple linedefs (e.g. a curvy waterfall), Boom provides no sane way to make all lines scroll in unison at a custom speed (i.e. something quicker than the hardcoded 1- or 3-tic scroll-down linedef specials).  Line special 254 ("Scroll Tagged Wall, Same as Floor/Ceiling") is borderline useless because the special factors in both the source & destination linedef's orientations for determining the rate of scroll -- i.e. if the linedefs aren't parallel, you get unwanted horizontal scrolling, meaning you gotta make a linedef pair for every single line in your waterfall 9_6. Meanwhile, line special 255 requires all the x offsets to be zero, which is misalignment hell. :P

 

Alternatively (or additionally?), a 254 variant that does not factor in the destination linedef's orientation into account could work too. Either-or; I just want to make a damn circular scrolling water fountain without pulling my hair out.

[skillsaw]

Yes, that would be a major improvement as well.

 

The sanest work around I am aware of in the current boom featureset is to make custom textures with the offsets required by your geometry baked in to the art asset, and then scroll them using 255 (scroll using sidedef offsets), but it probably doesn't work easily in all cases (it worked for the transdimensional alien tubes in AA26)... A linedef type would be way, way better.

[printz]

6 hours ago, dew said:

It is important to understand that this is actually not a bug, but a feature - MBF offers a different way of infighting logic. This is a toggleable setting that is "frozen ON" by complevel 11 becoming the defacto MBF standard. 

What?! Does -complevel 11 force that setting to ON in PrBoom, despite it being user-settable in the original MBF? If that is what you're saying, then that's a wrong implementation of complevels. What it should do is enable its user configuration, with just the initial default set to what MBF has when first run. Not always turn that option ON...

[printz]

10 hours ago, Xaser said:

The trouble with the pit approach is that it depends on whether or not a certain compat option is set (comp_dropoff I think)? Without the option set, monsters will not walk across the gap, but player attacks can push the monster over the line (and they'll get stuck :P ). Big benefit of the line is it'd prevent player weapon pushing.

 

Also relevant to DSDA-Doom (though maybe not so much in the context of a complevel discussion :P ) is the Maulotaur from Heretic. They'll happily dash into pits, unless you explicitly use a Block Monster line. Would be nice to have a line type that stops it without also stopping flyers (GZDoom doesn't even seem to have this, as far as I know).

Now that is a real pitfall! ;) 

[Redead-ITA]

I honestly just want the custom hitscan and projectile attacks for dehacked

I am fine if it is extended dehacked only

(Though it could use additional audio lines tbh)

Edited March 22, 2021 by Redead-ITA

[Smite of Disrespect]

15 hours ago, dew said:

MBF offers a different way of infighting logic. This is a toggleable setting that is "frozen ON" by complevel 11

What setting can I toggle in MBF to revert to the original infighting? The only thing that looks related is "Monsters don't give up pursuit of target.'

[Krull]

.

Edited September 2, 2023 by Krull

[ChopBlock223]

Features which I'd enjoy seeing:

 

1. Fixed generalized walkover crusher linedefs, I agree with Skillsaw, and it caused me a lot of confusion, grief, and anger when making my maps for 2048 Units Of /vr/. Advertised features not working makes me very salty, especially when they ought to have been fixed many years ago.
2. Not having to stick to the shitty and not fun infighting behavior that Complevel 11 has.
3. Block non-flying monsters linedef attribute, that sounds like a great and useful idea.
4. Block player linedef attribute.
5. Generic scroll texture up and scroll texture down linedef specials, because scroll by offset is frequently not useful due to the lack of texture alignment, and scrolling by the angle of a dummy linedef is frequently impossible to align in any reasonable manner. Or the useful dummy linedef functions Xaser suggested.
6. Those convenient codepointers for DeHacked which Xaser suggested.
7. Possibly the ability to set a generic 50% transparency on an actor with DeHacked regardless of if the player has the standard method set to Fuzzy or not.
8. Ability to add new sounds for new actors to use (primarily I would want to use this for ambient sounds, but it would be just super useful for general DeHacked use). Don't remember if this is available already or not, just woke up.

I was almost going to suggest some sort of Brightmaps feature, but remembered you can fake that with DeHacked already.

Oh yeah, and I guess if possible to implement support for gamepads and analog stick behavior, because I really enjoy the comfort of mouselook + analog stick. Only if it can be demo compatible though.

Edited March 22, 2021 by ChopBlock223
Idea!

[GoneAway]

11 hours ago, printz said:

What?! Does -complevel 11 force that setting to ON in PrBoom, despite it being user-settable in the original MBF? If that is what you're saying, then that's a wrong implementation of complevels. What it should do is enable its user configuration, with just the initial default set to what MBF has when first run. Not always turn that option ON...

I don't want to derail this into a discussion of pr+ vs mbf, but something important to know is that pr+ isn't mbf compatible at all. I'm not sure why, but there are a variety of changes and cl11 demos will desync in mbf in many cases. I'm guessing the lack of a large set of demos for verifying compatibility at the time could be to blame, but considering the options handling was dropped, it may have just been a decision to not maintain strict compatibility 🤷

[GoneAway]

15 hours ago, maxmanium said:

Wait, question. Are we all deciding on one new complevel standard, or will it be a complevel which is always configurable by the wad author?

 

If it's the latter, I think it'd be pertinent to allow the use of some cool MBF enemy features (like backing away from melee attacks).

This is about having one complevel that supports configuration to a greater extent, so that you have one standard from the sense of demo format / version and options available, but where the wad defines the behavioural subset of what is possible.

[printz]

1 hour ago, kraflab said:

but considering the options handling was dropped

The next person who updates PrBoom+ should seriously think of adding OPTIONS support back, at least for complevel 11 and higher. There was totally no good reason for Proff/CPhipps/etc. omitting it, and there's no downside to supporting it. Its lack totally screws MBF-targeting wads over.

Edited March 22, 2021 by printz

[GoneAway]

8 minutes ago, printz said:

The next person who updates PrBoom+ should seriously think of adding OPTIONS support back, at least for complevel 11 and higher. There was totally no good reason for Proff/CPhipps/etc. omitting it, and there's no downside to supporting it. Its lack totally screws MBF-targeting wads over.

It was added to dsda-doom master a few days ago actually...I wanted to figure that out before making this post :^)

For pr+, I don't know. A wad overriding a user's settings isn't intrinsically good, it does have downsides - just ask the players that want jump always enabled in zdoom. Evidently the pr+ philosophy at the time was to prefer the player over the mapper, whereas mbf had the opposite philosophy. I'm not disagreeing though.

[esselfortium]

OPTIONS would be great to have.

 

Especially if it could mean forcing off the Boom-derived blockmap bug that causes BTSX E2M20 to completely explode in Pr+ when you don't set the right complevel...