promotional bannermobile promotional banner

Create: Avionics — ComputerCraft for Aeronautics

ComputerCraft peripherals for Create: Simulated and Create: Aeronautics
Back to Files

Create: Avionics 0.7.0

File namecreate_avionics-neoforge-1.21.1-0.7.0.jar
Uploader
SolAstriusSolAstrius
Uploaded
Oct 27, 2026
Downloads
73
Size
293.1 KB
Mod Loaders
NeoForge
File ID
9347804
Type
A
Alpha
Supported game versions
  • 1.21.1

Curse Maven Snippet

NeoForge

implementation "curse.maven:create-avionics-1539942:9347804"

Learn more about Curse Maven

What's new

Added

  • navigation_table: getMaxRange. The range at which the held item's signal cuts off, which reads exactly like being parked on the target — so a program steering on bearing alone could chase a dead needle. Upstream spells "no limit" as zero, which is not comparable against a distance; this reports math.huge for that case. Both the compass and the map are unlimited while everything else takes the 200-block default, so neither constant was safe to hardcode.

  • navigation_table: getBearingRate / getBearingRateRad. How fast the needle is swinging, in degrees (or radians) per second. This is the intercept signal — with the target ahead and closing, a bearing rate near zero means the current course arrives at it, and a steady non-zero rate means it misses by a margin that only grows as range falls. Upstream never computes it, so programs differenced getBearing() in Lua and had to handle the ±180 seam themselves, where a needle sweeping past dead astern reads as a full turn the other way. Sampled once per server tick — the cadence at which the table recomputes the angle, not the 11-tick distance cycle — and suppressed for one tick after a waypoint swap, since re-aiming the needle is not motion of the vehicle.

  • navigation_table: getTargetName and getTargetDisplayName. Every nav item that carries a per-item destination was anonymous to a program: a lodestone-bound compass reported only a tracker UUID, a marked map only a numeric id, and the Explorer's/Nature's Compass targets nothing at all. A display could say where it was heading but never what the waypoint was called. getTargetName returns the anvil-given name of the held item — the label a player actually chose — and is nil for an unnamed item; getTargetDisplayName falls back to the item's own name so a readout always has something to print ([#28]).

  • Weather instruments: thermometer, hygrometer, barometer, rain gauge and almanac. Avionics' first blocks of its own. Each reads one quantity in fixed units (C, rh, hPa, mm/h, and year or moon), sampled once a second and cached, so polling is cheap. Readings are taken at the block's position in the world, projected out of any Sable sub-level, so an instrument on an airship reads the air it is flying through rather than the air of the plot its blocks are stored in. Temperature and humidity come from Thermoo's environment when it is installed, which picks up every climate mod that plugs into Thermoo; pressure comes from Sable's dimension physics, the same curve airship buoyancy uses, lowered by rain and thunder; the almanac follows Serene Seasons in the Overworld and the moon everywhere else. All of them fall back to estimates from vanilla biome data, and read reports which source each value came from. The rain gauge also keeps a running total that empty resets.

  • Avionics controller: one wired connection for a whole ship. Placed on a Sable ship and wired to a computer, it publishes every peripheral on the ship onto that network, as if each had its own modem. Names carry a ship_ prefix so they never collide with modem-shared ones, keep their number while the block stays on the ship, and survive restarts. Peripherals that measure in a direction are named in ship terms (ship_velocity_sensor_forward_0, ship_optical_sensor_down_0, ship_docking_connector_up_0), and propellers, burners and engines by where they sit on the hull (ship_propeller_bearing_aft_port_0), relative to a bow the first controller sets and a wrench moves. Several controllers on one ship share a single set of names, and when the publishing one is destroyed the next takes over without a rename. Computers, modems and pure transmission (the create_avionics:not_bridged tag) are left out; the controllers appear once, as ship_avionics_controller.

  • Transponder. The controller is also the ship's transponder: a wrench on its antenna, or setTransponder from Lua, switches it ship-wide. While it is on, a radar that hits the ship reports its name; while it is off, the ship is an unidentified contact.

  • Radar Mk.1. One narrow beam straight out of its face, cast twice a second to 256 blocks. getContact reports what it meets (ship, terrain, or obstructed by the radar's own ship), the distance, the closing speed and a transponder name; a comparator reads the range from 15 up close to 1 at full range.

  • Recipes for all seven blocks. The instruments are shapeless on andesite casing, like Create's own gauges; the controller is a brass-tier part with a precision mechanism, an electron tube and a wired modem.

  • Guides to [the ship bridge] and [the instruments] on the docs site.

  • A note in chat when a new version arrives. The first time you join a world after installing or updating to a new minor version, your client says once what it brings, with links to the release notes, the guides and the community ([Discord], or [Telegram] for Russian). Patch releases stay quiet; announceUpdates = false in create_avionics-client.toml turns it off.

Changed

  • Avionics now has to be installed on clients as well as the server. It adds blocks, models and textures, so a client without it cannot join a server with it ([#1]).

Fixed

  • ComputerCraft no longer logs "Lua Method … should be final" for the altitude sensor, navigation table, gimbal sensor, velocity sensor, torsion spring, portable engine, physics assembler, steering wheel and analog transmission peripherals. CC warns about every overridable @LuaFunction the first time a computer uses the peripheral; all 62 are now final. No behaviour change.

Docs

  • propeller_bearing.getRotationSpeed and getAngularSpeed said only "the rotation speed" and "the angular speed" ([#29]). Both are degrees per tick, and both report the propeller's actual speed, not the shaft's: it eases towards the input by 0.4 / sqrt(sailPower) of the difference each tick, so bigger propellers spin up and down more slowly. The docs now give the unit, the conversion to RPM, the 76.8 that a fully spun-up propeller reads at Create's default maximum, and what happens unassembled and mid-disassembly. From a computer the two functions always return the same value; the difference upstream is confined to the bearing's own tick and to rendering.
  • getSpeed on kinetic peripherals now states its unit (RPM, signed) and that it is the network's speed, which inertial blocks may lag.
  • gimbal_sensor.getAngles now warns that its two angles break down near vertical, and points to the readings that don't: getGravity for tilt and navigation_table.getOrientation for the full orientation as a quaternion ([#30]).

This mod has no additional files