🚧 Work in progress — not yet a playable release. Although it is almost completely ready for a release!
A player-driven economy mod for Create-based Minecraft servers. The goal is to connect factories, trade resources, and cooperate through a shared order network that lets players request materials and fulfil industrial needs.
- Minecraft 1.21.1
- NeoForge 21.1.251
- Java 21
- License: MIT (see LICENSE)
This repository is beyond the initial scaffold: persistent orders, server-authoritative order actions, the Order Terminal screen, idempotent economy handling, a durable shipment journal, and several Create logistics adapters are implemented. It is not yet a playable/release-verified build. The remaining work is primarily end-to-end recovery coverage, live-world compatibility checks, live-world Stock Link isolation checks, belt delivery, and finishing chunk-loading safety controls.
The repository includes a GitHub Actions Java/Gradle build workflow and JUnit 5 regression tests for delivery-receipt transaction matching/finalization and bounded route-specific receipt validation, rejection of incomplete zero-count receipts, request validation, adapter registration/route-resolution failures, and rejection of economy providers whose metadata initialization throws. Optional economy providers are isolated: runtime/API-linkage failures fail closed instead of crashing gameplay or silently switching to the internal currency ledger. GitHub Actions runs on pushes; check the linked Actions history for the latest result. Rapid successive commits can cancel earlier runs, so a successful completed run is required before treating the suite as verified. Factory-source restart recovery now rechecks that the destination/source Terminal Logger is still owned by the original shipment claimant and still accepts the ordered item before topping up partially collected cargo; regression tests cover owner mismatch, null claimant, and filter rejection. This prevents recovery from moving newly sourced stock through a logger that has been rebound or reconfigured after the shipment was reserved. Factory stock discovery now isolates runtime and missing-linkage failures from individual endpoints so one broken optional factory cannot abort sourcing from healthy factories. Manual handoff payouts now use the delivery transaction ID for idempotent economy credits. Cancellation refunds use a separate purpose-scoped idempotency key, preventing duplicate escrow refunds if the economy save lands before the cancelled order state. Pending automated deliveries reserve order quantity until progress is applied, and the persistent reservation boundary independently verifies the claimant, order state, and remaining unreserved count before accepting a reservation. Server-stop lifecycle handling clears transient endpoint/adapter registries and Redstone Requester edge latches, preventing stale in-memory registrations from leaking across server restarts. The backend includes persistent orders, server-side order validation, the shared delivery-service boundary, and a bridge from Create's built-in Redstone Requester to adjacent configured Order Terminals.
When activated, a valid Redstone Requester can publish zero-reward restock orders to the order board. Duplicate active orders for the same owner and item are suppressed. This bridge still requires live-world verification against the pinned Create version; CI success confirms compilation, not that redstone event timing and block interactions work in-game.
A Create 6.0.x / Minecraft 1.21.1 train adapter is now implemented around Portable Storage Interfaces and Terminal Logger endpoints. It tags one or more cargo stacks with a shared transaction UUID, reserves quantities across the Terminal Logger buffer, dispatches through the active source PSI, verifies the full marked stack at the claimant-owned destination logger, and finalizes order progress/reward only after the receipt is verified. Reserved cargo can be resumed after restart, and a destination receipt can reconcile the narrow crash window before the dispatch milestone is saved. The adapter is code/CI-tested but still requires live-world testing with moving trains and real PSI handoffs. The Aeronautics Docking Connector adapter checks the optional stack's registry detection and requires server-side item-handler capabilities at both source and destination connectors, with transaction-marked multi-stack cargo and a verified destination logger receipt. This capability bridge is still provisional: it has not been validated against a real Aeronautics installation or confirmed to represent cargo actually carried by a moving airship. The Packager-mediated Frogport adapter is implemented in code but still needs live-world verification; belt automated delivery remains unimplemented and unsupported routes fail closed.
The planned Create-facing integrations are split by Create's Display Link and Stock Link systems. The Order Terminal represents the factory-wide view; each Terminal Logger represents one physical routing point. A factory can have multiple loggers, so logger displays must be local to the selected block rather than aggregated as if they were the whole factory.
| Create integration | iCreate block | Intended role | Status |
|---|---|---|---|
| Display Link | Network Statistics | Show network statistics, such as item input/output and rejected transfers | A Display Link source class exists; registration and live-world behavior still need verification |
| Display Link | Order Terminal | Show factory order information, such as active order counts and outstanding item quantity | Source implemented, registered, and covered by summary tests; live-world verification remains |
| Display Link | Terminal Logger | Show this logger's own routing configuration, filter, buffer/transfer state, and diagnostic status where available | Source implemented and registered; live-world verification remains |
| Stock Link | Order Terminal | Expose factory stock/request information to Create's stock network, with clear rules for what counts as available stock | Explicit Stock Link-to-factory bindings and owner/team authorization are implemented; live shared-frequency isolation still requires dedicated-server testing |
The Terminal Logger now has a local-state Display Link source showing owner short ID, output face, buffered item/slot counts, accepted/rejected transfer counters, filter, and last status. It is registered against the Terminal Logger block entity. This is a per-logger diagnostic display, not a factory-wide order display. The Terminal Logger is not currently planned as a Stock Link source: its local buffer and routing role do not necessarily represent the factory's overall stock. Multiple loggers may observe different parts of the same flow, so summing their inventories could double-count items. Any future stock integration would need explicit accounting rules to avoid that.
These integrations are distinct from crafting recipes and block models. Do not assume that a block supports Display or Stock just because its recipe exists. Each integration must use the pinned Create 6.x API, register safely, handle missing/unconfigured data, and be tested in a live Minecraft world. Create is an optional dependency, so Create-specific classes must remain isolated behind the mod's compatibility boundary.
The required delivery routes are manual handoff, Create trains, Aeronautics airships, Create Frogports, and Create belts. Train adapters are designed around Portable Storage Interfaces; airship adapters around Docking Connectors. Frogports are base Create package logistics, not an Aeronautics feature.
The six-way Terminal Logger is the local belt/funnel handoff point, with one configurable output face and five remaining faces for routing. Empty-hand right-click cycles the output face; sneak + empty-hand click on a non-output face toggles that input face, and the output face is always output-only. The Brass variant keeps its filter-clear shortcut by clearing the filter when sneak-clicking its output face. The standalone TerminalLoggerConfig routing-policy helper restores the former output as an input while preserving other explicitly disabled inputs; regression tests cover the helper's routing invariant and config serialization. This is a compact interaction control, not yet a full configuration GUI. The Andesite Terminal Logger is the cheap early-game version and uses an Andesite Funnel (not an Andesite Alloy substitute). The Brass Terminal Logger uses Brass Funnels and Create Filters for a more expensive filtered version.
Automated route support is adapter-specific. Train/PSI, Aeronautics docking, and Packager/Frogport adapter implementations exist, but only compilation and unit tests are automated; they still require dedicated-server validation. Belt delivery remains unavailable until it can reserve cargo and verify a destination receipt. Unsupported routes fail closed rather than consuming items on an unverified event.
The backend includes persistent orders and delivery receipts, server-authoritative create/claim/fulfil/cancel actions, idempotent payout/refund accounting, pending-delivery quantity reservations, manual inventory fulfilment, a Create Redstone Requester restock-order bridge, and a durable shipment journal with RESERVED → DISPATCHED → DESTINATION_RECEIVED → COMPLETED milestones. Train/PSI, Aeronautics docking, and Packager/Frogport adapter implementations are present. The Order Terminal screen is wired to server-authoritative actions. A Terminal Logger chunk-loading implementation is also present, but requires live-world lifecycle/resource testing before broad use.
Still outstanding before calling the backend complete: get the full Gradle CI suite green on the latest branch head; dedicated-server tests for train/PSI, Frogport, Redstone Requester, interrupted dispatch, receipt verification, payout retry, and restart recovery; shared-frequency isolation between factory Stock Links; belt delivery; and safe chunk-loading limits/ownership/toggle controls. The Aeronautics Docking Connector capability bridge is provisional and needs validation against the actual Aeronautics API and live-world transport. A passing CI build verifies compilation/tests, not in-game behavior. Display Link sources are implemented but still need live-world verification.
The current planning estimate is about 65% for the whole mod and about 85–90% for backend implementation, assuming the current model/recipe work is substantially complete. These are estimates, not test results. The backend is not complete until the latest CI run passes and the dedicated-server lifecycle/transport checks above are completed. See the backend progress snapshot and the completion gate for the explicit remaining checklist.
The Order Terminal Display Link reports active orders and outstanding item quantity for the factory owner's orders. It is registered alongside the Terminal Logger and Network Statistics Display Links. Create Frogport compatibility detection now requires Create's item, block, and block-entity type registry entries to be present; this is deliberately only a prerequisite check, not a working Frogport shipment adapter.
The Order Terminal Display Link has regression tests for active-order counting, outstanding quantities, owner scoping, and unclaimed terminals.
Build the optional server-only Mythic integration with gradle --no-daemon -Pis_Mythic_version=true build; the default false build excludes the Mythic integration package. The selected value is recorded in the JAR manifest as Is-Mythic-Version.
The Mythic dedicated server can post server lifecycle and player join/leave events to a Discord webhook. Missile launch, impact, and interception event hooks are included for the missile subsystem to call when those systems are connected. Server-side configuration and FTB team display-name mappings are documented in docs/MYTHIC_DISCORD_INTEGRATION.md.
The current bridge uses a server-only Discord webhook and local FTB team mapping; it does not yet connect the bot's /mc-link or team-sync approval queue, which needs a matching authenticated API in the bot process.
The Mythic bot API bridge and Discord webhook bridge now insert an actual zero-width space to neutralize @everyone and @here, normalize carriage returns, and preserve their message-length limits. Regression tests cover both sanitizers. The regular build excludes Mythic-only tests when the optional Mythic variant is disabled. This is a source-level regression fix; the latest GitHub Actions result must pass before treating it as build-verified.