I Wanted Orange (The machine would not make a mistake.)


Graph Design Blues

I'm having second-thoughts on how to manage the dependency graph(s). I've been experimenting with a "directed multigraph", but I worry that it adds too much complexity when it comes to determining what portions of it are connected when only a certain type of edge is considered, and whether I'm over-complicating things. Actually, I'm pretty sure I am over-complicating things, but freedom to experiment is part of what makes an independent project fun.


Profiles loading, now integrating new dependency graph

PackBSP's profile-loading (a nested Spring ApplicationContext, really) is well underway, but I'm adding another level of indirection (some data-holding classes) to avoid too tight of an integration with certain HL2Parse innards. My main goal right now is to geta build which reproduces most of the current dependency-crawling features, and then worry later about how components are going to merge/override specific configuration data, like recognized shader parameters.

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.

Tagged as: 1 Comment

Configuration solution?

It's still very much in the prototyping phase, but I think I have a long-term way for PackBSP to hit the right mix of reliability and customization it may need long-term. Key word? "Profiles".


Configuration Confusion

Well, Source-descended games have me stumped. There's a bunch of a variation in behavior between them (consider L4D2 campaign creation versus Portal 2's map transitions) and I'm trying to find the right technique to make PackBSP work differently depending on what the user has selected... Even assuming I can correctly identify the features of what they picked.

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.

Tagged as: Comments Off

Locked files on windows… Bah!

It seems that Steam can sometimes have an exclusive lock on the clientregistry.blob file, which keeps anybody else from reading it in just about any way. This is an inconvenience since it means PackBSP cannot read the data it needs about game-assets. I've been looking into using JNI with the Microsoft Volume Shadow Service, but not only is it quite a bit out of my comfort zone in C/C++, but there may be licensing issues that would make it very difficult to put the functionality into an open-source project.

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.

Tagged as: Comments Off

Deus Ex, PackBSP progress

Still alive, working on PackBSP when not creatively-drained from work. I may end up skipping past a few version numbers to represent all the rewriting going on. Among other initiatives:

  • 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.)


PackBSP, configurability, and Spring IoC

As PackBSP has grown, I've tried to keep certain things "softcoded" in configuration files, firstly to make more problems user-solvable, and secondly to support people making maps for new games and mods which I haven't personally encountered. For example, the list of VMT shader parameters can get new additions as games are patched, and some mods may incorporate things like level overviews.

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.

Tagged as: Comments Off

Working on L4D2 support (2)

Not a lot of news, been busy with work-work. I've made some progress with adding multiple-SDK support to PackBSP (progress you can follow on the GitHub page, if so interested) but there's still a ways to go in terms of specific support for SDKs like the L4D2 Authoring Tools. I may need to take some system tools and try to determine what the game is doing behind-the-scenes in terms of accessing file paths, working with add-ons, etc.

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.

Tagged as: Comments Off

Working on L4D2 support

I think the next step in PackBSP will be L4D2 support, which may require some architectural changes, given that L4D2 has it's own separate SDK rather than being just another game handled by the Source SDK launcher.

  • 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.

Tagged as: Comments Off

Maven repository on Github

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!