Common Mistakes that will no longer make a map vanilla compatible?

[dobu gabu maru]

I'm trying to make a mapset right now (Doom2 textures, only DB2 features) and I would like to make it vanilla compatible. I want to know what to avoid in order to ensure it still works in vanilla doom (like nothing more than 32k line segs). Any tips?

[Mechadon]

If you haven't seen it already, this page will be very helpful.

For me, VPOs are the ones that I struggle with (because detail detail detail and because they can crash the game). Thankfully, if you have the latest version of Doom Builder with the Visplane Explorer plugin, that can make your life much more enjoyable.

There are a lot of other quirks and bugs when mapping for vanilla compatibility, but many of them are aesthetic ones that won't necessarily crash the game. I'm sure someone else will post about them in more detail (maybe).

[glenzinho]

Forgetting to remove the DB 3D Mode thing

[Gez]

The D1/DR line types are the only ones that can safely have a 0 tag.

There are tight limits for a lot more stuff than you'd expect, like moving platforms, scrolling textures, etc. Not just visplanes.

Unknown line types are safe, but unknown sector types will crash if the player gets inside.

No vertical tiling of textures that aren't 128-pixel tall.

Middle textures cannot be made of more than one patch.

[Never_Again]

Special linedefs block "use" action. Example: you won't be able to press a button or open a door if there is a special linedef between you and what you are trying to activate. Note that the blocking special linedef doesn't have to be of the trigger variety, the scrolling special will do as well.

[Scypek2]

Use Chocolate Doom. If a map works fine with it, it should be vanilla compatible. Also:
- If width of a texture isn't a power of two, it will be displayed improperly.
- doombuilder 3d mode thing can be present on a map as long as it doesn't have any difficulty flags set.
- linedefs longer than 1024 units may act weirdly.
- Floor and ceiling of a sector can't move at the same time.

Gez said:

Middle textures cannot be made of more than one patch.

fortunately, that's only true for 2-sided lines.

[printz]

Scypek2 said:

Use Chocolate Doom. If a map works fine with it, it should be vanilla compatible.

Or you can simply run vanilla Doom via DOSBox.

[Snakes]

Neglecting to test in vanilla Doom often leads to one not accounting for infinite heights and blocking decorations (certain hanging corpses especially).

[Grazza]

Gez said:

The D1/DR line types are the only ones that can safely have a 0 tag.

This is worth emphasizing because, in practice, this is by far the most common reason for maps that are intended to be vanilla-compatible (or Boom-compatible) to fail, especially when made with DB and only tested in Zdoom.

Fortunately, it is also easy to detect these problems. In this post I described how to check for these errors using WadAuthor.

If you test in Prboom+ using -complevel 2, then in addition to emulating most vanilla behaviour (apart from limits), the stdout.txt will list a number of things that may cause problems, such as solid hanging decorations, a short reject lump and various other mapping problems. You may find this more user-friendly than a mere crash, or unexplained crazy behaviour in-game.

Passthru issues are harder to track down, since the only ways to avoid them are by thorough testing in a vanilla-compatible exe, or simply not placing the relevant lines too close together to begin with.

[myk]

I agree with the advice to use Doom on DOSBox or Chocolate, as editing "in theory" tends to fail. A very useful tool is Chocolrenderlimits, as it raises some limits somewhat to avoid crashes but lets you see the limits and is still based on Chocolate (so port fixes don't make some issues invisible).

Check also small textures such as steps look, as aligning them may cause tutti frutti lines between tiles, and if you apply multipatch textures on two-sided lines you'll get a medusa effect (which looks like a dynamic tutti frutti and slows the game down.) Some (older?) node builders made for source ports have tended to build maps without REJECT or BLOCKMAP data, that is a no-no, as Doom will read junk from memory instead of the required data, producing weird effects and making demos desynch.

It would also be neat, though, if some generous coder were to create a "vanilla analyzer" tool that listed anything (or most things) not admitted by vanilla in a log or text file.