Repository navigation
feat: weather instruments, avionics controller, transponder and Radar Mk.1 - #35
Merged
Merged
Conversation
…ter, barometer, rain gauge and almanac
…s and dial rendering Thermometer, hygrometer, barometer, rain gauge and almanac blocks in their own creative tab. Readings come from Thermoo (temperature, humidity), Sable's dimension physics (pressure) and Serene Seasons (calendar), each with a vanilla fallback, taken at the block's world position so instruments on airships read the outside air. The almanac switches to a moon dial where there is no season calendar. Full support shape so wired modems mount on any side.
The controller's facing marks the ship's nose. Every couple of seconds it scans its Sable sub-level for peripherals and builds the channels a gauge can show from the sensors that are actually mounted: altitude and vertical speed, pitch and roll, heading, airspeed per axis, and the weather instruments. Channels read live from the sensors' own peripherals, so they agree with what those sensors report to a computer.
The controller is a ComputerCraft wired-network block. A computer cabled to it sees every peripheral on the ship under its own type and API, named type_N by position on the ship. Controllers on one ship join one network: the lowest publishes, the rest stand by and take over with the same names if it is destroyed. Peripheral objects are reused across rescans so computers don't see detach/attach churn.
… names CC drops a withdrawn peripheral name from the whole network, whichever node published it, so a controller stepping down could wipe the new leader's names. The leader now makes its peers stand down before it publishes. Bridged names get a ship_ prefix so they can't collide with CC's own names for modem-shared peripherals, stay with their block for as long as it is on the ship (saved with the controller, mirrored by standby controllers), and velocity sensors are named by role: ship_velocity_sensor_forward, _vertical, _lateral. Computers and turtles are no longer bridged.
The ship's bow is ship state, not a property of whichever controller leads: the first controller placed sets it, later ones adopt the newest bow any controller knows, and a wrench moves it on purpose. An arrow on top of every controller points at the bow, and whoever placed it is told whether it set the bow or followed it. Names are always numbered. Directional peripherals carry their role relative to the bow: velocity sensors by axis (forward/vertical/lateral), laser and optical sensors and docking connectors by side (fore/aft/port/starboard/up/down). Blocks tagged create_avionics:named_by_position (propellers, engines, burners) are named by where they sit (e.g. ship_propeller_bearing_aft_port_0) and keep that name when the ship grows. Blocks tagged create_avionics:not_bridged (shafts, cogwheels, gearboxes, belts...) are left off the network. A controller that becomes leader without names adopts the ship's existing ones instead of renumbering, and standby controllers save the names they mirror.
The avionics controller is now the ship's transponder: switch it with a wrench on its top or from a computer (avionics_controller peripheral: isTransponderOn, setTransponder). It is ship-wide, like the bow. Redrawn as a full andesite casing with Create's own redstone-link antenna, lit while transmitting, a raised brass arrow at the bow and a readout window. Radar Mk.1 casts one narrow beam straight out of its face twice a second and reports the first thing it meets (ship, terrain, or its own ship blocking it), the distance, the closing speed, and the ship's name if its transponder is on. An andesite casing with a dish sunk half a block into its face and a brass feed inside. On a ship it is named by direction, e.g. ship_radar_fore_0. All art is at Create's own resolution: one texture pixel per sixteenth of a block.
The ship scan only asked for the NeoForge peripheral capability, so blocks CC serves through its own generic lookup (chests, tanks, clutches, gearshifts) were never bridged. Fall back to Peripherals.getGenericPeripheral. Since the controller has a peripheral of its own (the transponder switch), the bridge was also publishing the controllers, so the names a computer saw depended on which controller led. Controllers are already on the network they publish to, and the transponder is ship-wide, so leave them out.
Names by position (propellers, burners, engines) stayed put when the bow moved, so a bearing named aft_port could sit fore-starboard. They still stay put when the hull grows, but are zoned again when the bow changes, like the other ship-relative names already were. The bow they were given under is saved as NamedFor and travels with the names between controllers; names saved before this are adopted under the current bow.
Instruments are shapeless on andesite casing, like Create's own gauges. The controller takes brass casing, a precision mechanism, an electron tube and a wired modem; the radar is a copper dish over a brass and electron tube feed on andesite casing. Each unlocks in the recipe book with its casing (the radar with an electron tube).
The bridge has no Lua methods of its own, so its rules (what is bridged, names, the bow, several controllers, transponder) had nowhere to live. Also list the new blocks and optional dependencies in the README and index, and bring CODEMAP's content packages up to date.
Leaving controllers out of the bridge also hid the transponder switch from every computer on the ship: a controller's own peripheral is only reachable through a modem attached to it. The publishing controller now adds its own peripheral under a fixed name, so computers see one switch whichever controller leads.
The radar never told its neighbours its signal had changed, so a comparator kept the value it read when placed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Avionics' first blocks of its own.
ship_<type>_<n>names. The names are sticky, named relative to a ship-wide bow, and zoned by position for propellers, burners and engines. Several controllers share one set of names, with handover when the publishing one is destroyed. Generic CC peripherals (chests, clutches) are bridged; computers, modems and transmission blocks (thenot_bridgedtag) are not.setTransponder, ship-wide; the controller is bridged once asship_avionics_controller.Also merges
main(#31, #32, #34). The mod now has to be installed on clients as well (#1).Tested headless on a NeoForge server: the ship-bridge cases (names, roles, the bow and its re-zoning, standby and handover, restarts, hull growth, wrench, generic peripherals) and the radar and transponder cases all pass.