bofu

I don't do it so much these days because one of the mods hasn't been updated in a while, but I used to do runs with DoomRLA and DoomRPG. I'm back to vanilla these days. Brutal Doom and Project Brutality don't play nicely enough with a lot of stuff released these days anyway.

You could probably workaround the TID thing by using an argument to use a TID mode or a "first found thing in sector tag X" mode via args, if you really wanted to. I love these ideas though and will definitely see what I can do. (Just to manage expectations since there are a lot of other ideas floating around: the draft I'm working on is only for Thing/Weapon behaviors and compflags.)

I think this would be great. I'll have to figure out the math, and it may turn out to be beyond my abilities, but I imagine it would be quite possible to reverse engineer something from the NewChaseDir code or whatever it's called. And that would allow us to perhaps also add a codepointer for simply moving a step in the thing's current direction (or even a relative direction, for sidestepping), no turns required.

I think it's possible, though it might be kind of scuffed. First, you'll want to give the turret thing a very high mass to keep it from getting moved by damage. Then, you'll want to give it an initial spawn state where it keeps calling A_Look. But instead of using A_Chase for its chase frames, you can just give it a cycle of A_FaceTarget starting at its "First moving frame" to make it face its target, and then, after the last A_FaceTarget frame (which will depend on how long you want it to wait before firing), have it go directly to its attack sequence, skipping A_Chase entirely. Have its attack sequence then loop back not to its first moving frame, but to its initial spawn frame. This will keep it from continuing to attack the player after they've left line of sight. It'll require some trial and error, but it should work with enough tweaking. (This should probably go to Editing Questions forum, however.)

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.

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.

From personal experience: if you're making a Doom wad with new Dehacked actors, it's beneficial to make a separate ZScript or Decorate lump (even if a separate wad) to replace them with equivalents, and not too difficult, especially if you used DecoHack to make your DEHACKED. This will help with compatibility with GZDoom mods. I ended up doing this for the final release of Dominus Diabolicus, and I haven't regretted it.

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.

I've got a soft spot for the hitscannersz and when they punch above their weight class, I'm always pleased. I replaced the Wolfenstein SS with a super shotgun zombie, and it was fun seeing them actually kill Hell Knights and Revenants in infighting.

Pretty sure that first { after class needs to go, along with one of the } at the end.

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.

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.

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.

Dominus Diabolicus is a 33-map MBF21 megawad and my first solo project. It's gone through quite a few transformations over its two-and-a-half-year development cycle, but the core concept has stayed the same: something that delivers a fresh yet familiar-looking experience, that feels like a complete package that feels like a progression of Doom without going overboard and delivering a completely new, foreign experience. While the vast majority of textures are vanilla or based on vanilla assets, they're often used in ways that completely subvert expectations of how vanilla-textured levels look. There are detailed cityscapes, offices, torture chambers, corrupted techbases, industrial zones, and more. Difficulty is tough but fair, and while seasoned Doom pros may be able to get through most of the maps on UV, the super secret maps are also incredibly challenging. Download the release HERE or HERE (UPDATED 8 MAY). And please report any bugs you run into. You'll need the Doom 2 IWAD. Episodes have been implemented as a "shortcut" to the starts of different areas, but starting from the beginning of an episode will take you all the way through the rest of the wad. Some of the features include: Some tasteful implementation of interactive environments, such as destructible office chairs, playable organs, or flushing toilets. An expanded bestiary and custom boss monster, all of which are designed to fit the Doom aesthetic and serve unique battlefield roles. An entirely original soundtrack, including a special guest track by Lee Jackson. 33 levels, including 3 secret levels, all designed by yours truly. Full multiplayer support. Compatibility with MBF21-enabled source ports and GZDoom, with recommended/required compatibility settings bundled right into the WAD itself. New HUD adapted from the Freedoom HUD, modified to fit the Doom aesthetic. Updated cast call for GZDoom users. Skill levels fully implemented, with additional monsters and added challenge available via solo netplay/coop spawns. There have been some additions made to the cast of enemies, too. There are some surprises in store, but here's what I can tell you about: Former Human Vanguard: Even the elite shock troops of the UAC have been corrupted by Hell's forces. These guys wear protective armor and wield deadly super shotguns, but at least they're nice enough to trade them to you in exchange for some hot lead or plasma. Cybermancubus: This relative of the Mancubus has been infused with cybernetic enhancements that make it a bit tougher and allow it to channel its corrosive bile into streams of corrosive sludge. Getting hit by one of their projectiles isn't that bad on its own compared to their less hearty brethren, but the pools of acid that get left behind can quickly eat away at you if you stay put for too long. They get along too well with other mancubi to get into fights with them, too. Summoner: And you thought the Arch-Vile was bad. Instead of resurrecting slain monsters, these bastards call new ones in to the fight, and their fire attacks spew a lot more flame at you if you get caught out in the open by them. They're usually busy warding important areas and have to be killed to proceed, so you can't even avoid them. ???: The leader of Hell's forces is no mere Gatekeeper, but a fearsome warrior. Unfortunately, there's no intel on this creature or its capabilities... The Levels: CREDITS: Bofu: Level design, Dehacked, music, various backgrounds and UI graphics, Cybermancubus and boss sprites, Vanguard sprite edits, texture edits Xim: Basis for the Vanguard sprite Amuscaria: Summoner sprite Hambourgeois: Liquid textures Raven Software: Various props and parts of sprites Mek: Skies Lee Jackson: Music for MAP11 Midway Software: Some sounds Napsalm: Plasma sound Freedoom Team: Base status bar SCREENSHOTS: SOUNDTRACK: The tracks I made myself are available for limited streaming and purchase on Bandcamp here if you're interested. TESTED PORTS Doom Retro DSDA-Doom GZDoom 4.11.3 Nugget Doom Woof PORTS WITH PENDING ISSUES Helion DISCLAIMER Unfortunately, I can't guarantee support for any gameplay mods (Brutal Doom, Project Brutality, etc.). That being said, if you are willing to produce a compatibility patch for such mods, I am happy to link it here or provide technical information.

I'm particularly excited about the sprite rendering fix that's been merged into the next release. For those who aren't aware: since the vanilla days, the sprite rendering method has used an imprecise and situationally glitchy method to determine which sprites need to be drawn. The original method was to draw only the sprites whose origin was inside any of the sectors that were visible from the player's point of view, which generally works fine for older, less detailed levels. But in levels with small detail sectors such as light transitions or small child sectors for floor or ceiling detailing, this could lead to situations where sprites, especially large ones like Mancubi or Spider Masterminds, would suddenly pop out of view if the sector in which they were centered was no longer being rendered, even if the vast majority of the thing was located well inside the player's field of view. I discovered that it was possible to fix this behavior because every sector maintains not just a list of what things are in it, but also which things are touching it, and shared this finding on the feature request along with a proof of concept. I was struggling to find a way to make it only draw each thing once so as to not tank performance (since the same thing could touch multiple visible sectors). But then, the torch was swiftly picked up, and performance was fixed. This is one of those small but really long overdue fixes, and while I hope it gets propagated to other source ports that used the vanilla method to draw sprites, I'm just really stoked to see my Doom pet peeve getting addressed.

I think old wads get a pass, but people really shouldn't do it these days just out of courtesy unless they have something very specific in mind (where that MIDI absolutely is integral to the experience and not just chosen out of personal taste, like Italo Doom having a very specific theme that made its MIDI selection a core part of its identity). There are really good publicly available alternatives these days.

MIDIs that get YouTube playthroughs copyright claimed.

There are enough "glowing altered palette OTEX structures suspended in voids" maps out there and I'm not going to somehow do it better, so do something else, instead. Also, blend realism with the surreal. They can blend very well in the right circumstances.

Some things don't move with the floor due to having NOBLOCKMAP set in their definition. Try replacing the sprite with something like an item, and see if it still stays still.

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.

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

I'm pretty sure that one would've always worked, actually, as the WolfSS obituary was already replaceable via the DEHACKED lump. This specific fix applies to DEHEXTRA actors who use thing IDs 150-249, which have a hard-coded classname of Deh_Actor_151 ... Deh_Actor_250.

When I saw this, Doom the Way id Did and Ultimate Doom the Way id Did immediately came to mind, but you already played them, so there goes my first thought. And upon further reading, I will actually do something gauche and plug my own megawad Dominus Diabolicus here specifically because while the difficulty scales a bit higher than the IWADs (I recommend HMP or HNTR if you want id levels of UV difficulty), architecturally and visually, I was going for a "IWADs but more detailed" look. It's an MBF21 WAD, but really only uses the features to expand the bestiary and achieve some light background scripting. Episode 2 and Episode 3 have some visual nods to those particular episodes of Doom (it's a Doom 2 megawad with continuous play, but episodes are there for thematic reasons and in case you want to skip to certain points).

The above ZMAPINFO issue has been addressed, as well as the following: Texture and lighting inconsistencies in a few areas have been touched up. A few maps have had particularly noisy traps turned into more subtle, less noisy ones. Automap fixes. MIDIs that were too slow or were looping incorrectly have been fixed. I've replaced the Corruption Cards pack with a full-fledged ZScript compatibility wad that converts all the Dehacked monsters to ZScript versions that play nice with most gameplay mods, and the Corruption Cards lump is embedded within instead. (No more "Deh_Actor_xxx" when you aim at a Cybermancubus or Summoner! The Vanguard is no longer problematic!) Balance in UV+ (Ultra-Violence with co-op spawns) has been tweaked a bit to make sure you have enough ammo if you go it alone and pistol start... if you're good enough. Visual issue fixed in MAP20. Fixed some minor DEHACKED jank with the boss that made one of his attacks slightly goofier than it should've been. Unfortunately, this will invalidate any recorded demos, but as there aren't any submissions, I felt it should be fine! Apologies for the re-release, but I had a nice, relaxing few days to iron things out. The Dropbox link (here) has been updated, and idgames submission is pending!

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.