Foxpup

Yes, monsters move diagonally by non-integral distances, as defined by the xspeed[8] and yspeed[8] arrays in p_enemy.c, which are the movement speed multipliers for each of the eight directions. Oddly, the diagonal speed multiplier is exactly 47000/65536 (0.71716) instead of the more accurate 46341/65536 (0.70711), making monsters move slightly faster diagonally than they should. Nothing subsequently snaps monster positions to integral coordinates.

For some reason, you have the melee attack set to one of the chase frames (frame 209). This is an infinite loop, as the chase state will instantly switch to the melee attack state (which in turn restarts the chase state ad infinitum) whenever there's a target within melee range (eg, immediately after a successful lost soul attack).

You also need to place a teleport destination Thing inside the tagged sector, and it must be flagged to appear on all relevant skill levels/game modes.

Incidentally, the reason why adding WFALL1-WFALL4 textures to a WAD "just works" without requiring any additional hacks is that this animation sequence has always been defined in all versions of the game despite there being no textures for it until Final Doom. This may be why you misremembered it as already existing. (It's the same story for the nonexistent SWATER1-SWATER4 animated flat, which can also be used simply by providing the missing flats for it.)

Well, the other part of the negativity is that some things just are negative. You asked us (quite emphatically) to confirm this effect of saving and reloading and we did. That confirmation included the inconvenient fact that your discovery has already been discovered and well documented by others before you. I can see how this is disappointing, especially if you put a lot of time and effort into it, but you shouldn't let it discourage you. Not every great idea you have will be a winner; you just have to keep at it and hope the next one will be better.

At least part of the negativity stems from the simple fact that allowing saving and loading in speedruns would allow far more shenanigans than this. There is actually quite a lot of game state that is lost/reset when loading a saved game. In particular, saving and loading restores normal gameplay after triggering the all-ghosts bug, thus trivialising any map where that bug can be triggered on demand (though it does allow 100% secrets on E4M3, for what that's worth). There are also less game-breaking but still unfairly beneficial tricks such as making monsters forget their targets and making revenant and archvile attacks miss. Part of the reason Doom speedrunning doesn't need a "glitchless" category is that the single-segment requirement automatically excludes an entire class of known glitches.

There's nothing wrong with your DEHACKED lump, and I don't know why you thought it was to blame. Remember that projectile speeds are multiplied by 65536, so your projectile actually had a speed of "only" 70. This is still extremely high, and you may observe various problems with projectiles this fast, but crashing the game isn't one of them. No, the reason your WAD crashes is simply that you forgot to convert your punch sprites (PUNG*), which are still in PNG format. Any port that can't use PNG sprites will crash when a player selects the fist (either manually or automatically when going berserk or running out of ammo).

More specifically, switches, teleporters, and manual/push actions work only from the front side. Walkover actions other than teleporters and all gunfire actions work from either side.

There are a few exhibition and cowboy action shooters who are this fast, though it's probably not a viable technique under combat conditions. The real question is why Doomguy fires the pump shotgun so slowly by comparison: anyone this skilled can easily run a pump gun almost as fast as an autoloader. It's almost comical the way Doomguy handles the pump shotgun like a total beginner but the double-barrel like a world champion.

Just teleporters, specifically. This is so that a traditional pad-to-pad teleporter won't just immediately teleport the player again when they step off the destination pad.

The original v1.3D release is clearly the best. They never should have patched out Duke's impressive hopak dance moves.

Which WADs specifically are you trying to play? If they require a modern source port, well, there's your answer. Or are you having this issue with vanilla-compatible WADs or the original IWADs?

What you're seeing is pincushion distortion from mapping the cylindrical projection used in sky textures to the gnomonic perspective used to render the game world, so that the rendering of the sky visually matches the rest of the world. For example, step onto the balcony at the start of Doom 2 MAP01, and turn slowly while looking at the sky through the fence. Observe that the horizontal spacing between the fence posts changes as your view rotates due to perspective, and the sky distorts to match it (at least on the horizontal axis). The perspective mapping of the sky is done using the precomputed math table xtoviewangle[], which is generated in R_InitTextureMapping() using the tangent table. The effect is that each vertical column of pixels in the sky texture is stretched horizontally by a factor of 1/cos2(α) where α is the viewing angle relative to the centre of the screen.

Write caching is the culprit. When you save a file, it is not actually written to disk immediately, instead it is temporarily stored in the disk cache so that multiple file operations can be batched up and written to disk all at once, improving both throughput and disk lifespan by reducing the number of physical writes required. It does have the nasty side effect that a power failure will cause loss or corruption of cached files that you thought were already saved, which includes not just your WAD but also UDB's configuration files. Write caching can be disabled if you want extra protection against this type of event, though it will impact disk performance. An uninterruptible power supply is a far better solution to the problem of power failures.

Actually, the fact that projectiles without NOBLOCKMAP will randomly crash vanilla Doom has been common knowledge since as early as 1995 (the phenomenon is mentioned in Fun with DeHackEd!, for example), though until this thread I don't think anyone has known why.

No doubt this is because Blue Shift isn't actually a Half-Life mod; it actually uses its own modified engine (for some reason), and is totally incompatible with the original Half-Life engine. It would indeed instantly crash if you tried to load it as a Half-Life mod, so the behaviour in the update isn't a regression.

This actually pre-dates ZDoom - the first source port to add vertical spread to all hitscan weapons was none other than DOSDoom , which I don't think even gives you an option to restore the original behaviour at all.

Part of it is coming from the fact this is the usual reason for people to ask questions similar to yours, but most of it is coming from the fact that you said "ya pretty much" when I straight-up asked you whether this is the case.

Inb4 "the hanged corpse sprites are edited photographs of the execution of Mussolini and his followers". They're not.

Considering the error message specifically refers to a sky texture, this may have been worth mentioning earlier. Does your WAD's TEXTURE1 lump (or TEXTURE2 if present) contain a valid texture named "SKY3"? Because it needs to even if your map doesn't contain any sky sectors, as Doom unconditionally attempts to load the hardcoded sky textures when starting a new game.

They say the definition of insanity is doing the same thing repeatedly and expecting a different result. That's actually not the case: the definition of insanity is being mentally incapable of controlling one's actions or understanding the difference between right and wrong, and therefore being unable to be held legally or morally responsible for said actions. Still, it is the case that you're doing the same thing repeatedly and expecting a different result, so let's start there. You still have state 741's next state inexplicably set to 737. (Also, I think you need to think harder about how your monster's pain and death states are going to work if you're overwriting them with an extended attack.)

Are you using a third-party texture/resource WAD for your map? If so, what does its text file say about advanced engine requirements?

Every WAD you download should include a text file detailing (among other thing) whether an advanced engine is needed to run it. PrBoom+ (and DSDA-Doom) are not advanced engines - they are basic limit-removing Boom ports. If the "advanced engine needed" is anything other than "Boom", "limit removing", or "no"/"vanilla", the WAD is (probably) not compatible with PrBoom+/DSDA-Doom and cannot be expected to run without errors.

Corrupt geometry can sometimes be magically fixed by clicking on the problem sectors in Make Sectors mode; beyond that it's impossible to suggest anything without seeing the WAD.

It does in co-op multiplayer, and BFG tracers absolutely do not discriminate.