Skip to content


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

  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.

Posted in Programming.

Tagged with .