Reflections and Aspirations: MBF21 in 2024

[Xyzzу]

Something from a while back I just remembered, could this be addressed?

Quote

A possible change for this future complevel: TIL the MonsterProjectile codepointer doesn't properly autoaim vertically at a target when the vertical offset of the projectiles spawning is large enough. It seems the offset takes effect *after* the angle needed to hit the target is calculated, leading to situations where a tall object for example is shooting downwards at something below (or at the same sector floor height even), but is consistently missing because the projectiles are spawned too high up.

Demonstration video for reference:

Spoiler

 

 

Edited February 6 by Χyzzy

[ViolentBeetle]

22 hours ago, Χyzzy said:

Something from a while back I just remembered, could this be addressed?

It doesn't change angle at all, which is useful if you want to spawn like a wall of projectiles. You can correct angle with custom seektracer, though I did add a request to add another argument to have it recalucate angle.

 

As an addition to my wishlist: decouple thing's ability to get hit from targeting by autoaim. Also make it possible to a thing to feel pain without dying. And maybe a possibly for thing to get hit without stopping the projectile/hitscan, sort of like backwards ripper.

Both would be useful to create destructible (like a trash can that falls apart when hit) and disruptable (Like a hologram that gets distorted when hit) ambient objects. Right now I'd like to make some ambient objects that die when hit, but I don't want them to catch autoaim, so I don't.

[Gez]

8 hours ago, ViolentBeetle said:

As an addition to my wishlist: decouple thing's ability to get hit from targeting by autoaim.

As a sidenote, the explosive fungal pods in Heretic have just that; they're not autoaimed.

[Peccatum Mihzamiz]

Thanks for all the hard work! Weird idea perhaps but hear me out: a way to make a custom weapon that propels the player forward (or in another direction which can be specified in the 'code') without the player taking damage. Using the Mikoportal flying combat I have used in several maps, the player would be able to change directions in midair in situations where they would normally not have air control. Attaching it to a weapon makes it a fun gimmick that can be explored with things like ammo scarcity, necessitating the player going through a platforming puzzle with precision/careful thought.

I'm envisioning you could make an entire wad centered around jumps and Mikoportal flying that use a weapon like this. Jumpwad but different. The fire extinguisher scene from the movie Gravity, who knows? (I'm making a post in the Edit section of Doomworld tomorrow about this Mikoportal flying I keep talkin about. Here's a video that showcases an early test of mine of it)

[ViolentBeetle]

A few more ideas:

• Make health and ammo a valid argument to what ammo does player's gun accept
• A_Become, to turn a thing into another thing. Mostly swapping its state pointers, but with extra arguments can inherit flags and maybe reset health. Useful mainly for multi-stage enemies
• New flag for linedef - "Silent", making sectors not make sound when moved by it (When applicable)

[RjY]

I think a new compatibility level is the right time to migrate to blockmap-based line-of-sight.

Presumably one of the reasons UDMF support was introduced is for the likes of Insane_Gazebo, Bemused, et. al. to be able to make high-detail slaughter maps of such complexity as to exceed the sidedef or even linedef limits. But maps with tens of thousands of monsters and sectors are precisely those which still need reject tables to run performantly due to the inefficiencies of using the BSP tree to check line-of-sight.

Building reject tables for very large, complex maps is increasingly a problem. While workarounds were found for most of Bemused's work, the same tricks failed for the later maps in Sunder. Only one, map15, has a nontrivial reject table -- which unfortunately was not even built with publically available tooling, but with some arcane process known only to Ribbiks. The state of the art has improved a little since 2018-9, with ZokumBSP -- TTBOMK, the only remaining maintained reject builder -- now able to build Sunder's reject tables, but with its lack of UDMF support (and Zokum's primary focus being vanilla Doom) it seems prudent to look for another approach.

That approach is of course to change the line-of-sight algorithm to one that is far more performant. Having P_CheckSight use the blockmap instead of the BSP tree sidesteps the problem, to the tune of a fivefold improvement in one case I measured. ZDoom has of course been doing this for years, allowing ZDBSP to ignore the problem entirely and even fully omit the reject table from wads it builds instead of filling them with huge blocks of zeroes by default. Moreover, I recall entryway mentioning how much faster the Heretic algorithm was in comparison when he added it for v1.2 demo compatibility. In my own experiments, I observed a reduction from 7.87 to 1.39 seconds, that is an increase from 23.6 to 134 fps, in running 186 tics of -nosound -nodraw -timedemo standing still at the start of Cosmogenesis map05 (obviously first having zeroed out its existing reject table :) ).

Just remember that you would need to fix the corner bug.

[bofu]

On 2/7/2024 at 4:14 PM, ViolentBeetle said:

It doesn't change angle at all, which is useful if you want to spawn like a wall of projectiles. You can correct angle with custom seektracer, though I did add a request to add another argument to have it recalucate angle.

 

As an addition to my wishlist: decouple thing's ability to get hit from targeting by autoaim. Also make it possible to a thing to feel pain without dying. And maybe a possibly for thing to get hit without stopping the projectile/hitscan, sort of like backwards ripper.

Both would be useful to create destructible (like a trash can that falls apart when hit) and disruptable (Like a hologram that gets distorted when hit) ambient objects. Right now I'd like to make some ambient objects that die when hit, but I don't want them to catch autoaim, so I don't.

 

I worked around this somewhat in Dominus Diabolicus by giving the descructible props the FRIENDLY flag, which causes Autoaim to deprioritize them.

 

In other news, I think one thing that would be wonderful to have, and is long overdue in non-3DGE and GZDoom source ports, is the ability to edit the cast call at the end of Doom 2 to reflect new monsters and the like.

[Rykzeon]

- Add portal because I hate make exact replicas of certain rooms just to make fake RoRs.
- Add actual "Block Projectile but allow Hitscan" linedef, because sometimes I don't wanna relying on Self-Referencing Sector to do it

[DoomGappy]

5 minutes ago, Rykz said:

- Add portal because I hate make exact replicas of certain rooms just to make fake RoRs.
- Add actual "Block Projectile but allow Hitscan" linedef, because sometimes I don't wanna relying on Self-Referencing Sector to do it

You made me think about a "vision blocking line" sort of thing, like there are sound blocking lines. Would be another to make see through objects without having to need to make walls and stuff. 

[Doomy__Doom]

The above post about reject/LOS prodded my brain a bit - a new complevel is also a good time to consider maybe finally introducing blockmap bug fix to the demo-compatible world.

 

Yes, some speedruns occasionally rely on that behavior, but that's hardly a compelling reason to keep it in every complevel ever. It's not like people will stop making vanilla and boom maps.

[Rykzeon]

33 minutes ago, DoomGappy said:

You made me think about a "vision blocking line" sort of thing, like there are sound blocking lines. Would be another to make see through objects without having to need to make walls and stuff. 

You can use REJECT table to achieve it. Now, my brain crossed with "Block Hitscan & Projectiles" and "Block Monster Vision" linedef flag besides "Block Projectiles only" flag (see video in spoiler tag). Could be make life easier when making unbreakable windows.

Spoiler

 

 

 

 

28 minutes ago, Doomy__Doom said:

The above post about reject/LOS prodded my brain a bit - a new complevel is also a good time to consider maybe finally introducing blockmap bug fix to the demo-compatible world.

 

Yes, some speedruns occasionally rely on that behavior, but that's hardly a compelling reason to keep it in every complevel ever. It's not like people will stop making vanilla and boom maps.

I doubt people will stop making vanilla/limit-removing maps, but maybe Boom will if MBF21 is just expansion of Boom.

Edit: Maybe also add 16 sprite direction support

Edited February 17 by Rykz
my brain crossed with something

[maxmanium]

Why not finally fix the blockmap bug? And melee hitreg while we're at it.

[bofu]

2 hours ago, maxmanium said:

Why not finally fix the blockmap bug? And melee hitreg while we're at it.

 

As much as I dislike the blockmap bug, fixing it does also alter some game behaviors that people have gotten very used to. That being said, Woof does have the setting to fix it built in regardless of complevel.

 

I'm not strongly opposed to this, but I feel like it's best kept as an option.

[DoomGappy]

Teleport: player only and generalized teleporters (somehow?)

[DoomGappy]

Don't know if I've mentioned before, probably yes, but I think a great feature would be "triggerable" changing lights linedefs. Like action 261, but with W1, WR, S1, SR types of triggers, which would allow mappers greater flexibility on changing level brightnesses. I don't know if there is already anything like this, and please correct me if I'm wrong, as it would actually make my current maps even better, but having only 35 and 255  as options is too limiting. If we could use other brightness levels with some voodoo doll scripting, I'm sure amazing results can be achieved. 

[baja blast rd.]

There's been times, including recently, where I wanted to take a group of sectors that are lit to many different values and raise their lighting in the course of playing the map by a set amount like 32 or 48 while preserving any existing differences, like gradient lighting. Those setups are sometimes not practical or possible with the existing lighting actions. 

 

"Increase/Decrease Lighting As Sector Changes Height" would make that very convenient to do -- and is conceptually similar to the scrolling actions, so wouldn't require any new skills from the mapper.

 

Imagined example of setup: That action with a tag on a control sector. The player (or a voodoo doll) raises the height of the control sector by let's say 32. Then the sectors with that tag get their lighting increased by 32. 

 

The "As Sector Changes Height" model would also open up possibilities for manually scripted lighting effects. The length of the control linedef is still free to do something sensible if you want, but that isn't necessary. 

[redEYE]

On 2/13/2024 at 6:03 PM, ViolentBeetle said:

• New flag for linedef - "Silent", making sectors not make sound when moved by it (When applicable)

If line flags could be created and used to add special effects for standard line actions I'd propose line flags for:

- Key actions
So that add a Blue key flag to line with action 62 Lower lift - any you'll have a Blue key requiring lift? Add a Red skull flag any you'd have a Blue key+Red skull lift?

 

- Instant mover
To move the tagged sector to the target instantly. So that you wouldn't need to deal with extra control sectors to move floors to the lowest ceiling the or the highest floor as the target.

 

- SoftMover
- SoftMoverStart
- SoftMoverEnd
So that a door or a lift would start moving at slow speed but the speed would accelerate to the moving sector's own speed. The speed would stay for a while. Then the mover's speed would deaccelerate until it reaches it's target. Start and End versions would do the acceleration only at the start or the end of the movement.

 

- Delay action until the current movement is done
So that for example if a floor is moving at speed x you could trigger the delayed action which starts instantly after the floor has reached it's initial target: Floor starts moving at speed 2*x and/or to the opposite drection.

 

- Preserve teleported item's z-height
To be used on a teleport action line. The Final Doom quirk.

 

- Teleport, telefrag
Teleport monster even if it telefrags someone.

 

- Forced teleport, no telefrag
In Boom/MBF/MBF21 the player or a living monster can block keycards, weapons or even the non-solid bloody mess from teleporting. Let such "soft" objects to teleport.

Lineactions:

 

- Activate tagged teleports
- Deactivate tagged teleports
Self explanatory. Maybe this could be done with a flag: "Teleport deactivated at start" to have a teleport which is deactivated at the start of the level.

 

- Two part door
As in Doom64. Native two part door: Raise ceiling and lower floor, wait, lower ceiling and raise floor to their original heights. If this is done with generalized actions then a possibility to set up speeds separately for both floor and ceiling, please.

 

- Raise Lift, wait, Lower lift
As the normal 62, 88, 123, 120 Lower lift, wait, raise lift - but the movements other way around.

 

- Start Light Glow
- Start Ligt Flickering
- Stop Light Glow
- Stop Ligt Flickering
Apply Doom sector 8, 17, ... light effects on tagged sectors. If stopped return to the sector initial light value.

 

- Change tagged sectors light level according to the control sector height change (what baja blast rd. suggested above)
Similar to Boom 214-218 acclerative scollers: Scroll faster when the control sector ceiling raises higher. But now for the light level: Intensify light when the control sector height increases, diminish light when the control sector height decreases? The aim would be to have a smooth and controlled light change over a period of time. The Last Sanctuary has a night-day light cycle but it's done with 27000 lines in over 2000 control sectors.

 

The MBF door light uses this kind of method. In Boomedit.wad if you raise sector 55 and 56 ceilings to 5500 the door light effect inside the room takes around 10 seconds. This works only in complevel 11 and above. It's most smooth in GZDoom, K8Vavoom, PrBoomX/opengl > DSDA Doom/opengl, Doom Retro, Edge Classic > DSDA Doom/SW, Eternity, Helion and Woof.

 

- Increase or decrease tagged sector's light level by 4, 8, 16, 32, 64 or 128?
But so that if the light level goes outside the range [0, 256] it would still be counted. That way if you (voodoo) script an opposite light change the light levels of all the sectors would not get flattened to 0 or 256.

 

On 1/26/2024 at 2:10 PM, DRON12261 said:

Add support for coloring sectors in specific Colormap (as it works in SMMU and Eternity Engine). Even better, if it would be possible to select any color for a sector, not just through a separate Colormap. Especially for Eternity Engine I'm currently making a colormap pack with a lot of different colors of lighting and fog. It would be nice to see such functionality not only in Eternity Engine.

 

 

I'd add to that:

 

- Run time colormaps?
Boom allows using linetype 242 and the colormap name as the sidedef texture. For example Boomedit.wad has colormaps BLUMAP and GRNMAP in between C_START and C_END, and the MAP01 has line 595 lower texture: "BLUMAP", line 2069 upper texture: "GRNMAP" and so on. This is a rip off from Doom Legacy but could those be dealt during the map loading time and have "#RRGGBBa" as the colormap and texture name? "#0000FF" would return blue and "#00FF00" for green? The "a" would denote the degree of saturation?

 

- Apply, change or disable colormap?
So that if the player or a voodoo doll triggers the action line the colormap change would be applied to the tagged sectors?

[Hebonky]

Maybe a change sky action like a "w1 change sky" and it would change the sky texture to what you (or a voodoo doll) just walked over, you could simulate a thunder storm, or a sunrise that way. If you were willing enough you could add a full in game day night cycle with light levels changing based on the time!

[Plerb]

Some teleporter related ideas I had:

-Walkover teleport action that specifically affects the player and not voodoo dolls, so that a voodoo doll can cause you to teleport somewhere else.

-A sector-based teleport type. More traditional teleporters activated by landing on a sector would be nice as well, but the main idea I have in mind would work similarly to line-based silent teleporters. A control sector would be used to decide the floor level for what Z position within the sector would cause you to teleport, and when you teleport to the new sector, your position (including Z position), angle, and velocity are retained. This would be a useful method of simulating, for example, going into a hole into the floor and coming out of the ceiling beneath it seamlessly.

 

Also, the ability to set a specific COLORMAP to a single sector without affecting the whole screen is perhaps my most wanted feature.

[Sikreci]

I sure would love having access to some kind of fast projectile that can handle a speed higher than 32. But are deep physics changes like that beyond the scope of what a new MBF standard can even do?

[Scorcher]

EDIT: Read this instead.

Edited March 28 by Scorcher

[Xaser]

Posting here so future-folks don't forget: walkover triggers don't work with UMAPINFO's "bossaction" field -- the safest way of fixing this would be to add a new comp_ option and default it to fixed in some future MBF24/25/etc.

[JadingTsunami]

9 hours ago, Xaser said:

Posting here so future-folks don't forget: walkover triggers don't work with UMAPINFO's "bossaction" field -- the safest way of fixing this would be to add a new comp_ option and default it to fixed in some future MBF24/25/etc.

 

And I would also recommend finally fixing A_LineEffect code where the bug originated. It's not commonly used at the moment, but why leave broken behavior in place?

[Scorcher]

Two more previously reported MBF21 bugs.

 

1

2 (Read the bottom of the post)

Edited February 29 by Scorcher

[Redneckerz]

On 2/16/2024 at 3:03 PM, RjY said:

I think a new compatibility level is the right time to migrate to blockmap-based line-of-sight.

Presumably one of the reasons UDMF support was introduced is for the likes of Insane_Gazebo, Bemused, et. al. to be able to make high-detail slaughter maps of such complexity as to exceed the sidedef or even linedef limits. But maps with tens of thousands of monsters and sectors are precisely those which still need reject tables to run performantly due to the inefficiencies of using the BSP tree to check line-of-sight.

Building reject tables for very large, complex maps is increasingly a problem. While workarounds were found for most of Bemused's work, the same tricks failed for the later maps in Sunder. Only one, map15, has a nontrivial reject table -- which unfortunately was not even built with publically available tooling, but with some arcane process known only to Ribbiks. The state of the art has improved a little since 2018-9, with ZokumBSP -- TTBOMK, the only remaining maintained reject builder -- now able to build Sunder's reject tables, but with its lack of UDMF support (and Zokum's primary focus being vanilla Doom) it seems prudent to look for another approach.

Just want to highlight this and also invite @Ribbiks to share (if possible) what the witchcraft was regarding this. I know it was some kind of custom scripting that achieved that reject table. But in the here and now, it would be interesting to hear this out.

 

Having said that, i attest to RjY's point of view. There are more and more mappers that are attempting to stretch the outer limits of what is possible without going GZDoom, and its these stress tests that are of value to something like Helion (Whose insane performance would negate the use of a reject table if most processing goes through the GPU).

 

That being said, in regards to these benchmark maps, reject tables should be re-assessed. Even with current year hardware, outside of Helion, Doom's rendering puts every modern computer to the test when met with such a map - Inherent to Doom's rendering model, for sure, but it is exactly why a renewed interest for reject is in order. Outside of ZokumBSP, the current tooling to generate these is outdated at best - RMB is still a useful tool these days and that is a late 90s tool (And Zennode supports it). Additionally, reject table based effects should be explored more - In terms of Vanilla, we have seen a lot of exciting things using the stock suite, but when it comes to rejects, there is little news to find.

[camper]

Sorry for the possibly stupid question. Can weapons modified with MBF21 be reloaded?

 

The topic of firing from a railgun has also already been touched upon above. In addition to shooting through things, perhaps you'll want to shoot through walls or doors? A gunshot trail is also required. If there is a smoke trail from projectiles, then maybe add a smoke (or electric discharge) trail from the hitscan? I think I saw such an option for a plasma shotgun in https://www.doomworld.com/forum/topic/123800-v100-vesper-mbf21-showcase-mod/, correct me if I'm wrong.

[Ribbiks]

On 2/29/2024 at 7:05 PM, Redneckerz said:

Just want to highlight this and also invite @Ribbiks to share (if possible) what the witchcraft was regarding this. I know it was some kind of custom scripting that achieved that reject table. But in the here and now, it would be interesting to hear this out.

 

Making that reject table was largely a manual process. I defined specific chunks of the map and their adjacency relations (e.g. these are the bounding coordinates of area A, and area A is never able to see area B), which would then be encoded into the reject data for all sectors in each chunk:

 

Spoiler

 

Shortly thereafter I did spend a bit of time prototyping a generic reject builder (basically just as an alternative to zennode et al.), but it didn't get too far along.

[Redneckerz]

8 hours ago, Ribbiks said:

 

Making that reject table was largely a manual process. I defined specific chunks of the map and their adjacency relations (e.g. these are the bounding coordinates of area A, and area A is never able to see area B), which would then be encoded into the reject data for all sectors in each chunk:

 

  Reveal hidden contents

 

Shortly thereafter I did spend a bit of time prototyping a generic reject builder (basically just as an alternative to zennode et al.), but it didn't get too far along.

This is fascinating stuff, thank you.

 

So pardon me asking (Because i just find this fascinating, plus when it comes to extreme reject tables, this is highly unusual) So this manual process, how did you build this? Was this a piece of code, a script or even something you made directly in UDB?

 

 

[realjohnmadden]

More additions to the OPTIONS lump would be appreciated.

- Infinite thing height option (useful for, say, Heretic-style wads or just wads that need it in general)

- Force (or at least recommend) software renderer (in ports with hardware rendering as an option). This is already a thing in DSDA-Doom, but as far as I know it only applies there.

Better support for custom weapons and items would also be incredibly useful. This was mentioned before, but you could also tack on a Pickup state that could be used to give items to players for, say, a backpack that gives you full ammo but doesn't expand ammo capacity, or a berserk that also gives you a megasphere and invulnerability.

 

While you're at it, throw in 3D floors as well. /joke

 

[deathz0r]

On 3/1/2024 at 6:05 AM, Redneckerz said:

Helion (Whose insane performance would negate the use of a reject table if most processing goes through the GPU).

The "insane performance" is not universal - TWOGERS MAP04, MAP05 and MAP36 bring it to a crawl, and none of those maps have a large monster count. Also, REJECT tables have nothing to do with rendering performance.

On 3/1/2024 at 6:05 AM, Redneckerz said:

Outside of ZokumBSP, the current tooling to generate these is outdated at best - RMB is still a useful tool these days and that is a late 90s tool (And Zennode supports it). Additionally, reject table based effects should be explored more - In terms of Vanilla, we have seen a lot of exciting things using the stock suite, but when it comes to rejects, there is little news to find.

RMB is a real mode 16-bit DOS application that only uses conventional memory - it will bomb with an out of memory error if more than ~1300 sectors exist in a map. ZokumBSP's ability to read .RMB files appears to be the most appropriate solution moving forward, but I'll have to do some tests especially with regard to what @zokum mentioned with needing to generate the blockmap twice - I automatically rebuilt the REJECT lump for almost every map in TWOGERS with ZokumBSP using -n- -b- -r as the command line options, and maps that surpass ZokumBSP's BLOCKMAP size limit of ~128KB had no issues with creating a valid REJECT lump. In particular, I'll be experimenting with MAP36 and MAP48 as they both fail to generate a blockmap and they have clear benefits by removing line-of-sight checks for closets and areas where monsters will never appear - I'll start with MAP48 first since 970 sectors is significantly easier to create a .RMB file for than 14113 sectors.

On 3/4/2024 at 5:40 PM, Redneckerz said:

So pardon me asking (Because i just find this fascinating, plus when it comes to extreme reject tables, this is highly unusual) So this manual process, how did you build this? Was this a piece of code, a script or even something you made directly in UDB?

I don't see how inputting a RMB file through ZokumBSP will be any different, other than the possibility of Ribbiks' tool having some sort of visual interface.

Edited March 6 by deathz0r