One of the issues in PackBSP I want to improve is that it doesn’t “know” about dependencies (like a model used in a prop_static entity) stored in the entity data of a map. At least, not for other mods: PackBSP is currently hardcoded to the set that TF2 supports. The solution seems to be interpreting the FGD files that Hammer uses to determine all the places a user might insert a model or a texture while mapping. These definition files should be created by mod-makers for just about any “serious” Source Engine mod, so it seems safe to piggyback on their information. I’ve had a parser for the FGD files for a while now, but just parsing the file isn’t enough: You have to resolve and assemble all the dependencies into a final state.
I’ve been spending some time trying to reverse-engineer the undocumented rules that Hammer uses for its FGD files. These include how one file can include or override another, and inheritance between the defined classes.
Findings so far:
- Before paying any attention to the base(…) method of classes-inheritance, Hammer goes through and parses each item in a file.
- This initial parsing includes the @import statements, and the order of these statements matters. Imports act like the #include directives in C, and basically temporarily interrupt the parsing of the current file to go and handle the imported file first.
- The definition for a class found last within the file is the one that gets used. Since @import is like text insertion, this means the order of everything matters and affects how redefinitions of a class get resolved. (Last one wins.)
- If a class inherits (via the base(…) modifier) from multiple parents that conflict, the last parent specified has priority. An example of a conflict would be two identically-named properties.
- When referencing a superclass via the base(…) inheritance, the class ought to be already-defined in terms of how things are ordered within the FGD file. While Hammer complains about this, it will still work in the end.
