Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
vdgg

W_CacheNumLump: 3316 >= numlumps

Recommended Posts

This is a message I get when I tried to play back a demo with my WAD in vanilla. What I did before was I created three new flats so that the teleporter pads could match the grid.

Step-by-step what I did:

I created 3 bmp images with Paint
I created a lump F_START
I created 3 lumps GATE5, GATE6, GATE7
Imported the bmps, converted 3 bmps to Doom Flats
I created F_END

My lump list:

F_START      0   Marker
GATE5     4096   Flat
GATE6     4096   Flat
GATE7     4096   Flat
F_END        0   Marker
MAP01        0   Map
THINGS    3340   Map Things
LINEDEFS 10836   Map Linedefs
SIDEDEFS 39990   Map Sidedefs
VERTEXES  3116   Map Vertices
SEGS     17844   Map Segs
SSECTORS  2240   Map SSectors
NODES    15632   Map Nodes
SECTORS   4564   Map Sectors
REJECT    4006   Reject Table
BLOCKMAP  6372   Blockmap
What I did wrong?

Share this post


Link to post

You need to rename F_START to FF_START. You could also just delete it, but it's better to keep a valid marker there for editing tools to use.

Share this post


Link to post

Yes. The reason is that Doom was not designed for mods with additional flats, patches, textures or sprites, which is why you have to use hacks, include the full original data, or require source ports.

It's looking for standard flats, but it looks for them in between the last F_END marker and the last F_START marker. Because you include both, it only has your three GATE flats to look from, and doesn't find the standard flats. By using FF_START instead of F_START, you fool it into looking through all lumps in between the IWAD's F_START and your mod's F_END.

Share this post


Link to post
Gez said:

Yes. The reason is that Doom was not designed for mods with additional flats, patches, textures or sprites, which is why you have to use hacks, include the full original data, or require source ports.

Fixed that for you. Vanilla can handle custom patches and textures just fine, so long as your new TEXTUREx lump(s) contain the IWAD textures too (or at the bare minimum, the animated textures and switches which are hard-reffed in the EXE).

Share this post


Link to post
Quasar said:

so long as your new TEXTUREx lump(s) contain the IWAD textures too (or at the bare minimum, the animated textures and switches which are hard-reffed in the EXE).


Which is just what I called "including the original data". :p

Share this post


Link to post

When you said that I almost replied in a similar way, but with second thoughts I corrected myself and also imagined other implementations which could have made texture additions more straightforward and autonomous, such as the ability to add extra TEXTUREx lumps that are independent from TEXTURE1 and TEXTURE2, as well as separate PNAMES lumps. Sort of like Quake handles PAK files all the way to PAK9.PAK, in one directory.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×