Sterister f21bcb7b11 Pitch-compensated lift feedforward: hold altitude under forward thrust
Reported symptom: the ship sinks as soon as it moves forward. Confirmed in
code -- altitude.lua had no pitch input at all. Pitch only fed the front/aft
differential; nothing compensated the common-mode lift. So when the propeller
pushes the nose up, the lift vector tilts with the hull and its vertical
component drops ~cos(pitch), and only the slow altitude integrator (~5-10 s)
fought it -> a multi-block sag every time you accelerate.

- altitude.lua takes measured pitch and boosts common-mode lift by 1/cos(pitch),
  bounded by cfg.pitchLiftMax (default 1.5 = full comp to ~48 deg, 1.0 = off).
  Sign-agnostic (cos is even); feedforward adds no loop gain so it can't
  destabilize -- altitude feedback still owns steady-state.
- FLY HUD shows the live boost (liftFF xN.NN); u_sum in fly.log reflects it.

Physically motivated but unverified against the mod's exact lift model: if lift
were world-vertical the ship would climb slightly on accel instead (feedback
corrects it) -- still better than sinking. Tune pitchLiftMax from flight.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-25 18:13:40 +02:00

Airship Autopilot (Create: Aeronautics + CC:Tweaked)

Altitude/pitch autopilot for a hot-air airship, delivered as an in-game installer so it runs on any Minecraft server regardless of the computer's id.

Install — ONE command, both PCs

Run the same command on each CC computer:

wget run https://gt.zyon.no/Stian/airship-autopilot/raw/branch/main/install.lua

The installer detects which PC it is on (flight sensors → autopilot, monitor → cockpit), installs the right role, and continues straight into setup — no reboot, no role names to remember. Re-run the same command any time to update; it also cleans out files that no longer belong and asks whether to keep or reset the ship profile.

(Advanced: append autopilot or cockpit to override detection.)

Requires HTTP enabled on the server (default on). If it is off, set [http] enabled = true in computercraft-server.toml and restart the server.

First-time setup (per ship)

The installer ships code only — everything ship-specific (which redstone side drives which balloon, pitch sign, hover level) is measured on the ship by the setup wizard, which the install flow takes you straight into:

  1. Wiring — the wizard pulses each free side; you say which burner fired.
  2. Sign test — the ship lifts off by itself, finds its own lift power, waits until buoyancy has righted it and the rates have steadied, and only then takes its attitude reference. It rocks between front and aft pushes; the sign comes from rate(+push) rate(push), which cancels any constant lean exactly, so a ship hanging crooked measures fine — that lean is what is being measured. It then learns the differential trim that levels the ship, saves it as a warm-start, and descends to hover. No config editing, no freefall. Takes 24 minutes.

A hull built to fly usually lies over on the ground; that is fine and expected. The ground attitude is never used as a reference — nothing is measured until the ship is airborne and steady.

After that the ship is ready: FLY from the menu or ENGAGE from the cockpit console. Pitch and altitude keep self-learning in flight. The wizard can be re-run any time: ap setup, press S in standby, or menu choice 1.

Balloon orientation does not need to match any particular side of the computer — or any particular build direction: sensors are found by type, wiring is mapped by the wizard, and the sign test measures which gimbal axis responds to the push (saved as pitchIndex) along with its sign. The only physical requirement is two balloons spaced along the hull.

Roles

Role Boots Purpose
autopilot ap boot → wizard/standby v3 observer autopilot (13 modules in autopilot/)
cockpit cockpit pilot control console (monitor + modem)

Boot chain (autopilot): startup.luaap bootautopilot/main.lua. Menu any time: Ctrl+T, then ap. (stabilizeV2 remains as an alias.)

Ship state lives on the computer only: sides.txt, calib.txt, target.txt, settings.txt, engaged.txt. Reset it via menu pR, or when re-running the installer.

Surviving chunk unload / reload

When you fly away and the ship's chunk unloads, the CC computer powers off and its redstone outputs reset to 0 — so on its own the ship would drop the moment you return. The autopilot handles this:

  • While flying it keeps an engaged.txt flag. On boot (startup.lua runs automatically when the chunk reloads) it drives the hover baseline immediately, then re-enters the flight loop on its own — no manual ENGAGE, holding the same target it had.
  • A pilot STOP clears the flag, so a ship you deliberately stopped stays stopped across reloads. HOLD/LAND keep flying, so they resume.

There is still an unavoidable ~12 s gap while the computer boots; on this slow ship that is harmless. If the computer comes back off after a reload (some server setups), right-click it once — CC then runs startup.lua and the auto-resume takes over.

Updating the code

The repo is the source of truth for the installer. After editing the Lua:

./build.sh                # regenerate manifests
git commit -am "sync autopilot"
git push

Then re-run the wget run command in-game to pull the update.

Syncing with the singleplayer dev world (optional):

./build.sh --from-world   # world -> files/  (code only; state/legacy filtered)
./build.sh --to-world     # files/ -> world  (code only; never touches state)

Default world path is the "Modda wii" save; pass a different computercraft/computer path as arg 2 if the world moves.

Notes

Design history, hardware facts, tuning lessons and the recommended control strategy are in AIRSHIP_AUTOPILOT_NOTES.md (in the modpack profile). The control loop never fully converged; pitch oscillation under climb is the open problem. Keep the altitude cascade simple and make pitch a slow trim.

Description
CC:Tweaked airship autopilot + wget installer
Readme 242 KiB
Languages
Lua 97.3%
Shell 2.7%