This is a fantastic tool, working very nicely for me so far. Thanks!
VBCT replacement - CompilePal
- Thread starter Freyja
- Start date
Kill_the_Bug
aa
- Oct 6, 2008
- 1,965
- 450
Sorry at work and my pc is still in pieces at home...will be for another 2-3 days.
I've always built the cubemaps first and then packed in my custom content pakrat/vide and experienced no issues with them.
So if I got this right - this program has an auto pack feature - I assume that this is for models, custome textures, etc. If I needed other files i.e. custom HUDs, reosurce and scripts can I add them in too? Is it easy to do?
I've always built the cubemaps first and then packed in my custom content pakrat/vide and experienced no issues with them.
So if I got this right - this program has an auto pack feature - I assume that this is for models, custome textures, etc. If I needed other files i.e. custom HUDs, reosurce and scripts can I add them in too? Is it easy to do?
Yes, this proggy scans the BSP, reads the entity data and packs any assets it thinks should be included. If you use a custom model or material in the map for example, then the proggy will detect that and include it. It's also smart enough to scan soundscape, soundscript and particle manifest text files and include assets referenced inside them that are not referenced in the map directly (E.G. MP3 files, but you normally use the game sound names from your soundscript in Hammer and not sound filenames).
If an asset path and filename are found in the BSP file they should be included (like CP HUD icon overlays) but for things like simple texture replacements you will have to pack them manually afterwards using VIDE because the program won't find them when it scans the map. You could try making some fake entities in Hammer that reference your files in fake keyvalues, to see if CompilePal picks up on them and packs them in. Anything you find out would be of great use to the authors.
If an asset path and filename are found in the BSP file they should be included (like CP HUD icon overlays) but for things like simple texture replacements you will have to pack them manually afterwards using VIDE because the program won't find them when it scans the map. You could try making some fake entities in Hammer that reference your files in fake keyvalues, to see if CompilePal picks up on them and packs them in. Anything you find out would be of great use to the authors.
Today I have been trying to get CompilePal to run TF2 after compile. You may remember that I said I encountered an error:
I believe this error message text is not from CompilePal, but from hl2.exe.
I then added this line to the GAME step in CP, and entered tf in to its little text field. I ran the compile and TF2 launched successfully, just like the version that Hammer launches 
This is what it looks like:
With this post I would like to make a request. That is for the CP compile process to end when TF2 has launched. Currently, CompilePal still thinks the compile is ongoing whilst TF2 is open, and won't say it's finished until you close it. But if you use the -hijack argument to hijack an existing instance of TF2, you need to be able to compile again after you make changes. CompilePal won't let you do it until you have closed the game so if you want to use it to replace your Hammer compile it falls down because it can't be used as quickly and repeatedly.
I believe this error message text is not from CompilePal, but from hl2.exe.
- I tried making sure that the Current Game field in the Source SDK was set to TF2, and then launched Hammer from it (the separate, outdated Source SDK tool that is downloadable from Steam. Don't worry, I do not use this tool for mapping, I only keep it for reference and for the source material it comes with).
- I tried making sure the VPROJECT environment variable was correct. I presume that is working okay because TF2's Hammer.exe works for me and doesn't give me any error messages.
- I tried copying gameinfo.txt to Team Fortress 2/hl2, which did work but the instance of the game that launched had fresh settings, and when I alt+tabbed out my screen went black and I could no longer switch between apps or access my desktop environment.
Code:
Game; -game;TRUE;Game directory (E.G. tf, cstrike);This is what it looks like:
With this post I would like to make a request. That is for the CP compile process to end when TF2 has launched. Currently, CompilePal still thinks the compile is ongoing whilst TF2 is open, and won't say it's finished until you close it. But if you use the -hijack argument to hijack an existing instance of TF2, you need to be able to compile again after you make changes. CompilePal won't let you do it until you have closed the game so if you want to use it to replace your Hammer compile it falls down because it can't be used as quickly and repeatedly.
Good to see some people are learning the slightly overcomplicated configuration system. Your issue with game launching should be fixed in V023, as I'm making Compile Pal not wait for the game to exit during a compile.
On another note, V022 came out yesterday and features many fixes by maxdup for the BSP packing. There's now a cool little website if you want something to share: http://compilepal.ruarai.com/
Thanks, ruarai.
I don't think configuration is overcomplicated. I think it's pretty obvious what is going on when one looks at the text files. I am sadly not a programmer but I am able to grasp it. I suppose it would be even more user-friendly if the app had a UI for people to add their own arguments and edit existing ones.
I don't think configuration is overcomplicated. I think it's pretty obvious what is going on when one looks at the text files. I am sadly not a programmer but I am able to grasp it. I suppose it would be even more user-friendly if the app had a UI for people to add their own arguments and edit existing ones.
If you go into the CompilePal folder, and then into the Parameters folder, there's a file there called game.csv
Open this in notepad, and in a new line copy the following in:
Hijack; -hijack;FALSE;Hijacks an existing instance of the game rather than attempting to run it again.;
Then save and close the file, and open CompilePal. In the game settings window, click on "ADD..." and double click on hijack.
One bug I have noticed with this is that you need to open TF2 manually before compiling a map with CompilePal for the compile process to complete after hijacking the game. (Otherwise CompilePal will wait for TF2 to close before it says the compiling process has finished)
Another option I like is this:
Disable Freeze Time; +mp_enableroundwaittime 0;FALSE;Disables the freeze time at the start of rounds.;
which makes you able to start moving straight away upon choosing a team and class, rather than waiting the 5 seconds (or so) of freeze time.
Cynder loves Portal
L420: High Member
- Jan 9, 2016
- 434
- 103
I'll give this a try. Looks useful.
CompilePal is an absolutely fantastic tool. The only issue I have is, the .bsp is copied from my personal folder to tf\maps before it is packed/repacked, and never copied back. For a pleb like me, this results in unpacked maps being uploaded to the site.
If there's a next version of CompilePal, could it copy packed/repacked maps from tf\maps to my personal folder?
If there's a next version of CompilePal, could it copy packed/repacked maps from tf\maps to my personal folder?
afaik the reason it doesnt do that is because it gives you an unpacked backup incase the packing corrupts it, and assumes that you know to use tf/maps for uploads (since honestly you should be, afaik cubemaps only save to the tf/maps version as it is)
That is correct, with the new nav/cubemaps operations, we had to work from the maps/ copy so we changed the order of operations a little. Having an untouched backup in you mapsrc is a bonus benefit to that. I don't think we're going to go back on this decision but we might try to make it more obvious as to what's going on.
Compilepal doesn't seem to handle custom blends correctly. It packed everything else nicely in Vindemine but I had to use VIDE for blends. Interestingly Compilepal found the files and put them to bsp but it didn't work and showed purple checkerboard
This sounds like it doesn't make sense. I've never had trouble with blend textures in the past but it could be a weird source quirk, especially if the files did make it in there. The thing tho is I'm not sure I'll be able to reproduce this bug so if your can shoot me the faulty bsp and the correctly packed one, that could get me a long way. Could have something to do with the materials/maps folder, I have no clue.
Broken packing https://www.dropbox.com/s/trjid2iv7wvdpe9/mvm_vindemine_a2_copy.bsp?dl=0
Working packing with CP first and then VIDE https://www.dropbox.com/s/onj7kt8ykwh6c9e/mvm_vindemine_a2.bsp?dl=0
Working packing with CP first and then VIDE https://www.dropbox.com/s/onj7kt8ykwh6c9e/mvm_vindemine_a2.bsp?dl=0
CompilePal - Automated Packaging
Finding sources of game content...
Found search paths...
Found wildcard path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf\custom\
Found search path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf
Found search path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf\bin
Found search path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf\download
Reading BSP...
Initializing pak file...
Writing file list...
Running bspzip...
Finished!
---------------------
4 materials found
5 models found
0 particle files found
0 sounds found
additional files:
---------------------
'Fast' compile finished in 00:00:41
4 errors/warnings logged:
(1) - Can't load skybox file [sub:1] to build the default cubemap! (Caution)
(2) - Can't load skybox file [sub:1] to build the default cubemap! (Caution)
(3) - Found a displacement edge abutting multiple other edges (Info)
(4) - fastvis = true (Info)
Finding sources of game content...
Found search paths...
Found wildcard path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf\custom\
Found search path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf
Found search path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf\bin
Found search path: H:\SteamLibrary\steamapps\common\Team Fortress 2\tf\download
Reading BSP...
Initializing pak file...
Writing file list...
Running bspzip...
Finished!
---------------------
4 materials found
5 models found
0 particle files found
0 sounds found
additional files:
---------------------
'Fast' compile finished in 00:00:41
4 errors/warnings logged:
(1) - Can't load skybox file [sub:1] to build the default cubemap! (Caution)
(2) - Can't load skybox file [sub:1] to build the default cubemap! (Caution)
(3) - Found a displacement edge abutting multiple other edges (Info)
(4) - fastvis = true (Info)
Attachments
Last edited:
So yeah. I'm getting an error when trying to pack content.
From an issue reported on github, the response is that it's likely to do with some form of corrupt content as the person who reported it has a TON of errors in their compile log. My compile log however has no errors.
I've traced the problem to some skybox models by hiding all models in the map, compiling, trying to pack, then unhiding models in a particular visgroup, compiling, trying to pack, then unhiding models in another visgroup, etc, etc until I found the models that were causing CompilePal to choke on packing content.
Bear in mind these models are showing NO other errors, not in Hammer, not in the compile log, and not in game. They simply cause Compile Pal's packing to choke.
I have not tried to pack them in with VIDE (and I probably won't bother, I'll just fix them and move on).
Anyway, all of this is a long winded request for some better error reporting.
Even using Fast compile to narrow down the models causing the problem, this still took a LONG time to iterate through all my visgroups before finding the problem.
"Something broke" is vague. Since it's an EndOfStreamException, I don't think you can do this, but ideally it should report "failed on trying to pack <asset>" or "failed to read <asset>".
Or maybe even just list the ones that it was able to read as it reads them. Or really anything to help narrow it down when this sort of error occurs.
From an issue reported on github, the response is that it's likely to do with some form of corrupt content as the person who reported it has a TON of errors in their compile log. My compile log however has no errors.
I've traced the problem to some skybox models by hiding all models in the map, compiling, trying to pack, then unhiding models in a particular visgroup, compiling, trying to pack, then unhiding models in another visgroup, etc, etc until I found the models that were causing CompilePal to choke on packing content.
Bear in mind these models are showing NO other errors, not in Hammer, not in the compile log, and not in game. They simply cause Compile Pal's packing to choke.
I have not tried to pack them in with VIDE (and I probably won't bother, I'll just fix them and move on).
Anyway, all of this is a long winded request for some better error reporting.
Even using Fast compile to narrow down the models causing the problem, this still took a LONG time to iterate through all my visgroups before finding the problem.
"Something broke" is vague. Since it's an EndOfStreamException, I don't think you can do this, but ideally it should report "failed on trying to pack <asset>" or "failed to read <asset>".
Or maybe even just list the ones that it was able to read as it reads them. Or really anything to help narrow it down when this sort of error occurs.
To follow up on this, it is definitely the skybox trees.
My antiquity trees consist of two models -- trunk and foliage -- for the purposes of getting proper lighting.
For the skybox versions, I integrated trunk and foliage into one model since moving at the scale of the skybox can be fiddly. Frankly I was too lazy to export another smd from 3ds Max, so I just used $bodygroup to add the foliage and used the existing smd files. Normally you'd do this only on prop_dynamic so you can turn the bodygroup off/on, but I compiled with $staticprop. And these models work 100% fine in game, in Hammer, in compile... they just fail to pack.
Exporting an smd from Max -- consisting of multiple parts, but one smd file -- and removing the $bodygroup portion of the QC, and these models now pack just fine.
I don't know if this is because Compile Pal isn't expecting such a strange condition, or if it hated having a prop_static with (unused) prop_dynamic properties, but I'm reporting it fully and letting you decide what (if anything) to do.
(we still could use better error reporting on failed packs, btw )
My antiquity trees consist of two models -- trunk and foliage -- for the purposes of getting proper lighting.
For the skybox versions, I integrated trunk and foliage into one model since moving at the scale of the skybox can be fiddly. Frankly I was too lazy to export another smd from 3ds Max, so I just used $bodygroup to add the foliage and used the existing smd files. Normally you'd do this only on prop_dynamic so you can turn the bodygroup off/on, but I compiled with $staticprop. And these models work 100% fine in game, in Hammer, in compile... they just fail to pack.
Exporting an smd from Max -- consisting of multiple parts, but one smd file -- and removing the $bodygroup portion of the QC, and these models now pack just fine.
I don't know if this is because Compile Pal isn't expecting such a strange condition, or if it hated having a prop_static with (unused) prop_dynamic properties, but I'm reporting it fully and letting you decide what (if anything) to do.
(we still could use better error reporting on failed packs, btw
)