I Wanted Orange

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!

Read more…

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.

Working on Hl2Parse this week. I want to release it at some point, but I don’t really want to stick with my own hodgepodge of code for reading binary files. Sure, it works, it’s customizable, but I still think something could be better. Preon caught my eye a while back, and I’m going to try to rewrite my code to use it.

As a bonus, this offers me an opportunity to experiment with Git, which I’ve been meaning to learn for a while after being used to Subversion. It also offers some interesting possibilities when it comes to synchronizing work I might do on different computers.

Once I get existing binary file functionality (BSP, MDL, PHY, Clientregistry.blob, etc.) translated into Preon annotations, I can see about adding more detail to the MDLs and parsing PCF dependencies.

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.

I finally managed to tear myself away from the Google AI Challenge and packaged up some stuff for FGDs. Check the Hl2Parse project page for more.

Quick code example:

File src = new File("test.fgd");
FgdSpec spec = new FgdSpec();
// If test.fgd uses an @include statement to 
// get another FGD, the DefaultLoader 
// will automatically handle it.
DefaultLoader.fillSpec(src,spec);
// Now you can pull information from spec
for(String name : spec.getEntClassNames()){
    FgdEntClass eclass = spec.getEntClass(name);
    System.out.println("Class "+name+" found of type "+eclass.getType());
}

This should give you output like:

Class base_prop_thing found of type BaseClass
Class prop_thingy found of type PointClass

Recently someone asked if they could use my FGD-parsing code, so I’m working on re-organizing the Hl2Parse code-base.

What I’d like to do is release it as a series of connected Maven modules to avoid burdening anybody with unnecessary dependencies. For example, someone who “just” wants to parse an MDL file doesn’t need to pull in all the dependencies (like ANTLR) that would be involved in FGD parsing.

So the modules would probably be something like:

• Text-parsers (VDF/FGD)
• Data representation (VDF/FGD classes, used by all other modules)
• Model binary parsing (MDL, PHY)
• Map binary parsing (BSP)
• ClientRegistry.blob binary parsing
• Higher-level utilities for soundscapes, materials, and comparing FGDs against map-entity data.

The emphasis, however, is just on the FGD stuff for now.

Well, PackBSP 2.0.4 may be delayed a bit due to extra complications in parsing the MDL files... In addition, I'm revisiting the idea of using Preon to more-easily program in the parsing rules. I tried it out a few months ago but decided to avoid it due to some blocking bugs. Now, however, with it getting a bit more activity and I want to see if it can replace some of my serviceable but-not-that-pretty code.

Here's a quick (incomplete) bit of sample code for MDL parsing. The Java class is being annotated so that the Preon framework can semi-magically shove data into it.

public class Mdl {

    @BoundString(match = "IDST", size = "4")
    protected String magicHeader;
    @BoundNumber
    protected int version;
    @BoundNumber
    protected int checksum;
    @BoundString(size = "64")
    protected String modelName;
    @BoundNumber
    protected int dataLength;
    @BoundObject
    protected Vector3f eyePosition;
    @BoundObject
    protected Vector3f illumposition;
    @BoundObject
    protected Vector3f hull_min;
    @BoundObject
    protected Vector3f hull_max;
    @BoundObject
    protected Vector3f view_bbmin;
    @BoundObject
    protected Vector3f view_bbmax;

    @BoundList(size="4")
    protected byte[] flags; //FIXME: Use boolean or bitset



    @BoundNumber
    protected int boneCount;
    @BoundNumber
    protected int boneIndex;

    @BoundList(offset="boneIndex",size="boneCount")
    protected Bone[] bones;
}

Hit a small wrinkle in PackBSP.  Sometime in the last few weeks Valve changed something about the format for clientregistry.blob and my code was complaining. (It probably would’ve worked fine but I put in some paranoid assertions.) It didn’t take too long to fix, but I figured someone might be interested in the findings.

1. Each application (ex. Team Fortress 2, appid=440) has a list of dependencies. That dependency list now carries an extra string of information for the OS, either “windows” or “macos”.
2. This means that Mac-specific GCFs exist. For example:
   • 316: Multiplayer OB Mac Binaries
   • 451: Team Fortress 2 Mac
3. As you might imagine, most of the preexisting GCFs have been marked “windows” except for those that only have sounds, materials, models, etc, which are platform-agnostic. So good news mappers: All those visual assets are definitely shared.

I can’t say PackBSP will be mac-ready in its entirety (in some ways I know it is not) but there’s something sort of cool when some future-proofing really comes together.

As I mentioned earlier, Valve’s been updating some of the SDK stuff, which means I have to play catch-up supporting these new things before I can really get my momentum back for PackBSP 2.  In addition to the @MaterialExclusion and @AutoVisGroup sections, it seems that @FilterClass is a new part of the FGD lexicon, to support some TF2 features.

So I’ve managed to rewrite the FGD parsing code in such a way that it should be a lot more friendly for a hypothetical future where Valve adds a new @ArbitraryPurposeClass, as long as it fulfills the same expectations  that the other class declaration sections do.

With that out of the way I can get back to putting in a GUI for a beta release. Except for the interface for customizing which files you want to pack, the user generally just has to choose things and click ‘next”.

Still rewriting various bits and pieces of PackBSP. Today I want to talk about how Source games handle finding files, as far as I can tell from guesswork, testing, and code comments. I'd welcome any corrections on this stuff.

If the game need a file, like  "sounds/weapon/pistol_shot.wav", where exactly does it get it from? For most Source-engine games, this turns out the ordering is a bit more complex than I had originally expected.