Tags: bar modding, lua scripting, customparams, buildoptions, tweakdefs, spring engine
Tweakdefs and gadget scripts in BAR use the Spring Engine Lua API to modify unit definitions at load time. A few common mistakes trip up new modders every week. Here is what to watch out for.
If a unit definition already contains a customparams.discountable field, you can modify it inside alldefs_post. Setting that value to 0.1 will take effect on any unit where the field exists.
The catch: modifying a field that does not already exist on a unit does nothing. BAR does not create the parameter on the fly. Modders expecting a new customparam to appear on every unit type need to add it explicitly to the unit definition file itself, not through a post-processing script alone.
Adding a new build option looks like a simple array push:
uDef.buildoptions[numBuildoptions + 1] = "cordronecarry"
That pattern works because buildoptions is an indexed array stored on the unit definition. Count the existing entries, increment the index, assign the new build name. The Chobby lobby reads this table when generating build menus, so the new option appears without additional lobby code.
Setting custom params to unit definitions inside gadgets causes problems. The gadget environment is meant for runtime simulation logic. Unit definition mutation belongs in the mod option and alldefs processing layer, not in synced or unsynced gadget code. The BAR modding community flagged this as a recurring source of bugs after the Chobby post-mortem review.
Keep definition edits in the modoptions and alldefs phase. Keep gadget code focused on gameplay logic. The split keeps the game deterministic and prevents lobby desyncs.
The Spring Engine wiki documents LuaUnsyncedRead functions like GetActiveCommand that modders use to inspect what the engine is doing during a game. When a tweak seems to silently fail, checking the wiki for the correct API call often reveals a naming mismatch or a missing sync qualifier.
Consistency between what you write in Lua and what the engine expects saves hours of debugging. Always test a small change, read the Spring log output, then scale up.
Clean modding habits mirror clean gameplay habits. Players who double-check their code before pushing also tend to call out strategies, share replays, and keep team chat focused. Creed of Champions built its community around that same discipline. The space welcomes players who want improvement without the toxicity.
"One of the few places where you can for sure coordinate with people in matches with a good supportive attitude. Everybody tends to be understanding and constructive." [Crd]
If you are learning BAR modding on the side while playing, that mindset carries over.