Packing .nav into .bsp

[squ1rrel]

I read ics's guide to packing nav files into the bsp for workshop submissions. It made sense but I think I'm doing something wrong.

The message in the console when I run nav.bat:

ValidateLump: odd size for lump 14Press any key to continue​

The words inside the .bat:

"..\..\bin\bspzip" -addfile koth_sludge_puddle.bsp maps\embed.nav koth_sludge_puddle.nav koth_sludge_puddle.bsp
@pause​

Is what's being said in the console and the .bat correct and if not, how do I fix it? Ty

 

[ics]

Your bsp seems faulty. Either it's from the map compile or the software you use to compile . Do you use only hammer or something like compilepal? Lump 14 is brush entities so might take a look at those too in your map. The bat itself looks ok to me.

 

[squ1rrel]

Used compile pal.

 

[henke37]

The valve provided compression is somewhat questionable. Lots of tools (that actually understand compression) think that there is something wrong with it.

 

[squ1rrel]

Ok, I think I'l just leave it out for now..

 

[The Jill]

There is a known bug with embedding files into already compressed maps with bspzip. As a workaround, decompress the map (bspzip -repack), add the file, and recompress it (bspzip -repack -compress).

 

[henke37]

There is a known bug with embedding files into already compressed maps with bspzip. As a workaround, decompress the map (bspzip -repack), add the file, and recompress it (bspzip -repack -compress).

Tell us more about this bug. Exactly what is the problem? Is it the handling of already compressed files or is it the initial compression? Because these two parts are clearly disagreeing about the validity of the file.

 

[The Jill]

Tell us more about this bug. Exactly what is the problem? Is it the handling of already compressed files or is it the initial compression? Because these two parts are clearly disagreeing about the validity of the file.

The former -- some commands to update bsp files use an incremental-resave path that tries to treat the lumps as vector data, rather than just copying them directly. This path isn't compression-aware, so it (correctly) aborts when it sees a lump that has the compressed header. Since maps are generally compressed as a last-step, and it's easy to decompress them to edit, it's a low priority feature to fix.

 

[MaccyF]

The former -- some commands to update bsp files use an incremental-resave path that tries to treat the lumps as vector data, rather than just copying them directly. This path isn't compression-aware, so it (correctly) aborts when it sees a lump that has the compressed header. Since maps are generally compressed as a last-step, and it's easy to decompress them to edit, it's a low priority feature to fix.

i understand some of these words

 

[Pocket]

I mean, if all it means is that you have to make repacking the last step, I'd barely even call that a bug, just a limitation. It's pretty normal for compressed files to have to be uncompressed before they can be edited. It's just that the process is usually automatic and invisible.

 

[henke37]

i understand some of these words

Don't worry, I had a hard time understanding it myself. I think the gist is that some functions in the code try to understand the chunk, to some extent, even if they don't need to, and neglect handling compression.

Overall, nothing that can't be fixed by adding automatic compression handling to the chunk accessor function that all code should be using.

 

[fubarFX]

The only real bug is mostly the error message not being "correct" and having various parts of bzpzip conflicting with each other. The paking process is not getting the data in the way that it expects so we're left with a "catch all" message that no longer reflects the state of bsp and it's recent developments. lump 14 is perfectly valid as it turns out, it's just in a state that no longer makes sense to the part of the tool that adds files since it was never built with repacking in mind. Luckily we can work around all of that, as long as you work from uncompressed files and ignore outdated error messages you'll be fine.

For what it's worth, note that none of the various tools are able to deal with compressed maps and will exit with this lump 14 error. that's vbsp.exe (-onlyents), vvis.exe, vrad.exe, vbspinfo.exe, buildcubemaps and bspzip.exe (unless you are decompressing).

Now, more to the point of what you're trying to do. From what I'm getting, you have this handy .bat file to help you pack a renamed nav file after you've compiled with CompilePal. That's pretty cool but CompilePal can pack that nav file and rename it automatically for you. Just go into the packing section and add the -renamenav option. Now good luck and be safe out there.

 

[ics]

As i see it, he had compressed the map before packing the nav in it, which caused the error. Repacking should be the last step. Infact i dont even do it, i let the workshop do it, unless i manually share the map myself.

Now, more to the point of what you're trying to do. From what I'm getting, you have this handy .bat file to help you pack a renamed nav file after you've compiled with CompilePal. That's pretty cool but CompilePal can pack that nav file and rename it automatically for you. Just go into the packing section and add the -renamenav option. Now good luck and be safe out there.

Have you tested that the nav file that compilepal packs in works when map is downloaded from the workshop works on gameservers and when player loads the map with command map worshop/idhere ? I wrote this topic due to that reason, as there was a regression in relation to packing navs in the old way. It is where the handy bat is from too. https://tf2maps.net/threads/future-...-work-properly-with-workshop-elsewhere.30583/

EDIT

And i just saw your reply next on that page. Nevermind.