Reflections and Aspirations: MBF21 in 2024

[ViolentBeetle]

Something I suggested before for 21 I just remembered. A "synchronized" flag on lines. If true, it would subject all of the identical actions and tags that are also synchronized to the same used state. This would work for curved switches and prevent incessant clicking from an event that is meant to trigger once but through several linedefs.

[Enator18]

11 hours ago, ViolentBeetle said:

Something I suggested before for 21 I just remembered. A "synchronized" flag on lines. If true, it would subject all of the identical actions and tags that are also synchronized to the same used state. This would work for curved switches and prevent incessant clicking from an event that is meant to trigger once but through several linedefs.

YES, THIS. or at least some version of this. Would also be useful for walk over lines that are split up by texture or height changes or are curved.

[Scorcher]

This should probably be fixed.

[Xaser]

Got a MBF21 bug report, but one that might need to go in a new complevel due to demo sync concerns, so here it goes. ;)

 

Using A_AddFlags or A_RemoveFlags to add/remove either the NOBLOCKMAP or NOSECTOR flags is probably hella unsafe right now (i.e. it'll corrupt the blockmap). The proper fix is to check if either of these change, call P_UnsetThingPosition before the change, and call P_SetThingPosition after the change. Taking a quick peek, GZDoom handles this safely, but dsda-doom doesn't (yet). Unless it's done in a far-off land and I missed it. :P

 

In general, it may be worth peeking at how GZDoom handles adding/removing flags and codifying the behavior in the spec; under the hood its get/set functions do various housekeping things, like updating the monster tally if COUNTKILL is adjusted, and so forth.

Edited May 14 by Xaser

[bofu]

Some new movement codepointers I think I can implement:

 

• A_Wander - A_Look combined with a generic movement codepointer
• A_ChaseNoAttack - A_Chase, but doesn't perform attack checks
• A_Flee - move away from target without attempting to attack
• A_Strafe - move randomly, but continue facing them; can perform attack check
• A_TeleportToTag - teleport instantly to the teleporter destination in sector with the specified tag as if having crossed a teleportation linedef

[ViolentBeetle]

Being able to swap a thing into another thing while keeping track of health would be nice. I did it with flags, but checking and jumping on every state is cumbersome. Plus, would be nice to be able to change other stats.

[Doomy__Doom]

9 hours ago, Xaser said:

various housekeping things, like updating the monster tally if COUNTKILL is adjusted

Housekeeping w.r.t. add/remove flags and spawnobject definitely deserves some care.

 

A while ago I've made a -cl21 meme map relying on abusing existing dsda count* inner workings, designed to produce silly end of map screen with arbitrary high %s. Essentially faking IoS-spawn-like behavior - prevent updating map totals but count kill%, combined with looping spawner things:

thing MTF_CHAINGUNNER { -COUNTKILL }
state 408 { CPOS A 0 A_AddFlags(COUNTKILL) }

thing MTF_SHOTGUNGUY { -COUNTKILL }
state 209 { SPOS A 0 A_AddFlags(COUNTKILL) }

thing MTF_ZOMBIEMAN { -COUNTKILL }
state 176 { POSS A 0 A_AddFlags(COUNTKILL) }

thing MTF_EXTRA03 "HumanSpawner" {
	ednum 2503
	-COUNTKILL
	
	clear states
	States{
		Spawn:
			TNT1 A 1
			TNT1 A 0 A_RandomJump(Chain, 64)
			TNT1 A 0 A_RandomJump(Shot, 85)
			TNT1 A 1 A_Explode
			TNT1 A 1 A_SpawnObject(MTF_ZOMBIEMAN)
			goto Wait
		Chain:
			TNT1 A 1 A_Explode
			TNT1 A 1 A_SpawnObject(MTF_CHAINGUNNER)
			goto Wait
		Shot:
			TNT1 A 1 A_Explode
			TNT1 A 1 A_SpawnObject(MTF_SHOTGUNGUY)
			goto Wait
		Wait:
			TNT1 A 1050
			goto Spawn
	}
}

 

Conversely +COUNTITEM items, such as "thing MTF_AMMO_ROCKET_BOX { +COUNTITEM }", spawned by A_SpawnObject do not up item counters without further effort with states, completely inconsistent with spawning +COUNTKILL things.

 

I guess there's an "easy" vs "flexible" solution choice here, i.e. always counting vs splitting into COUNTITEM/UPDATETALLY.

 

[traversd]

12 hours ago, bofu said:

• A_TeleportToTag - teleport instantly to the teleporter destination in sector with the specified tag as if having crossed a teleportation linedef

 

and if there are multiple teleport destinations found, chooses a random one :)

[bofu]

1 hour ago, traversd said:

 

and if there are multiple teleport destinations found, chooses a random one :)

I'd also like that to be an option. Randomized teleporters (or fallback teleporters) based on multiple sectors with the same tag having teleport destinations could either be a new linedef action or new, complevel-gated behavior on the existing ones.

[Enator18]

One thing that would be nice to have is the ability to change the ammotype that the player starts with so that you can have the starting weapon be able to use an ammo type other than bullets

[ViolentBeetle]

Very niche thing I remembered. MBF21 undid the Boom thing where monsters would fall of the ledges, making it so they only do so if they are being pushed by a scroller. However they hit the wall if they try to fly over one more height change, can they retain the flight property until they touch the ground?

I'm pretty sure they don't walk on mid-air so the game should know when their feet aren't on the ground, right?

[bofu]

Here's a list of all the things flags I've been able to implement so far in my local test environment. I'm probably going to be focusing on Dehacked stuff exclusively, since that's the code I'm most familiar with:

• NODAMAGE: Thing doesn't lose health when taking damage.
• ANTITELEFRAG: If another thing would telefrag this thing, that thing gets killed instead.
• PUSHABLE: Thing can be pushed by other things.
• CANNOTPUSH: Thing cannot push pushable things.
• NOTAUTOAIMED: Thing is ignored entirely by player autoaim.
• UNSTOPPABLE: Charging monster doesn't stop when receiving damage.
• KEEPCHARGETARGET: Charging monster resumes pursuing its target after charge sequence ends.
• ONLYSLAMSOLID: Charging monster doesn't stop when it hits a non-solid thing.
• NOBFGSPRAY: A_BFGSpray and the eventual custom spray attack codepointer don't hit this thing even if it's shootable.
• NOCRUSH: Thing doesn't turn into gibs if its corpse would get crushed; if an item that's been dropped by a dead monster, it doesn't get destroyed (so that you can have monsters safely drop keys if the keys have this flag added, for instance).
• NEVERRESPAWN: This thing doesn't respawn when killed in Nightmare mode or when -respawn is used.
• FLOATBOB: Thing floats like Hexen powerups; currently broken on flying monsters, however.
• DEADFLOAT: Thing does not fall when it's destroyed.
• NOINFIGHTING: Thing never infights with other monsters.
• NOPAIN: Thing doesn't ever call its pain state. (The difference between this and not simply giving the thing a pain state is that you can alter this on runtime, such as turning off the pain state right before a lengthy attack animation.
• Four generic flags for logic checks. GENERIC1, GENERIC2, GENERIC3, GENERIC4

I've also implemented four counters on things (default to 0) that can be modified and altered in real time, and there's also a RESETONDEATH flag that optionally makes counters reset when A_Fall is called.

Edited May 27 by bofu

[Scorcher]

Speaking of flags, I'd love to have FLOATBOB (Thing bobs up and down slightly on the Z Axis) from Heretic/Eternity Engine, and maybe also DEADFLOAT (NOGRAVITY is not removed when a non-projectile thing dies, like the Lost Soul)

 

EDIT: I'll also suggest the extended A_PlaySound codepointer that lets you define the volume of the sound played.

Edited May 26 by Scorcher

[bofu]

2 hours ago, Scorcher said:

Speaking of flags, I'd love to have FLOATBOB (Thing bobs up and down slightly on the Z Axis) from Heretic/Eternity Engine, and maybe also DEADFLOAT (NOGRAVITY is not removed when a non-projectile thing dies, like the Lost Soul)

 

EDIT: I'll also suggest the extended A_PlaySound codepointer that lets you define the volume of the sound played.

It's pretty easy to move existing Heretic/Hexen flags over, so I'll give those first two a shot tonight.

EDIT: Even though DEADFLOAT didn't technically exist, it was actually really easy to implement just by adding a conditional into the P_KillMobj code. FLOATBOB also appears to work now that I've added it, but the Hexen implementation screws with monsters, so I'll need to look more into it.

Edited May 26 by bofu

[Scorcher]

On 5/19/2024 at 1:45 AM, Enator18 said:

One thing that would be nice to have is the ability to change the ammotype that the player starts with so that you can have the starting weapon be able to use an ammo type other than bullets 

Pretty sure that's always been possible even with Vanilla DeHackEd. :)

EDIT: Nevermind...

Edited May 26 by Scorcher

[Enator18]

Just now, Scorcher said:

Pretty sure that's always been possible even with Vanilla DeHackEd. :)

You can change the ammo amount but not the type I think. Unless I'm really dumb and you can, but I can't find a way to

[Scorcher]

2 hours ago, bofu said:

EDIT: Even though DEADFLOAT didn't technically exist, it was actually really easy to implement just by adding a conditional into the P_KillMobj code. FLOATBOB also appears to work now that I've added it, but the Hexen implementation screws with monsters, so I'll need to look more into it.

Interesting, good luck with the investigation. :)

47 minutes ago, Enator18 said:

You can change the ammo amount but not the type I think. Unless I'm really dumb and you can, but I can't find a way to

This Community Project replaces the pistol with a shotgun type weapon that uses shells, so I assume It's at least possible in MBF21. Maybe I was wrong about vanilla though...

EDIT: Nevermind...

Edited May 26 by Scorcher

[Enator18]

4 minutes ago, Scorcher said:

This Community Project replaces the pistol with a shotgun type weapon that uses shells, so I assume It's at least possible in MBF21. Maybe I was wrong about vanilla though...

Yes it replaces the ammo that the slot 2 weapon uses, but it isn't able to replace the ammotype that the player starts with so instead they chose to set the starting bullet amount to 0 and just place shells towards the start of the map.

[Scorcher]

19 minutes ago, Enator18 said:

Yes it replaces the ammo that the slot 2 weapon uses, but it isn't able to replace the ammotype that the player starts with so instead they chose to set the starting bullet amount to 0 and just place shells towards the start of the map.

I see, forget everything I said then, +1 to customizable starting ammo!

Edited May 26 by Scorcher

[bofu]

1 hour ago, Scorcher said:

Interesting, good luck with the investigation. :)

 

It looks like the Hexen version was never intended to work with monsters - an interesting thing happens when it's applied to them in that the monster's health will constantly fluctuate back and forth. I was able to work around this, but the issue comes with the fact that monsters can have variable Z positions compared to the floor, particularly if they're non-floating monsters. I'll need to look into how GZDoom handles it, but I suspect it'd be a pretty complicated effort to translate it over.

[bofu]

Given that I've been able to successfully jam so much Dehacked stuff into my  MBF24 test build (fork of DSDA-doom, Woof fork to follow) that it basically justifies a new complevel on its own, I think what remains is to actually organize every proposed change into a community list along with rankings for how useful they would be, how difficult or risky the changes would be to implement, etc.

 

I'm familiar enough with the actor and Dehacked code that I feel comfortable working with it and making contributions there, but there are also things like new line specials, comp settings, and MBF21 bug fixes that are best left to those more qualified.

 

I'd be happy to share what work I've done with the greater community for collaboration, testing, and refinement, but we should really figure out who can contribute and what the scope will ultimately be in a more organized sized medium.

[Blast_Brothers]

I'd be happy to turn this thread into a Google doc/spreadsheet, if people think that would be useful.

[ByRntStarOEI]

This suggestion basically comes from a response to a post I had with some questions about UMAPINFO.

 

The general idea from a reply:  "The ability to skip intertext and go straight to endcast/endpic after an endgame exit"

 

That also got me thinking of another idea that may be a useful option for some: Death Exit- the player is sent to this map upon death (can be different for each map if desired) Could also even have a death intertext, as well.

Of course this one may not be possible due to Doom's inner workings.

 

 

Edited May 29 by ByRntStarOEI
Grammar

[Edward850]

25 minutes ago, ByRntStarOEI said:

That also got me thinking of another idea that may be useful for some to use in their wads: Death Exit- the player is sent to this map upon death (can be different for each map if desired) Could also even have a death intertext, as well.

Of course this idea may not be possible due to Doom's inner workings.

I'd say that's more or less not in the template. The rules for death are very non-specific as dead players can trigger normal exits and multiplayer, well, exists. Plus we as a community have so many different kinds of multiplayer modes as well. Throw voodoo dolls into the mix and you have something that's ripe for a lot of undefined behavior that we couldn't make a complete ruleset for even if we tried.

 

Also I could imagine it just being annoying as well for speedrunners and challenge runs, as it blocks efficient restarting of a level.

Edited May 29 by Edward850

[bofu]

I was able to do the following:

• Add comp_nohorizontalautoaim, a comp setting to disable horizontal autoaim. Has no effect in complevels other than 24 (it could probably be safely added to 21 without breaking anything - just needs to be set to "off" by default).
  • Even though player projectile horizontal autoaim is disabled with this comp setting (which I turned on by default for complevel 24, though it can be overridden), when it would kick in, the vertical component of it still does. This allows you to lead enemies that are higher or lower than you with projectile weapons much more reliably.
• Fix the bug where the SSG disappears after firing the last shot sometimes. Probably will need to be turned into a compatibility setting, but this one I think should be available for use in MBF21 since the code is already there; it just isn't available.
• Test MBF21 demo playback against current DSDA-Doom and Woof and eliminate desyncs.
• Implement and test MBF24 demo recording and playback.
• Ensure that all new functionality is gated behind appropriate conditionals pertaining to complevel.

[Gez]

On lundi 27 mai 2024 at 12:37 AM, bofu said:

 

It looks like the Hexen version was never intended to work with monsters - an interesting thing happens when it's applied to them in that the monster's health will constantly fluctuate back and forth. I was able to work around this, but the issue comes with the fact that monsters can have variable Z positions compared to the floor, particularly if they're non-floating monsters. I'll need to look into how GZDoom handles it, but I suspect it'd be a pretty complicated effort to translate it over.

IIRC, it's a separate vertical offset variable that is used purely for rendering -- the actor's physical coordinates for collision/picking up purposes are not changed by floatbobbing.

[bofu]

Comp settings that I've been able to add (haven't made them configurable in MBF21 yet, though if they become accessible, they will default to whatever the MBF21 behavior was:

• comp_nohorizontalautoaim: This one was requested by a lot of people. It removes any horizontal aim adjustment from the autoaim of player-fired projectiles, but if a Thing would have been targeted by horizontal autoaim and would've adjusted the vertical aim, the vertical aim will still be adjusted. This will allow for leading shots for enemies at a height different from the player.
• comp_ssgautoswitch: Fixes a bug in MBF21 where, upon firing the last shells from the SSG, there was a possibility that it would lower and no weapon would raise to take its place.

The reason I made these into comp settings is because I think MBF21 could benefit from them being turned on in the future as a user-enabled option (not for demos unless the WAD specifies it in the OPTIONS lump, obviously).

 

I'm able to confirm that the addition of these options, and their consumption, has not impacted MBF21 demos.

Edited May 30 by bofu

[Peccatum Mihzamiz]

I'm looking to have a way to give a player, monster or object a horizontal shove without damaging them. Would be great being able to make a custom device (weapon slot) that moves the player directly forward when suspended in mid air via peccaportal. And to be able to adjust that from directly forward to another direction would be a nice bonus. Also for the mapper to be able to code that thrust so it is adjustable to a project's taste would be great.

 

Napsalm and I looked into mbf21 being able to do this and got far, but it all involved things like explosives going off in front of the player etc.. I would like to be able to be flying with peccaportals and then get a push in mid air to another direction. I might link it to ammo for this feature being scarse etc.: forcing the player to not miss their direction or having to do it over.

[Enator18]

On 6/1/2024 at 5:44 PM, Peccatum Mihzamiz said:

I'm looking to have a way to give a player, monster or object a horizontal shove without damaging them. Would be great being able to make a custom device (weapon slot) that moves the player directly forward when suspended in mid air via peccaportal. And to be able to adjust that from directly forward to another direction would be a nice bonus. Also for the mapper to be able to code that thrust so it is adjustable to a project's taste would be great.

 

Napsalm and I looked into mbf21 being able to do this and got far, but it all involved things like explosives going off in front of the player etc.. I would like to be able to be flying with peccaportals and then get a push in mid air to another direction. I might link it to ammo for this feature being scarse etc.: forcing the player to not miss their direction or having to do it over.

 

Someone else suggested adding an A_Thrust codepointer that applies velocity to something. I think they were suggesting it for enemies but it could be added for weapons as well I guess. Could also be useful if you wanted to make a weapon that has kickback or something.

[Xaser]

Another sorta-related thing: in addition to a "set velocity" / "add velocity" sort of special, it'd also be nice to have new versions of MBF's A_Turn and A_Face that also modify the actor's velocity -- right now you can't do something like call A_SkullAttack and then use A_Turn to make the charge inaccurate, since it only rotates the actor and doesn't update the velocity vector at all.

 

[A_Turn and A_Face also suck in other ways: they don't work with negative numbers or units smaller than 1 degree. May as well fix those while in the neighborhood too. :P]