Tags: modding, bar, beyond-all-reason, game-dev, tweakdefs, unitdefs, weapondefs
Quick-reference notes from the BAR modding community on unitdefs, weapondefs, and the tweakdefs pipeline — the stuff that actually matters when you're trying to get your tweaks working.
Most modding questions about BAR tweakdefs come down to one thing: not knowing which layer to touch. Unitdefs and weapondefs are separate systems, but tweakdefs sits on top of both. You need to know which file you want to inherit from before changing anything.
The common pattern is copying a unit definition, changing a stat, and wondering why it didn't work. Usually it's because fireState or weapon references weren't updated alongside the unit change. Every tweakdef entry that modifies a unit also needs to account for the weapons that unit carries.
The SpringRTS wiki documents fireState under UnitDefs, and it needs to be set explicitly in your tweakdefs code. If you copied a unit from the base game and changed its weapon but left the original fireState, your unit will either refuse to fire or fire when it shouldn't.
The fix is always the same: check the fireState value on the source unit, then set your own value in the tweak. Don't leave it inherited unless you want the behavior matching the original exactly. For custom units like a modified Armlich, that almost never works out.
There's no point reinventing the wheel. BAR's codebase has reference implementations you can study. The cordoom unit definition on GitHub is a solid template for understanding what weapondefs fields need to be checked and changed alongside unit modifications.
When you're building a new unit or heavily modifying one, copy the structure from an existing working unit and adapt it. The weapondefs fields — weaponType, damage, areaOfEffect, and reloadTime — all need to be consistent with the unitdef they belong to. A mismatch means either crashes or broken behavior in-game.
There's a debate in the BAR modding scene about building generic tweak systems versus setting units individually. Generic is elegant — write one rule and it applies across multiple units. But it's harder to debug. If you're just starting, set units individually until you understand the dependency graph. Then abstract.
The BAR modding community works because experienced builders share reference implementations instead of gatekeeping. That ethos carries into the broader BAR community:
"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."