CompilePal
CompilePal copied to clipboard
ruarai
Repack process should copy repacked bsp back to vmf folder
Is your feature request related to a problem? Please describe. In line with the 'PACK' process, the 'REPACK' compression process should copy back the BSP that is compressed at $mapFolder$ back to vmf folder.
Describe the solution you'd like Copy repacked bsp to vmf folder after the repack process instead of leaving it only at $mapCopyLocation$
Unfortunately due to how the REPACK step is setup it can't easily be modified to copy back to the vmf folder. However, this can easily be done with a custom compile step
The program is cmd and arguments /c xcopy /y /f "$bspdir/$file.bsp" "$path/$file.bsp". I can create a bat file to do this too if you want.
If I'm reading the code right, it's because REPACK is part of the general executable runner and just executes bspzip with generic parameters. Perhaps an easier method is just to chain bspzip && xcopy for the meta.json for REPACK. The repacked map has little to distinguish it from the uncompressed version since it's only usually smaller so it's easy to mistake the one in the vmf folder as the release-able copy.
In the meantime, I'll try your custom command idea.
Releasing from your $mapCopyLocation$ folder instead your $mapFolder$ is always the way to go. From running buildcubemaps, mapper's should know that the complete bsp is the one that was ran through the game. If there's any confusion, it is inherent to Source and not CompilePal. Also, part of the philosophy is that the stock compile can be long and the steps after "copy" can be unreliable (we're not immune to bugs). "Copy" acts as a checkpoint. Leaving an untouched bsp in $mapFolder$ means we can resume a compile from "copy" if anything were to go wrong in the later half of the compile.
Tho I agree that it's inconsistent with "pack". I personally disagree with "pack" copying to the $mapFolder$ but it leaves a backup so I'm not too mad about it.
Unfortunately due to how the REPACK step is setup it can't easily be modified to copy back to the vmf folder. However, this can easily be done with a custom compile step
The program is cmd and arguments
/c xcopy /y /f "$bspdir/$file.bsp" "$path/$file.bsp". I can create a bat file to do this too if you want.
Seems like the CUSTOM step seems to run before the REPACK step for some reason.
CompilePal - cmd
Args: cmd
Args: /c xcopy /y /f "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\download\maps\/map.bsp" "C:\map/map.bsp"
C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\download\maps\map.bsp -> C:\map/map.bsp
1 File(s) copied
Program completed successfully
Valve Software - bspzip.exe (Oct 2 2021)
Warning: falling back to auto detection of vproject directory.
Repacking C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\download\maps\map.bsp
Successfully repacked C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\download\maps\map.bsp -- 10934776 -> 1229029 bytes
You can change the order the compile steps are run in using the Order tab. Just drag the cmd step to the bottom of the list
Closing stale issues, please try the latest prerelease and if the issue is still happening feel free to reopen