Adding custom flats is breaking my level in Chocolate Doom

[lilpastasalad]

I have a vanilla Doom question this time. In trying to relearn the correct way to add textures to a WAD that are vanilla-friendly, I've found that time and time again, despite following multiple tutorials, as soon as I add in my custom textures in SLADE3 the WAD will not load up in Chocolate Doom. I convert the graphics to Doom Flat format, add F_START and F_END markers, and save my WAD before opening it in Doom Builder 2. When I try to test the map, Chocolate Doom gives me this error:

W_CacheLumpNum: 42545742 >= numlumps

I don't understand what could be the problem. The map ran fine before I added the new flats. The images are the correct 64x64 size, the proper Doom Flat format, and are nested between the F_START and F_END markers.

I attached a RAR archive with the WAD file and flat graphics if you want to take a look, along with a screenshot of what my entries look like in SLADE3. There's custom palettes in there too, but they worked fine when I tested the map after adding them in. Any input would be greatly appreciated. I have no idea what the issue could be. Thanks.

Test.rar

 

EDIT: Sorry for posting this outside the questions forum, I wasn't paying attention. Hopefully a mod can move it to the proper forum or lock this one and I can post it in the proper section.

[andrewj]

Use FF_START instead of F_START.

 

See: https://doomwiki.org/wiki/Adding_custom_textures

[DynamiteKaitorn]

Try creating a shortcut to your chocolate DooM exe file and inside the "properties" tag, put -merge (insert wad name here). This worked for me. :)

[lilpastasalad]

1 hour ago, andrewj said:

Use FF_START instead of F_START.

 

See: https://doomwiki.org/wiki/Adding_custom_textures

 

You're the best. Got the flats working. Also started with the wall textures. Is there a way to make a wide SKY1 texture with multiple patches in a vanilla Doom II PWAD like in Final Doom? It seems like in order to do that I would need to add a TEXTURE1 lump to my PWAD containing the new SKY1 texture, but I think the contents of texture lumps of PWADs overwrite the contents of the texture lumps in IWADs, meaning unless I copy the entirety of the Doom II TEXTURE1 lump into my PWAD, I couldn't use any of the base textures in my maps. I tried making and adding a wide SKY1 into a TEXTURE2 lump, but in Chocolate doom it will still load the default SKY1 texture. Am I stuck with modifying the RSKY1 patch if I want to only use the TEXTURE2 lump? I hope that makes sense.

 

2 minutes ago, DynamiteKaitorn said:

Try creating a shortcut to your chocolate DooM exe file and inside the "properties" tag, put -merge (insert wad name here). This worked for me. :)

I know about the -merge command, I've been trying to avoid using it unless absolutely necessary. I'm assuming I'll need to use it to solve the problem above unless you can make wide sky textures without merging with the IWAD. I used to make maps years ago and didn't realize that I had been adding textures to my WADs the "wrong" way (dragging image files into XWE as patches without making a PNAMES or TEXTURE file). I mainly used ZDoom and Zdaemon so I didn't know that while they could handle raw patches as usable textures, vanilla Doom would have spat out an error message. I'd make maps in vanilla Doom format despite not knowing that they wouldn't even run in Zdoom-based source ports. Since I want to try ZDoom mapping now, I figured I should go back and learn the "proper" way to make Doom maps the old way before I learn the new stuff.

Edited April 26, 2020 by lilpastasalad

[Gez]

The way texture loading works is that the engine is loading the last TEXTURE1 lump, then the last TEXTURE2 lump, using the last PNAMES lump for both... But then looks for texture first in TEXTURE1, then in TEXTURE2 if it exists, and returns the first texture it finds.

 

So a texture from TEXTURE1 that is redefined in TEXTURE2, will still use the version from TEXTURE1. And in fact, if you make several textures with the same name in TEXTURE1, only the first of them will be used, the others will be ignored.

 

Finally note that modifying RSKY1 will not change the texture's definition -- even if you put a 1024x240 RSKY1 patch, the SKY1 texture will still be 256x128. So using a patch replacement will not help you achieve the wide sky effect you want.

 

My advice is to stop worrying and start editing TEXTURE1. The way it depends on PNAMES and the way you necessarily added stuff to PNAMES to get your TEXTURE2 working means that you can already forget about being compatible with different TEXTURE1 lumps (such as in Final Doom). May as well go whole hog on it.

[lilpastasalad]

5 minutes ago, Gez said:

My advice is to stop worrying and start editing TEXTURE1. The way it depends on PNAMES and the way you necessarily added stuff to PNAMES to get your TEXTURE2 working means that you can already forget about being compatible with different TEXTURE1 lumps (such as in Final Doom). May as well go whole hog on it.

 

So I will have to copy the entire Doom 2 TEXTURE1 file into my PWAD in order to be able to use the base Doom 2 textures in my PWAD, correct?

[Gez]

Yeah. If you don't it won't be able to work with ports other than ZDoom-based.

[Doomkid]

3 hours ago, lilpastasalad said:

So I will have to copy the entire Doom 2 TEXTURE1 file into my PWAD in order to be able to use the base Doom 2 textures in my PWAD, correct?

It shouldn't have to be that hard, though. The instant you right click and add a patch to PNAMES and TEXTURE, it should auto-generate a PNAMES and TEXTURE1 lump for you. Then you can just go into the auto-generated TEXTURE1 lump and modify the SKY1 texture to be 1024 wide and use 4 patches rather than just one, as Final Doom does.

 

I'd make maps in vanilla Doom format despite not knowing that they wouldn't even run in Zdoom-based source ports.

This was maybe a typo, but just in case, vanilla Doom maps will work fine in ZDoom-family ports, but not the other way around.

 

Rant: Using the -merge command is also usually not necessary since DeHackEd can be used to add the one resource -merge is needed for, which are sprites. So long as your sprites and SS_START/S_END sprite markers are the first entries in the wad, you can indeed use custom sprites in vanilla so long as you used a DeHackEd lump to rename and define them. This way you can distribute your wad in a 100% playable state for all source ports and vanilla Doom without the need for any port-specific commands. I guess some might consider merge to be the "right" way but so long as you assemble the pieces in a specific way, it isn't necessary.

Edited April 26, 2020 by Doomkid

[lilpastasalad]

Yeah that was a typo. Meant to say "wouldn't run outside of ZDoom-based ports".

Thanks for the great replies everyone. I learned a lot from just a few posts. The DeHackEd tip for sprites is great to know.