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.
Read more...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.
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?
Altered:
New:
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.