Force-loading units and debugging buildoptions replacements that appear to do nothing.
Assigning ud.buildoptions to a new value silently fails unless all units are force-loaded first. The force load setting lives in the advanced options menu. Without it, the engine does not have the unit table in memory and the assignment targets an incomplete data structure.
Always enable force-load all units before running tweakdef commands that modify buildoptions.
When using tweakunits instead of tweakdefs, the array position must be specified explicitly. Tweakunits operates on raw table structures without executing code. Writing a buildoptions entry requires the correct numeric index:
ud.buildoptions = {[1] = "unitname"}Replacing the entire buildoptions array requires the bracket syntax. Appending entries uses a different approach. Confusing the two produces unexpected menus.
A common point of confusion involves examples that look like tweakdefs but use tweakunits syntax. Tweakunits accepts table definitions directly. Tweakdefs requires valid Lua code blocks with proper syntax. Mixing the formats leads to commands that look correct but produce no results.
Check which system the example targets before copying it into the lobby command line.
Assigning a new table to ud.buildoptions replaces every existing build option. This is the intended behavior when the goal is a complete build menu restructuring. For targeted additions, append to the existing array instead of replacing it.
Understanding which system does what prevents hours of wasted debugging. The community that shares clear explanations helps everyone avoid the same traps. Good teams communicate expectations before acting.
The first and only community I have seen that actually holds up to its values. I have honestly not had a single bad experience here.