Chocolate Doom error: R_DrawSpriteRange: bad texturecolumn

I'm trying to make my maps vanilla compatible. It happens when I run my wad in Chocolate Doom. What causes that and how do I fix it?

Heres the doom wiki page on the error but I don't know what it means.
http://doom.wikia.com/wiki/Error_message#R_DrawSpriteRange:_bad_texturecolumn

n e one?

Most likely reason is that your WAD has sprite replacements, which Vanilla Doom doesn't support directly (you have to use something like DEUSF to patch your IWAD file). In Chocolate Doom, you can use '-merge' on the command line instead of '-file' to load your WAD file, which will merge your sprites in a way that simulates DEUSF.

I've always wondered -- why do you get this error message if you don't merge the IWAD sprites into your PWAD? It doesn't make much sense to me.

Never_Again said:

Does your WAD replace any graphics?

yes

fraggle said:

Most likely reason is that your WAD has sprite replacements, which Vanilla Doom doesn't support directly (you have to use something like DEUSF to patch your IWAD file). In Chocolate Doom, you can use '-merge' on the command line instead of '-file' to load your WAD file, which will merge your sprites in a way that simulates DEUSF.

it does have sprites. -merge fixes that, thanks.

but I get this sometimes
Error: W_CacheLumpNum: 6687437 >= numlumps
it doesn't matter too much though, thanks for the help guys. my wad wont be vanilla compatible i decided theres too many limitations for what i want to do.

InsanityBringer said:

I've always wondered -- why do you get this error message if you don't merge the IWAD sprites into your PWAD? It doesn't make much sense to me.

It is probably one of the least understood errors, given that even I cannot answer the question. I guess I need to dig into the code and figure out exactly what goes on to cause this.

EDIT: OK here's what I surmise happens:

1. S_START/S_END being overridden in the PWAD causes the sprites in the IWAD to be ignored.
   
2. This causes the spritedef_t structures for any sprites not replaced in the PWAD to remain uninitialized.
   
3. DOOM happily accesses the uninitialized spritedef_t and puts a garbage value into the patch member of the vissprite. If this is still within range of the master wad directory when added to firstspritelump, the game loads some unrelated lump as a patch_t, leading to a bad texturecolumn error. If it's not within range, you get a W_CacheLumpNum error instead.
   

InsanityBringer said:

I've always wondered -- why do you get this error message if you don't merge the IWAD sprites into your PWAD? It doesn't make much sense to me.

I'll do my best to explain.

When you look at a WAD in an editor like NWT (or XWE?) you see a list of lumps with names. When you load a WAD file with '-file', it adds the list from the PWAD file to the end of the IWAD's list, so the resulting directory (internally) looks like:

PLAYPAL   (first doom2.wad lump)
COLORMAP
ENDOOM
DEMO1
...
SLIME14
SLIME15
SLIME16
F3_END
F_END           (last doom2.wad lump)
MAP01           (first lump of PWAD)
THINGS
LINEDEFS
....

When the game searches for a particular lump by name, it searches backwards from the last lump. In this way, the PWAD lumps "override" the IWAD lumps; for example, when loading MAP01, the MAP01 from the PWAD is found before the IWAD version and used first. This clever technique works for almost everything: levels, graphics, textures, sound effects, music, etc. But there are a couple of things that don't work properly.

The first is flats. All floor and ceiling textures are kept between "F_START" and "F_END" markers. When the game starts up it uses these markers to find where to look up flats. The problem is that if a new flat is added in a PWAD, it won't be between the IWAD's F_START..F_END markers. Fortunately, it's possible to work around this, by adding a second F_END in the PWAD. The game uses the F_START from the IWAD, and the F_END from the PWAD, and everything between it is a valid floor/ceiling texture - all the textures from the IWAD and the new ones from the PWAD too.

The second thing that doesn't work properly is sprites, for the same reasons (S_START..S_END) but the flats trick doesn't work for sprites. Sprites have to be in a set format (four letter sprite name, followed by frame number and rotation number). If you put S_END in a PWAD, not everything between the S_START..S_END markers is a valid sprite name.

The "standard" way that ports allow sprites is by allowing multiple S_START..S_END sections (typically SS_START..SS_END is also allowed, as this is what deutex uses to hold replacement sprites). some ports like Legacy also allow direct replacement of sprites without section markers, but this is generally more crude and haphazard.

fraggle said:
The second thing that doesn't work properly is sprites, for the same reasons (S_START..S_END) but the flats trick doesn't work for sprites. Sprites have to be in a set format (four letter sprite name, followed by frame number and rotation number). If you put S_END in a PWAD, not everything between the S_START..S_END markers is a valid sprite name.

The flats trick does work, though, if new sprite graphics have names that are different from any of the sprites in the IWAD, using DeHackEd. An example of this is STRAIN.

myk said:

The flats trick does work, though, if new sprite graphics have names that are different from any of the sprites in the IWAD, using DeHackEd. An example of this is STRAIN.

Yes indeed, that's another clever trick. When the game starts up, it processes all the lumps it finds in the WAD directory between the S_START..S_END tags. It uses this to build internal lookup tables with information about sprite rotations, etc. However, it doesn't like duplicate definitions of frames. So for example if it sees "PLAYA1" and then later encounters another "PLAYA1" lump, it bombs out with an error.

However, if the first four characters are not a valid sprite name, the lump gets ignored. For example, if the lump is named "DOOMWRLD", it gets ignored because there is no sprite called "DOOM". If you use dehacked to change the internal list of sprite names, the IWAD sprites are no longer valid sprite names, so you're free to define them in your PWAD; there is no longer any duplication.