Foxpup

Debian 10 and Windows 10 (dual-boot), RTX 3090 using official Nvidia drivers for both OSs. Identical behaviour on both systems. Also, I just noticed that OpenGL indexed light mode also causes the invulnerability colormap to be erroneously rendered on top of (instead of underneath) the partial invisibility effect, making partially invisible objects brighter instead of darker. This actually affects gameplay fairly significantly as it makes spectres much harder to see while invulnerable.

When using OpenGL indexed light mode, the invulnerability colormap affects the sky whenever a non-zero palette (eg radsuit) is in effect.

Yeah, it's actually a little surprising that no source ports currently support Buttplug.io for what may euphemistically be called "haptic device control", which I assume is what you're looking for (it's what I'm looking for, at least).

Go into Find and Replace Mode (F3), then for "Search Type" select "Sector Effect" and "Find What" enter "9" (Secret).

If you remember Doom having a high enough resolution to clearly make out floor and ceiling textures, especially in tall rooms where you can only see the ceiling from a distance (no looking up or down), that's the Mandela effect. Go ahead and play that map in the original 320x200 resolution, and you'll see that ceiling as nothing but an ugly aliased mess of blue and black pixels that could easily be mistaken for stars.

In vanilla, these icons appear in the bottom right corner of the screen when loading data from the CD or hard drive respectively, eg when changing levels. I don't know which modern ports, if any, still use them the same way. In any case, you're unlikely to see them for more than one frame on a modern system.

Flats go between FF_START and F_END. (Technically they only need to be before F_END and without F_START; FF_ markers do nothing in game and are purely for organizational purposes.) It's not clear what's going on in that first screenshot; my guess is that whatever garbage value the engine came up with trying to look up a flat that isn't before F_END just happened to be a valid lump by pure chance, though it's visually corrupt since it isn't a flat. Usually you'll get a wildly out of bounds value that crashes the game instead; don't rely on this behaviour.

They don't. They normally only return to idle when their current target dies, which need not be their original target; if a monster starts infighting, it will ignore the player even after killing the other monster... unless the player ever made a noise in the sector, which re-alerts the monster and causes them to target the player again, no matter how long ago the noise occurred. (This behaviour is not specific to Chocolate Doom; it happens in vanilla and any port that doesn't alter monster AI.) The other way monsters can become idle is to load a saved game, which does not restore monster targets. This is a bug in vanilla Doom that is replicated in Chocolate Doom, but fixed in most other ports.

You're mistaken. Type 117, like all manual door actions, ignores tags completely and instead affects the sector on the back side of the trigger line. The crash here occurs because the line in question is one-sided, resulting in a (usually fatal) wild pointer access when trying to find the nonexistent back sector. Doors aren't true ceiling actions either, and I don't think there's a limit to how many can be active at once. At least I've pancaked larger maps than MAP06 with a forgotten door tag in vanilla without crashing.

It certainly would have said much more than that. Please post the exact text of the message displayed by your antivirus software or a screenshot of same. Without further details, it is impossible to determine if this is a false positive or if you do indeed have an infected file (extremely unlikely if you downloaded it from ModDB, though only moderately unlikely if you inexplicably downloaded it from some shady warez site despite it being a free mod).

You generally can't run multiple mods simultaneously and expect them to work correctly. You certainly can't claim to have encountered a bug in either Doom or any of your mods unless you can reproduce it with no mods or a single mod respectively.

Raise-and-change-texture actions use the trigger line's front-side sector to set the floor texture, as opposed to lower-and-change-texture actions which use the sector adjacent to the tagged sector as you're expecting. You can place a thin dummy sector in front of the trigger line to set the desired texture.

Remember that you can open both versions of your map simultaneously in two instances of Doom Builder, and copy-paste map structures between them. There should be no need to rebuild the area by hand.

No, the problem is vanilla Doom. Chocolate Doom intentionally emulates all of the bugs and limitations present in vanilla, for testing purposes; if Chocolate Doom doesn't crash on a WAD that crashes vanilla Doom, that's a bug.

That's one approach, though you can go a long way by blocking off complex areas from other complex areas with one-sided lines so the engine isn't trying to render everything at once. These are really engine limits, not map format limits. You can make very complex maps in Doom format as long as you target limit-removing ports (ie, pretty much everything except Chocolate/vanilla).

Custom flats need to go between FF_START and F_END, not FF_END. (Strictly speaking, they just need to be before F_END, with FF_START being completely ignored by the engine. F_START, if present, tells the engine to expect all flats to be in the PWAD, and so is not normally used as then the IWAD flats won't work.) The rendering error is a drawsegs overflow, and is caused by too many lines in view at once. You want to avoid having areas with a clear view into the rest of the map. Visplane Explorer mode in Ultimate Doom Builder can help you identify problematic areas (and will also help you avoid the similar but more serious visplane overflows, which will crash the game instead of just causing a harmless rendering glitch).

U restores data from DOOMHACK.EXE instead of DOOM(2).EXE, to undo changes you haven't yet applied (same effect as restarting DeHackEd after quitting without saving).

Press Z in DeHackEd to restore the original game data before loading your DEH file.

This issue is why custom sprites are a pain to get working in vanilla Doom (and why some sources claim it's outright impossible). The fact is you do have duplicate lump names: those in the IWAD and those in the PWAD. There are two ways around this: Use a WAD merging utility such as DeuSF to place the IWAD sprites in your PWAD (or vice versa, though I don't recommend modifying your IWAD), so that all sprites are in a single WAD with no duplicates. Note that the resulting merged WAD will be illegal to distribute; you must distribute your PWAD with only the new sprites plus instructions for users to perform the merge operation themselves. (The -merge parameter in Chocolate Doom will emulate this without actually modifying your WADs.) Alternatively, you can rename your sprites completely, and use DeHackEd to change the sprite names in the engine. The new sprites also need to be between SS_START and S_END markers for this to work (not S_START).

Flats are simple: they just need to go between FF_START and F_END markers, and be converted to Doom Flat format (which is different from the Doom Gfx format used for sprites and wall patches). Do not use F_START: this tells Doom to expect all flats to be in your PWAD, and the original flats won't work. The docile imp is harder to diagnose without seeing your WAD, since it has many potential causes. It could be too close to walls or other monsters. Some ports allow monsters to move away from such obstructions, but in vanilla they will be stuck and unable to move or attack. Note that a thing's collision box is actually square, not circular, as misleadingly displayed in some editors. Also make sure you haven't accidentally placed two of the same monster on top of each other, which can be hard to notice in the editor. Your map may have a corrupt REJECT lump. This is created by the nodebuilder and is used to speed line-of-sight calculations in the engine. Like most nodebuilding-adjacent problems, the usual causes are bad map geometry (eg linedefs crossing or overlapping), extremely large or complex geometry (more than vanilla Doom can handle), or conversely, extremely simple geometry (a single sector map will often fail to build valid nodes - you need at least two). In rare cases, Doom's line-of-sight code may just straight up not work correctly, despite your map having no errors. Moving the monster slightly can fix it.

Doesn't work with vanilla gameplay. Weapons remain in place when picked up, so all players can get all weapons. Keys work the same way. Speaking of keys, in vanilla players lose all keys on death, making keyed doors that don't stay open an awful lot of fun as respawned players get to go through the whole level again to fetch all the keys (though this can be mitigated somewhat by having new connections open up to make reaching the keys from the start less tedious). Another problem with keyed doors not staying open is that players can enter such a door without the required key (by following another player who does have the key) and then get trapped when it closes (if it requires a key from both sides, as is usually the case), forcing the other player to go back and let them out. Make sure there's another way to get out or make progress in such cases (or just use doors that stay open).

You're not the first one to be annoyed by this warning: Jeff Rabenhorst, author of EdMap, was sufficiently annoyed by it to write a utility for bypassing it and include it with the editor. It's called STUFFBUF and works by adding simulated keypresses into the input buffer. Download EdMap, extract STUFFBUF.EXE (and the rest of the editor, if these ancient DOS editors are your thing), then run Doom through it with: stuffbuf doom -file filename.wad!! (The double exclamation mark tells STUFFBUF to simulate pressing enter twice after typing the command, once to run Doom and the second time to dismiss the warning.) This utility is naturally more useful in batch files and external launchers (which is its intended use), since running it by hand doesn't really offer any advantage over just pressing enter a second time yourself.

It's certainly possible; after all, DOSBox for browser exists, and many (probably most) DOS editors work well in DOSBox, so theoretically it's just a matter of putting all the pieces together on a web server somewhere (pieces which include a full version of Doom/Doom II, since most of these editors will refuse to work with the shareware version, which may pose a slight legal challenge).

That depends largely on exactly what OP's problem is with having multiple executables. If the intention is to actually play episode 4 levels with accurate non-Ultimate Doom behaviour, it simply can't be done: some of those levels depend on the new behaviours introduced in Ultimate Doom, and will completely break without them; have fun beating E4M6 in an engine that thinks bosses only do something special on level 8, for example. @roboticmehdi2, if you could tell us what you're actually hoping to achieve here, we might be able to suggest a more suitable method.

That's "free" as in "free beer", not "free speech". Shareware games are still subject to copyright (see section 2 of shareware Doom's license agreement), and using them as a base for a new work is probably illegal and certainly immoral.