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.