Thermal Expansion and Thermal Dynamics (1.12.2 source releases)

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. thermal-expansion/fluid-grid-forming

Cited by: Fluid network, Power network, Thermal Expansion

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. thermal-expansion/fluid-grid-tank

{
 "defaultThroughput": 120,
 "maxPerDuct": 3000,
 "minThroughput": 80,
 "maxThroughput": 600
}

Super-laminar ducts (GridFluidSuper) override the throughput modifier and per-duct maximum and are excluded. "Open" means the side is an input or output and its connection allows transfer, with any filter on it passing the fluid (DuctUnitFluid.isOpen, matchesFilter).

Cited by: Fluid network, Thermal Expansion

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. thermal-expansion/fluid-grid-output

The ducts that hand out fluid are the grid's node set: ducts with a fluid-handling block, or a servo, on a side (DuctUnit.loadSignificantCache, isNode). Servos and other attachments tick in the same pass and pull fluid in; their code isn't read here.

Cited by: Fluid network, Thermal Expansion

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. thermal-expansion/fluid-grid-split

The removed duct also takes its share (destroyNode runs on it first); where that share goes once the duct is broken isn't read here.

Cited by: Fluid network, Thermal Expansion

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. thermal-expansion/segments-compared

Factorio's side is the posts' (factorio-production/fluid-segments), not its 2.1 code. At half full, Thermal Dynamics' getFluidThroughput gives half + half × (amount − capacity/4) / (capacity/2) = three-quarters of the full rate.

Cited by: Fluid network, Thermal Expansion

In Thermal Expansion r5.3.9 (Minecraft 1.12.2), in the loop its machines share, a machine's recipe costs an amount of Redstone Flux (RF), and the machine works by spending it: each tick a running machine takes some RF from its store and subtracts it from what the recipe still needs, and finishes when that reaches zero, getting back any RF it spent past the cost. So a machine with more power finishes sooner. A machine whose store runs dry mid-recipe stops and clears what the recipe still needed, so the RF spent on it is lost: the furnace, starting again, sets the recipe's full cost. An idle machine checks on a timer whether it can start. The charger and the transposer replace parts of this loop in some modes, and are excluded. thermal-expansion/machine-processing

Each machine sets the recipe's cost (processMax, processRem) in its own processStart, from the recipe's energy (TileFurnace L166, for one). How often timeCheck and timeCheckEighth fire is in CoFH Core's tile base, not read here. Most machines' own update() adds a fluid transfer before the shared loop; TileCharger and TileTransposer handle processRem themselves in some modes.

Cited by: Power network, Thermal Expansion

In Thermal Expansion r5.3.9 a machine's power follows how full its RF store is. With the default settings and no augments, a machine of base power P stores 1,000 × P RF and takes up to 4 × P a tick. It spends P RF a tick while its store is at least 90% full, the store divided by 900 between 10% and 90% (P/9 at 10%, about 0.56 × P at half), and P/10 below 10%, or what's left once less than that remains. Base power is 20 RF a tick for most machines and 50 for the charger and the crucible, multiplied by 1, 1.5, 2, 2.5, or 3 for the machine's level. With the SmallStorage option a machine stores only 10 × P and always spends P. Augments change the draw and are excluded: the power augment, which any machine can take, adds the level's base power to P and makes recipes cost 15% more; the furnace's pyrolysis and the crucible's lava augment change it too. thermal-expansion/machine-power

{
 "energyRamp": 900,
 "levelScalingPercent": [
  100,
  150,
  200,
  250,
  300
 ]
}

Base power and the level scaling are config options (BasePower, CustomScaling); these are the defaults. getBasePower clamps the level to Thermal Foundation's TFProps.LEVEL_MIN and LEVEL_MAX (not read here) and indexes the five-entry POWER_SCALING with it.

Cited by: Power network, Thermal Expansion

Thermal Expansion began as an addon that ran its machines on BuildCraft's Minecraft Joules (MJ), and Team CoFH say it split into its own mod "due mostly to the design choices by the BuildCraft developers". Its 3.0.0.0 changelog (25 December 2013) drops MJ for its own Redstone Flux (RF), at 10 RF to 1 MJ: machines take only RF, dynamos that make RF replace engines, and the Redstone Energy Conduits take RF but convert it to MJ on output where needed. thermal-expansion/rf-replaces-mj

The design choices aren't named on the page, and no BuildCraft developer's account of the split was found. "Engines" in the changelog are BuildCraft's MJ engines, which earlier Thermal Expansion versions needed for power (cofh-about).

Cited by: Power network, Thermal Expansion

Redstone Flux's reference store, in Team CoFH's RedstoneFlux API for Minecraft 1.12, is an amount of energy with a capacity, a most it takes in at once, and a most it gives out at once; changing the amount directly clamps it between 0 and the capacity. Thermal Expansion r5.3.9's machines use this class for their RF store. thermal-expansion/rf-api

Cited by: Thermal Expansion