I Wanted Orange

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.

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…

PackBSP 2.0.5 is now available on the download page, and is open-sourced (in all its badly-commented tests-disabled glory) on GitHub. Eventually I want to migrate certain things (like the “support” page) to the GitHub system as well.

Edit: For the moment I think I need to focus on checking that everything can be successfully downloaded and easily built by anyone interested in doing so, and then investigate what I need to do to make it “seamless” in terms of versioning and Maven artifacts/repositories.

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.

I think the third-party jRegistryKey library is exploding on 64-bit systems, which is why people have had problems with PackBSP 2.0.4.

I’ve rewritten things so that it is no longer a dependency, and plan to release 2.0.5 within a week or so, which will also include some minor fixes in terms of recognizing ambient-occlusion texture dependencies.

After a lot of procrastination I’ve released HL2Parse under one of the Creative Commons licenses… I still plan to add a few things to it, but now it’s out there, warts and all. See the project-page for more information.

About a week ago someone made a video for Bad Company 2 showing a sniping comparison between the use of normal bullets versus the “Magnum” ammunition upgrade. Interestingly, they thought it showed no difference, while I came away with the opposite impression. This post is a horribly nit-picky comparison of shots in the video. Read more…

Mainly focused on my day job right now, with a bunch of projects gently simmering and making me feel guilty they’re not being done.

• Adding SLF4J logging to my github branch of Preon
• Getting a working Preon-based parser for Valve’s DMX format (with a further focus on PCF particle definition files.)
• I’d like to try making something with Processing.js that helps compare and contrast weapons in the game Battlefield:BC2
• Learning to make a Blender animation, visualizing the control scheme of BC2 helicopters as the topic.
• An improved version of ctf_2fort_revamp (particularly since the Engineer Update weapons have altered the balance in some areas.)
• An improved version of ctf_2fort_fixup (backported features from Revamp, like moving clouds.)

Well, I managed to survive the holiday season, went off to see some relatives, and snapped up Battlefield: Bad Company 2 from a sale on Steam, which is proving to be one of my major distractions right now.

PackBSP stuff is somewhat on hold pending work on Hl2parse, where I’m having some difficulty getting Preon to work in quite the way I want it to.

Here's the wrong way to use decorators in Preon. They'll only work on the first level, and won't apply to nested Preon objects.

final DefaultCodecFactory fact = new DefaultCodecFactory();
Codec<MyFileType> codec = fact.create(MyFileType.class);
final LoggingDecorator ld = new LoggingDecorator(new CustomLogger());
codec = ld.decorate(codec,null,MyFileType.class,null);
// Resulting codec only does outermost-level logging.

The right way appears to be:

final DefaultCodecFactory fact = new DefaultCodecFactory();
final CodecDecorator[] decorators = new CodecDecorator[]{
    new LoggingDecorator(new CustomLogger())
};
final Codec<MyFileType> codec = fact.create(null, MyFileType.class, new CodecFactory[]{},decorators);

I haven't found any other way to alter the decorator-chain yet.