BAR widget testing policy and what cannot be tweaked

Settings you cannot change via tweakunits

Not every BAR parameter responds to tweakunits commands. Some values are hardcoded in the game definition layer and require direct definition file editing. Unit names fall into this category. You cannot rename units through tweakunits because the name strings are not exposed to that system.

A workaround exists for local-only changes. Placing a custom translation file in your local BAR installation, positioned to mimic the language folder structure, lets you override displayed names. This only affects your own screen. Other players see the standard names.

Open widget testing versus whitelists

Some argue for widget whitelists that only allow approved widgets in public games. The counter-argument holds that open testing produces better widgets faster. When any player can try any widget, bugs get reported sooner and improvements emerge from real gameplay feedback.

The current compromise bans user-created widgets in official tournaments but permits them in regular multiplayer matches. This preserves competitive integrity while allowing casual widget experimentation. Most community members find this balance acceptable.

Screen clutter and widget design

Widgets that add too much visual information to the screen create clutter that hurts gameplay. The solution is not removing the widget but designing it with toggleable sections. Players should choose which data layers appear based on the current game phase.

Using the Spring reference wiki

The Spring engine reference documentation at beyond-all-reason.github.io/spring covers the modding API surface including command definitions, unit properties, and engine behavior. This wiki provides the technical reference that BAR-specific documentation sometimes lacks.