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.

Is there a way to enforce BEX mnemonics for flags/mbf21 flags in the output file? Better yet, maybe it's worth making that default behavior for non-vanilla compats? It's a good deal more annoying trying to peruse wads made with decohack than it is with Whacked/hand editing (e.g. Crusader vs Eviternity). Ditto making a quick edit by hand when testing own stuff.

Jumping to Raise state doesn't reset health, flags etc by itself. To do that in zscript you can throw in an extra frame that calls Revive. class UndyingChaingunGuy : ChaingunGuy replaces ChaingunGuy { Default { Health 50; Mass 10000; PainChance 256; Dropitem ""; } States { Death: CPOS H 5; CPOS I 5 A_Scream; CPOS J 5; CPOS KLM 5; CPOS N 35; CPOS N 0 Revive; Goto Raise; XDeath: CPOS O 5; CPOS P 5 A_XScream; CPOS Q 5; CPOS RS 5; CPOS T 35; CPOS T 0 Revive; Goto Raise; } }

Gzdoom builder is outdated and unsupported, download Ultimate Doom Builder instead.

I guess my naturally-evolved crutch is reliance on some gimmicky idea to kick off the map. Whether it's a specific fight that I want to implement or a weird doom engine mechanic, my maps never begin with something like a "sense of place" or "visual theme". As a corollary I seem to regularly arrive at some form of "precarious terrain"/"watch your step" being a part of my creations. I imagine I will stick to this for an undetermined while since neither I map that often nor does the approach run contrary to what I do and don't find engaging about doom mapping. If you ever see me making an E1-style techbase, I'm probably secretly balancing it for Nightmare! or something :)

Another weird edge case bug report: Helion appears to handle transfer of secret property wrong (as in different from Doom/Boom). A secret sector can be turned "on" and "off" repeatedly by transfer lines and re-tagged for counting purposes (even in dos doom executable with vanilla transfer properties, and certainly in dos boom exe). I've recently made a map that relies on this silly behavior and only the "real" secret (in a long voodoo closet to the north of play area) can be tagged in Helion.

What exactly is the case behind textured automap being disallowed in strict mode? Does it reveal so much of something extra it can be comparable to iddt? Or is it about something like using textures for setups?

https://dsdarchive.com/intro I know it's a bit sideways to what you asked, but using those things you mentioned already disqualifies your demos by DSDA Archive standards, which is just about the only general definition of "cheating in demos" there is (individual smaller competitions like DW Ironman League and others nonwithstanding). Conversely, if you don't care about uploading demos to DSDA, then just do what you like and mention it alongside demo file/video/whatever I guess.

If that does what you want in Zandro, maybe put it into zandronum_patch.wad, add a note in .txt and call it a day? Corruption goes with that approach, and that wad has your name on the author list, so I feel weird suggesting that :)

Ever felt like 100% is just too low of a number? Well then look no further. Download (gdrive) I didn't expect to pick up doom editors this year anymore, but sometimes a borderline shitpost idea calls. You've got 15 minutes to survive for, a Speed Of Doom MAP30-esque scenario and a little magic to make all them numbers B I G. Pick your favorite end screen number, some or all of them, and knock yourself out making it as big as you can in the alloted time. Compatibility: MBF21 + umapinfo Tested with: dsda-doom 0.27 May not work with: idk, other ports may have different ideas about interactions of COUNTITEM flag manipulations with tally. Secret tally is DOS boom compatible, fwiw. Playtime: ~15 minutes (not counting dying) Difficulties: No, you'll die to infigting rockets anyway. ITYTD is a perfectly valid choice. Jump/crouch/etc: whatever you like Gameplay changes: - Ammo pickups count for item% (before you scream cheating - I could spawn "real" items underneath but why). - Chaingun goes brrr. - Ammo, health and Cybers/hitscanners will spawn periodically. Ammo and hitscanner types are random. - Cube spawners are silent. Mod compatibility: I pushed all custom things dehacked stuff into 3000+ frame range, so dehacked weapon mods might work. Mods that change Cyberdemons and any zombies might be broken or produce smaller numbers. Credits: - Textures/sky: 32-in-24 - Midi: "Young and Dead" by Velvetic - Doom tools for making this take a day instead of multiple evenings.

You'll have to creatively get close to its behavior with existing codepointers if you want to specifically use dehacked. For example, it seems to use A_Jump to shift by x frames a lot, the dehacked (mbf) equivalent A_RandomJump can only jump to a specific target frame, so you'll have to define state labels and jump to those instead so decohack can figure out exact frames for you. A_CustomMissile can be substituted by MBF21's A_MonsterProjectile. A_FastChase is not a thing, use A_Chase. There is no such thing as A_Countdown in dehacked either, you'll have to find alternative ways to replicate its functionality. And so on, so forth, you'll have to look at and understand every single thing about how the monster works and find what to replace that with, or how to create similar logic within confines of dehacked. It's not going to be a "quick copypaste" kind of deal.