[faceofcat]

Machines can expose independently coloured item inventories, fluid tanks and energy buffers in one right-hand configuration drawer. Selecting a colour above the player inventory opens that group; a vertical selector stays inside the drawer. Information stays on the left, both drawers align at the top, and the main inventory panel remains centred. Six flat, grey-bordered side panels show small, faded neighbour models and cycle only the operations supported by the selected inventory. Input/output badges occupy separate right-hand corners, and tooltips show side, neighbour and mode on separate lines.

Each inventory has four capability-validated addon slots with conditional filter attachments. Transfer roles are unique per inventory across item IDs and tiers; bidirectional inventories may have one input and one output addon. Legacy duplicate installations recover the extra addon and its filter. Removing an addon returns its configured filter to the player or drops it when full, including in creative mode. Filters supply composed editors or registered custom controls inside the drawer. The drawer fits its content, expands downward for the editor and scrolls within the screen bounds. Info drawers remain capped at the main panel height. Filter edits use server-checked sessions, attachment generations and configuration revisions.

Concrete pullers/pushers, fluid pumps, energy relays, four example filters, a seven-group workbench and the Recovery Capsule belong to the optional companion mod. The library provides the interfaces, data and shared runtime/UI infrastructure. Item and fluid transfers pay RF for actual delivery; energy relays have no auxiliary fee so they can bootstrap an empty buffer.

Pending transfers retain ownership across save/reload and neighbour removal. Inbound resources finish delivery without consulting their old source, and outbound resources can use another enabled output face. Refunds that cannot fit remain persisted until space is available. Breaking a companion machine drops installed addons, configured filters, pending recovery items and item transfer remainders exactly once. Pending fluid, energy and refunds drop in a Recovery Capsule: use it on a compatible companion machine to restore what fits, leaving the remainder in the capsule. Unknown resource payloads are preserved. Ordinary tank/buffer contents retain the host's existing break policy. Library hosts must provide a recovery callback to the break hook; a failed handoff leaves pending data intact.

Neighbour capabilities use invalidation-aware caches, addon validation scans dirty groups, menu snapshots use revision counters, and resource membership uses indexed lookups. Filter hover checks examine only the selected inventory's four filter slots. Shared AutomationLayout geometry supplies rendering, real slot placement and hit bounds. Base machine slot counts now bound destination routing and reservation snapshots, and null-side energy access preserves the buffer's normal operations.

Companion mod — concrete content and machine setup

• Six functional addons: item puller/pusher, fluid input/output pumps, energy import/export relays.
• Four filter items: basic item filter (8 entries), expanded item filter (36), tag filter and fluid filter.
• Each addon's transfer rate, interval, energy cost and supported inventory types.
• Filter matching rules, whitelist/blacklist behaviour and an example custom filter control.
• Recovery Capsule item for restoring pending fluids, energy and refunds after breaking a machine.
• Logistics Workbench demonstrating seven independent inventories.
• Machine-specific inventory definitions, colours, capability connections and break/drop hooks.
• Companion screen layouts, including the shared control row and centred Dual Crusher lanes.
• Item/block registrations, models, translations and gameplay/client integration tests.

Shared library — reusable APIs, behaviour and UI

• Resource groups and extensible resource types, with per-inventory side configuration.
• Addon/filter capability interfaces and compatibility rules.
• Four addon slots per inventory, conditional filter attachments, duplicate-role prevention and filter recovery.
• Transfer scheduler and item/fluid/energy transports, including energy accounting, persistent pending transfers, rerouting and lossless refunds.
• Generic break-recovery data and callback API; the library registers no Recovery Capsule item.
• Reusable InventoryColorButtonBar, automatic UI ordering, overflow scrolling and consistent drawer/keyboard navigation.
• Shared inventory-control row layout and <inventory-controls> XML support.
• Configuration drawer, neighbour previews, side-mode toggles, tooltips and screen-constrained sizing.
• Item-provided filter UI framework: layouts, ghost grids, toggles, text/numeric inputs and custom controls.
• Ghost-item transparency, correctly sized filter-slot highlights and shared UI sprites.
• Menu/network synchronisation, server-side validation and protection against stale filter edits.
• Capability caching, revision-based updates, indexed inventory lookup and JEI drawer exclusions.
• Public integration documentation and reusable-component tests.

Validation: check build passed with 123 JUnit tests, 67 library game tests and 36 companion game tests. Companion client smoke tests passed with and without JEI; screenshots were inspected for drawer alignment, colour selectors, neighbour previews and filter layout. The latest companion client smoke also verifies the shared toolbar, screen-ordered colour selection, centred lane display and compact filter-slot highlight. Unit coverage includes colour-bar ordering, overflow and resizing. Existing smoke checks cover fixed centring, content-driven sizing, internal scrolling, resize clamping and custom filter controls. Earlier library client smoke runs also passed with and without JEI.

Server regression coverage includes all six transfer addons and four filters, duplicate-role validation and recovery, exact break drops, source removal, destination rerouting, save/reload, clipped refunds, full/partial capsule restoration, unknown recovery payloads, failed handoffs, cache invalidation/replacement, dirty validation, unsided energy access and base-slot reservation bounds.

[dshadowwolf]

Overall the design is right -- transfers are paid for with energy, extracted resources stay owned by the machine until delivered, starting points rotate so no slot is starved, and addon roles are enforced as unique.

Spotted during review:

1. Escrowed items can get stuck for good -- breaking a neighbor on a side with escrowed items looks like it will cause a loss of the escrowed items
2. Breaking the machine destroys escrowed fluid and energy

• The energy refund can be clipped

3. A null-side energy query now refuses extraction
4. Two checks still use the old slot count
5. The performance issues add up for big logistics setups

• neighbour capability lookups every tick with no cache
• full revalidation and a large change-check string built every tick
• a hover check that scales badly with many automation slots
• a stream pipeline on every slot access from pipes

6. Layout numbers are hard-coded