Packing .nav into .bsp

squ1rrel

L4: Comfortable Member
Apr 11, 2016
167
24
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

http://ics-base.net
aa
Jun 17, 2010
841
541
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

L4: Comfortable Member
Apr 11, 2016
167
24
Used compile pal.
 

henke37

aa
Sep 23, 2011
2,075
515
The valve provided compression is somewhat questionable. Lots of tools (that actually understand compression) think that there is something wrong with it.
 

squ1rrel

L4: Comfortable Member
Apr 11, 2016
167
24
Ok, I think I'l just leave it out for now..
 
Sep 14, 2015
13
147
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

aa
Sep 23, 2011
2,075
515
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.
 
Sep 14, 2015
13
147
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

Notoriously Unreliable
aa
Mar 27, 2015
914
1,544
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

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
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

aa
Sep 23, 2011
2,075
515
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 "raw" in "nodraw"
aa
Jun 1, 2009
1,720
1,978
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.
 
Last edited:

ics

http://ics-base.net
aa
Jun 17, 2010
841
541
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.