Reflections and Aspirations: MBF21 in 2024

[Enator18]

We definitely have enough stuff here for a new spec

[bofu]

A couple ideas I had that I'm jotting down now so I don't forget: new mobjinfo property that is only consumed in cl24.

 

damagedice: used for missiles/projectiles. If set to anything but 0, when thing collides with another thing and would deal damage, then instead of using the default value of 8 as the random factor, use this number instead (with 1 being consistent damage). Since this would be a property on the tmthing that we can access when performing collisions, this can be passed to allow tweaking of random damage done by projectiles with proper guarding. It would be far trickier to add these parameters to a codepointer since the projectile attack codepointers don't have parameters for damage themselves, and it could be used to modify the random damage of existing projectiles if wanted.

 

Edited April 25 by bofu

[Scorcher]

Last main idea I have: Allow items that can fully change the properties of certain weapons (sounds, sprites, attacks, you name it) when picked up. Would allow for some cool DOOM 2016/DOOM Eternal style weapon upgrades.

 

EDIT: Maybe too beyond the scope actually...

Edited May 26 by Scorcher

[PBeGood]

Its not about having enough stuff for a new spec.

We should strive for a spec that will last for a lot of years.

 

mbf21 was 3 years ago and we are already looking at a new spec. It goes to show that while it mbf21 allows some awesome stuff it is just a transition phase for the future of doom mapping

 

If after mbf24, we get mbf27 mbf30 etc, we'll just cause a nightmare to port/editor developers, mappers and players

 

All this is to say, dont just create a new superset of mbf if you are going to have to make a new one each 3 years

Go for a more ambitious complevel that covers much more ground and will stand the test of time

[Enator18]

Yeah, that makes sense. In the mean time, I thought of more stuff that would be useful. The ability to do an archvile raise, but more arbitrarily, so it doesn't have to be part of a chase call, you choose the radius, and you choose the offset of the center of the check.

[DoomGappy]

Just remembered a good one: Middle texture wrapping, like in UDMF, where a middle texture will just tile infinitely in all directions. It would make creating panels and windows easier and less limiting. 

[Xaser]

Another random find: the comp_vile option intoduces an ugly bug (which unfortunately needs to remain as-is for cl11 demo compat). A new comp_ option that enables Archvile ghosts without introducing the cl11 sticky monsters bug would be good to have here (i.e. match the unbroken behavior that cl2 has under the hood).

 

[EDIT]

Editing this in so I don't double-post: A set of scroller specials that also scroll the back of a linedef, with the X direction mirrored, would be super-useful for scrolling midtextures on 2s lines. I've had to resort to ugly vanilla-style "two lines between a single pair of vertices" hacks a few too many times here. :P

Edited April 27 by Xaser

[Ravendesk]

I had a few difficulties I stumbled upon when mapping for mbf21, will list them below.

 

1. TOUCHY & SHOOTABLE & BOUNCES behaviour

There is a bit of a mess with TOUCHY and BOUNCES flags in MBF that MBF21 also inherited. Would be super nice to clarify their meaning and maybe split them in several flags in future MBF revisions.

 

Main problem I stumbled upon: TOUCHY requires SHOOTABLE. Presumably because current SHOOTABLE meaning is both "dies when health runs out" and "will be targeted by attacks". And TOUCHY just deals damage to itself which doesn't appear to be possible without "dies when health runs out". AFAIK gzdoom has a separate VULNERABLE state that allows things to have that first part of SHOOTABLE (able to die from damage) without having that second part (targeted by weapons). It would be very useful to be able to have that separation in MBF, too.

 

One example of when TOUCHY can be needed without SHOOTABLE is jumporbs from Jumpwad. When using them in an otherwise normal wad you don't want them to be shootable, you just want them to be a static environmental thingy.

Sample jumporbs decohack code for reference:

Spoiler

auto thing JumpOrb "Jumping orb"
{
//$Category User-defined/Other
    ednum 15202
    Radius 30
    Height 32
    Health 999999
    Mass 100000
      Speed 1
    PainChance 0
      ReactionTime 1
      clear flags
    +SPAWNCEILING
    +NOGRAVITY
    +TOUCHY
    States
    {
    Spawn:
        JORB AA 10 BRIGHT A_Look
        Loop
    See:
        JORB ABCDEDCB 4 BRIGHT
        Loop
    Death:
        SKUL I 0 A_AddFlags(NOGRAVITY)
        SKUL I 6 BRIGHT A_VileAttack
        SKUL J 6 BRIGHT A_Scream
        SKUL K 6 BRIGHT
        EMP0 A 6 BRIGHT
        EMP0 A 50
        EMP0 A 6 A_SpawnObject(JumpOrb)
        Stop
    }
}

 

 

There is also a weird side-effect of BOUNCES that actually helped to fix that problem by replacing SHOOTABLE with BOUNCES. The TOUCHY effect started to work for unclear reasons (without even adding a MISSILE flag, for example) after that. I wasn't able to figure out what exactly is going on with that flag exactly, but it feels like another reason to clarify the meaning and usage of these two flags and split all different effects into separate flags.

 

2. Back side of midtex scrolling

6 hours ago, Xaser said:

Editing this in so I don't double-post: A set of scroller specials that also scroll the back of a linedef, with the X direction mirrored, would be super-useful for scrolling midtextures on 2s lines. I've had to resort to ugly vanilla-style "two lines between a single pair of vertices" hacks a few too many times here. :P

Stumbled upon this problem literally a few minutes ago. Having alternative versions of line actions 1024-1026 to scroll back side (or both sides) instead of just front side would be incredibly useful for midtex detailing.

 

3. Independent control over sprite brightness

The logic of how brightness of things is calculated has changed from Boom to MBF and is also not consistent across source ports. In Boom brightness of things was equal to the brightness of sector itself no matter if brightness transfers (line actions 213 and 261) were applied to the sector's floor/ceiling or not. In MBF21 it is equal to average brightness of floor and ceiling. Walls and midtexes use sector brightness in both complevels.

Below is example of how this looks in MBF21 and in Boom in dsda-doom software renderer (and indexed opengl):

From left to right:

1. sector brightess 255, line action 213 (floor light level transfer) with 0 brightness + line action 261 (ceiling light level transfer) with 0 brightness

2. sector brightess 255, only line action 261 with 0 brightness

3. sector brightess 255, only line action 213 with 0 brightness

4. sector brightess 0, line action 261 with 255 brightness

5. sector brightess 0, line action 213 with 255 brightness

6. sector brightess 0, line action 213 with 255 brightness + line action 261 with 255 brightness

MBF21:

Spoiler

Boom:

Spoiler

 

What adds another layer here is that gzdoom's renderer actually behaves differently to both no matter what the compatibility options are. It takes floor brightness instead (for both things spawning on floor and on ceiling):

Spoiler

 

So, to summarise:

dsda-doom in cl9 = things get sector brightness.

dsda-doom in cl11/cl21 = things get (floor + ceiling)/2 brightness.

Gzdoom with any comp options = things get floor brightness.

 

One option that can allow maximum flexibility for mappers and also make visuals consistent across source ports would be to add a separate light transfer action that will control things brightness independently (similar to 213 and 261, but for things). I don't know however how complicated it is to support this in different source ports. Maybe there are better approaches.

 

Sample wad for reference: brightness_check.zip

 

Also big thank you for continuing mbf support and development, mbf21 has been incredible for mapping.

[Doomy__Doom]

An idea I'm prepared to get rekt for but... what if MUSINFO but for monster spawners? As in, a magic index range entity, let's say 2xxxx, which will spit out monsters defined in a lump on a per map basis.

 

Something like (lets call it SPWNINFO for now):

<id> <thingtype> <count> <min delay between spawns> <time to stay active for>
MAP01
1 Revenant 23  --spawn 23 revs by Zdoom class name, same as umapinfo
2 280 10       -- spawn 10 things using table index 280, to support dehextra/dsdhacked directly
MAP02
25 Archvile 5 350  -- spawn 5 viles with at least 10 sec/350 tics delay between spawns
26 DoomImp 200 0 3500  -- try to spawn up to 200 imps asap during 3500 tics from the moment spawner stops idling, remove spawner after time passes
27 Revenant -1 350 3500  -- keep'em coming for 100 sec/3500 tics with at least 10 sec/350 tics second delay between spawns

And so map01 would have entities 20001-20002 and map02 would have 20025-20027.

Spawners would

1. still have to be activated by usual means of sight/sound
2. respect difficulty and ambush map flags
3. check for free spawn space in a fashion similar to teleportation logic, possibly with some form of direct telefrag control for map30s and/or mapper not being happy about "standing on a spawn spot" tactic
4. actively try to spawn thing (i.e. check more frequently than delay value) if the spawn fails
5. maybe be "killable" by instakill floors and/or crushers
6. maybe be teleportable and be spawnable via dehacked codepointers
7. maybe have a field for initial delay before 1st spawn

 

Why:

1. Regulating spawn speed without a degree in monster fluid dynamics
2. Replacement viles et.al. that run out automatically without bloating killcount
3. Waves that naturally run out on a timer
4. (Partially) concealing kill total on stats without going "nothing is COUNTKILL haha"
5. Copypasting rows or Revs isn't particularly fun
6. Convinient repopulation of roaming monsters (think "_ Archvile 2 6300" to spawn as you turn a corner, and then a new one 3 minutes later)
7. Save on lines/blockmap space for maps that really push traditional format limits?

 

Why not:

1. one could certainly just decohack together similar things as needed, especially if the proposition on generic counters passes
2. more lumps for the lump god
3. some closet setups are likely faster to make anyway (similar to "do everything with scripts" trap for inexperienced user)
4. can't easily edit from just map editor
5. "don't trust killcount" can become a default assumption (not that it's bad in and of itself and can already be done with mbf21 anyway)
6. <something obvious I did not think of goes here>
7. <something technical that's obvious to port developers goes here>

[bofu]

7 hours ago, Ravendesk said:

I had a few difficulties I stumbled upon when mapping for mbf21, will list them below.

 

1. TOUCHY & SHOOTABLE & BOUNCES behaviour

There is a bit of a mess with TOUCHY and BOUNCES flags in MBF that MBF21 also inherited. Would be super nice to clarify their meaning and maybe split them in several flags in future MBF revisions.

 

Main problem I stumbled upon: TOUCHY requires SHOOTABLE.

 

I thought that too, but then looking at source code, I discovered that it can actually work without SHOOTABLE if you add DROPOFF.

 

In other news, I was able to start implementing some new things in my little unofficial pseudo-MBF24 environment that I've been working on that I'm pretty pleased with so far:

 

• New thing flag, NOTAUTOAIMED (named after the Decorate thing flag that does the same thing), that causes a shootable thing to be completely ignored for the purposes of autoaim. Useful for destructive props in areas where gameplay is needed.
• NORESPAWN flag that prevents a thing from getting respawned on Nightmare. Honestly, this was a really easy one to accomplish.
• Currently in the process of testing out new thing properties and/or flags for projectiles and actors to implement a basic damage resistance/vulnerability feature based on damage type. Not giving these distinct names yet because they should be flexible, but the idea I had was that you would assign projectiles DAMAGETYPE1, DAMAGETYPE2, DAMAGETYPE3, etc, or just have a new mobj property to represent it; then, an actor could have a flag that represents vulnerability to each damage type, resistance, or complete immunity. I've got some basic work done on this, but I'm trying to decide what the most effective and flexible implementation would be.
• This one's coming along nicely, but I had the idea of making generic versions of the Archvile attack codepointers. I'm pretty sure I can even allow the user to specify a thing to spawn/check for as the fire, as well as parameterize the damage and any extra damage done by having the fire present, as well as even allowing the user to change momentum. I could easily see this working to add damageless jump pads and the like.

 

I'm really only familiar with the actor/deh/mobj/enemy/inter parts of the code right now, since that's where the majority of what I've been tinkering with has lived. I'd love to take a stab at some of the compatibility option implementations that Xaser mentioned, as they're definitely doable.

 

And a modest proposal: I would really like horizontal autoaim to be disabled by default in the complevel, or at least the ability to disable it on certain weapons while leaving vertical autoaim intact. No, I haven't been giving myself facerockets on corners lately, why do you ask?

 

Also, I missed your post, @Doomy__Doom, but I was going to say as I was reading it, I've got counters next on the list to try making, and I'm pretty sure what you're proposing would be best done as a modder-defined Thing if those are implemented. That would allow the most customizability while also making compatibility easier.

Edited April 27 by bofu

[Enator18]

11 hours ago, Ravendesk said:

I had a few difficulties I stumbled upon when mapping for mbf21, will list them below.

 

1. TOUCHY & SHOOTABLE & BOUNCES behaviour

There is a bit of a mess with TOUCHY and BOUNCES flags in MBF that MBF21 also inherited. Would be super nice to clarify their meaning and maybe split them in several flags in future MBF revisions.

 

Main problem I stumbled upon: TOUCHY requires SHOOTABLE. Presumably because current SHOOTABLE meaning is both "dies when health runs out" and "will be targeted by attacks". And TOUCHY just deals damage to itself which doesn't appear to be possible without "dies when health runs out". AFAIK gzdoom has a separate VULNERABLE state that allows things to have that first part of SHOOTABLE (able to die from damage) without having that second part (targeted by weapons). It would be very useful to be able to have that separation in MBF, too.

 

One example of when TOUCHY can be needed without SHOOTABLE is jumporbs from Jumpwad. When using them in an otherwise normal wad you don't want them to be shootable, you just want them to be a static environmental thingy.

Sample jumporbs decohack code for reference:

  Reveal hidden contents

 

auto thing JumpOrb "Jumping orb"
{
//$Category User-defined/Other
    ednum 15202
    Radius 30
    Height 32
    Health 999999
    Mass 100000
      Speed 1
    PainChance 0
      ReactionTime 1
      clear flags
    +SPAWNCEILING
    +NOGRAVITY
    +TOUCHY
    States
    {
    Spawn:
        JORB AA 10 BRIGHT A_Look
        Loop
    See:
        JORB ABCDEDCB 4 BRIGHT
        Loop
    Death:
        SKUL I 0 A_AddFlags(NOGRAVITY)
        SKUL I 6 BRIGHT A_VileAttack
        SKUL J 6 BRIGHT A_Scream
        SKUL K 6 BRIGHT
        EMP0 A 6 BRIGHT
        EMP0 A 50
        EMP0 A 6 A_SpawnObject(JumpOrb)
        Stop
    }
}

 

 

There is also a weird side-effect of BOUNCES that actually helped to fix that problem by replacing SHOOTABLE with BOUNCES. The TOUCHY effect started to work for unclear reasons (without even adding a MISSILE flag, for example) after that. I wasn't able to figure out what exactly is going on with that flag exactly, but it feels like another reason to clarify the meaning and usage of these two flags and split all different effects into separate flags.

 

2. Back side of midtex scrolling

Stumbled upon this problem literally a few minutes ago. Having alternative versions of line actions 1024-1026 to scroll back side (or both sides) instead of just front side would be incredibly useful for midtex detailing.

 

3. Independent control over sprite brightness

The logic of how brightness of things is calculated has changed from Boom to MBF and is also not consistent across source ports. In Boom brightness of things was equal to the brightness of sector itself no matter if brightness transfers (line actions 213 and 261) were applied to the sector's floor/ceiling or not. In MBF21 it is equal to average brightness of floor and ceiling. Walls and midtexes use sector brightness in both complevels.

Below is example of how this looks in MBF21 and in Boom in dsda-doom software renderer (and indexed opengl):

From left to right:

1. sector brightess 255, line action 213 (floor light level transfer) with 0 brightness + line action 261 (ceiling light level transfer) with 0 brightness

2. sector brightess 255, only line action 261 with 0 brightness

3. sector brightess 255, only line action 213 with 0 brightness

4. sector brightess 0, line action 261 with 255 brightness

5. sector brightess 0, line action 213 with 255 brightness

6. sector brightess 0, line action 213 with 255 brightness + line action 261 with 255 brightness

MBF21:

  Reveal hidden contents

Boom:

  Reveal hidden contents

 

What adds another layer here is that gzdoom's renderer actually behaves differently to both no matter what the compatibility options are. It takes floor brightness instead (for both things spawning on floor and on ceiling):

  Reveal hidden contents

 

So, to summarise:

dsda-doom in cl9 = things get sector brightness.

dsda-doom in cl11/cl21 = things get (floor + ceiling)/2 brightness.

Gzdoom with any comp options = things get floor brightness.

 

One option that can allow maximum flexibility for mappers and also make visuals consistent across source ports would be to add a separate light transfer action that will control things brightness independently (similar to 213 and 261, but for things). I don't know however how complicated it is to support this in different source ports. Maybe there are better approaches.

 

Sample wad for reference: brightness_check.zip

 

Also big thank you for continuing mbf support and development, mbf21 has been incredible for mapping.

Oh yeah, the BOUNCES flag is also very messed up. To get the grenade-like behavior shown in the MBFEDIT demo, you have to have a projectile with BOUNCES but without MISSILE which creates incredibly inconsistent behavior with the various missile shooting codepointers, so that could definitely use fixing 

[Ravendesk]

4 hours ago, bofu said:

I thought that too, but then looking at source code, I discovered that it can actually work without SHOOTABLE if you add DROPOFF.

Well, ok, but intuitively it makes even less sense xd

Clearly there are certain confusing dependencies between flags inherited from original MBF.

[bofu]

15 hours ago, Ravendesk said:

Well, ok, but intuitively it makes even less sense xd

Clearly there are certain confusing dependencies between flags inherited from original MBF.

Oh, absolutely. It makes no sense. It'd definitely be better to make a new bounce entirely and leave that one alone for compatibility reasons, as even gating any changes behind an if(MBF24) statement would still make the code really unwieldy to work in there.

Edited April 28 by bofu

[Enator18]

I just had an interesting idea for a feature. A way to edit the cast sequence. Basically somewhere like a lump or maybe just in umapinfo or something to put a list of thing nums for the enemies that will appear in the cast sequence so that you can add your custom enemies to it, instead of it just being all of the doom 2 enemies or whatever they were replaced with.

[8088mph]

3 hours ago, Enator18 said:

I just had an interesting idea for a feature. A way to edit the cast sequence. Basically somewhere like a lump or maybe just in umapinfo or something to put a list of thing nums for the enemies that will appear in the cast sequence so that you can add your custom enemies to it, instead of it just being all of the doom 2 enemies or whatever they were replaced with.

oh my god, this is such an amazing suggestion. i imagine all the hacky things i could do with something like this.

[bofu]

14 hours ago, Enator18 said:

I just had an interesting idea for a feature. A way to edit the cast sequence. Basically somewhere like a lump or maybe just in umapinfo or something to put a list of thing nums for the enemies that will appear in the cast sequence so that you can add your custom enemies to it, instead of it just being all of the doom 2 enemies or whatever they were replaced with.

 

This might be easier done as a new lump rather than adding properties to existing things. This would also give WAD authors flexibility with things like specifying what states/sounds play during the cast call. f_finale.c in the DSDA source code contains the prebuilt cast call as a static const; if we could add a clause in there to determine if a CASTCALL lump is added, maybe we can populate a non-static one with the same info and execute that one instead.

Edited April 30 by bofu

[Enator18]

25 minutes ago, bofu said:

 

This might be easier done as a new lump rather than adding properties to existing things. This would also give WAD authors flexibility with things like specifying what states/sounds play during the cast call. f_finale.c in the DSDA source code contains the prebuilt cast call as a static const; if we could add a clause in there to determine if a CASTCALL lump is added, maybe we can populate a non-static one with the same info and execute that one instead.

Oh yeah looking at how this is implemented currently, it seems like this feature would be not too bad to implement.

[rita remton]

currently just one - transparency control for textures, especially for middle textures. tq.

[ViolentBeetle]

One thing that might be useful - a crusher that just kills whatever is under it when it reaches the bottom. Syncing floor change might not always work, but sometimes you might want a crusher that actually crushes monsters good.

[bofu]

11 hours ago, rita remton said:

currently just one - transparency control for textures, especially for middle textures. tq.

I think this is what using custom TRANMAPs with the Boom-style transparency is for, which is really flexible and lets you do additional things beyond changing the transparency, like making only certain colors transparent or color inversion. Aside from having a few presets for ease of use, I don't know what can be added that the existing implementation can't accomplish (once you find the arcane method of making it in your map, that is).

[Graf Zahl]

31 minutes ago, bofu said:

I don't know what can be added that the existing implementation can't accomplish (once you find the arcane method of making it in your map, that is). 

 

The existing implementation is extremely awkward to use, you can easily let the engine generate the TRANMAP from a transparancy percentage value as needed instead of requiring the mapper to do this.

It's also a lot easier to handle for hardware rendering where alpha values are the native way to blend colors.

 

[bofu]

9 minutes ago, Graf Zahl said:

 

The existing implementation is extremely awkward to use, you can easily let the engine generate the TRANMAP from a transparancy percentage value as needed instead of requiring the mapper to do this.

It's also a lot easier to handle for hardware rendering where alpha values are the native way to blend colors.

 

That's certainly fair. I haven't used any examples that haven't looked good in hardware rendering, though I've heard people say that hardware renderers only "approximate" some of the more advanced effects.

 

I'm all for having some predefined transparency settings, so long as the more advanced/customized ones are still supported in their current state.

[Graf Zahl]

The "more advanced" stuff is impossible to pull off outside an 8 bit software renderer. Even after so many years there is still no hardware that supports programmable blending.

 

[Blast_Brothers]

A couple of random ideas I thought up this morning:

 

• More or less the GlassBreak line special from Strife/ZDoom. If any attack makes contact with the midtex, it changes texture, plays a sound (different from the switch sound?), and becomes passable if it wasn't previously. Could have a "semi-destructible" variant that doesn't become passable (so you could have "bulletproof glass" that still cracks when you hit it), which you can kind of do with the existing specials but only with player hitscan. Bonus points if the linedef could have "health" so you had to shoot it multiple times to break it, with separate textures for initial -> damaged -> broken.
• "Solid" midtextures where you can walk above or below the texture but not through the middle. Would probably allow projectiles/hitscan through to be consistent with regular midtextures. And you'd have to deal with things standing on top of it, which might get weird? (EDIT: if standing on it works as expected, this means floor transfers are no longer needed to make 3D bridges!)
• Fake 3D floor helper: If a line has a midtex on the front and a flat specified as the midtex for the back, then the flat texture will render as a fake floor and ceiling behind the midtexture. Like projected flat 3D floors but with less setup and not limited to being next to walls. Not sure how to gracefully handle cases where the "3D floors" have different flats specified on different lines, or if the "3D floor" isn't closed on all sides, but maybe the existing flat flood fill behavior will handle those cases well enough?
• An effect similar to A_RadiusDamage that pushes/pulls nearby things instead of damaging them. Black hole/magnetism effect.
• Projectiles that could collide and interact midair - bouncing off of each other, or both exploding midair, a projectile that "absorbs" a rocket, falls to the ground, and explodes, but would delete any other projectile that collides with it, etc. Haven't thought this one through at all, and it sounds complicated, but it could be fun.

 

Edited May 5 by Blast_Brothers

[DoomGappy]

Separate flags for each difficulty from 1 to 5. Would allow better balance for Nightmare without compromising the other difficulties and vice versa.

[redEYE]

Line action: Alert monsters

 

If tag is not 0, wake up monsters from the tagged sectors only. For example monster teleporters without the mandatory need for player to fire the pistol at the start of the level.

 

If tag is 0, make a normal sound alert from the activator's location. The tagless version could be triggered by a voodoo doll if the voodoo player scrolling sector is soundlinked to the game area...

[ViolentBeetle]

Another thing for wishlist - ability to target both monsters and player from the projectile. The simplest thing I can think of is to attach it to tracer-finder so projectiles could pick whatever fits them.

I wanted to make a barrel that spits projectiles in a circle, would make sense for them to aim vertically.

[bofu]

So, maybe controversial, maybe not, but I would personally be thrilled if we just disabled horizontal autoaim entirely as part of the complevel. Demo recordings, demo playback, non-demo gameplay, all of it. Maybe make it a comp setting to reenable it or something. I've not heard a kind word said of horizontal autoaim, whereas every other quirk in the original game has some player-facing utility to it.

 

In other news, I've got my NOAUTOAIM and NOBFGSPRAY thing flags working, I think. I'm about to test them out, and unfortunately, to get them both working side by side, because the BFG spray attack just reuses the autoaim code, I had to duplicate the AimLineAttack command along with its corresponding Traverse command, and if running MBF24, those commands get called by A_BFGSpray instead of AimLineAttack but only if complevel is MBF24. This is also a good first step toward a parameterized SprayAttack codepointer.

 

One hiccup I found when trying to create a projectile-oriented, parameterized alternative to A_BFGSpray is that it becomes significantly less useful unless you make it fire rays in every direction from the projectile, but then, whatever it gets hit with gets completely obliterated because it eats about 70% of the tracers. Even when parameterizing the damage to very low values, I was one-shotting Cyberdemons very reliably while also failing to kill clustered up pinkies.

 

That being said, I did successfully parameterize the original spray behavior (player-originated) to allow customized damage, field of view, range, and even splash thing. I'll play around with it a bit more - the original damage calculation for the BFG tracers is very unintuitive for most people, so it probably works better as a "(damagebase * rnd(damagedice)) + flatdamage" calculation.

[Enator18]

2 hours ago, bofu said:

So, maybe controversial, maybe not, but I would personally be thrilled if we just disabled horizontal autoaim entirely as part of the complevel. Demo recordings, demo playback, non-demo gameplay, all of it. Maybe make it a comp setting to reenable it or something. I've not heard a kind word said of horizontal autoaim, whereas every other quirk in the original game has some player-facing utility to it.

 

Only problem is won't most people be super used to it? I don't really know how impactful it is but won't it be jarring to turn it off?

[bofu]

2 hours ago, Enator18 said:

 

Only problem is won't most people be super used to it? I don't really know how impactful it is but won't it be jarring to turn it off?

The same could be said of a lot of changes any complevel has made in the past. Some of those have altered monster pathfinding or attack patterns. MBF monster infighting and Boom letting living monsters get blown off ledges both come to mind.

 

About the only impact I'd see removing the horizontal component of autoaim having is that people would hit what they're trying to hit more often, and perhaps some BFG tracers missing that wouldn't normally miss (its tracers are actually fired using the autoaim code), but that last one can be worked around pretty easily.

Edited May 6 by bofu