Required subtables for BAR tweakdefs and the difference between tweakdefs and tweakunits.
Writing new tweakdefs without initializing required subtables causes silent failures. The subtables BAR checks include buildoptions, customparams, weapondefs, and weapons. If a tweak addresses a nested value inside one of these and the parent subtable does not exist, the entire operation fails without error output.
Initialize the subtable before writing to nested keys. This defensive pattern applies to all tweakdef modifications, not just specific examples.
BAR tweakdefs accept arbitrary nesting in buildoptions modding. Modders who want to create multi-level build menus do not hit a nesting ceiling. The only constraint is practical readability. Tables nested beyond three levels become difficult to track and test.
These two systems serve different purposes. Tweakdefs runs actual Lua code. Variables declared with local create scope-limited references for complex logic. Tweakunits accepts raw table definitions that overwrite existing values without any code execution.
The distinction determines which tool fits which task. Use tweakunits for simple value swaps. Use tweakdefs when the modification requires conditional logic, loops, or calculated assignments. The local keyword in tweakdefs creates variables that exist only within that script context.
When the goal is changing buildoptions across every unit that can build, tweakdefs provides the necessary iteration capability. Tweakunits requires listing every unit individually, which becomes impractical at scale. The tweakdefs loop approach scales to the full roster in one pass.
Understanding which tool fits which job saves time and frustration. Communities that share this knowledge freely help everyone level up faster. The result is better gameplay and better mods.
Gaming actually fulfills a human purpose here - cooperation, mutual upbuilding, fun and striving for greatness together. Instead of random anonymity, you meet, learn from, and enjoy real people.