Adding buildoptions to a unit through tweakunits or tweakdefs does not automatically give it building capability. Beyond All Reason units need specific animation script support for building actions. Without the right animation hooks, a unit shows the build menu but never actually constructs anything.
Tags: BAR modding, tweakunits, builder units, animation scripts, armsat T3 builder, beyond all reason
For a unit to build structures, its animation script file must contain the building action sequences. Simply adding buildoptions strings and buildCost values through tweakunits will not work. The unit needs a buildprint, construction initiation logic, and animation callbacks that drive the actual build animation. Spring engine checks for these at runtime, not at definition load time, so the unit passes inspection but does nothing when told to build.
The armsat unit is a common test case for modders trying to create a tier-3 builder. Adding build strings, assisting build capability, and buildprint through tweakunits gets the unit to accept build orders and display structure blueprints. But construction never initiates because the animation script lacks the required build action hooks. This limitation applies to any non-builder unit modified through tweakdefs.
Some units in the Spring engine have hardcoded targeting restrictions that tweakunits cannot override. Air units that attack only ground targets, for example, use weapondef target categories defined at the engine level. Changing which unit types a unit can attack requires modifying weapondefs target categories, which is sometimes possible through tweakdefs and sometimes requires engine-level access depending on how the restriction is implemented.
Removing specific unit wrecks from the battlefield after battles requires gadget or widget hooks that run on GameFrame. Some wreck removal patterns fail silently because the wreck object type differs from what the removal code expects. Wreck objects have different class names than unit objects and need separate handling in cleanup scripts.
When running modded test games, apply speedcontrol settings once at the beginning of the match rather than trying to toggle them mid-game. Speedcontrol 0 should be set before combat starts to avoid desync between the modified game state and the speed modifier.
The kind of deep technical troubleshooting that goes into BAR modding takes patience and a community willing to test things repeatedly. Creed of Champions provides that environment. Custom lobbies, patient teammates, people who understand what you are trying to do instead of questioning why. That makes a real difference when you are trying to get something working versus just playing ranked.
[Crd] I love being able to communicate with my team, getting and sharing tips and constructive feedback on gameplay, and having a good spirited community.