Foxpup

That's not technically a question (basic or otherwise), but yes, a door (or any other action) can be activated in as many ways as you have linedefs tagged to it. If your intention is to make a door that can only be opened by a switch, the linedefs comprising the door itself must not be tagged to open the door manually.

Reject table inaccuracies and blockmap misalignments are the more likely culprits in that case, but yes there are edge cases where the nodes themselves can cause desyncs.

Not at all (at least not in this particular case); it's actually the fault of whoever set the monsters' properties. Contrary to assertions that Doom has only 2±0.5 dimensions, the Z axis exists and is taken into account when it comes to monster movement; monsters cannot enter sectors that are shorter than their defined height. The problem here is that the revenant has its height set to 56 units (the same as the player and humanoid enemies) despite its sprites being around 80 units tall, thus allowing it to fit under ceilings significantly lower than its visible appearance. (The arch-vile has the same issue, though it's less frequently noticed, due to it rarely appearing in tight spaces.)

It definitely looks like an unclosed sector (though it's impossible to be sure without seeing the WAD itself); you can often fix these by going into Make Sectors mode (M) and clicking on the problem sectors. Note that this may split or merge sectors you didn't intend to, so you should only try this as a last resort and try to avoid creating invalid geometry in the first place. No, the editor grid is purely an aid for creating evenly sized and aligned geometry; it isn't used at all by the game itself, either for rendering or any other purpose.

The null texture name is a single hyphen character ("-"), not blank. Leaving the texture name blank won't work and isn't allowed.

Surround sound output of any kind isn't in the original Doom mixer, so virtual surround headphones have nothing to work with anyway in that case. Any ports that do support surround sound output are probably doing so using a modern 3D sound API with HRTF for proper specialisation with regular headphones. A quick glance at the OpenAL docs suggests that this is enabled by default if the OS reports stereo headphones are connected; nether developers nor users need to do anything to get this behaviour. Virtual surround headphones won't provide any benefit in that case either since the sound library is doing it already.

It absolutely is enough, if you use a head-related transfer function that properly accounts for the fore-aft asymmetry of the human head and ears causing sounds in front of you to sound different from sounds behind you. Doom's mixer of course didn't use a head-related transfer function, though I think most modern game engines (including Unity) do, and is also how surround headphones work under the hood. (How else would they work? You've still only got two ears, after all.) This also means there's no point in using surround headphones if the engine already provides HRTF for regular stereo headphones.

We might indeed, in which case correspondence chess was probably the first multiplayer game played entirely online. Avoiding such ridiculous answers is why we're asking you to define your terms.

What do you think the Internet even is, but a bunch of devices connected with cables or similar communication lines? That's what the "line" in "online" literally refers to, after all. Networks similar to the modern Internet have existed since ARPANET first came online in 1969. Please define your terms if you want a useful answer.

Are you using a resource mod/DeHackEd patch that alters the gore things and/or add new ones? Because there are definitely not blocking and non-blocking versions of this thing in unmodified Doom 2.

What is the type number of the thing you're using? Because I can find no such thing as "hanging corpse looking down"; the closest is "hanging torso, looking down" (type 75), which is blocking and correctly identified as such in UDB, and there is no non-blocking version of this thing.

That one's not a true void glide, though: it's an intercepts overflow, an entirely unrelated glitch. The reason it has only been utilised very recently is because it is almost impossible to trigger on demand (at least in the stock IWAD levels) and even harder still to do anything useful with: it completely disables all collision detection on the map, which means normal exit lines can't be triggered and bosses can't be killed, so the only way to complete the map is through the rarely used exit sector special. Trigger the glitch on any map which doesn't have such an exit (ie, literally anything except E1M8 and a very few PWAD maps) and you're stuck and have no option but to restart.

The arch-vile attack normally does 20 direct hit damage plus up to 70 blast damage (though in practice the damage is always slightly less than that since the target isn't at the exact center of the explosion). The attack only doing 20 damage means something (eg map geometry) is blocking blast damage, which has nothing to do with the monster's speed.

It's also worth noting that nearly all damage randomisation follows a discrete uniform distribution rather than any kind of bell curve distribution, so maximum and minimum damage values are just as likely as average values. The wide range of random damage values is very much an integral part of Doom's gameplay, encouraging evasion and movement tactics rather than expecting the player to just tank hits, since you never know whether that revenant missile will knock off 80 health or not. Be aware that using mods that change or remove damage randomisation will create a very different experience.

Far less improbable than you might think. Most embedded devices more advanced than a microwave oven are running some flavour of Linux, and the original Doom source release was for the Linux version. It seems like a joke (and it technically is), but it's probably actually easier to port Doom to these devices than to Windows. Not much easier, mind you: Doom was originally designed on NeXTSTEP while being intended to run on DOS, so it was designed with some degree of cross-platform portability in mind from the very start, which no doubt simplified later porting efforts.