Reflections and Aspirations: MBF21 in 2024

I have requested a feature to launch projectiles from projectiles before. Another functionality I'd like is to spawn projectile from projectile using its direction as reference and nobody in particular. It kinda works horizontally, but not vertically.

Another thing - a flag specifically set to remove a thing on nomonsters mode, even if it is not counted for kills. Useful if you set up turrets or something else not meant to be killed. Perhaps opposite would also be useful for keens and the like.

What if introduce classes for weapons and ban the use and carrying of more than two weapons of the same class? This could solve the psychological paradox of the shopping cart whith weapons and make the gameplay similar to ROTT (where heavy weapons cannot be carried and used together).

It was also similar to Halo. For single player it's not that fun, but for multiplayer it's very good.

1 hour ago, camper said:

What if introduce classes for weapons and ban the use and carrying of more than two weapons of the same class? This could solve the psychological paradox of the shopping cart whith weapons and make the gameplay similar to ROTT (where heavy weapons cannot be carried and used together).

It was also similar to Halo. For single player it's not that fun, but for multiplayer it's very good.

That sounds pretty far off scope.

Extra argument to A_SeekTracer, a thing to spawn if there IS a tracer.

To have custom revenant smoke.

I don't think I wrote this in my first post, but I would REALLY love if it was possible to make weapons check for if you have Berserk, and that way you can make a completely custom attack and puff for using fists with Berserk. Hell, maybe even extend that to all weapons, so they all have a different behavior when you have Berserk.

10 hours ago, ChopBlock223 said:

I don't think I wrote this in my first post, but I would REALLY love if it was possible to make weapons check for if you have Berserk, and that way you can make a completely custom attack and puff for using fists with Berserk. Hell, maybe even extend that to all weapons, so they all have a different behavior when you have Berserk.

If custom item support is added, then this functionality could also be added to them, that way you could make a fully functioning Unmaker with demon keys, or nuDOOM style weapon mods.

Absolutely yes please. +1

Was thinking about declaring new pickups. Right now, the code for checking if an item is a pickup hard codes which items are pickups and which aren't; there would need to be a few things added to accommodate defining new pickup things.

• We need a way to define, in a DEHACKED patch, which things are pickups. (There was a suggestion earlier to go off of the sprite, but that is inadvisable.)
  • We also need to define what happens when a thing gets picked up.
    • Ammo type(s) and amount(s)
      • Does this get doubled on ITYTD/Nightmare?
    • Armor type and amount
      • Allow boosting over max?
    • Health amount
      • Allow boosting over max?
    • Powerup type(s) and duration(s)
      • This will be hard enough assuming we don't try to add custom powerup parameters, which will be tricky since a lot of the powerup handling is written directly in code
    • Pickup message alias (we would also need to allow defining completely new strings in DEHACKED/LANGUAGE lumps, if not already present)

Here's a sample format I came up with, though I will fully admit that I lack the ability to implement such a thing myself:

[NEWPICKUPS]

Pickup 0 (Atomic Health)
Thing type = 1401
Health amount = 50 // gives 50 health
Pickup string = GOTATOMIC
Bits = BONUSHEALTH // allows health to exceed maximum

Pickup 1 (Ammo Crate)
Thing type = 1402
Ammo 0 amount = 50 // gives 50 bullets
Ammo 1 amount = 20 // gives 20 shells
Pickup string = GOTCRATE
Bits = ALLOWDOUBLE+SAVEAMMO // gives double ammunition in ITYTD/Nightmare!; also will not be picked up if either ammunition type is at max value

Pickup 2 (Armor Repair Kit)
Thing type = 1403
Armor type = 0 // 0 = current, 1 = green, 2 = blue; perhaps additional armor types can even be defined later
Armor amount = 10 // gives 10 of whatever the player's current armor type is
Pickup string = GOTREPAIR
Bits = BONUSARMOR // allows armor to exceed maximum

Pickup 3 (Combat Stimulant)
Thing type = 1404
Berserk duration = 1050 // duration in tics
Health amount = 10 // will only heal up to health maximum due to BONUSHEALTH not being set in Bits
Pickup string = GOTCSTIM
Bits = ADDDURATION // if player already has any powerup given by this pickup (in this case, berserk), increase the value of its duration instead of replacing it

Then, there would need to be code telling the engine that if it encounters a thing with MF_SPECIAL that isn't an expected object, it may need to be looked up here. (Perhaps it would be better to store it by thing type as the primary counter, or even add it to the thing defintiion itself instead? That's already getting pretty bloated)

--

In other news, I've added a few of the recommendations that have been made here to my little test implementation. In particular, A_JumpIfTargetFlagsSet / A_JumpIfTracerFlagsSet, A_JumpIfHasTarget / A_JumpIfHasTracer, and A_JumpIfBlocked have been added.

Proposal for another flag: some sort of flag to allow a thing to trigger W1/WR linedefs that are otherwise player-only.

Use case: particularly in non-UDMF maps, having a reliable way of moving a "voodoo doll"-type actor across linedefs to activate advanced effects without the hassle of having to worry about multiplayer starts, Deathmatch gamemodes, potential interactions with player health, or even really just having to remember which Player 1 start you placed last in the map would be great. This would allow for easier conveyor belt scripting setups as well as making sure that all those fancy lighting effects work in multiplayer if Player 1 drops or something.

I'm not sure where the code would need to go for this, but I assume that (at least in the DSDA codebase, which is what I've been sloppily using as a workspace) P_CrossSpecialLine/P_CrossCompatibleSpecialLine is where the relevant code would go, but I'm not sure what the other touch points would be.

Sorry to keep bumping up the thread, but I'm pretty excited about what I've managed to accomplish over at a branch of my experimental build that I'm doing some testing with: Thing Use States.

Things can have a use frame defined in the Dehacked patch, just like you can define pain states or shooting states or death states. When the player presses use, so long as the complevel supports MBF24, the player's use press will now also check for things in addition to linedef specials.

• In order for a thing to be "usable," it must meet the following conditions:
  • have a "Use frame" defined in its DEHACKED block
  • its current frame must have the new ALLOWUSE flag
  • must be within line-of-sight of the thing that used it (which means no using things that are on very high or very low heights compared to the player, or behind thin walls - at least, as long as REJECT does its job)
• If a thing is not in a "usable" condition for one reason or another, it is ignored, and the use press passes through it as if it weren't there.
• The use intercept check will hit the first qualifying linedef or thing it hits based on distance from the source, so you won't accidentally press a switch behind a thing or activate a thing behind a switch.

This can be used for all sorts of things in isolation or with some of the other features I've already managed to add:

• Sprite-based switches, which you can make repeatable or single use by creating a DEHACKED entity and even have a custom switch sound. Using the thing counters I created, you can even have a sprite-based switch that performs different actions based on how many times it's been pressed.
• Ammo crates that spawn randomized ammo or supplies when used, or searching dead marines for ammo pickups and other supplies.
• Allow the player to interact with stationary objects or even unaware enemies, like having ALLOWUSE set on a monster's Idle frames so that you can have a crude sort of coup de grace against unaware enemies.
• Defusable bombs or timed traps you can activate.
• By using flags or counters and checks on zero-tic frames, you can even have toggleable switches for things like lamps that turn on and off.

I'm really excited about this in particular, and I got some help with troubleshooting and testing.

(Why a Frame flag when GZDoom doesn't have an equivalent StateOption in ZScript? Put simply, this approach is both more flexible/configurable and has fewer touchpoints. That being said, I'm still considering adding the USESPECIAL flag from GZDoom to be an additional qualifier, though it seems redundant given the requirements already in place, and an eventual GZDoom implementation could simply check for the presence of a Use frame to see if a Dehacked object should have USESPECIAL or not.)

6 hours ago, bofu said:

Defusable bombs or timed traps you can activate.

Will this be possible to use in multiplayer?

4 hours ago, camper said:

Will this be possible to use in multiplayer?

It should be, as long as the port supports it. The only thing is that in order to get frags to count toward the right player, I may have to add additional flags like maybe a “TARGETUSE” flag to set the thing’s target to the player who last put it in its use state. Otherwise, there wouldn’t be anything to tell the game which player made it explode or whatever.

In other news, I also was particularly productive last night in implementing the following:

• ZDoom-style floatbobbing with the FLOATBOB MBF24 Bit (where the bob effect is done in the renderer rather than the thing’s actual Z position). The Hexen approach is still doable if you’re in Hexen game mode, but this approach works much better with flying enemies.
• Projectiles that hug the floor with FLOORHUGGER and can climb ledges with STEPMISSILE.

Another request I'd like to make is "Lower to 8 above highest floor" as a generalized acrtion argument under target for the Floor category action. I can work around that using dummy sectors, of course, but this is a much better oprion than "lower to lowest floor", which looks kidna weird. I like to always have different flats on different heights. Im sure this area could use more arguments too, though I'm not sure which ones. I'd argue that at least a 64 pixels (relative) would be good, for raising floors to a height where doomguy can't reach, to put a key, weapon or item just out of reach. 

56 minutes ago, DoomGappy said:

Another request I'd like to make is "Lower to 8 above highest floor" as a generalized acrtion argument under target for the Floor category action. I can work around that using dummy sectors, of course, but this is a much better oprion than "lower to lowest floor", which looks kidna weird. I like to always have different flats on different heights. Im sure this area could use more arguments too, though I'm not sure which ones. I'd argue that at least a 64 pixels (relative) would be good, for raising floors to a height where doomguy can't reach, to put a key, weapon or item just out of reach. 

Wow, this ended up being really easy to add (and I agreed with your reasoning). I think having more customizable versions is the reason why UDMF is a thing, but these are definitely options I've wanted as well.

EDIT: Okay, not as easy as thought without also breaking some of the later Boom generalized linedef specials. I can see now why UDMF is seen as the path forward for additional parameterization. As it turns out, each of these trigger/speed/model/etc. options add up to a single number that is then broken down bitwise, but the issue is that you can't add things to the Target enum list (which uses 2^7 = 128 as its interval and goes up to 896) without overflowing into the Change enum list (which uses 2^10 = 1024 as its interval). The next option in the Target list would get parsed as the second option in the Change list as a result (because 896+128 = 1024).

40 minutes ago, bofu said:

 

Wow, this ended up being really easy to add (and I agreed with your reasoning). I think having more customizable versions is the reason why UDMF is a thing, but these are definitely options I've wanted as well.

 

EDIT: Okay, not as easy as thought without also breaking some of the later Boom generalized linedef specials. I can see now why UDMF is seen as the path forward for additional parameterization. As it turns out, each of these trigger/speed/model/etc. options add up to a single number that is then broken down bitwise, but the issue is that you can't add things to the Target enum list (which uses 2^7 = 128 as its interval and goes up to 896) without overflowing into the Change enum list (which uses 2^10 = 1024 as its interval). The next option in the Target list would get parsed as the second option in the Change list as a result (because 896+128 = 1024).

I really don't understand what you're talking about, because I'm just an end user with ideas. I admire what you're doing on your fork with the testing of new features people have suggested here. I hope it gets noticed.

22 hours ago, DoomGappy said:

your fork

Is this Doom Retro?

18 minutes ago, camper said:

Is this Doom Retro?

No, Bofu is working on a fork of DSDA-Doom by himself, I think.

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

Can we have a something to jump if target is closer AND in sight?

I wanted a monster that accelerates if monster is far away or out of sight, and chaining the two checks led to some odd coding.

On mercredi 24 juillet 2024 at 2:39 AM, bofu said:

Proposal for another flag: some sort of flag to allow a thing to trigger W1/WR linedefs that are otherwise player-only.

Aren't Boom generalized lines sufficient for that purpose?

4 hours ago, Gez said:

Aren't Boom generalized lines sufficient for that purpose?

Those only exist for doors and lifts IIRC. (Monster-activated bit that is)

On the subject of "8 units above", could there be 2 more bits: normal vs 8 units off; above or below. Or just 1 bit that sets 8 units short? Or are we hitting some kind of variable length? Boom arguments would just read 00, which would translate to "0 units off, above" (Obviously above/below would be meaningless with no offset, but so does "model")

Additionally, would it be possible to have lift that changes texture while at rest at the bottom? To fully submerge it in liquid. Lifts do remember where they must return, can they remember what texture they were?

Dunno of other place to ask for this, since it's probably a UMAPINFO thing and that is not exactly the point of the thread, but I think mappers should be able to enforce that a mapset be played from a pistol start, just like they can enforce no jumping and no freelook. That would be a great tool to have. 

Another small thing, but there is not exactly a distinction between lifts, the regular Doom kind (I), and elevators which were introduced with boom and raise both the floor and the ceiling (II). Would it be possible to do that in the future, as well as have generalized elevator type linedefs?

(I)

(II)

A thing I keep forgetting - a new argument DrawRadius could be useful.

Doom renderer culls sprites based on thing radius which is a usually not a problem, but "top-heavy" obstacles like palm trees and giant mushrooms would normally have collision match the trunk and not the crown, meaning they will sometimes pop in and out of frame.

If DrawRadius is zero, as default, the game should use regular radius.

25 minutes ago, ViolentBeetle said:

Doom renderer culls sprites based on thing radius which is a usually not a problem,

Point of clarification, that's actually not what it does and thus presents a big problem making this a MBF spec; the renderer doesn't see the object at all and thus has no idea to draw it. Objects are collected to draw by the seg processing step. If a sector isn't visible, there's no sprites knowable to even add, and thus nothing to sort either.

You'd need to be adding a whole new sprite collection method to the engine at large. Doable, but highly inappropriate for a portable modding spec. And of course this is all renderer dependent as well which makes things even more messy.

Gonna call that "implementation defined". I have big issues with it in Rum and Raisin since the threaded renderer works by narrowing the BSP traversal at screen space before rendering, and have a method to sort objects by the width of their sprite in to sectors since the renderer otherwise only cares about the actual position of an object and cares not for its radius at all. The method isn't cheap at the moment, since it requires collecting all sectors a mobj overlaps if it moves in the tick phase. It was, however, the path of least resistance. I plan on iterating on this in the future.

tl;dr - trying to add this to a map editing specification when it is quite literally a renderer problem will not bode well.

Ok, guess I was wrong to think the engine does this.

1 hour ago, ViolentBeetle said:

A thing I keep forgetting - a new argument DrawRadius could be useful.

 

Doom renderer culls sprites based on thing radius which is a usually not a problem, but "top-heavy" obstacles like palm trees and giant mushrooms would normally have collision match the trunk and not the crown, meaning they will sometimes pop in and out of frame. 

 

If DrawRadius is zero, as default, the game should use regular radius.

This may be subsector rendering issue the original game had. Things were only set to a subsector based on their x,y coordinates. If you have a large sprite behind something and the BSP traversal doesn't hit that subsector then the sprite wouldn't be rendered at all, even if part of it would be in the players view. I believe this was fixed in Boom by rendering all sprites from a subsectors sector instead.

Gonna have to quote myself again here:

On 7/1/2024 at 3:59 AM, Xaser said:

As a related note, this is a brainstorming thread -- it's intended to catch anything and everything that might be relevant to a new standard/complevel/common-port-feature/etc. Don't discourage users from posting in here for fears of being "off topic" -- that's how good ideas get lost.

The point of this thread is not to tell people their feature suggestions don't work*, especially if the reasoning requires intimate knowledge of some facet of the game most modders won't have (e.g. the inner workings of Doom's renderer, in this case). Everything mentioned here will be properly evaluated for cross-port viability before being considered for a spec, and this sort of thing will be caught then -- but this thread isn't the time or place.

[*unless they're repeatedly being wildly off-topic/derailing. Spam is spam, but this ain't. :P]

1 hour ago, hobomaster22 said:

I believe this was fixed in Boom by rendering all sprites from a subsectors sector instead.

Nah, that's how Vanilla works. It's the problem I inherited. I build up a separate overlap list for each sector on worker threads now, but it's still not a complete solution. It works pretty much perfectly for a single-threaded software renderer. There are times when a thread should render a sprite though, but it'll never ever get the correct clipping information for it because that thread will never visit the relevant part of the BSP. I'm not stressing too hard about it right now, gonna let my brain slow burn on a solution.