Getting started with BAR modding, tweakdefs, and Lua gadgets

A practical overview of how mod options, custom parameters, and Lua gadgets work in Beyond All Reason, including common pitfalls when porting ideas from similar RTS games.

Tags: bar modding, lua gadgets, tweakdefs, customparams, modoptions, lobby commands

Understanding Modoptions in the BAR lobby

Every BAR lobby exposes a modoptions panel that lets hosts tweak game rules before a match starts. Under the hood this panel reads configuration from the game's Lua scripts and serializes choices into a Base64 string that every player must agree on when the game launches. If you are building a local copy of the game to test changes, you will want to look at how the lobby encodes those options. The LuaMenu widget that handles the panel lives in the Chobby codebase where it reads modoptions definitions and builds the UI controls. Adding a new option means defining its type, default value, and any encoding rules so the lobby can serialize it correctly.

Customparams and model transformations

One topic that comes up repeatedly is model rescaling. Players coming from similar RTS games sometimes discover that model rescale customparams exist in those communities and assume BAR supports the same approach out of the box. BAR's architecture makes model-level transformations more complex than a single parameter. Changing a unit model's transformation matrix means working with Spring Engine gadget code that hooks into the base piece of the model. A common mistake is treating the transformation matrix as a simple multiplier when really you need to understand the hierarchy of pieces and apply the matrix at the correct level in that hierarchy. The BAR team has evaluated model rescale features in the past and declined them on performance grounds. That does not mean it cannot be done in a personal mod, but it requires careful understanding of how the engine handles piece transformations rather than brute-force multiplication of all transform values.

Placement gadgets and map boundaries

Beyond modoptions, BAR uses placement gadgets to enforce rules like preventing buildings from being constructed on cliffs or in water. These gadgets check terrain data and reject invalid positions during the build order phase. If you are experimenting with game rules and encounter issues where sea nanos end up incorrectly tagged, or buildings phase through cliff edges, the place gadget is usually the relevant system. Toggling placement boolean flags without understanding the underlying terrain checks can quickly create games where structures float or sink.

Working with local copies

The standard workflow for BAR modding starts with a local copy of the game files. From there you can edit gadget scripts, add new modoptions, and test locally before sharing with others. A few practical tips:

Always define your modoptions clearly so the lobby can encode them without errors
Check if Base64 encoding is needed for your custom parameters before the game launches
Test placement gadgets with varied terrain to catch edge cases early
Understand the piece hierarchy before attempting model transformations

Why BAR takes modding seriously

The BAR modding community values clean execution and thorough testing. Changes that break game sync or create desyncs between players get caught fast. The community expects modders to test locally, verify their options encode correctly, and understand what systems their changes touch. That discipline keeps the game stable and prevents the kind of chaotic modding environments that drive players away.

"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]

Creed of Champions values that same approach to teamwork: clear communication, careful execution, and zero blame when someone is still learning. If you are serious about BAR and want a community that treats improvement as a shared project rather than a scoreboard, the clan is worth a look.