I Wanted Orange

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.

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.

Changes

• Feature: Tries to auto-detect the Steam directory from the
  Windows Registry.


• Fix: Issue where if the same file exists in the game
  directory and in the GCFs, it was being unnecessarily packed, even
  if the file content is identical. Now such “harmless duplicates” are ignored and not
  packed. (This is particularly important for TF2 maps using the old
  Swamp Pack assets became officially adopted.)


• Fix: Issue where model-skin paths contained an extra slash
  due to how the QC options where written prior to compile.


• Fix: VMTs legitimately provided in place of SPR files are now
  parsed correctly to find depended-upon materials/textures.


• Fix: Clientregistry.blob is no longer directly read, but
  instead copied to a temporary file to avoid conflicts with
  concurrent Steam operations. This can still fail if Steam is in the
  middle of updating or downloading game data, but the error message
  should be much clearer now.


• Fix: Upgraded to use HlLib 2.4.0, fixing an issue where HlLib
  could not extract from GCFs over 4gb in size.

Known issues:

• Ensure you have re-run the Source SDK and/or any mods you are working with
  before using this program, because Valve occasionally updates their SDK and everything is in a broken-state
  until their software is re-run.
• “Locked” variations of TF2 control-point hud
  icons (ending in _locked.vmt) are not discovered for
  team_control_point. This is due to hidden behavior of the TF2
  engine, and will require additional work to add “plug-ins”
  that can solve this in an extensible manner.


• Textures that are needed for custom particles are not
  detected. This will require more work to parse PCF files.
  

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.

You know how long-term deadlines somehow sneak up on you? Turns out the TF2 Art-pass contest is ending real soon, so I need to scramble a bit to get a newer version of PackBsp out.

Version 2.0.4 should mainly be bug-fixes and stability improvements: I don’t want to gamble too much on new features if people might be using it to submit final contest entries.

See project page for the download link. This release is a bit hurried, since I’ll be away from civilization for the next two or three days.

Changes:

• Due to discovering an unresolved bug in model-parsing, all materials for a model are now packed, even if that model is static and some might not be used. This temporary workaround potentially increases the file-size of maps but does not run the risk of missing model-textures.
• Handles model-gibs (ragdoll and rigid) for non-static models, through parsing the .phy files.
• Handles models’ $includemodel settings, to pull in shared animations and sequences.
• Support for special-case entities:
  • env_screenoverlay
  • material_modify_control
  • trigger_vphysics_motion

It looks like my current code for model skins is incorrect, which will cause problems detecting the right textures for all dynamic/physics/ragdoll models in your map… unless those models are extremely simple, like crates or barrels.

In Hammer, you can specify a number for the “skin” that a prop uses, such as having a blue sign or a red sign. It turns out this is actually an index for a whole package of textures that work together. However, my code was developed and tested against simple models, so that there was a one-to-one relationship between the skin# chosen and which VMT needed to be used.

In more complex props, this relationship is no longer valid. For example, a level-two dispenser-model has two skins, but four different materials.

I’m working on fixing up my code so that it handles these cases properly in 2.0.3. Later, version 2.0.4 should have additional fixes that allow it to recognize a few more special-case materials, such as a the material for a model’s eyeballs. (Yes, eyeballs. They’re actually their own special thing, but you seldom see it used outside of NPC/Player models.)

I had hoped to release 2.0.3 today to solve the model-gibs issue, but two last-minute bugs are going to push the timeline out a bit.  I need to add custom code to handle two “weird” Hammer entities whose dependencies are not being detected:

• env_projectedtexture
• env_screenoverlay

It’s possible I may skip env_projectedtexture entirely, since it relies on the hard-to-analyze I/O system to set a VTF.

Code to read the PHY file format went smoother than expected, so this week I expect to get 2.0.3 released, which will support model gibs.

This means that players destroy your custom crate, any custom crate-bits you created will be there too. Props which are static will not pull in gib-models, since they cannot be destroyed.

Partly spurred on by the Art-pass contest, and partly by a lull at work, I’m (re-)starting my attempts to learn Blender and create custom models for TF2.

I have very little experience detailing maps–barring some narrow types of optimization– and I’m slightly worried I won’t have time to actually implement the story and setting I want to create after I spend time learning how to do it.

On that note, I hope to also take some time to revisit how PackBsp handles models. It is deficient when it comes to:

• Skins for models with “sub-model” pieces
• Gibs for models when they are destroyed

At least to get the gib-data, it seems I need to write code to read the binary .PHY files. They appear to have less documentation than most of the other stuff so far, so I’ll probably have to tinker a lot in a hex-editor.