Separation of "PostCompiler" into stages.

[The1stWii2]

Currently, HammerAddons performs all transformations to a map through the use of a program known as the "PostCompiler" which is run after VBSP, but before VVIS. While this is useful, this implementation does have issues, some described here:

• Transformations involving world brushes or other aspects handled during VBSP, are difficult, if not impossible, to implement due to the program running after said stage.
• Due to a fault in VVIS and VRAD, large maps (~100 MiB, but dependent on users' systems) are likely or guaranteed to be corrupted, a problem users of HammerAddons face due to its useful auto-pack and asset generation features.
  • This issue isn't just limited to users who utilise the auto-pack feature, as the PostCompiler will attempt to pack any map-specific items which can quickly exceed this threshold.
• Currently, outside specifically defined transformations, transformations are run in order in alphabetical order, which may cause issues should in future a transformation depends on another not in alphabetical order.

As such, it should be considered whether the "PostCompiler" should be split across the compilation process, for example: .vmf -> [Comp Stage 1] -> VBSP -> [Comp Stage 2] -> VVIS -> [Comp Stage 3] -> VRAD -> [Comp Stage 4]

The major arguments against would be:

• A rework of up to large sections of the PostCompiler would be required.
• Increased complexity for the end user. — However, regarding this point specifically, we can look at prior work to see potential ways to counteract this. Tools like "CompilePal" or other external "compilers" can assist, or it could be integrated into HammerAddons itself, like the forked "ExternCompiler". I, myself, am designing a potential system for external compiler tool for my own uses.

[TeamSpen210]

I very much agree. In particular adding “stage 1” would allow replacing instance collapsing ourselves, making it possible to do a variety of advanced features. I don’t think “stage 2” would be particularly useful though.