Since the card (an Nvidia 8800GT variant) is still decently-powerful and has no obvious damage, I’m going to see what I can do under the limited-lifetime warranty. Compared to its earlier foibles, RMAing now ought to be unambiguous and straightforward, given that the computer now refuses to even POST if the card is present.

The real problem is this: What kind of information might be needed to analyze a node and add its children, and in what order do you do that? Every node needs to be visited, but what about every incoming edge, or every path? Using a multi-graph is making it difficult to reason out a correct and deterministic traversal order, particularly when it comes to preventing cycles. In particular,  cycles which may be valid in the graph as long as they require two-or-more edge types to exist!

I’m wondering now if–despite being an interesting experiment–I ought to restructure things as a collection of graphs bound together in a “Graph Project”. The unifying project would serve to de-duplicate nodes, provided nodes are all immutable data-holders.

You may be wondering why de-duplication is important, if nodes are immutable and have a good equals() implementation. The answer is Weak References. I want to allow NodeHandler implementations to store arbitrary information about what nodes they’ve already seen, so that they can avoid duplication of effort when necessary. For example, the same material file may have the same texture dependencies, whether it occurs in the graph for Map A or the one for Map B. If there are two separate Node instances which are equal() to one another,  WeakHashMap can only reliably store one of them.

To solve this problem, I’m considering setting up a system where NodeHandler instances register themselves as listeners to a Graph Project, so that they can store a hard reference instead, and are informed when they can safely forget it due to the Node being removed.

This will also mean integrating and testing the new dependency-graph classes, which unlike the old version are able to model crawling multiple maps at once, where each map may potentially have its own copy of a named asset in its pakfile. This is done by allowing multiple edges in the graph (directed acyclic multigraph) where each edge corresponds to the context of a particular map. In this way most nodes will be shared across maps (avoiding duplication of effort) but differences can still be modeled by having certain nodes only connected through map-specific edges.

1. Development kits (or “devkits”) are something that needs a new version of PackBSP to add. So if Valve someday releases an “Episode 3 Development Kit”, there will need to be a new version of PackBSP which is able to determine whether someone has it installed on their computer and how to interpret the way it is set up. Fortunately, this should be infrequent.
2. The modeling for devkits will also include the games which are set up to be used in them. Notably, this includes the information Hammer uses from FGD files, which determine how users pick models and entity-textures.
3. In parallel, there will be a system of “Profiles”, which are essentially sets of Spring configurations and properties. To start work, a user must pick both the devkit option, and also the profile that will be used. Profiles can contain information restricting themselves to certain devkits.

Now, it is entirely possible for a user to pick the “Team Fortress 2″ option from the Source-SDK devkit, and then combine it with the “Counter-strike Source” profile, but this is unavoidable, since the effort of accurately cataloging and fingerprinting every SDK option as games are constantly patched is daunting at best.

The big benefit is that profiles are largely text-editable. They may refer to specific Java classes to use, but it is possible for savvy mappers to create their a profile and share it to allow PackBSP to handle a new mod or new features added to a game.

Sometimes that means little things like specifically looking for certain entities that aren’t listed in the FGD files. Other times it almost means changing what GUI a user will see.  Creating completely different “editions” of PackBSP seems like it would lead to its own difficulties keeping everything updated, so I’m hoping to find some solution with the Spring framework. I considered the Apache Commons-Configuration library for a while, but I really do need the ability to swap out different code and wiring as opposed to key/value settings.

This gets a little weirder when you consider how to handle new mods. Should it limp along, treating “Mod X” as if it were the same as default Half Life? How easy would it be to add support for Mod X? How would the program recognize it if the authors did a revamp and released “Mod X 1.5″?

Perhaps the best solution is to mostly divorce the detection of games from the identification of games. So the user sees that they can pick “Zombie Shooterz” as a game, but it is up to them to tell PackBSP to use the “Half Life 2 Episode 2″ setting, or the “L4D2″ setting, depending on what code-base the game is built from.

It might be easier to lobby Valve for a workaround, like having Steam periodically attempt to dump a copy to some other filename.

In the meantime, simply turn off Steam, start PackBSP, choose the game you want to pack for, and then restart Steam before you reach the actual altering-the-BSP step.

• Some sort of system to handle packing multiple maps at once, in order to support the VPK/campaign workflow.
• Per-game config files, allowing various features to be toggled on and off.
• Foreign-language support. It’ll be possible for non-programmers to contribute translations.
• Ability to manually create a per-map config file that specifies assets to include/exclude

On a lighter note, I went ahead and pre-ordered Deus Ex: Human Revolution, mainly on the strength of the favorable comments everyone who downloaded the leaked press-beta, but unfortunately it won’t be out until August. (And let’s face it, with a title like “I Wanted Orange” I pretty much had to.)

Working on support for multiple SDKs/Engines/Mods, I think the effort I’ve put into these configuration options (which are starting to multiply and cross-cut) runs the risk of “reinventing the wheel”…. So I am considering rewiring PackBSP to use some minimal parts of the Spring Framework instead. (No, PackBSP is not becoming a web-application.)

My hope is that this will allow a broad, consistent, and easier route for configuration, which reduces the barrier tech-savvy users face when it comes to getting PackBSP to work just right with an obscure game or new mod.

I’ve also added an announcement e-mail list for anyone who wants to get notified when the next release comes out. (It may be a while, but all the more reason to set up a reminder before you forget, eh?) The sign-up form is on the PackBSP page here on the blog.

• Change how SDKs, engines, and games are detected so it can detect and use the L4D(2) Authoring tools rather than assuming SourceSDK
• If working on an addon campaign map, the include-path where it looks for files ought to include that addons directory
• Change the final packing step so that the user can choose to:
  1. Save to a file format (res file, bspzip list)
  2. Use BSPZIP right away (current behavior)
  3. Copy files to the correct places in a folder (so that a VPK can be created)
• Update map-includes (loading screens, map overviews)
• Update “special” map entities that aren’t covered by the FGD, document those that can’t be supported at this time
• Update known material shader properties

Once I have L4D2 support in place, the original L4D  and/or Alien Swarm should both be quite a bit easier to add.