Da Werecat

I doubt it would apply to all of the industrial levels.

Sounds like -shorttics though? I recall there were issues with that, but I don't remember when/if they were resolved.

You can say that the opposite applies as well. Switch-operated crushers aren't obvious by definition, so the "protagonist" may very well activate one by accident. So there is no inherent difference, from the hero's standpoint or from the player's. But the idea appealed to me on some aesthetical level, I'm not sure exactly why.

I kind of feel the same here, TBH. More clarity = good. Making things nice and cozy and achievable in a straightforward manner = giving up, pretty much.

Crushers could be separated by activation method. Switch-activated are obviously intentional, while walkover crushers are obviously not exactly? As a frequent watcher (but not a runner) I had more problems with Tyson due to the fact that you're allowed to pistol everything to death. Not only does it look like a huge compromise, it's also excruciatingly tedious to watch.

The thing about making the monsters infight is that you're using their own hate against them. It's poetic. You may have provided an opportunity, but it's their desire to kill that produces death. It's not the same with crushers, because stupidly walking into a hazard is not a crime. And crusher isn't a living being, so it's more akin to a weapon than a monster you manipulate. These are "feel" objections that would make the rules impossible on several maps though. Kind of like MAP30 was thought to be impossible, except I doubt people would try as hard with a PWAD map.

I thought syntax changed in PrBoom from MBF?

Having legacy OPTIONS would be sweet. However, new features would require a different lump to preserve compatibility with stock MBF.

IIRC, aggroing is tied to pain animation. A single rocket only has two chances of triggering it: from the rocket itself and from the splash damage. Which is more than most attacks in the game, but still not a lot.

Nice damage boost.

Classic Doom in BFG has plenty of shortcomings, TBH. They only did about enough to sorta make it run, kinda, and that's about it.

Hmph. Is there a comprehensive list of such quirks exhibited by certain thing numbers, states, or codepointers? I only knew about arch-vile. I also know that moving around chaingun flash states can be disastrous if done wrong, and maybe a couple more minor things. But this seems to go deeper, with subtle changes in behavior that wouldn't be noticeable right away.

Have there been any discussion about modifying MUSINFO functionality to include crossfading? This would allow implementing Quake-like area-specific ambient sounds with a reasonable amount of shorter tracks. It could also potentially allow to remove or minimize the switching delay that makes good synchronization difficult.

Sometimes I wish classic ports had scaling, TBH. One of the long-standing issues I've experienced involves faraway scenery like texture trees. Midget vegetation is a bit of a staple of Doom-derived games, but if you're ambitious you might wanna attempt a more realistic scale. This could be achieved in two ways. Both involve making gigantular textures (provided the source port of choice supports them), but in one case it's a properly detailed texture that looks good (if terribly flat) up close; the other means simply resizing an existing small texture. The former seems like one big advantage, until you consider that it takes effort to actually make it look good. You'd want to have them at a bunch of sizes too. Then again, while it involves a lot of wasted effort and space for all the detailing that will probably be removed quite far from the action, the latter is a perfectionist's nightmare: all the wasted space is still there, except now it's properly wasted on duplicated pixels or blurry craptaculance depending on the method of resizing. But at least it's quick. Then again, even with the former method that just seems like a luxurious waste of time, there may still be aesthetic issues. I remember someone saying that pixels should all be the same in a game where they're huge. This might be true in a level that is close in scale and detailing to something IWAD-like; I'm not so sure about expansive scenery, because then the contrast between the chunky foreground and the noisy background may be too jarring. Of course, using stock-like textures makes it all the worse, because then you can add a bunch of repeating patterns to the aforementioned background's issues, which would in turn necessitate a lot of complexity in the faraway structures. Which would then lead to even more noise. Engine-side scaling won't solve the problem of gigantular pixels if the player is allowed to approach the decoration, but this is a mapping issue. The efficiency of it would justify everything. Feels like slowly reinventing ZDoom though.

If not for rotating and scaling, then what's the point?

I meant disabling the aspect ratio correction. It's for a potential TC. Working on squashed graphics is a bother, and it's annoying to have to uphold a quarter-century-old standard that was only relevant for a few years. I can sort of approximate it with setting a wrong aspect ratio, but it's far from perfect.

Is there any reliable way to enable square pixels?

How would they break if it will only work with the new spec patches? Or will the new spec patches be exactly like the old patches including DEHACKED lump name?

EEEXCELENT.

Wouldn't extending the feature set already break things? Old behavior should be used with old spec patches.

I don't know about Misc, more like I thought it would be useful to simply make it work by default, provided that the dehacked entry is of the expanded type. I actually tried to imagine a way to abuse the behavior of subtracting the max shells counter until it's in the negatives, but I'm yet to come up with something non-broken. Auto-fire is EZ though, just mix some ReFire into WeaponReady, much like one would do when disabling the first precise pistol/chaingun shots. Wasn't sure it would work, but tested it just now. Of course, as with many hacks, an additional state is wasted.

Death is easy, just use custom MBF action for playing sounds. Sight - I don't know, doing the same sounds hacky to me, requires some testing.

A_Spawn was technically a good universal way to specify any drop, and without being bound to any specific frame during the death animation.

Suggestion: infinite ammo with non-melee attack codepointer = shouldn't subtract ammo from anywhere. A weird omission in BEX patches, since it shouldn't be that hard to implement.

Just call it DEXTER. Dexter likes to hack!