Add item duct transport system

[DeadmanLabs]

Note: This is a DRAFT. I am looking for feedback from the CoFH team with regards to code cleanliness, efficiency, commenting and logging, etc.

Implements a complete item transport network with:

• Basic item ducts with windowed/opaque variants
• Dense ducts (lower routing priority, overflow handling)
• Vacuum ducts (higher routing priority, pulls items)
• Impulse ducts (faster item travel speed)
• Signalum variants for all duct types
• Item servo attachment for extraction with configurable amount
• Item turbo servo attachment (faster extraction, up to 64 items)
• Item filter attachment for controlling item flow
• Visual item rendering traveling through ducts
• Smart routing with pathfinding and backflow prevention
• Overflow storage when destinations are full

Base class changes (minimal):

• Grid.java: Added topologyVersion for cache invalidation
• DuctBlock.java: Added attachment installation fallback
• AttachmentRegistry.java: Added ITEM_GRID cases

No changes to energy/fluid duct functionality.

🤖 Generated with Claude Code

[Terminal-Access]

Just a heads up, this Draft dosent include any crafting recipies that i could find when teating. thus you can only grab the ducts from creative, effectivly making them unobtainable in survival mode.

[Xefyr0]

Hello, modpack dev here. This would be a very helpful addition to one of the packs I'm working on, so I've got an interest in pushing this forward as much as I can. I'm not a Java dev so I can't help in terms of code quality, but I've confidence in my ability to tear things apart with manual testing so I did just that.

What Works

• Basic item transfer
• Cross-chunk item transfer
• Itemducts appear to transfer items normally in unloaded chunks
• Wrench connecting & disconnecting Itemducts
• Transfer rate increment & decrement
• Wrench picking up pipes & attachments with Shift+right-click
• Deny/Allow list filtering on Servos and Filter attachments
• NBT filtering
• Filling filters using "ghost" items from EMI/JEI
• Redstone control over Servos
• Shorter distances (endpoints closer to the start) are prioritized
• Dense & Vacuum Itemducts have lower & higher priority than regular Itemducts, respectively
• Items don't render on paths entirely consisting of opaque pipes
• Items don't transfer if no valid destination is available
• Items that lose access to their destination while in-transit will re-route back to the source
• Items that lose access to both their destination and source while in-transit will exit the pipe and become an item entity

Issues

Item Renders.
This one's a whole nest of issues.
Sometimes the item render in pipes doesn't appear at all, occurring most frequently when the start & end itemducts are both opaque but there are transparent ducts between.
I've seen a pickaxe float outside an Itemduct into a block that was NOT its destination before teleporting to the correct destination.

Connecting, disconnecting, breaking, or placing pipes while items are in-transit can lead to items halting their motion.

Breaking the pipe they're in either voids the item, causes the item to re-route to a "valid" destination, or does not affect the item at all, leading to an item floating midair.

Renders of items in-transit have also stopped working entirely after some time in my test world.

Impulse and Signalum Itemducts are not available.
Exactly as written. Despite Impulse and Signalum itemducts being included in the PR comment above & the assets included in the diff, Impulse and Signalum Itemducts aren't in any creative menu, /give command autocomplete, or recipe viewer like EMI or JEI.

This means that I was unable to test their functionality, so they, too, may have issues not covered in this report.

Attachments applying to the wrong part of the pipe.
When applying a Servo or Filter to the side of an Itemduct attached to an inventory, the attachment will only apply to the correct side if the Itemduct is the most recently placed Block. Otherwise, the Servo will apply to the bottom face of the Itemduct.

Filters still apply when they should be disabled by Redstone
When a filter is disabled via redstone control, the attachment correctly renders the "disabled" texture but the filter still acts upon how items are routed. For example, if I had a filter that had a Deny list with Spruce Logs attached to a Barrel that would otherwise be the highest priority destination on the network, then Spruce Logs would avoid that destination even when the filter is disabled via Redstone.

Servos can send mixed stacks.
Unsure if this is actually an issue, but it results in weird transfer visuals and IIRC it's different from old Thermal Dynamics behavior so I'm writing it here anyways.

If you e.g. have 2 Acacia Logs and 2 Spruce logs in a Chest and your Servo is set to transfer 4 items the next time it acts, it will transfer all 4 items in one 'stack', causing the items' visuals to overlap in transparent itemducts until one item type is filtered away from the other.

Itemducts are incompatible with Auto-Output capability of Thermal Expansion machines
If a Thermal Expansion machine (in my case, an Electric Furnace) has the output facing an Itemduct and Auto-Output is enabled, no items are transferred.

Missing Lang keys
The buttons to increment and decrement the stack size for Servos transferring items don't have lang keys on my end.

Itemducts cannot disambiguate destination using Furnace sidedness
If you have a setup like the one pictured below with both Sand and Coal in the chest, then the Coal will transfer to the Furnace just fine through the bottom face but the Sand will not. Only after disconnecting the ducts to the bottom and side of the Furnace will Sand enter the top face of the Furnace.

I assume this may be because the item routing procedure selects the top priority destination before considering whether the face would allow that item, and halts item transfer if that isn't the case rather than attempting lower-priority destinations.

Bugged row of GUI slots in Servo and Turbo Servo GUIs
In the Servo and Turbo Servo GUIs, there is a bugged 3x3 grid of extra slots that sits between the rows of the player inventory on the center 3 columns.

Missing Texture inside ends of Itemducts
On the ends of Itemducts that don't have any attachment, there is a white square which I assume to be a missing texture. There is a similarly nondescript blank square on the ends of Itemducts that do have attachments, but it's a dark grey so it's less clear if that's intended.

Servos do not always react to GUI changes for redstone control
If you place a servo on an itemduct that has redstone power and then select the "Signal Required - Low" control option in the GUI, the servo will disable itself but will keep the Enabled texture until updated through some other means, such as accessing the attached inventory or changing the redstone signal.

Itemducts not craftable
As Terminal-Access said, Itemducts have no recipe and are thus unobtainable in survival.

Thoughts

It's not possible to put filters or servos in-line on Itemducts (i.e. not attached to a storage) IIRC this was possible in older versions of Thermal Dynamics - need input on whether or not this is acceptable & intended.

When an item has multiple destinations of equal priority, one destination is selected through some unknown means and is used for every transfer thereafter. It's unclear to me how this destination is selected but IMO it'd be better for the player experience if, given the choice between multiple destinations of equal priority, items selected their destination randomly each time or followed a round-robin distribution.

Servo & Turbo Servo speeds are quite slow - 10s per action for regular Servos and 5s per action for Turbo Servos. In my opinion, it would be nice if they would act twice as fast and had a config option or NBT-specified speed like Integral Components' base mod.

The UI to change the quantity of items moved by Servos in each action is a bit clunky. It defaults to the minimum transfer rate and you can only increment/decrement 1 at a time. I don't want to have to click 63 times to max out my turbo servo transfer rate. I should be able to shift-click to increment/decrement 8 at a time, and Servos should default to the maximum transfer rate from the start.

I don't have very much understanding of how the chunk loading system works, so I was unable to test how Itemducts act when parts of the network are unloaded.

As I mention in the "What Works" section, itemducts appear to transfer items normally even when in unloaded chunks. I don't know how this is accomplished, (assuming this is not the result of an error on my part) but I believe it's worth manually looking into the code to confirm that it works as intended.

World Download & Instance information

Minecraft 1.20.1
Forge 47.4.12
CoFH Core 11.0.2
EMI 1.1.22+1.20.1+forge
JEI 15.20.0.27
Thermal Foundation 11.0.6
Thermal Dynamics built from source using the branch in this PR
Thermal Expansion 11.0.1

Test World download:
Test World.zip

[DeadmanLabs]

Hello, modpack dev here. This would be a very helpful addition to one of the packs I'm working on, so I've got an interest in pushing this forward as much as I can. I'm not a Java dev so I can't help in terms of code quality, but I've confidence in my ability to tear things apart in playtesting so I did just that.

What Works

• Basic item transfer

• Cross-chunk item transfer

• Itemducts appear to transfer items normally in unloaded chunks

• Wrench connecting & disconnecting Itemducts

• Wrench picking up pipes & attachments with Shift+right-click

• Deny/Allow list filtering on Servos and Filter attachments

• NBT filtering

• Redstone control over Servos

• Shorter distances (endpoints closer to the start) are prioritized

• Dense & Vacuum Itemducts have lower & higher priority than regular Itemducts, respectively

• Items don't render on paths entirely consisting of opaque pipes

• Items don't transfer if no valid destination is available

• Items that lose access to their destination while in-transit will re-route back to the source

• Items that lose access to both their destination and source while in-transit will exit the pipe and become an item entity

Issues

Item Renders.

This one's a whole nest of issues.

Sometimes the item render in pipes doesn't appear at all, occurring most frequently when the start & end itemducts are both opaque but there are transparent ducts between.

I've seen a pickaxe float outside an Itemduct into a block that was NOT its destination before teleporting to the correct destination.

Connecting, disconnecting, breaking, or placing pipes while items are in-transit can lead to items halting their motion.

Breaking the pipe they're in either voids the item, causes the item to re-route to a "valid" destination, or does not affect the item at all, leading to an item floating midair.

Renders of items in-transit have also stopped working entirely after some time in my test world.

Attachments applying to the wrong part of the pipe.

When applying a Servo or Filter to the side of an Itemduct attached to an inventory, the attachment will only apply to the correct side if the Itemduct is the most recently placed Block. Otherwise, the Servo will apply to the bottom face of the Itemduct.

Filters still apply when they should be disabled by Redstone

When a filter is disabled via redstone control, the attachment correctly renders the "disabled" texture but the filter still acts upon how items are routed. For example, if I had a filter that had a Deny list with Spruce Logs attached to a Barrel that would otherwise be the highest priority destination on the network, then Spruce Logs would avoid that destination even when the filter is disabled via Redstone.

Servos can send mixed stacks.

Unsure if this is actually an issue, but it results in weird transfer visuals and IIRC it's different from old Thermal Dynamics behavior so I'm writing it here anyways.

If you e.g. have 2 Acacia Logs and 2 Spruce logs in a Chest and your Servo is set to transfer 4 items the next time it acts, it will transfer all 4 items in one 'stack', causing the items' visuals to overlap in transparent itemducts until one item type is filtered away from the other.

Itemducts are incompatible with Auto-Output capability of Thermal Expansion machines

If a Thermal Expansion machine (in my case, an Electric Furnace) has the output facing an Itemduct and Auto-Output is enabled, no items are transferred.

Missing Lang keys

The buttons to increment and decrement the stack size for Servos transferring items don't have lang keys on my end.

Itemducts cannot disambiguate destination using Furnace sidedness

If you have a setup like the one pictured below with both Sand and Coal in the chest, then the Coal will transfer to the Furnace just fine through the bottom face but the Sand will not. Only after disconnecting the ducts to the bottom and side of the Furnace will Sand enter the top face of the Furnace.

I assume this may be because the item routing procedure selects the top priority destination before considering whether the face would allow that item, and halts item transfer if that isn't the case rather than attempting lower-priority destinations.

Bugged row of GUI slots in Servo and Turbo Servo GUIs

In the Servo and Turbo Servo GUIs, there is a bugged 3x3 grid of extra slots that sits between the rows of the player inventory on the center 3 columns.

Missing Texture inside ends of Itemducts

On the ends of Itemducts that don't have any attachment, there is a white square which I assume to be a missing texture. There is a similarly nondescript blank square on the ends of Itemducts that do have attachments, but it's a dark grey so it's less clear if that's intended.

Servos do not always react to GUI changes for redstone control

If you place a servo on an itemduct that has redstone power and then select the "Signal Required - Low" control option in the GUI, the servo will disable itself but will keep the Enabled texture until updated through some other means, such as accessing the attached inventory or changing the redstone signal.

Thoughts

It's not possible to put filters or servos in-line on Itemducts (i.e. not attached to a storage) IIRC this was possible in older versions of Thermal Dynamics - need input on whether or not this is acceptable & intended.

When an item has multiple destinations of equal priority, one destination is selected through some unknown means and is used for every transfer thereafter. It's unclear to me how this destination is selected but IMO it'd be better for the player experience if, given the choice between multiple destinations of equal priority, items selected their destination randomly each time or followed a round-robin distribution.

I don't have very much understanding of how the chunk loading system works, so I was unable to test how Itemducts act when parts of the network are unloaded.

As I mention in the "What Works" section, itemducts appear to transfer items normally even when in unloaded chunks. I don't know how this is accomplished, (assuming this is not the result of an error on my part) but I believe it's worth manually looking into the code to confirm that it works as intended.

World Download & Instance information

Minecraft 1.20.1

Forge 47.4.12

CoFH Core 11.0.2

EMI 1.1.22+1.20.1+forge

JEI 15.20.0.27

Thermal Foundation 11.0.6

Thermal Dynamics built from source using the branch in this PR

Thermal Expansion 11.0.1

Test World download:

Test World.zip

Exactly what I was looking for. Ill work on all of these as soon as I can