Doomy__Doom

You could be facing some variation of this issue. In UDB you should avoid sectors that close on themselves with a single line, trying to draw any complex geometry (sometimes just any lines at all even) inside them can produce weird outcomes - unwanted sector merges, voids and whatnot:

If all you need to do is add a custom sky on top of 32-in-24 - just copy pnames/texturex from that via slade and add your sky there. Project lead will have to reassemble pnames/texturex for the final wad anyways, so I wouldn't spend time worrying about cleaning out unused textures from there and whatnot, as long as the map can be tested with 32-in-24 loaded before your wad.

You're making the classic mistake of not merging pnames/texturex. Zdoom does it for you. Most (if not all?) boom family ports do not, only the last lump in the load order is used. So most textures are missing from Woof/prboom/dsda perspective.

Indistinguishable copies of same monster types with messy and weird infighting groups/no retaliation setups.

If Arch-Viles and spawner entities aren't involved, then just setting original enemies to COUNTITEM and making them drop an actual pickable item should keep the count consistent. A_SpawnObject-ing something with COUNTIKILL does not increase map item total. At least in DSDA-Doom, that's the only port on which I tested applying the idea to a map to deliberately go over 100% count (ammo pickups have COUNTITEM set initially in properties and are repeatedly spawned via A_SpawnObject). No clue if it's consistent with other ports' handling. If Arch-Viles are involved, resurrections don't update map item total, so you'd go over 100% (again tested only on dsda-doom). In that case, you could hack a bit of logic to distinguish first death by setting one of the "free" ExMyBOSS flags and branching with A_JumpIfFlagsSet whether to spawn the pickup or not based on that. ExMyBOSS is only relevant to Doom 1 bossdeath logic, so it should not cause an issue in Doom 2-targeting map. If you want entire corpses to be visually pickable up, then I guess last frame of death animation goes to TNT1, spawned "armor bonus" has the corpse frame. It's probably better to just make those enemies have no raise state to avoid the complexity of dealing with Viles resurrecting stuff out of thin air. Re:original question, I honestly don't know how game decides that something needs squishing.

Then you have to refer to the actual patch in question. If it has bits - you have to use those, otherwise take defaults for the respective thing it alters.

Ability to add codepointers to arbitrary frames requires BEX (Boom and up). Vanilla dehacked cannot do that because of limitations related to physically modifying original exe - you can only change (not even delete/clear) original codepointer placements. Doom 1.9 configuration in Whacked follows vanilla restrictions and produces vanilla-compatible patch format.

It does here under "SPECIAL: DSDHACKED Patch Behavior":

You just decide what your sprite willl be named and use it. Decohack using arbitrary NEWS sprite name: #include <dsdhacked> #include <friendly> thing 152 { states { Spawn: NEWS AB 10 A_Look Loop } } Generated output with auto-added [SPRITES]: Patch File for DeHackEd v3.0 # Created with DECOHack v0.30.3 by Matt Tropiano # Note: Use the pound sign ('#') to start comment lines. Doom version = 2021 Patch format = 6 Thing 152 (Extra thing 1) Initial frame = 1100 Frame 1100 Sprite number = 245 Next frame = 1101 Duration = 10 Frame 1101 Sprite number = 245 Sprite subnumber = 1 Next frame = 1100 Duration = 10 [CODEPTR] FRAME 1100 = Look FRAME 1101 = Look [SPRITES] 245 = NEWS Obviously, you'll need to actually put in a sprite named NEWS<+rotation mnemonics> into the wad.

Here's to another 30 years and then some. Also a minor issue: top 12 page one reads "Home > Top Ten - Page 1" in the navbar at the site top.

Your freelook mouse will not be bound vertically by strafe key, so your view will likely drift up/down instead of seeing where you're going (or get wobbly). Instead, bind turn right/left to other keys (not A/D). I use Z/X, because it's easy to press with a thumb without moving hand off of WASD in any way. So for example [w]+[d]+[x]+[rmb] to sr50 forward right.

There are plenty of buttons you can use on a modern source port, doubly so if you mainly play maps without jumping/crouching. My setup is: - WASD: for usual things - 1234FEQ: weapons (FEQ replaces 567) - Space: interact - Mouse wheel: interact, input spam edition - LMB: pewpew - RMB: strafe on (for quick mouse SR-50 method, locking facing etc) - Z/X: turn left/right (for long SR-50) - Shift: toggle run, I don't use walking speed much but you never know - Tab: automap - R: vertical mouse movement toggle - T/Y/G: keyframe/rewind-related stuff C/Ctrl are unused in case I ever need jump/crouch without changing the whole setup or some really important feature suddenly becomes a thing. I'm not in a habit of using any hud toggles either.

100% vanilla - you're stuck with 100% vanilla placement of text screens, secret exits and boss death mechanics.

No. Because you're editing existing weapons that already have flags set on them as per MBF21 spec that correspond to vanilla doom weapon behaviors. For example, if you're replacing the pistol with a new rocket launcher, you might not want AUTOSWITCHFROM to stay there. Hard to tell without seeing the relevant part (presumably A_WeaponProjectile?) or better yet the entire decohack file. The only thing I can suggest blind is to make sure your projectile code is defined before weapon code so the parser definitely sees it first.

"Edge" config in DBX is for Doom format (there is a separate Edge UDMF config for UDB). There is no line horizon in Doom format. You have to do it the classic way, with 0-height sky sector. See how, idk, Sunder 05 does it. Plenty of maps out there to reference.