tags: modding, buildoptions, lua, blender, beyond-all-reason
Three practical modding takeaways from the BAR community: where buildoptions live, what to know about Blender-to-BAR texturing, and the challenge of action-tracking cameras.
The buildoptions table in a unit definition file controls what that factory or builder can construct. Look at armvp.lua in the ArmBuildings directory for a clean example. If you are trying to add or remove units from a build menu, this is the file to edit. It is not a widget, it is not a tweakdef. It is the unit def itself.
Exporting from Blender to BAR uses Spring RTS workflow but with a twist. BAR ships with three megatextures - normals, color, and a third texture channel. Getting a model inside the game file is the easy part. Getting it textured correctly is where people hit the wall. You need to match BAR's megatexture layout rather than standard PBR pipelines. Post your attempt in the modding channels and someone will spot what is wrong faster than you will figure it out alone.
Building a camera widget that follows the most intense action on the map sounds simple until you realize you need to measure projectile density in real time. Where are the most projectiles flying right now. Which units are clustered. BAR does not expose a clean API for "where the action is." You can approximate it by tracking explosions and unit counts per zone, but keeping that smooth and performant is the real challenge. Anyone claiming to have solved this cleanly should show the code.
"Having a space like here that offers a community, trainings, events, and the guarantee to not be judged or insulted by fellow members is really precious. Keeping the game safe, and more importantly, fun."