1. Keep your original FBX, textures and authoring files in a separate working folder.
2. Open your original FBX-based ship in **Ship Setup**.
3. Finish your changes and click **Save JSON**. Unsaved settings must be saved before export.
4. Choose the export setting:
   - **Export settings: editable** (default): recipients can adjust the ship configuration, including equipment placement and handling.
   - **Export settings: locked**: the game uses an authenticated copy of the exported settings inside the protected model. Changes to the external JSON do not replace those settings, and Ship Setup cannot save them.
5. Click **Export protected ship**.
6. Read the status message for the new export folder. Share that complete folder, rather than your original authoring folder.

Exports are created in: <game project directory>/Saved/ShipExports/<ship-id>-export-<unique-id>/

Every export creates a new directory. The original FBX ship and earlier exports are preserved.

What to distribute

A typical export contains:

```text
my-ship-export-.../
    boat.json
    model.atsship
    preview.png       (if present)
    Sideview.png      (if present)
    Audio/...         (only configured audio files, if present)
```

The exporter copies the configured preview, sideview and audio files. These supplementary files remain ordinary files. The original FBX and loose model textures are not copied; texture pixels needed by the model are embedded in the encrypted model.

Do not add the original FBX or source textures to the export folder yourself if you want to keep them private. Review any other personal information in your ship configuration before sharing it.

Installing a protected ship

Recipients place the complete exported folder under:

```text
Mods/Boats/<ship-folder>/
```

The folder must contain `boat.json` directly, alongside `model.atsship`. Reload the custom ship list or restart the game as usual. The JSON references the local protected model:

```json
"model": "model.atsship"
```

Do not rename that model file without rebuilding the export. Keep the exported ship ID. A source version and its protected export share the same ID, so install one version at a time to avoid duplicate-ID conflicts.

Recipients need a game build that supports `.atsship`. Older builds that accept only FBX cannot load these exports.

Equipment and controls

The format preserves the static geometry's object names, hierarchy, pivots, material sections, vertices, triangles, normals, UVs, vertex colours and tangents. Object-name assignments for propellers, rudders, radar antennas, lamp lenses and bridge controls continue to use those names.

With editable settings, recipients can use the existing ship editor and save JSON changes. The protected model remains protected. The game does not provide an FBX export or a protected-model re-export command.

With locked settings, Ship Setup is for viewing the model and placements. The creator needs the original FBX authoring version to change settings and create a new release. The lock is enforced by the game; it is not a guarantee against a modified game or reverse engineering.

Updating a protected ship

Edit the original FBX-based version, update its configuration/version, save it and export a new protected copy. Distribute the complete new folder. Keep backups of your original project: the protected distribution is not an editable source backup.

Format and limits

- Static imported ships only; skeletal models are not supported by this export format.
- Maximum 2,000,000 section vertices and 6,000,000 triangle indices per model.
- Maximum 8,192 nodes and 8,192 material sections overall, with up to 512 sections per node.
- Maximum texture dimensions: 8,192 × 8,192 pixels.
- Prepared model data and expanded texture references have memory limits of 512 MiB. Very large or heavily repeated textures can exceed these limits even when the source FBX is small.
- The model uses a versioned binary format, compression and authenticated AES-256-GCM encryption. Damaged or modified encrypted data is rejected.
- Geometry is decrypted in memory. The loader does not write a temporary plaintext FBX or an unencrypted model cache.
- Existing FBX import remains unchanged for creators who choose not to use protected export.

The editor's generator selector starts at 1 for convenience. JSON and the Blueprint Generator Index start at 0.

The editor shows an outlet placement marker, not a live smoke preview. Save JSON and reload the ship to apply your changes. Creator-locked protected ships cannot have their settings edited; configure the original FBX-based version and export a new release.

Merge these entries into the existing `bridgeEquipment` array. Keep other entries; do not create a second array with the same key. Every entry needs a unique `id`.

```json code
{
  "bridgeEquipment": [
    {
      "id": "main_engine_exhaust",
      "type": "Exhaust",
      "action": "Engine1",
      "positionCm": [-500, -100, 800],
      "rotationDeg": [0, 0, 0],
      "exhaustEnabled": true,
      "exhaustAutoRPM": true,
      "exhaustIdleRate": 12,
      "exhaustFullRate": 70,
      "exhaustIdleSpeed": 40,
      "exhaustFullSpeed": 120,
      "exhaustScale": 1
    },
    {
      "id": "second_engine_exhaust",
      "type": "Exhaust",
      "action": "Engine2",
      "positionCm": [-500, 100, 800],
      "rotationDeg": [0, 0, 0],
      "exhaustIdleRate": 12,
      "exhaustFullRate": 70,
      "exhaustScale": 1
    },
    {
      "id": "generator_1_exhaust",
      "type": "Exhaust",
      "action": "Generator",
      "generatorIndex": 0,
      "positionCm": [-700, 0, 900],
      "rotationDeg": [0, 0, 0],
      "exhaustAutoRPM": true,
      "exhaustIdleRate": 3,
      "exhaustFullRate": 15,
      "exhaustIdleSpeed": 20,
      "exhaustFullSpeed": 60,
      "exhaustScale": 0.6
    }
  ]
}

Positions are ship-local centimetres: +X forward, +Y starboard, +Z up. Rotation order is `[pitch, yaw, roll]`, in degrees. Position values above are examples, not automatic funnel detection.

| Field | Default | Meaning / range |
| --- | --- | --- |
| `action` | `Engine1` | `Engine1`, `Engine2` or `Generator` |
| `generatorIndex` | `0` | Generator index, 0–63 |
| `exhaustEnabled` | `true` | Enables this outlet |
| `exhaustAutoRPM` | `true` | Uses the assigned machine's RPM range |
| `exhaustIdleRPM` | `700` | Manual lower RPM, 0–100000 |
| `exhaustFullRPM` | `4200` | Manual upper RPM, 1–100000; must exceed the lower value |
| `exhaustIdleRate` | `12` | Lower output, 0–2000 particles/second |
| `exhaustFullRate` | `70` | Upper output, 0–2000 particles/second |
| `exhaustIdleSpeed` | `40` | Lower exit speed, 0–10000 cm/s |
| `exhaustFullSpeed` | `120` | Upper exit speed, 0–10000 cm/s |
| `exhaustScale` | `1` | Smoke sprite size multiplier, 0.01–100 |

Currently the shared `bridgeEquipment` limit of 64 entries includes exhaust outlets, instruments, lights, antennas and controls.

Use the Heeling section to choose whether the vessel leans into a turn, leans away from it, or has no additional turn heel. The effect responds to the ship's actual forward speed and rate of turn. Adjustable strength, an angle limit and separate response and return times let you create a quick banking motion or a slower, more restrained response.

The additional turn heel is combined with the existing wave-induced roll. Turning it off does not stop the ship from rolling in waves. The maximum turn
heel setting limits this additional contribution, not the vessel's total roll.

Ship Editor Workflow

1. Open the imported ship in the Ship Editor.
2. Select Heeling in the left-hand list.
3. Enter the required values. Press Enter or leave the numeric field to commit it.
4. Select Save JSON to save the changes.
5. Start a new voyage with that ship to test the result.

Use Default next to an individual field to remove its saved override. The
editor then uses the native default for that setting.

Heeling Parameters
Configure the additional turn-induced roll described below.

Editor label                              JSON key                                 Default  Range
Turn heel direction             TurnHeelMode                             None     See modes
Turn heel strength              TurnHeelStrength                             1.0      0 to 4
Maximum turn heel (deg)   MaximumTurnHeelDegrees             6.0      0 to 30
Heel response time (s)        TurnHeelResponseTime                   1.0      0.01 to 60
Heel return time (s)             TurnHeelReturnTime                        1.5      0.01 to 60
Minimum heel speed (kn)   MinimumTurnHeelSpeedKnots        2.0      0 to 200

TurnHeelMode
None: disable additional turn-induced heel.
Inward: lean towards the inside of the turn.
Outward: lean towards the outside of the turn.
JSON mode strings are case-sensitive. Use the names, not numeric enum values.

TurnHeelStrength
Multiplies the calculated target angle. Higher values produce more heel for 
the same speed and rate of turn, subject to MaximumTurnHeelDegrees.

MaximumTurnHeelDegrees
Caps the absolute target angle of the additional turn heel. It is a limit,
not a fixed angle that the vessel will reach in every turn. A value of zero
produces a zero turn-heel target.

TurnHeelResponseTime
Controls smoothing when heel builds in the same direction. A larger value
gives a slower response. It is an exponential time constant, not an exact
delay or the time required to reach the final angle completely.

TurnHeelReturnTime
Controls smoothing when heel decreases, returns towards zero or changes
direction. Larger values make the motion settle more slowly.

MinimumTurnHeelSpeedKnots
Below this absolute forward-speed threshold, the turn-heel target becomes
zero and the additional heel fades using the return time. This uses forward
speed through the vessel's heading, not the total sideways velocity.

JSON EXAMPLES

These are partial configuration objects, not complete ship manifests. Merge the fields into the existing root-level handling object in boat.json. Preserve
other handling fields and the rest of the ship configuration. Do not create two handling objects or replace the complete boat.json with a snippet.

Example A — slower outward heel:

{
  "handling": {
    "TurnHeelMode": "Outward",
    "TurnHeelStrength": 0.65,
    "MaximumTurnHeelDegrees": 4.0,
    "TurnHeelResponseTime": 3.0,
    "TurnHeelReturnTime": 5.0,
    "MinimumTurnHeelSpeedKnots": 1.5
  }
}

Example B — quicker inward banking:

{
  "handling": {
    "TurnHeelMode": "Inward",
    "TurnHeelStrength": 1.0,
    "MaximumTurnHeelDegrees": 8.0,
    "TurnHeelResponseTime": 0.8,
    "TurnHeelReturnTime": 1.5,
    "MinimumTurnHeelSpeedKnots": 3.0
  }
}

Example C — disable additional turn heel:

{
  "handling": {
    "TurnHeelMode": "None"
  }
}

Editor setting                                        JSON key
Tank capacity (L)                                    FuelCapacityLiters
Initial fuel (L)                                          InitialFuelLiters
Idle consumption per engine (L/h)        IdleConsumptionLitersPerHour
Full-throttle consumption per engine   FullThrottleConsumptionLitersPerHour

Capacity: 0.01 to 100,000,000 litres.
Initial quantity: 0 to capacity, with the same 100,000,000 litre upper limit.
Consumption: 0 to 1,000,000 litres/hour per running engine.
Full-throttle consumption must be at least the idle consumption.

Example

Merge these fields into the existing root-level handling object in boat.json.
Keep other handling fields and the rest of your manifest. This snippet is not
a complete ship definition. The values illustrate a large-tank configuration
and are not a calibrated preset for any real ship.

JSON CODE

{
  "handling": {
    "FuelCapacityLiters": 500000,
    "InitialFuelLiters": 350000,
    "IdleConsumptionLitersPerHour": 50,
    "FullThrottleConsumptionLitersPerHour": 800
  }
}

How consumption works in Across the Seas

Only running main engines contribute to consumption. For each running engine,
the rate is interpolated linearly between idle and full throttle using the
absolute throttle input. Forward and reverse use the same absolute-input rule.

With the example above:
One engine at idle:             50 L/h
One engine at 50% input:  425 L/h
One engine at full input:    800 L/h
Two engines at full input:  1,600 L/h from the shared tank

Stopped engines consume nothing through this calculation. Refuelling is capped
at the configured capacity. The existing empty-tank engine-stop behaviour and
fuel gauges use the configured tank. Fuel-pump electrical demand is configured
separately through the electrical system's fuelPumpLoadKw setting.

The rates configure the main propulsion engines. Generator fuel use is not
added by these settings.

Radar display

`type: "Radar"` adds an interactive 3D radar display. Set its size with `widthCm` and `heightCm`, and its local brightness with `brightness` (0–1).

The display's local **+X faces the viewer**, and **+Z is screen up**. Adjust `rotationDeg` to match the console.

Radar needs electrical supply, an enabled radar circuit and the radar device switched on. The UI and 3D instrument provide the device power control and share its state.

Rotating radar antennas

`type: "RadarAntenna"` animates an existing FBX object. It does not create antenna geometry or a separate radar sensor.

| Field | Meaning |
| --- | --- |
| `mesh` | Unique FBX name of the rotating scanner only |
| `positionCm` | Rotation pivot in ship-local centimetres |
| `rotationDeg` | Orientation of the pivot |
| `axis` | Local rotation axis; `[0, 0, 1]` is vertical for an unrotated pivot |
| `rotationDegrees` | Rotation speed in **degrees per second**, despite the field name |

`rotationDegrees` defaults to `45` and accepts −720 to 720. Negative values reverse rotation; `0` stops it. `axis` must be nonzero and is normalized automatically.

Assign only the moving scanner, not its stationary base. The pivot must be positioned at the scanner's rotation shaft. Mesh placement is preserved when it is attached to the pivot.

You can add multiple antenna entries with unique IDs and separate meshes. They can rotate at different speeds and in different directions, but all follow the ship's shared radar power state. They stop when the radar device, circuit or supply is off. Meshes already assigned to another moving control, propeller or rudder cannot be assigned again as an antenna.

Add the entries to the existing top-level `bridgeEquipment` array in your ship configuration. Keep all other ship settings and existing equipment. Do not create a second `bridgeEquipment` key.

The combined example below is an equipment section, not a complete ship configuration. Replace its example positions and FBX object names with those for your ship.

- Each entry needs a unique `id`.
- Positions use centimetres in ship-local coordinates: **+X forward, +Y starboard, +Z up**.
- `rotationDeg` is `[pitch, yaw, roll]` in degrees.
- `mesh` identifies an FBX object by name, not a file path or material name. Use unique object names.
- The array supports up to **64 entries in total**, including instruments, controls, lights and antennas.
- Save the configuration and reload the ship to apply changes. The ship editor shows placement markers for lights, rather than a live lighting preview.

Merge the entries in this array into your existing `bridgeEquipment` array:

Use `type: "NavigationLight"` and select the light's role with `action`. With `lightRoleDefaults: true`, the existing navigation light system supplies the role's colour and visibility sector.

| Role (`action`) | Purpose |
| --- | --- |
| `PortSidelight` | Red port sidelight |
| `StarboardSidelight` | Green starboard sidelight |
| `Sternlight` | White sternlight |
| `ForwardMasthead` | Forward masthead light |
| `AftMasthead` | Aft masthead light |
| `ForwardAnchor` | Forward or single anchor light |
| `AftAnchor` | Aft anchor light |
| `TowingMastheadSecond` | Second light in the towing masthead group |
| `TowingMastheadThird` | Third light in the towing masthead group |
| `TowingYellow` | Yellow towing light |
| `FishingUpper` | Upper fishing light; colour follows fishing mode |
| `FishingLower` | Lower fishing light |
| `FishingAdditionalMasthead` | Additional fishing masthead light |
| `FishingGearDirection` | Fishing gear direction light |

Roles are switched by the existing **Off, Navigation, At Anchor, Towing and Fishing** modes. Some roles depend on vessel length and the native towing/fishing settings. Adding a role does not mean it is enabled in every mode. Imported vessel length is taken from the configured hull length

For example, a larger vessel can add `AftMasthead` and `AftAnchor` entries at appropriate positions.

Optional lens mesh

Without `mesh`, a navigation light uses a small sphere as its lens. Set its radius with `lightRadiusCm`.

With `mesh`, the selected FBX material slot is replaced by the supplied lamp material, and the sphere is removed. **Use a dedicated lens material slot, not a slot shared by the lamp housing or the entire ship.** Slot numbering starts at **0**. The source FBX file is unchanged.

Missing or ambiguous mesh names, invalid slots and duplicate mesh/slot assignments are skipped and logged. If a navigation lens assignment cannot be made, the fallback sphere remains.

Custom colour and sector

Set `lightRoleDefaults` to `false` to use `color`, `lightArcDegrees` and `lightSectorYaw`. Sector yaw is measured relative to the ship's forward axis; rotating the placement marker alone does not rotate the sector. Fishing mode can override fishing-light colours through the existing native logic.

Bridge, work and exterior lights

| Equipment type | Lighting group / radial menu entry |
| --- | --- |
| `BridgeLight` | Bridge |
| `DeckLight` | Deck Work |
| `ExteriorLight` | Exterior |

These types create point lights that illuminate nearby surfaces. `lightIntensity` is measured in **lumens**, and `lightRangeCm` controls their reach. Shadow casting is optional and disabled by default.

They also support an optional `mesh` and `lightMaterialSlot` to illuminate a lens using `lightEmissive`. This replaces only the selected material slot, just as for navigation lights. Without a lens assignment, the point light still illuminates its surroundings.

Light fields

| Field | Default | Allowed values / meaning |
| --- | --- | --- |
| `color` | `[1, 1, 1]` | RGB components, each 0–1 |
| `lightIntensity` | `500` | 0–100000 lumens; group lights only |
| `lightRangeCm` | `500` | 1–100000 cm; group lights only |
| `lightRadiusCm` | `3` | 0.1–100 cm; fallback navigation lens radius or point-light source radius |
| `lightEmissive` | `25` | 0–1000; lens emission strength |
| `lightCastShadows` | `false` | Point-light shadow casting; group lights only |
| `lightRoleDefaults` | `true` | Automatic navigation colour and sector |
| `lightArcDegrees` | `360` | 0.1–360 degrees; custom navigation sector |
| `lightSectorYaw` | `0` | −180–180 degrees; custom navigation sector centre |
| `lightMaterialSlot` | `0` | Integer 0–63; must also exist on the assigned mesh |

Light controls and power

The radial menu continues to work. Its navigation modes and Bridge / Deck Work / Exterior commands control the same systems as assigned bridge switches.

- Battery-powered ships require the battery master to be on and the battery to have charge.
- On ships using the ship power network, navigation and bridge lights use UPS supply by default; deck and exterior lights use the main bus by default.
- Individual imported lamps do not add a separately configured electrical load. Existing electrical-system loads still apply.

Here is a quick guide for importing you own created watercraft into the sim. I will improve and expand the docs for importing over the dev time. You can you the small car ferry in the Mods/Boats folder as a template.

Structure tree of imported models. Propeller and ruder (needs to renamed to rudder, will come with an update) correct naming is needed in your 3d program.

Mods/
└── Boats/
    └── MyFishingBoat/
        ├── boat.json
        ├── ship.fbx
        │   ├── Prop1
        │   ├── Prop2
        │   ├── Ruder1
        │   ├── Ruder2 
        ├── preview.png
        ├── Textures/
        │   ├── hull_basecolor.png
        │   ├── hull_normal.png
        │   └── hull_roughness.png
        └── Sounds/
            ├── engine_idle.wav
            ├── engine_running.wav
            └── horn.wav

Ship Setup —ingame watercraft editor

If the naming is correct, the imported folder structure would be regcognized by the sim and the boat will be visible in the boat selection menu. For imported ships is the boat editor available in the boat selection menu. Most of the setup can be done in the editor and only a small part is only needed in the json file. 

Open and edit

1. Open ship selection, choose a custom ship and press **Ship Setup**.
2. Right-drag to orbit; middle-drag to pan; wheel to zoom. Click the preview for keyboard focus,
   then use W/A/S/D and Q/E to move the view. Shift increases the movement step.
3. Select a point in the left list or click its marker. Drag an axis (red X, green Y, blue Z),
   or commit a numerical coordinate on the right with Enter or by leaving the field.
4. **Preview bridge** looks from the configured camera. **Use view as bridge** copies the current
   preview camera position, rotation and FOV to that point. **Frame ship** returns to orbit.
5. **Save JSON** writes setup to this package's `boat.json`. It preserves unrelated top-level fields,
   including the existing physics tuning. Known setup objects/arrays are rewritten. Changes apply
   on the next voyage, not to a boat already running in the world.
6. **Close / discard unsaved** discards unsaved configuration changes. It does not undo earlier saves.

The preview has no boat simulation or collision and is destroyed on close. It is currently a standalone/singleplayer authoring tool.
The source FBX is not changed by this tool.

Before a save, the previous JSON is copied to `Saved/ShipSetupBackups/<id>/boat-<unique-id>.json`.
If the manifest changed since opening, the save is rejected: close and reopen Ship Setup.
Read-only installations cannot be edited until the mod directory is writable. Backups are outside
the Mods directory and therefore are not automatically included in a new package.

Propellers and rudders: one FBX, separate objects

Recommended authoring convention:

- Hull/superstructure: ordinary static objects.
- `Prop1`, optionally `Prop2`: individually selectable propeller mesh objects.
- `Ruder1`, optionally `Ruder2`: individually selectable rudder mesh objects.

Export the objects **together in the main ship FBX**. Do not combine them into one hull mesh. Each name
must be unique. Apply export scale/orientation consistently and triangulate. All vertices should remain
in the ship's assembled positions. Empty helper nodes are not visible propeller/rudder meshes.
The editor dropdown can map other object names; names are matched case-insensitively. Missing,
ambiguous or already-used names skip animation rather than preventing the boat from loading.
Select **None** when no visual model is available. The physical propulsion/rudder points still work.

There is no requirement to supply these meshes immediately. The current ferry can use its existing
FBX until the propeller/rudder objects are modelled. Separate extra FBX files are not imported by this
version. They can be supported later, but would also need explicit transforms, scale and material paths.

Each part has two points:

- **Force**: where the existing boat physics applies propulsion/rudder forces.
- **Pivot**: the rotation centre of the visible object. It need not equal the force point.

`axis` and `direction` control **cosmetic animation**, not an azimuthing thrust direction. The axis is
in boat coordinates, nonzero and normalised on save; +X is typical for shafts, +Z for rudders.
Use +1 or -1 for direction. **Toggle animation** tests the pivot and direction without running physics.
During a voyage, propellers follow engine RPM/drive direction and rudders follow steering input.
The native propeller animation speed scale remains 0.2. Two engines split `thrustKN` equally;
adding the second engine does not double the configured total thrust. The normal two-engine UI is reused.

Mooring and fenders

**+ Mooring point** creates a station that works with the existing O / Ctrl+O mooring interface.
Set position, label, rope diameter, maximum length and breaking load. Up to 32 stations are supported.

**+ Fender** adds a standard small rubber-fender representation (an elongated sphere), plus a separate

**rope top** marker. Position the centre alongside the hull and the rope top on the rail/attachment.
The wire outline in the preview shows the configured size. Port/starboard chooses the control group;
changing the side button also sets yaw to face outboard. Local +X must face away from the hull, +Z up.
The runtime component reuses the existing deployment, contact and cosmetic pendulum logic. Its visible
rope ends at the fixed ship attachment and it adds no separate rigid-body mass. Up to 32 fenders.
Custom fender mesh files and large quay-fender authoring are not part of this ship-setup extension.

Sounds and preview images

Select **Engine sound** or **Horn sound** to edit sound filenames and attenuation. Files are relative
to the boat folder. Use forward slashes, for example `Sounds/engine.wav`; absolute paths, `..` and
backslashes are rejected. Empty fields are allowed. A missing/unsupported WAV is skipped with a warning.

- Supported audio: uncompressed PCM16 WAV, mono/stereo, 8–96 kHz, at most 16 MiB and 120 seconds each.
- Prefer **mono** for spatial localisation. Supply engine start, seamless running loop, engine stop
  and horn as separate files. The two engines have independent playback cursors but share the configured
  engine sound position in this version. No sound assets are supplied/generated by the code.
- Attenuation inner radius and falloff are in centimetres; volume is 0–2.
- Supported selection image: PNG, at most 2048 × 2048 and 8 MiB. When the `preview` field is missing
  or empty, `preview.png` beside `boat.json` is used automatically. Explicit filenames take priority;
  an invalid/missing explicitly selected image does not silently fall back to another file.
  Reopen ship selection after copying an image into the package folder.
- **Create preview PNG** captures the current ship-only view without markers to a unique new PNG in
  the package. Then press **Save JSON** to assign it. Existing images are not overwritten. The generated
  PNG remains on disk even if you close without saving the configuration; remove unused captures manually.

JSON fields (optional extension to schemaVersion 1)

Existing schema-1 manifests still load with one physical propeller and rudder and their legacy points.
Retain the required legacy `cameraCm`, `propellerCm`, `rudderCm` fields. The editor keeps the latter two
in sync with the first array entries. New fields can be added to the existing object; this fragment is
not a complete manifest and its coordinates are examples, not calibrated positions for the ferry

Positions/sizes are boat-local centimetres (+X bow, +Y starboard, +Z up), **after** the presentation
model's scale/offset/rotation. Rotation arrays are pitch, yaw, roll in degrees. These setup settings do
not automatically compute hull collision, displacement or stability. Keep the existing tuned values.

Imported-ship handling settings

Ship Setup now has four English-language sections: **Performance**, **Rudder**, **Heeling**,
and **Resistance**. These expose the existing native BoatPawn controls, not a new physics model
or automatic copying from a Blueprint boat. Save with **Save JSON**, then start a new voyage.
Blueprint boats and the existing imported-ship buoyancy coefficients are unchanged.

- Performance: total/per-shaft thrust, reverse thrust, RPM response, thrust exponent, optional
  low-speed boost, engine-start immersion requirement and speed limiting.
- Rudder: angle, actuator speed, lift/force limits, propeller wash and each rudder's physical area.
  Length and height are full centimetre dimensions; they do not resize the visible mesh.
- Heeling: None, Inward or Outward turn heel, strength, maximum angle, response/return times
  and minimum speed. This is turn-induced heel, not wave damping.
- Resistance: lateral grip, three-point resistance and its yaw contribution/weights, plus
  linear/angular damping. Angular damping affects all rotation, including roll and pitch.

An optional `handling` object uses the exact C++ property names shown below each control.
Only edited overrides are stored. **Default** removes that override and restores the native
default; per-shaft thrust instead falls back to an equal share of root `thrustKN`.
Root `thrustKN`, `linearDamping` and `angularDamping` are saved from their own controls.
Second-shaft/second-rudder settings require two corresponding attachment entries.
Native force values are Unreal force units: **1 kN = 100,000 UE units**.

Example fragment (illustrative values):