BROKEN ARROW WORKBENCH

The data contract.

Coordinates

SystemAxes / units
Workbench / gameX east/right, Z north/up on the canvas, Y elevation; metres. Rimal spans X/Z 0–1,000.
Blender mapX=Workbench X, Blender Y=Workbench Z, Blender Z=elevation. Native-building yaw is negated on round trip to match the two views.
glTF modelsRight-handed, Y-up. Blender exporter uses its standard Y-up conversion; game adapter reflects Z, triangle winding, rotations and bind poses into Unity coordinates. Do not manually apply another axis flip.

Project structure

project.baw                  schema 1 JSON; project, assets, layout, scenario GUID
height-metres.f32             513² little-endian float32 samples; metres
Assets/<id>/model.glb        validated deployable visual
Assets/<id>/editable.blend   Blender working file (not deployed)
Assets/<id>/validation.json  import report
Jobs/                        JSON requests to background tools
Logs/                        conversion / Unity logs
Backups/                     Blender map-return checkpoints
Exports/                     timestamped staged game packages

Keep the whole project directory. Moving it is supported: deployable asset paths are relative. Original Source paths are informational. Project IDs remain stable across saves. Opening two copies with the same ID means they deploy over the same project slot; create a new project before making an independent variant.

Supported GLB subset

Game-only shaders, procedural Blender node graphs and Unity Editor components do not transfer simply by importing an FBX. Start with baked opaque base-colour materials and an efficient mesh. Large polygon counts produce a warning rather than a false performance guarantee.

Map scope

The map companion is the existing TBS Maps source, version 0.1.5, extended to read a Workbench project route. Default Rimal/coast map data remains the fallback. Workbench authoring supports only the two known Rimal local scenarios, at 1 km/513 samples. The original 8 km coast scenario can still use its original data; this app does not author or deploy that larger map format.

Building families reference installed native prefabs. Native building footprints affect navigation blocking. Imported GLB visuals do not affect navigation, collision, cover or building destruction. Roads are generated surfaces/masks; they are not newly registered native highway assets. The exporter writes an all-urban mask, suitable for this district; separate land-cover painting and water authoring are not in this build.

What makes a model a functioning native unit?

The visual pipeline is only one part. A combat unit needs stable game registry identifiers, spawn/deck categories, ownership, targetability, health, movement/nav data, weapon definitions, ammunition, animation-state integration, death/destruction and serialization/network compatibility. Workbench 0.1 does not manufacture these systems. There is no "attack" checkbox claiming otherwise.

The next development task is a version-specific native unit adapter and a documented entity schema. That work must use supported game behaviour, keep BARO unchanged, and undergo local gameplay acceptance. It is intentionally absent from the current export format instead of silently substituting a native vehicle under an imported monster.

Deployment targets

Mods/ThunderBuddiesWorkbench.dll
Mods/ThunderBuddiesMaps.dll
UserData/TBSWorkbench/active.json
UserData/TBSWorkbench/Projects/<id>/scene.json
UserData/TBSWorkbench/Projects/<id>/Assets/...
UserData/TBSWorkbench/Projects/<id>/Map/...  (when enabled)

Deployments never write BrokenArrowRealismOverhaul.dll, BrokenArrow.exe, EasyAntiCheat directories, deck files, saved games, settings or scenario definitions. The revised TBS Maps DLL replaces the existing companion with a backup. Only one Workbench project is active at a time.

Reference documentation