I've been spending some time updating maven build-scripts, making test-code more portable, and even added a maven repository on my github account.
The problem with "Maven Repositories" it is not always clear what is the minimum needed to distribute code versus what kind of management/proxy server software that someone wants to sell you. The minimum you need is really just a file structure!
For the last week or two I've been cleaning up PackBSP's documentation and build process to get it ready for open-source hosting on GitHub. With everything important out in the open (including the jhllib and hl2parse libraries) I hope to avoid the type of abandonment that befell Pakrat. With luck, I'll finally cut the ribbon sometime this week and simultaneously release version 2.0.5.
Version 2.0.5 is primarily bug-fixes, particularly to solve an issue where PackBSP won't start up correctly on certain Windows installations.
If anybody already has a GitHub account, feel free to add or vote on the Issues Page in terms of what needs to be done next, but I'm currently thinking of support for parsing PCF files (custom particles) to determine what sprites or materials they depend-upon.
Well, it's a slow week so I think I might as well share some old code to apologize for not making new code. In jHllib, which allows Java programs to inter-operate with a certain C/C++ DLL, I found myself needing to refer to certain integer values that were defined in C. All the documentation and examples for JNA (the Java< ->native bridging platform) tell you to use non-type-safe integer constants in your program, but this just didn't sit well with me.
After some experimentation, I found a way around to use Java's type-safe enums with JNA. First I'll show you what the final product looks like, and then look at the guts that make it possible.
Please see the project-page for download links.
This release is primarily small bug-fixes. Unfortunately,
screening out non-used static-prop skins is still not working until I
puzzle out more of the MDL format, sorry.
- Feature: Tries to auto-detect the Steam directory from the
- Fix: Issue where if the same file exists in the game
directory and in the GCFs, it was being unnecessarily packed, even
if the file content is identical. Now such “harmless duplicates” are ignored and not
packed. (This is particularly important for TF2 maps using the old
Swamp Pack assets became officially adopted.)
- Fix: Issue where model-skin paths contained an extra slash
due to how the QC options where written prior to compile.
- Fix: VMTs legitimately provided in place of SPR files are now
parsed correctly to find depended-upon materials/textures.
- Fix: Clientregistry.blob is no longer directly read, but
instead copied to a temporary file to avoid conflicts with
concurrent Steam operations. This can still fail if Steam is in the
middle of updating or downloading game data, but the error message
should be much clearer now.
- Fix: Upgraded to use HlLib 2.4.0, fixing an issue where HlLib
could not extract from GCFs over 4gb in size.
- Ensure you have re-run the Source SDK and/or any mods you are working with
before using this program, because Valve occasionally updates their SDK and everything is in a broken-state
until their software is re-run.
- “Locked” variations of TF2 control-point hud
icons (ending in _locked.vmt) are not discovered for
team_control_point. This is due to hidden behavior of the TF2
engine, and will require additional work to add “plug-ins”
that can solve this in an extensible manner.
- Textures that are needed for custom particles are not
detected. This will require more work to parse PCF files.
PackBSP 2.0.4 will primarily be a bug-fix release. I delayed it a bit (due to other programming projects and obsessions) and I'm going to delay it just a liiiitle bit more.
With the recent TF2 Halloween update, a bug in HlLib (upon which PackBSP relies) has been discovered involving large (>4gb) GCF files. So I'm going to wait for that to be fixed, update and check that jHlLib works, and then ship 2.0.4 with the newer libraries.
Update: HlLib 2.4.0 was released today (Tuesday Nov 2nd), but I have to do things like vote and attend certain festivities, so I'm aiming for PackBSP 2.0.4 (and new version of JHlLib) sometime around Friday.
Today Valve released a patch for TF2, but strangely the download monitor says it weighed in at about 100 megabytes. What's in there? About a week ago I went ahead and adapted some jhllib code to log data about the updates, so it seemed like a good opportunity to try it out. So what changed between the 13th and the 19th?
As you can see, the changes seem to pretty closely track the posted patch notes. Shaders, bug reports, HUD elements... And many of the shaders increased in size, perhaps with a lot of conditional code for Mac compatibility?
However, the size changes don't seem to match what Steam is showing. It's possible Steam's download status screen is wrong, or includes CS:S beta content which was skipped for me... Or I'm just not looking in the right places. Hmmm.
Worked on PackBsp a bit today. Indirectly.
I'm rewriting my ANTLR grammars for Valve's data formats, since I'm now trying to parse some new file types. Valve's own SDK framework has a bunch of configuration data that I'd like to be able to get at. Namely, information in the SDK's GameConfig files and inside the FGD files. Using those together, I can begin to create my own tool-launcher which is able to automatically know a lot more about the SDK environment.
The end-goal, of course, is for PackBsp to automatically gather all the entity information for maps. (Such as custom sounds which play when you enter a certain area.) If someone creates a new mod, PackBsp will automatically support it once it's been wired up to the SDK. More up-front work, less maintenance later.
One other belated announcement: I've been relying on HlLib in order to access Steam's compressed archive files. Of course, this is a Windows DLL, and I'm programming in Java, but it's not entirely a Shakespearean tragedy. Through the magic of JNA you can bridge the two. Since it's been a while since I've needed to change it, I've gone ahead and released JHlLib on the off-chance that somebody else has a similar need in the future.