In Thermal Dynamics r2.3.9 (Minecraft 1.12.2), connected fluxducts of one tier form a grid that keeps its energy in one store; ducts of different tiers neither connect nor merge. The store holds five times the tier's transfer rate for each duct that touches a block. Energy put into any duct goes into that store, at most the transfer rate per insertion and up to the free space. Once a tick, while the store holds energy, each duct beside a block offers the blocks around it the store divided by the number of such ducts, worked out once for the tick (the remainder when that rounds to 0), and no more than the transfer rate; the round stops at a duct whose chunk is unloading. With the default base of 1,000 RF a tick, the five tiers (energyBasic, which the config's comment calls the Leadstone Fluxduct, energyHardened, energyReinforced, energySignalum, energyResonant) move 1,000, 4,000, 9,000, 16,000 and 25,000 RF a tick. The super-conducting duct has a transfer limit of 0, so it can't join these grids, and is excluded. | src/main/java/cofh/thermaldynamics/duct/energy/GridEnergy.java L12–15src/main/java/cofh/thermaldynamics/duct/energy/GridEnergy.java L27–34src/main/java/cofh/thermaldynamics/duct/energy/GridEnergy.java L37–43src/main/java/cofh/thermaldynamics/duct/energy/GridEnergy.java L69–73src/main/java/cofh/thermaldynamics/duct/energy/GridEnergy.java L93–119src/main/java/cofh/thermaldynamics/duct/energy/GridEnergy.java L154–162src/main/java/cofh/thermaldynamics/duct/energy/DuctUnitEnergy.java L34–39src/main/java/cofh/thermaldynamics/duct/energy/DuctUnitEnergy.java L204–217src/main/java/cofh/thermaldynamics/duct/energy/DuctUnitEnergy.java L309–313src/main/java/cofh/thermaldynamics/duct/TDDucts.java L180–185src/main/java/cofh/thermaldynamics/util/WorldGridList.java L59–66 | Code |
| In Thermal Dynamics r2.3.9 (Minecraft 1.12.2), connected fluid ducts form one grid. A grid forms outward from one duct, breadth-first over its connected ducts: a duct with no grid joins, and a duct in another grid merges the two grids, the smaller into the larger, the larger keeping its fluid and taking the other's. A grid holds one fluid: a duct joins, and two grids merge, only when their fluids match or one is empty; otherwise the connection is rejected. When a duct is placed, it compares its neighbours' fluids with one of them, the fluid of the duct the player aimed at or else the first neighbour that has one, and blocks its sides to every neighbouring duct whose fluid differs from that. | src/main/java/cofh/thermaldynamics/multiblock/MultiBlockFormer.java L14–26src/main/java/cofh/thermaldynamics/multiblock/MultiBlockFormer.java L44–61src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L204–225src/main/java/cofh/thermaldynamics/duct/fluid/DuctUnitFluid.java L419–425src/main/java/cofh/thermaldynamics/duct/fluid/DuctUnitFluid.java L427–442 | Code |
| In Thermal Dynamics r2.3.9 a fluid-duct grid stores its fluid in one tank, not in its ducts. The tank holds the grid's duct count times a per-duct volume, which for ordinary fluiducts is 25 times the fluid's throughput, at most 3,000 mB. The throughput is 120,000 divided by the fluid's viscosity (taken as at least 100), clamped to 80-600 mB a tick; steam is set to 600. A fluid of viscosity 1,000 gets 120 mB a tick and 3,000 mB a duct, the tank's defaults. Fluid of the grid's kind put into any open side of any duct goes straight into that tank, up to its free space, with no other limit on the rate. | src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L27src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L80–85src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L135–143src/main/java/cofh/thermaldynamics/duct/fluid/FluidTankGrid.java L10–17src/main/java/cofh/thermaldynamics/duct/fluid/FluidTankGrid.java L53–68src/main/java/cofh/thermaldynamics/duct/fluid/DuctUnitFluid.java L489–494 | Code |
| In Thermal Dynamics r2.3.9 a fluid-duct grid hands out fluid once a tick. If its tank holds fluid, each duct beside a block that takes fluid offers its neighbours, side by side from where it last stopped, up to the tank's amount divided by the grid's duct count (the remainder when that rounds to 0), and no more than the grid's throughput for that tick. That throughput is the fluid's full rate while the tank is at least three-quarters full, half of it at a quarter full or less, and rises in a straight line from half to full in between. Fluid inside a grid doesn't travel from duct to duct: every outlet draws on the one tank. | src/main/java/cofh/thermaldynamics/util/WorldGridList.java L59–66src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L162–176src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L227–243src/main/java/cofh/thermaldynamics/duct/fluid/DuctUnitFluid.java L89–110src/main/java/cofh/thermaldynamics/duct/fluid/DuctUnitFluid.java L164–177src/main/java/cofh/thermaldynamics/duct/tiles/DuctUnit.java L157–162src/main/java/cofh/thermaldynamics/duct/tiles/DuctUnit.java L269–272 | Code |
| In Thermal Dynamics r2.3.9, removing a duct that had two or more connected ducts queues its grid to be rebuilt; a duct with one connection or none leaves the grid as it is. A rebuilt grid first gives every duct its share of the tank, the amount divided equally among the ducts that store fluid, with the first duct also taking the remainder, and each duct pours its share into whatever grid it joins next. A duct saved with the world keeps its share the same way. | src/main/java/cofh/thermaldynamics/multiblock/MultiBlockGrid.java L143–171src/main/java/cofh/thermaldynamics/util/WorldGridList.java L44–58src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L145–152src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L265–275src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L46–59src/main/java/cofh/thermaldynamics/duct/fluid/DuctUnitFluid.java L374–377 | Code |
| Factorio 2.0's fluid segments match the description of Thermal Dynamics r2.3.9's design: connected pipes or ducts merge into one unit that holds one fluid, its volume summed from its parts, and fluid put in is available anywhere along it at once (FFF #416, 2024). In the design as FFF #416 first described it, machines push in at an unlimited rate, as Thermal Dynamics takes fluid up to the tank's free space, and pull at a rate proportional to how full the segment is, half the maximum at half full; each Thermal Dynamics outlet duct instead hands its neighbours between half and all of the fluid's throughput, scaled by how full the tank is (three-quarters of it at half full), and no more than the tank's amount divided by its duct count (or the remainder, when that rounds to 0). FFF #430, still before 2.0's release, gave the rules as changed: pushing in is now slowed as the sink fills, and every transfer is capped at 100 units, a limit that already existed, multiplied by the fullness of both source and sink. The scaling by the source's fullness has a counterpart in Thermal Dynamics; the 100-unit cap and the scaling by the sink's fullness don't. FFF #416 doesn't say which version of the mod Rseding played. | src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L80–85src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L215–219src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L162–167src/main/java/cofh/thermaldynamics/duct/fluid/GridFluid.java L227–243 | Dev blog |