Xaser

A couple of folks have pointed this out already, but IMO the best "hard rule" re: saving one can set for themselves that will make the biggest impact is "don't save during a fight" -- give that a try. Set a savegame before a big fight (or before venturing into an unknown area) and see what happens -- before long, you'll be overcoming your old habit by virtue of not wanting to reset your progress if you're doing well, and a total botch won't set you back to the very beginning of the level so it's not so brutally punishing.

Don't try and use folks' lists of dislikes as a guideline for making your maps -- these sorts of threads tend to collect a lot of very bizarre complaints, and you'll never please everyone anyway unless you literally make Nothing... and even then, that might be disappointing to someone anyway. :P

The original post is maybe like... 10% about the 'softlocks', and it really doesn't read like you're having fun with the wad in general. Maybe you are, though, and it didn't come through in the post -- either way, folks are going to respond to that, 'cause it's there. I do think a lot of this frustation stems from the "100% or bust" mindset though -- if you're locked into that way of thinking, then flaws like these (annoying as they are) will become showstoppers. If you are having fun with Scythe 2 except for this issue, then it's worth breaking the cycle before it drags down the experience for other wads. Embrace the double-digit percentages until your second or third replay.

Gotta drop the usual advice here: If you're having a miserable time going for 100%, then don't go for 100%. If that doesn't do the trick, try lowering the difficulty level. And if that doesn't work either, you may be best off finding a new wad to play. I want to zero in on that last point: you don't have to play Scythe 2 if you're not jiving with it. It's totally fine to not enjoy something even if it's something folks tend to rave about, and you're far from the only one who thinks Scythe 2 gets a bit Much(tm) in its final act. There's really not much to gain by forcing yourself through it -- I'm sure there's another wad just around the corner that you'll end up having way more fun with, and you have the power to skip ahead past the frustrating part. [FWIW, I also prefer it when 100% is attainable in maps without any sneaky "point of no return"s, but it sounds more like this case is a symptom of a greater frustration, rather than the root cause.]

This is going to sound like a tangent from your original question, but bear with me a moment. :P You're about to hit a pretty significant "feature wall" here -- the set of DEHACKED features available to Boom and PrBoom-Plus (even the MBF extensions) is missing a metric ton of stuff you're used to, most notably the ability to define new sets of states. While it's technically possible to do something like hijack the SS Nazi or the MBF Dog, there's a Better Way(tm). First thing's first: upgrade from prboom-plus to dsda-doom -- the former has long ago ceased development, and the latter has picked up where it left off and added a ton of new features. The community at large has transitioned to dsda-doom much in the same way that all the ZDoom users migrated to GZDoom -- basically a seamless transition in all but name. Once that's all done, you now have access to the MBF21 feature set, which is basically "Boom v2" -- it takes everything Boom has and adds a ton of new features on top, and it's supported by a wide variety of ports (dsda-doom, GZDoom, Woof!, Eternity, Doom Retro, and so on). Most significantly in your case, it adds a ton of new DEHACKED features and codepointers, and ports that implement the standard also tend to support DEHEXTRA and its souped-up cousin DSDHacked, which raise (or even remove) the state limit. That probably sounds like a lot of new stuff to learn, but thankfully there's a one-stop shop for all your "how do I use this?" questions: DECOHack. This tool not only supports all the fancy new editing standards I linked above, but lets you write your actor code in a very DECORATE-like syntax and will generate the DEHACKED patch for you, which oughta be doubly handy in your case since it'll feel a lot more familiar to you than WHackEd4. It's part of the DoomTools suite, so install that and you'll be good to go. I'll dig up a "getting started" guide here in a bit, but tl;dr if you read this before I get back: install DoomTools, grab dsda-doom, and you'll be all set up to start making some cool cross-port mods. [EDIT] Here's a super-quick bit of example code -- this basically creates a copy of the spectre with all its states cloned (and a couple of properties changed just to show how that's done), so you can modify 'em at will without it touching the pinky at all: #include <dsdhacked> #include <friendly> thing MTF_SPECTRE "Spectre 2.0" { health 999 speed 12 clear states States { Spawn: SARG AB 10 A_Look Loop See: SARG AABBCCDD 2 Fast A_Chase Loop Melee: SARG EF 8 Fast A_FaceTarget SARG G 8 Fast A_SargAttack Goto See Pain: SARG H 2 Fast SARG H 2 Fast A_Pain Goto See Death: SARG I 8 SARG J 8 A_Scream SARG K 4 SARG L 4 A_Fall SARG M 4 SARG N -1 Stop Raise: SARG N 5 SARG MLKJI 5 Goto See } } To get that code running, I'd suggest checking out Doommake (also part of DoomTools) to generate a full project. If you're comfortable with command-line utilities (or willing to learn; it's a superpower ;), there are some instructions on the linked page on how to get started. Or you can use the DoomTools' GUI util to generate a project (Tools -> DoomMake -> New Project in the top menu, then in the "Will it use a DEHACKED patch?" dropdown, pick "Yes, using DECOHACK") -- that oughta get you all set up.

Spectres as-is are pretty interesting, but IMO they only work "by accident". Sounds weird, but lemme explain. Pinkies are a flawed monster in hindsight, since you can just back up a couple of inches when they start to bite and you'll take no damage. They're really only a threat if you let them surround you or box you into a corner, and even then you can be like goku and avoid damage anyway. They really only work if you mix in other dangerous peeps that deal the actual damage, with the pinkies themselves serving as a sort of "space denier" that restricts player movement. Bit of a self plug, but MAP28 of MAYhem 2020 ("The Scar") shows this technique off in its first big fight. They're certainly not useless, but they're pretty bad at main role you'd think they would fill (i.e. "get too close and take damage"). Spectres are much more interesting, though -- since they're hard to see in dark areas, they can sneak up on the player to great effect. That said, the player always has a chance to back up if they hear the bite sound or realize they've hit an ""invisible wall"" in time -- i.e. the pinky's biggest weakness is one of the spectres' biggest strengths; it provides the player a reliable method of defense. If you "fix" the pinky by making them attack faster, or charge forward when attacking, or other techniques to make their bite more potent, then spectres suddenly become way too annoying since you can't avoid damage unless you're lucky enough to see them first. You'd basically have to make their attack different than the pinky... which isn't too hard to do, just not very intuitive. ;)

Eeey, good to see all the newest stuff used :P Quick thing real quick, though: Has a GZDoom bug report been opened for this? MBF21 features are supposed to work identically between ports; if there's an inconsistency, it's a bug that needs fixing. That said, "don't playtest with GZDoom" is still sage advice for cross-port projects, since you don't want to accidentally hit any other ZDoomisms like tag 0 lifts and other such things. When in doubt, dsda-doom or Woof! oughta work great.

If there are bugs related to a gameplay mod, you'll have to report those to the gameplay mod developer.

Oh welp, I just re-read the OP -- for the effect you're looking for, A_SpawnItemEx is the tool for the job. It has args that lets you set the spawned actors' velocity directly, so you won't have to mess with pushing them after the fact. Set the `xvel` and `zvel` params, adjust 'em to taste, and adjust the `angle` to spawn 'em outward from the center. Can also toss in some `frandom(x, y)` calls into the various `pos` fields (or `angle`) if you want their initial spawn positions to be randomized.

Are the imps hitting a line with the "Block Monsters" flag, by chance? That will stop 'em dead in their tracks.

Oh hey, I know that one. :P So, normally the answer would indeed be "sorry, no midi unless someone makes one", but... turns out, someone made one :D Midi is by @DCG Retrowave, also thanks to @Bobby :D for commissioning it. May want to double-check with those two before sneaking it into a wad, but I'm cool with it at least. Chaos_Theory.mid.zip

Try A_Blast instead -- it's much more effective.

The title and first post still say "vanilla" -- if you replace that with "GZDoom" then it'll clear up all the confusion for everyone. If making the project run in other ports is something you're interested in doing, it certainly wouldn't hurt to give it a go, but only the reason folks are trying to play it in dsda et.al in the first place is because of the word "vanilla" in the title; change it to GZDoom and you're good. :P For future projects, if you want your project to not be GZDoom-exclusive, you'll need to actively test the project in a different source port (e.g. dsda-doom) while you're working on it. GZDoom is very "permissive" and allows you to do things that might not work in other ports (e.g. PNG graphics, using tag 0 for lift actions, etc.), even if you're not intentionally trying to use GZDoom-exclusive features. If you only test in GZ, you'll inevitably hit one of these.

@OP, if you're feeling like you're having to rush through the levels due to time constraints, you're much better off focusing on a smaller number of levels and making them as good as can be. Don't shoot for an arbitrary number; 32 maps is a crazy amount for a single person to make, even for long-time mappers.

The wiki page Kappes Buur linked is a pretty good starting point, though it could use an update since it's missing some notable stuff -- off the top of my head, dsda-doom, Woof!, Nugget Doom, EDGE Classic, Rum and Raisin, and Helion are missing from the chart, and I'm sure I'm missing several more. All that said, while source port "genealogy" is worth documenting in its own right, it doesn't necessarily map cleanly to editing standard feature support (e.g. Boom, MBF21, et.al) -- for instance, ZDoom isn't directly based on MBF (the source port) or even the original Boom for that matter, but it implements pretty much all of their features, to the point that ZDoom has long been considered "Boom-compatible", give or take a few compatibility flags. :P Then there are newer features like MBF21, UMAPINFO, DSDHacked, and so forth, which are newer standards that were adopted by multiple "downstream" ports that diverged long ago. As a random sample, Doom Retro, Woof!, GZDoom, and Helion all support MBF21, but none of their immediate "ancestor" ports do -- in fact, if you trace it backwards, technically speaking you'd have to go all the way to the original Linux source release to find a true common ancestor... for three of them. The fourth is Helion, which is technically a from-scratch reimplementation of the engine (albeit using the original code as reference). And we certainly couldn't get the shared ancestors to support new features without a time machine or two. :P tl;dr, there's plenty of code sharing, to the point where the ancestry alone isn't quite enough to tell the full picture of what supports what. But maybe that just makes it all the more interesting to research. :P

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.

I can't force y'all to change your project, but I do need to challenge this point. MBF21 has been around for nearly 3 years now, has very good cross-port support, and most critically, these include the same ports that everyone's been using for playing Boom wads. GZDoom and Eternity are up to spec, prboom-plus is now dsda-doom, nobody uses the original boom.exe, relative newcomers like Woof! and Nugget are gaining a playerbase, and Odamex has the co-op* crowd covered. Dropping down to Boom allows players to play the project in... the same ports, plus some old versions of things that almost nobody uses. The entire reason I post in these threads is because most people starting these projects simply don't know there's been an update. There are 15+ years worth of once-sound advice to "use Boom", because for 15+ years that was indeed the best cross-port feature set you could get. That's no longer the case, but people keep stumbling across old advice simply because there's so much of it. Let's stop perpetuating the old myths here. [*re: multiplayer, that's an exception to the rule at the time of writing, since Zandronum and ZDaemon don't have MBF21 support (yet? ;) -- but this is only a concern if you're doing deathmatch, CTF, co-op-only, or some other multiplayer-only set. It's never a bad thing to include co-op support in SP wads, but co-op is a tiny, tiny slice of the pie. It's not worth nerfing your project just to make it work on all 3 MP ports, especially since at some point in the future this will inevitably be moot; the two Z's are in active development, despite rumors to the contrary :P ]

This is a community project -- you're making the decision to remove these features from other mappers' hands, and their absence does nothing to benefit the project or its theme. Keep in mind that this isn't something that requires a "version bump" on everyone's part -- folks don't suddenly have to learn a new map format (e.g. going to UDMF), or be restricted in port choice (e.g. transition the project to GZDoom), or anything of the sort. These features are freely available for use in the target ports, and their absence does nothing to improve the final product.

Well hi there. :P Yup, MBF21 is basically "Boom 2", adds a bunch of new features and works in all the main ports folks use these days -- it's a direct upgrade. This project in particular would get a lot of mileage out of the "Block player" and "Block land monsters" flags. The other side of the coin, UMAPINFO (which us also supported by the same family of ports), lets you arrange maps in whatever order you want, add secret maps wherever, split the projects into episodes if you want, and so forth. For community projects like these, it's best not to have people pre-reserve map slots (or to even have a fixed number of "map slots" at all -- the 32-map restriction is gone) and instead rearrange maps afterward to fit, else you'll get a very chaotic difficulty/theme progression (unless contributors go out of their way to coordinate with their neighbors, which typically doesn't happen).

The "Can't be hit" option is labeled "Visible & untouchable" in WHackEd -- the flags are in the same order in both programs, even if the names differ a bit. This flag's proper name is NOBLOCKMAP (or MF_NOBLOCKMAP if you want to be super literal re: the source code :P ) -- the full explanation of what it does is a bit geeky, though the ZDoom wiki does a sort-of-OK explanation here. Neither OG DeHacked nor WHackEd have a good "name" for it, unfortunately.

Damn, y'all guys are getting AD? I still see this:

If you're targeting MBF21, then UMAPINFO is also available, so you'll be able to split the project into proper episodes of whatever length you want, move the secret maps/exits, expand/shrink the available map slots based on interest, and so forth -- there's no need to stick to Doom 2's 32-map format. Relatedly, it's generally a good idea to have folks reserve an episode (for theme's sake) but not a specific map slot, then figure out the optimal order based on the submissions that come in. If map slots are pre-reserved and there isn't a directed effort to have folks coordinate with their neighbors, you'll end up with super-wonky difficulty curves and pacing issues (e.g. 3 people making huge maps in a row). Or at least reserve the right to rearrange stuff afterward, so folks know to expect it.

Looks damn cool, but as a heads-up it looks like the image is too large for Doomworld's forum software -- it's been scaled down, which renders it hard to use. Try uploading it to Imgur or someplace similarish.

You can instruct GZDoom to always load lights.pk3 by putting LOADLIGHTS = 1 into a GAMEINFO lump in your wad -- there's a similar option for brightmaps.pk3 too, if you need it.

FWIW, I went ahead and made a pull request for an MBF21 compat preset. The only reason it doesn't exist presumably is because nobody got around to making it just yet. :P