ZDBSP maps over map99

Post by **Enjay** » Thu Nov 24, 2005 5:45 pm

I've just come up with a problem that may be unfixable because it's probably something to do with a standard somewhere. Or maybe I'm just doing something wrong.

Anyway, if you have a WAD with maps with names like map100, map101 etc and use ZDBSP to build GL nodes, I think it writes lumps with names like GL_MAP10. Now, if you also have a map called map10 in the same WAD, these GL lumps conflict with map10 and actually make it crash when trying to load. Well, it makes GZDoom crash but I think the problem lies with the naming of the lumps created by ZDBSP.

I've no real idea if the maps called map100... are using their GLnodes or not, seeing as how they are presumably not recognised for that map because there isn't (and cant be) a lump called GL_MAP100 etc. They certainly seem to take a little longer to load than other maps, which may indicate that GZdoom is building them. But they are big-ish maps, so maybe it's just load time.

Posted a "mirror" over at the GZDoom forum.

http://forum.drdteam.org/viewtopic.php?p=5541

Post by **Graf Zahl** » Thu Nov 24, 2005 6:18 pm

You can use compressed GL nodes. They fit into the normal level structure and can also be used by ZDoom itself so you don't need any normal nodes anymore.

For level names longer than 5 characters there's a workaround since GL nodes v5 but so far no port supports that.

Post by **Enjay** » Thu Nov 24, 2005 6:32 pm

OK, thanks. It's getting late. I'll try compressed nodes tomorrow.

Ajapted · Post by **Ajapted** » Thu Nov 24, 2005 8:01 pm

Crikey, that's one MEGA wad with over 100 levels.

You could just use MP100, MP101 etc...

Post by **Enjay** » Fri Nov 25, 2005 3:02 am

Ajapted wrote:You could just use MP100, MP101 etc...

Yeah, I was thinking about something like that myself if there was no other fix. It still existed as a problem though so I thought it was worth bringing up. However, the compressed nodes seem to work and have reduced the size of the wad by a fair bit too.

Post by **Graf Zahl** » Fri Nov 25, 2005 3:56 am

Enjay wrote: the compressed nodes seem to work.

Trust me, they don't just 'seem' to work.

Hirogen2 · Post by **Hirogen2** » Mon Dec 05, 2005 4:52 pm

We need a new container format, WAD has outserved.

Post by **Apothem** » Mon Dec 05, 2005 7:24 pm

At first I thought you were just doing something theoretical, but now I see you're seriously doing a 100+ map wad

Post by **Graf Zahl** » Tue Dec 06, 2005 3:10 am

Hirogen2 wrote:We need a new container format, WAD has outserved.

That's why I added ZIP support to GZDoom. But for GL nodes it is more a design issue than a WAD problem. When mapping for (G)ZDoom the compressed nodes are better anyway because a set of compressed GL nodes is sufficient for both software and hardware rendering so you end up with considerably less data.

Hirogen2 · Post by **Hirogen2** » Tue Dec 06, 2005 10:36 am

Yay PK3 support.

What about directory structure in the ZIP, is it (un)supported? Would textures be found if they were at "textures/" rather than "." ?

Post by **Graf Zahl** » Tue Dec 06, 2005 10:48 am

Some directories are used as namespace replacements and I reserved a few for common types of data in the main namespace.

The current structure is likw rhis:

"flats/" : F_START/F_END
"textures/" : TX_START/TX_END
"sprites/" : S_START/S_END
"colormaps/" : C_START/C_END
"acs/" : A_START/A_END
"voices/" : V_START/V_END
"patches/", "graphics/", "graphic/", "sounds/", "music/" : Global namespace
Root directory: global namespace

Everything else won't be added as a standard lump. It can only be used by its full name in parts of the code that supports them.