Packing .nav into .bsp

Discussion in 'Mapping Questions & Discussion' started by squ1rrel, Apr 11, 2017.

  1. squ1rrel

    squ1rrel L4: Comfortable Member

    Messages:
    158
    Positive Ratings:
    72
    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
     
  2. ics

    aa ics http://ics-base.net

    Messages:
    723
    Positive Ratings:
    438
    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.
     
  3. squ1rrel

    squ1rrel L4: Comfortable Member

    Messages:
    158
    Positive Ratings:
    72
    Used compile pal.
     
  4. henke37

    aa henke37

    Messages:
    1,931
    Positive Ratings:
    456
    The valve provided compression is somewhat questionable. Lots of tools (that actually understand compression) think that there is something wrong with it.
     
  5. squ1rrel

    squ1rrel L4: Comfortable Member

    Messages:
    158
    Positive Ratings:
    72
    Ok, I think I'l just leave it out for now..
     
  6. The Jill

    aa The Jill

    Messages:
    13
    Positive Ratings:
    123
    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).
     
    • Thanks Thanks x 2
    • Like Like x 1
    • Agree Agree x 1
  7. henke37

    aa henke37

    Messages:
    1,931
    Positive Ratings:
    456
    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.
     
  8. The Jill

    aa The Jill

    Messages:
    13
    Positive Ratings:
    123
    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.
     
    • Thanks Thanks x 1
    • Like Like x 1
    • Agree Agree x 1
  9. MaccyF

    aa MaccyF Notoriously Unreliable

    Messages:
    913
    Positive Ratings:
    1,478
    i understand some of these words
     
    • Funny Funny x 3
    • Agree Agree x 1
  10. Pocket

    aa Pocket func_croc

    Messages:
    4,489
    Positive Ratings:
    2,219
    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.
     
  11. henke37

    aa henke37

    Messages:
    1,931
    Positive Ratings:
    456
    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.
     
  12. fubarFX

    aa fubarFX The "raw" in "nodraw"

    Messages:
    1,632
    Positive Ratings:
    1,723
    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: Apr 14, 2017
  13. ics

    aa ics http://ics-base.net

    Messages:
    723
    Positive Ratings:
    438
    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.

    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.