Reactor Controller

alaindustrial:reactor_controller

NuclearHVImplementednuclearreactormultiblockshieldingautomationtier-hv

Summary

The Reactor Controller is the only intelligent block in the shell and the room's only machine. While the room is being built it finds the shell around itself, checks it and reports what is wrong and where. Once the shell is closed it becomes the reactor: it collects the fuel assemblies, works out output and heat, boils the coolant, re-settles the fluids inside every stack of columns, wears the rods down and pushes EU/FE out.

The controller goes in place of one casing block in a vertical wall, facing outwards: the front face carries the screen the player reads, and the redstone goes to the same side. The cable goes on any other face. A room with two controllers does not form — a room has exactly one brain.

The controller does not need a room in order to work. Without one it drops into bare mode: it finds the racks around itself with a radius scan, delivers a markedly cut-down output, and pays for it by melting blocks around the racks themselves at regular intervals. That is a choice the player makes, not a breakage — the details are under "Bare mode".

Where overheating ends. Past the mark the room starts melting its own contents, and a gauge that reaches 100 % starts the countdown — two to three minutes to an explosion unless the gauge is brought down. Radiation around a running core lives apart from both the meltdown and the accident.

Where it has to stand

All four conditions are checked by the same scan and produce the same class of answer — a status plus a place. There is no separate "setup mode": place it, read the screen, fix the thing.

The scan

The scanner works in two passes, and that is not an implementation detail but the reason its messages are useful.

1. Six walls — along ±X, ±Y, ±Z from the cell in front of the controller. Each wall is found not by

one ray but by up to nine parallel ones: the ray of that cell itself and the rays of the eight cells around it in the plane across the direction. The wall stands where most of the rays stopped; on a tie the cell's own ray wins, then the nearer wall. A neighbouring cell that is itself a shell block (the controller's wall, the floor under the cell) does not vote. If no ray found the shell, the room is "unbounded in this direction" — either it is too large, or one of its sides has been knocked out.

1. A walk of the whole perimeter implied by those six walls. This is the pass that finds a missing

cell anywhere in a 14³ shell and names its coordinates. Having found the first hole, the walk does not stop but counts all the others: the first 12 it remembers by coordinates, beyond that it only counts. As long as there are no holes, the same walk counts controllers, remembers door cells and tallies the glass share.

Why a vote rather than one ray (playtest,. One ray per direction ran into whatever stood on its single column. Two holes in the middle of the ceiling, one of them above the cell in front of the controller, let the ray out into the sky, and a room with a holed ceiling was declared a room with no ceiling — "No walls found" instead of "breach". A stray casing block inside the room on the same column, the other way round, stopped the ray under the real ceiling, and the room "shrank". The neighbouring rays outweigh both.

Why every hole rather than the first (same playtest). The walk used to stop at the first non-shell cell, and a player who had knocked out two cells on the right and four on the left saw one marker on the right. They fixed it, waited for the scan, and only then learned about the next one.

A ray reaches + 1 steps, not exactly the limit. The extra step is not slack but the condition under which "too large" can exist as a status at all: a ray capped at exactly the limit can never see the far wall of a room that is one block too wide, so every oversized room would report "unbounded". With the extra step, "you built it one block too wide" and "there is no wall there" stay different answers.

Why not a plain flood fill: a flood fill cannot tell "this room is too large" from "this room leaks" — both simply run until the cap. Two passes give two different answers to two different questions.

The order of the checks is a usability decision as well, not a coding one:

1. controller placement (is there an open cell in front of its face);
2. bounds — the six rays;
3. size (TOO_SMALL, then TOO_LARGE);
4. seal — the non-shell cells of the walk (BREACH; the first is reported, all are counted);
5. the controller itself found as a wall cell rather than an edge one;
6. a second controller;
7. a doorway;
8. the glass share.

Each answer is actionable on its own, and the player fixes one thing at a time instead of being handed a list. The glass cap comes last on purpose: it is the one "soft" problem — a room that hits it is sealed and correctly built, it simply does not count as containment — and reporting it ahead of an actual hole would be the wrong order of priorities.

The periodic pass is mandatory: only fires for the six blocks touching the controller, and a room can be 14 blocks across. A block mined on the far wall is nobody's neighbour here, and without its own timer the controller would never notice. For the same reason the controller never goes to sleep.

States

Nine states. Eight of them are a job to be done; the ninth is "done".

TOO_MUCH_GLASS is appended to the end of the enum rather than slotted in next to BREACH where it belongs by meaning, and that is not sloppiness: the order of the constants is the wire format — what travels to the screen is an ordinal. Inserting in the middle would rename every state after it.

The position TOO_MUCH_GLASS reports is not a "guilty" cell — the share is guilty, not any one block but the first glass cell in perimeter-walk order. It is there so the smoke leads the player to the glazed part of the shell: a 14×14 room is large, and "too much glass" without a direction is a message with no action attached.

How it runs the reactor

A finished room is one machine, and the controller executes its whole tick. The fuel assemblies have no tick of their own at all: a hall with thirty racks costs the server what one block entity costs.

Collecting the columns

On the same sweep as the shell check (once every = 40 ticks), the controller walks the room interior and records every reactor column — loaded and empty alike. The same pass sums the rods that carry uranium and counts the adjacency pairs.

Empty columns go into the list deliberately. Filtering on fuel looked harmless and was not: an empty rack fell out of the water loop and out of the stack settling pass, which is why water pumped into the bottom of a column never rose past the first loaded assembly. A column is part of the machine because it stands in the room, not because somebody has fuelled it yet.

Adjacency, on the other hand, is counted by fuel: two empty racks side by side accelerate nothing, or the bonus would be paid for scaffolding.

Sweeping a 12³ interior is 1728 block reads: absurd sixty times a second, cheap once every two seconds. The price is latency: a rod inserted by hand enters the calculation on the next sweep, so no later than two seconds. Next to a rod that burns for minutes, that is invisible.

Adjacency pairs are counted over +X, +Y, +Z — each pair exactly once — but both racks of the pair get the bonus, hence the x2 in the output formula.

Output, fuel and heat

The ceiling is applied before the throttle, not after. The potential is clamped to 512 EU/FE/t first, and only then scaled by depth. The other order looked equivalent and was not: on any core whose potential had already cleared 512, every stop of the slider produced the same 512 EU/FE/t — the control did precisely nothing at the exact scale it was built for.

Fuel is counted in EU/FE, not in time. The controller charges the columns with exactly the energy it produced, and a column converts that into durability points on its rods (144 EU/FE per point; the details are in the rod spec). Hence the model's central property: a rod is worth 144,000 EU/FE everywhere, and no layout makes uranium cheaper.

It was not always so. Before stage 4 fuel was driven by an "effective depth" — the fraction of its potential the room actually delivered — and on a large room that fraction truncated to its floor of 1 ‰. Two absurdities followed from the same line: a rod lasted about a thousand real days, and heat became full heat / 1000 and grew without bound as the room grew (a 12x12x12 hall came out at roughly 105,000 heat a tick — more coolant than the shell has surface to admit).

Heat has an adjacency coefficient of its own, and it is the larger one — = 40 % against = 25 %. That is the key number of stage 3: a dense core heats up faster than it strengthens, so a layout that raises power raises the price of cooling with it. The stage-2 rule "heat = output / 3" no longer holds: it is two thirds on a lone column, 0.79 on two adjacent ones, and it approaches 1.07 on a very dense core at the HV ceiling a room makes more units of heat than it makes EU/FE.

That same division is also what bounds the heat from above. Both terms carry the same rods and the same adjacencies, so the heat-per-EU/FE ratio converges as the room grows instead of diverging:

heat at the HV ceiling -> 512 x (4 x 0.8) / (6 x 0.5 = 546 units/t

A dense room at the ceiling runs between 500 and 546 heat a tick (six columns in a 2x3 block make 500, a 12x12x12 hall 546), and none runs hotter than 546: the more sparsely the columns stand, the less heat the same ceiling costs.

A big room buys autonomy, not power. Everything past 512 EU/FE/t delivers the same 512 EU/FE/t; what grows is the time between refuellings, because the same stream is divided among more rods. The room's appetite is identical for every layout that reaches the ceiling: 256 rods = 128 uranium ore an hour. The per-layout figures are in

Heat is settled every tick, even with the reactor shut down: cooling has to work, or "scram and wait" would not be a way out. A full scale on a stopped reactor drains to zero in 395 ticks (19.8 s). Past the mark the room starts melting its own contents — see "Meltdown" — and a gauge that reaches 100 % starts the accident countdown.

Controls: redstone and depth

There are deliberately no other controls: two is exactly as many as fit in the head of a player standing in a smoking hall.

The throttle rides the vanilla container-button channel, like the dome toggle on the repeller: the button id is the requested depth in percent, so no payload of its own is needed. The value is clamped on the server, not in the screen.

The throttle works at every scale: it cuts a figure that has already been clamped, so 50 % on a 3x3 layer gives 256 EU/FE/t — and exactly half the heat, half the water and half the uranium per hour. In stage 2 that was not so (the ceiling was applied last, and above it every stop was identical); the discrepancy was closed in stage 3.

Cooling: water is the only thing that cools a running room

While the reaction runs, the shell sheds no heat at all. Whatever the water did not carry away stays on the scale, so a reactor with no water heats all the way to the top — and starts the countdown there. Output does not depend on water: a dry reactor delivers the same EU/FE and burns the same fuel, it just heads for an accident. How fast is decided by

It was not always so. Before the shell shed 4 + heat x 8 / 1000 — up to 84 units/t — at any moment, and every core weaker than that settled at its own equilibrium: one column at 15 %, two adjacent at 66 %, eight rods at 65 % depth at 40 %. Water could be left out altogether by throttling the rods back, and the very first playtest of the «Console» tab showed it.

A stopped room cools on its own — along the same curve 4 + heat x 8 / 1000: lever pulled, depth at 0 %, fuel spent. Otherwise "scram and wait" would stop being a way out.

Every tick the water carries away all of the reaction's heat and, on top of that, a twentieth of

reaction heat = requested > 0 ?: 0
water, mB = ceil((reaction heat + ceil(heat / 20)) / 2) (rounded UP)
removed = boiled x 2
shell losses = reaction running ? 0: 4 + heat x 8 / 1000
heat(t+1 = clamp(heat + reaction heat − removed − shell losses, 0, 10,000)

The first term holds the scale, the second brings it down after a drought: five dense columns that get their water back at 100 % return to 84 % in four ticks and to zero in four seconds. Neither term has a threshold, and that cures the sawtooth the playtest found: the old loop engaged only from 60 % of the scale and removed heat in steps of two units, so a core sitting on the line crossed it every few ticks and the gauge flickered 59/60 %.

is not a detail: at the smallest depth the reaction asks for a whole EU/FE while its heat rounds down to zero, and without the one such a reactor would run with no water forever. Water is rounded up for the same reason: truncation returned 0 for any heat below the exchange rate.

A reactor that has enough water reads zero on the gauge, and the bar is empty. The amber band means the water is not coping, and the WARNING chip lights even earlier — as soon as the water carries less than 95 % of the reaction's heat.

The controller boils, not the column: it walks its list of columns and asks each one for as much as it has not gathered yet. Whatever could not be boiled stays as heat and goes on the scale. That is the entire failure mode of a starved loop: not an error message, a rising bar.

Re-settling the stacks

Every tick the controller tidies the fluids inside each unbroken vertical stack of columns: all the water gathers at the bottom, all the steam at the top. A stack therefore behaves as one vessel, and a pipe plugged into any block of it fills the whole thing.

Without this a stack simply would not fill: water sinks, the bottom block reaches capacity first, and a pipe asking "is there room?" got "no" from a vessel that was half empty.

⚠️ Columns standing side by side are not connected. The controller used to even the tanks out across the whole room, and one pipe watered the entire hall. That was convenient and untrue: coolant appearing inside a rack nothing is plumbed to reads as a bug however useful it is. Plumb the columns you want cooled — the easiest way is to build them in stacks.

Bare mode: a reactor with no room

A controller whose room never came together does not sit idle. If loaded racks physically adjoin it, it takes to running them directly. This is a second full working mode, not a failure state.

The link has to be physical. The controller steps outwards from itself through touching racks and shielding-alloy blocks — through a half-built shell, then, as well. Open ground does not conduct the reaction: a column standing three blocks away across a gap is not part of the reactor, however much of it there is. is a bound on the length of that walk, not a search radius.

The rule came out of a playtest: the search used to go by radius, and a controller on bare earth lit up from a column across a gap. It looked like power being handed over through thin air. Touching works, and that is exactly the feeling it should have.

A full buffer does not switch the danger off. Fuel is only spent when the energy is wanted (and that is right), but the reaction runs whether or not anybody is buying the current. So the block damage hangs on "the reactor is not scrammed and it has fuel in it" rather than on this tick's output — otherwise it could be switched off by simply unplugging the consumers. Radiation behaves the same way, and always has.

The only control a bare reactor listens to is redstone. Cutting the signal shuts it down completely, and that is a working tactic: to finish the shell around a live core in peace, flick the lever.

The depth throttle is deliberately neither shown nor honoured. A throttle working out of sight would be a trap: a room with its rods withdrawn that then lost a wall would fall silent and say nothing at all about why.

The output is cut twice — by a share and by a cap — and both limits are needed. The share makes a bare reactor weaker than a built one; the cap stops the player answering that by simply piling on more rods. Without the cap a large enough heap would out-produce a room, and the shell with its cooling loop would turn into decoration.

Whose racks are whose

Two controllers next to the same heap of racks would each count the whole heap — energy out of thin air. There are two rules, and one scan settles both without any bookkeeping on disk:

Racks inside somebody else's sealed room are invisible from outside. A bare controller planted next to a working reactor cannot feed off it. Between two bare controllers a rack goes to the nearer one. A tie is broken on coordinates rather than on distance alone: a rule each side works out for itself would hand the same rack to both.

A known gap: a controller in an unloaded chunk is invisible, so a rack out at the far edge of a chunk boundary can briefly be counted twice. That is a few EU/FE a tick until the neighbour loads; closing it by force-loading chunks would be a cure worse than the disease.

Meltdown: the price of overheating

Past the mark a sealed room starts melting its own contents: the floor, ordinary pipes and everything the player carried inside. The first to go is always an ordinary fluid pipe, wherever it stands: it is the part assembled out of whatever was already to hand, and so it is the one that explains best what went wrong.

The shell itself stays whole. The casing, the glass, the door, the inlet, the outlet and the controller all stand on the ring outside the interior and never enter the selection at all. That is exactly what the room was built for: the accident stays inside.

The fuel racks come through whole as well. They are assembled around a shielding plate, and a part crafted to survive the reactor survives its accident too. The uranium inside is not lost — a meltdown takes the player's fittings and time, not their stock of fuel.

Every melted block carries heat away with it, so a meltdown is self-limiting — the room eats its own insides and cools down as it goes. The player loses the contents and the fuel inside them, but is left with a shell that can be refitted rather than with a crater.

While this is going on the panel headline reads "Meltdown" instead of the geometric verdict: a perfectly intact shell is telling the truth at that moment, and it is the least useful truth available.

Melting blocks: what it looks like

Both modes destroy blocks the same way, and both always warn first — pointedly, at the block itself.

1. A block is picked. Flame and smoke break out on it, and there is a hiss.
2. pass (two seconds). Getting clear in time, or taking away whatever stands on

it, is exactly the difference between a danger and a punishment.

1. The block becomes a lava source. The pick prefers cells with air above them: the sphere

around a rack goes half underground, and without this rule most of the damage silently hollowed out the rock underfoot while the visible scar looked half the stated radius. If the player mined it in the meantime, nothing happens: the choice is re-checked rather than carried out blind.

What never melts in either mode: air, anything with a fluid inside it (waterlogged blocks included — water stops lava everywhere, and flooding the place is a fair tactic), and anything indestructible — tested against the block's own property rather than against a list of names, so another mod's own bedrock is respected for free.

What does not melt anywhere, ever: everything made of shielding alloy. That is the reactor's own blocks — the casing, the glass, the door, the inlet, the outlet, the lamp, the button, the racks and the controller — and the Shielding Chest. The rule is exactly that: "made of shielding alloy does not melt", not "belongs to the reactor". The list lives in the block tag , and a datapack can extend it. Without that, "a bare station as a long-term strategy" would not be a choice but a fuse. Everything else within the radius — the player's cables, their pipes, chests and the ground underfoot — is a legitimate target, and that is precisely the price of the corner that was cut.

In bare mode the radius is measured from each loaded rack, not from the controller. The controller is the brain; it is the fuel that is dangerous, and radiation already counts it that way, so both mechanics answer "how far out is it dangerous" the same way. Measuring from the controller was a mistake you can see from the far side of the reactor: it stands in a wall, half the sphere is taken up by the reactor's own untouchable body, and all the damage landed on the side it faces.

⚠️ Lava flows. A melted block becomes a lava source, and lava spreads by vanilla rules — up to three blocks sideways and downwards without limit. One melted block is not one loss but a puddle, and through the holes in an unfinished shell it pours inside. The harshness is deliberate, but building a bare station right up against anything you would miss is a bad idea.

⚠️ The block under a player or a mob is not protected. The harshness is deliberate: dying through inattention in the middle of an accident already under way is possible, and no position is skipped for safety's sake.

The whole thing is switched off by. Switched off it leaves every warning in place — the sound, the particles, the status — but changes not one block: the key protects the world, it does not hide the reactor's state.

The accident at a hundred percent

A heat gauge that reaches the top no longer just sits there — it starts a countdown. The panel's headline changes to MELTDOWN IMMINENT, a draining red bar appears under it, and the siren keeps going to the end.

The bar carries no figure, on purpose. The duration is rolled per accident, between two and three minutes: a fixed delay would be memorised within a week and the panel would stop being read. The bar honestly says "time is running out" and does not say how much is left.

It can be cancelled up to the last tick — there is no point of no return. Two ways, and both come down to the same thing: the gauge has to come off a hundred and stay off it for five seconds.

• feed water into the loop;
• pull the lever (the scram).

Breaching a wall is not a way out, although the panel used to suggest it. The room falls into bare mode, and a bare reactor has a scale of its own: from 14 rods the instability runs up to a hundred in about 20 seconds and starts a new countdown — this time with no loop that could help.

The five seconds are not pedantry, they close an obvious loophole. Heat is clamped at the top of the scale, so a single tick without a signal is enough for the gauge to read 99 %. While the countdown was cleared on that instantaneous reading, a repeater clock with one tick off in twenty gave the reactor ninety-five percent duty and total immunity. Now the countdown pauses while the core is below the line and clears only once it has stayed there for the whole window; one tick back at the top forfeits everything banked. Every honest fix clears it with room to spare, and blinking the signal buys nothing.

A full buffer is not on that list. A reactor with nowhere to put its energy does not stop: the reaction runs, the gauge climbs, and without coolant it reaches the explosion just the same. Only one thing changes — no uranium is spent, because fuel is charged against energy actually delivered. A reactor left switched on with a full buffer heats for free and explodes for nothing.

Blast power grows with the rod count and stops at a ceiling. The numbers live in the room entirely — everything inside is gutted, not one block outside changes — and a large station is not. That is what the walls cost what they cost for.

What is left afterwards is a crater, lava at the epicentre, uranium scattered out of the racks, and irradiated soil — but only where the blast actually reached. The switch removes the accident entirely, keeping the countdown, the sound and the panel.

A bare reactor's instability

A reactor with no room has neither heat nor water — what it has is instability, shown on the panel as a row of its own. It grows with the number of rods in the pile and decays on its own, so every size has its own resting point:

Hence the lava farm's rule: three racks is the maximum that can be left running unattended. The fourth turns the farm into a bomb, and the panel says so in advance.

Interface

Type: a screen with no slots at all and no player inventory — the controller is read, not loaded. There are no slots on purpose: empty slots would invite hoppers into it. The player's inventory rows would take the lower half of the panel, and clicking them would do nothing. No upgrade panel: the controller is not a processing machine, and four hidden upgrade slots would promise something it cannot do. No progress arrow: a reactor has no operation that is "in progress".

A screen with tabs. The panel is 236×184, with tabs down its left edge drawn from the game's own advancement-screen sprites: each has an item for an icon and a tooltip with its name. Tabs arrive one at a time, and there are no empty "coming soon" tabs. Today there are four, «Console», «Room», «Core» and «Coolant». A closed tab can carry a marker: red means an alarm, yellow means a warning. The last tab you opened is remembered until the game restarts.

The header is the same on every tab: the tab's name, the status chip on the right and, under it, the accident countdown bar with no figure on it. The chip is chosen in order — the first matching state wins:

A countdown outranks a meltdown because it is the only state with a deadline. WARNING outranks IDLE: while the reaction runs the shell sheds no heat, and a reactor short of water heads for an accident whether or not it is selling energy. A full buffer used to show such a reactor as a grey IDLE. A stopped room uses no water and is not counted as under-cooled.

The «Console» tab

The tab shows the reactor in one of three forms — never two at once.

Marks on the heat bar — the warning (70 %) and the start of meltdown (85 %), with their numbers under them. The coolant-target mark (60 %) is gone: a reactor on water sits near zero on the gauge, and the line it used to hold at stopped describing anything. Its channel now carries the share of heat the water carried away. The numbers come on channels from the server, not from the client's config. The config is not synced to the client, so on a server with a changed balance the marks would otherwise sit somewhere other than where the reactor acts. The first version of the screen got exactly that wrong: its yellow step came from the client's config. The bar is green below the warning, yellow up to the meltdown, red above it.

Next to the heat label there is a trend arrow: up if the heat rose by 2 % or more over the last two seconds, down if it fell by as much. A reactor sitting at its equilibrium wobbles by a percent either way, and an arrow flickering with it would stop meaning anything. For the first two seconds after the screen opens there is no arrow: there is nothing to compare with yet.

Steam has its own bar. From 90 % its label changes to "exhaust blocked" and the bar turns yellow. With a blocked exhaust the coolant bar sits reassuringly full while the heat rises: the water is there, but it has nowhere to boil to. Before, only the yellow colour of the coolant bar said so, and nothing on screen explained what it meant.

Rod depth is the vanilla slider with a 5 % step and a STOP button that sets the depth to 0 %. The value reaches the server as one request: when the slider is released or when an arrow key is pressed. It travels on the vanilla container-button channel; the button id is the depth in percent. The requested value is held on screen until the server answers, but for no longer than two seconds. Without holding it the number would jump back while dragging; without the limit a request the server refused would stay on screen for good.

The slider and STOP are shown only for a sealed room. A bare reactor ignores the depth, and a control that looks alive but does nothing is exactly the trap refused when bare mode was introduced. A click where the slider would be does nothing in the other forms — the slider is simply not there.

Advice is the dark box at the bottom of the tab: a title in the state's colour and what to do. If a translation runs long, the text shrinks as a whole rather than being cut mid-sentence.

"No water" is a warning at any temperature. While the rods work nothing but water cools the reactor, so a dry room heads for an accident from the first tick. Water carrying 95 % of the heat or more counts as enough: a supply that runs a millibucket late on the odd tick must not make the chip flicker.

Tooltips on hover exist for the heat bar (what each mark means, in its colour), output, buffer (the exact charge in EU/FE), coolant, steam, instability, the slider and the STOP button.

The «Output» row never shows a dash. A built, fuelled and silent reactor is this machine's worst state, and each of its causes has a different fix, so instead of a zero the row prints the idle reason in red: not sealed, no fuel, rods withdrawn, no redstone, buffer full. A dash left the player guessing between five different faults.

Every row is a label and a value measured separately. The value keeps its size — it is what the row is read for. The label shrinks into the room left over. This follows directly from the screen's first version, where label and value were one string and the Russian text ran into the pictogram.

The «Room» tab

The tab for building: the shell from above, the scanner's checks in order, and what to fix.

An unbuilt room opens the screen straight on «Room». The decision is taken on the first tick after the channels arrive from the server, not when the screen opens: a fresh menu reads zeroes, and zero is the ordinal of a formed room. The sign that they have arrived is the maximum-room-size channel: the server always sends it, and it is never zero. If the player has already picked a tab themselves, the choice is left alone, and «Room» does not become the tab they come back to next time. The marker on the tab's label is red while the shell is being built, yellow in bare mode.

The map from above. A cell is a column of blocks, north at the top, east on the right. The map shows the ring of the shell, the interior volume, the controller (orange) and blinking problem cells — for a breach, every hole, up to 12 by coordinates. A cell carries the hole's height relative to the controller ("+2"): seen from above, a floor cannot be told from a ceiling. If one column has several holes, the cell is labelled "×2", and the hover tooltip lists each one. For a breach with several holes the box under the map gives their number instead of the direction to the first; if there are more than 12 holes, it also says how many of them are on the map. Orientation is by the compass, not "from the controller's face": directions in the text — "4 east, 2 up" — are by the compass as well, and a map that turned with the controller would draw east on the left for half of all rooms. The cell size adapts to the room: a 5×5 is not drawn postage-stamp small, and a 15×15 shell — a room one block over the limit — fits whole. On hover a problem cell names the direction to each of its holes, and the controller cell says that it is the controller.

Until the scanner's rays have found all six walls there is no shell on the map: only the controller and the problem cell, and for ROOM_UNBOUNDED the text under the map reads "No walls found".

The checklist — the scanner's checks in the order it performs them:

Rows before the failed one are marked ✓, the failed one ✗ on a highlighted background, and rows after it "·": the scanner never got to them. The checklist also answers "what has already passed": a player fixing a room block by block watches the red row move down, while a lone red verdict never showed that the size had been fine from the start.

Why "controller not in a wall" is two rows. The scanner issues this status from two different places. Before the rays — the cell in front of the controller's face is occupied: nothing has been measured, and this is the first check. During and after the perimeter walk — the controller stands in the floor, the ceiling or an edge: by that point the rays have already measured the room, and the walls and the size have passed. What tells the two cases apart is whether the room has been measured. A single row with ✗ at the top, above two rows known to have passed, would be telling an untruth. There is one exception to "everything before the failure passed": a controller in the floor or the ceiling is found in the middle of the perimeter walk, so in that case the "No holes in the shell" row stays "·" rather than ✓.

The row order is checked against the real scanner: an L1 test builds rooms with two defects at once and requires the scanner to name the defect of the earlier row.

The limits in the rows come on channels from the server, like the heat marks: the config is not synced to the client, and a checklist with a local 3…12 on a server with different limits would show the wrong numbers.

Where the map gets the walls from. The channels carry the size of the interior volume and the offset of its west and north edges from the controller, and for a breach the number of holes and the offsets of the first 12, three channels per hole. They are not packed into one channel: the room-size limit in the config has no ceiling, and a packed offset would wrap around on a large room. A failed scan used to throw away the room it had measured, so for a breach the size arrived as zero. Now every verdict found after the rays — size, a hole, a misplaced controller or door, glass — carries the room it was found in.

The box under the map is the same dark box as the advice on «Console»: the verdict in the state's colour, what to fix and where. For a formed room it reads "Room sealed", with a pointer to «Console», where the reactor is run.

A dash instead of zeroes. While the room has not been measured the size row shows "not measured", not "0 × 0 × 0". Zero is also a measurement, and showing it where nothing was measured is a lie; a dash honestly says "nothing to show". The same goes for the problem's place: a direction is printed only for the states that really point at a block (BREACH, SECOND_CONTROLLER, CONTROLLER_NOT_IN_WALL, TOO_MUCH_GLASS); for NO_DOORWAY the "place" is the controller itself, and an offset would be noise.

ROOM_UNBOUNDED does not show a direction, although it has a technical position. This was a fix after a playtest: the "place" of that status is wherever the ray gave up, up to 13 blocks out in open ground, and a lone controller smoking into a hillside turned out worse than silence. It pointed where there was nothing to fix.

A place is a direction, not coordinates. The offset is counted from the controller itself and reads like "4 east, 2 up": the player reading the screen stands at the controller, and such a phrase brings them to the right block faster than three numbers. Axes with no offset are dropped — a breach straight overhead reads "2 up", not "0 east, 2 up, 0 south". Technically it is also the only option: the menu's sync channel carries a signed 16-bit number, an absolute world coordinate does not fit in it, and the offset never exceeds ±14 by construction.

The state is visible from outside as well: a formed room's controller face glows (the formed blockstate), an unformed one's stays dark. You can check a build without opening the screen.

The «Core» tab

The tab shows the core from above: one cell is one vertical stack of columns. A stack is a single vessel for water and steam, so it is read as one whole as well. The grid is oriented like the «Room» map: north at the top, east on the right.

A cell looks like an inventory slot. The rods are drawn as bars for the stack's average column: bright ones are fuelled, dark ones are spent casings. Under them is a wear strip styled like an item's durability bar: green for fresh rods, through yellow to red for burnt-out ones, by the stack's average wear. If a stack has more than one column, their number is written in the cell's corner — when the cell is at least 9 pixels, that is, in cores up to 9×9. The cell size adapts to the core: a 12×12 hall fits whole, and two stacks are not blown up to fill the whole grid. In cores from 9×9 up a cell is too small for four bars, so it is drawn as a single fill — green if the stack has fuel, dark if it holds only spent casings — with a wear line along the bottom.

The densest stack is marked with a red square in the corner of its cell. The mod has no per-column heat — there is one heat for the whole room — so the mark goes not on the "hottest" stack but on the stack whose columns have the most fuelled neighbours across the six directions. The neighbour bonus is counted for the whole room: every pair raises the output and heat of the entire reactor, and the output is shared equally among all the rods. So the mark shows where that bonus is earned, not a stack that runs hotter. A rack holding nothing but spent casings does not count as a neighbour. On a tie the first in order wins: the northernmost, and among those the westernmost.

The panel on the right holds the details of the selected stack: columns, fuel rods (fuelled out of slots), spent casings (in yellow, if there are any), wear — average and worst, energy left, fuelled neighbours, and the stack's water and steam. Clicking a cell selects its stack. While nothing is selected, the panel shows the stack to replace first, and if there is nothing to replace, the densest one. The selection is tied to the stack's place relative to the controller, not to the core's corner: when a bare reactor loses its westernmost rack and the corner of the core shifts, the same stack stays selected.

Under the grid are a summary of the core (stacks, fuelled rods, average wear) and the «Replace first» row: the stack with the most worn rod, where a spent casing counts as fully worn; on a tie, the northernmost, then the westernmost. While no rod is worn at all, the row says there is nothing to replace. The marker on the tab's label is yellow while at least one rack holds spent casings.

The data comes in a packet of its own, not on menu channels. A menu channel is a 16-bit number, while a core is up to several hundred stacks at about fifteen numbers each. The reactor_zone packet goes only to a player who has this controller's screen open: sending hangs off the menu's , and vanilla calls that only for an open screen. No more than once a second, and only if the snapshot has changed; the first snapshot goes out as soon as the screen opens. A column placed or broken shows up in the snapshot after the next room scan. The server merges the stacks, so the packet carries no more than one entry per cell of the core — up to 289, the area of 17×17, beyond which a bare reactor with a search radius of 8 does not spread. A room wider than 17 cells (the room-size limit in the config has no ceiling) is shown by its north-west 17×17 corner; neighbours across the edge of that cut still count. The coordinates in the packet are offsets: stacks are measured from the core's corner, and the corner from the controller. The server does not hand out absolute world positions.

Energy left is computed with the same arithmetic the rods are spent by: the remaining durability points multiplied by the EU/FE per point. The screen has no second formula, so the tab will not promise energy the rack will not deliver.

The «Coolant» tab

The tab shows the water loop from above on the same grid as «Core»: one cell is one vertical stack of columns. A stack selected on either of these two tabs is selected on the other as well.

A cell holds two bars side by side: water on the left, steam on the right, both rising from the bottom of the cell. They are two different tanks and do not add up into one bar: a full steam tank hidden behind a full water tank is exactly the fault this tab was made for. The steam bar turns yellow when the stack's exhaust counts as blocked; under the water bar of a dry stack the floor is red. In cells of 12 pixels and up a faulty stack is also marked with a square in the corner: yellow for a blocked exhaust, red for no water; in smaller cells the square would cover the bars themselves, and there the fault shows by their colour.

A dry stack is one where at least one of its vessels holds not a single millibucket of water and has given the reaction not a drop during the last second. A trickle is no longer dry: it boils, and there is no point sending the player to fix it. Nor is a stack dry that the reaction boils dry every tick while its pipe tops it up again: the controller boils the columns in the order of its list, the pipe tops up on its own tick, and at the moment of the snapshot such a stack may hold 0 mB — but it is working. Exhaust blocked means steam fills 90 % of a vessel or more: there is water, but it has almost nowhere to boil to. It is the same line at which the steam bar on «Console» turns yellow. A vessel is a stretch of a stack that is unbroken by height, the way the controller re-settles them; a cell with a gap in its height is two vessels, and each is judged on its own: a full lower one will not hide an empty or blocked upper one.

The panel on the right is the selected stack: columns, water and steam in millibuckets out of their capacity with bars, and the state — «In order», «Dry» or «Exhaust blocked». While nothing is selected, it shows the first stack with a blocked exhaust; if there is none, the first dry one; and if there are no dry ones either, the first stack of the core.

Under the grid is a summary: how many stacks are dry, how many have a blocked exhaust, and how much water the reactor boiled off in the last tick. Below it is the advice, the first match in order:

A blocked exhaust comes first: steam with nowhere to go stops the boiling even in a stack a pipe is topping up with water, and piping in water before that is pointless. A dry stack among wet ones is almost always exactly that plumbing mistake, so the advice names the stack, not the room. The second cause is a water line that cannot keep up: the controller boils water out of the columns in the order of its list, and a stack whose pipe lags behind eventually runs dry — so the advice also suggests checking the line. A core wider than 17 cells (the room-size limit in the config raised above its default) is judged by the north-west corner that is shown: stacks beyond the edge of the cut are in neither the summary nor the advice.

The marker on the tab's label is red when there is a dry stack or a blocked exhaust and the water already carries less than 95 % of the reaction's heat: heat is building up. Yellow means there is a fault, but the heat is still getting away. A short loop with no dry or blocked stacks is flagged by «Console».

The data is the same reactor_zone packet. Each stack gains its water and steam in millibuckets with their capacities, and two flags; the server judges the faults from the columns' tanks, and the client recalculates nothing. The water rate is a menu channel that «Console» already shows. No config numbers are printed on the tab: the config is not synced to the client.

Feedback in the world

Text alone is not enough in a build of a thousand blocks, so the controller also answers with sound and particles. A multiblock that silently starts working leaves the player wondering whether it did.

The failure sound plays on the transition only, never in a loop, and that matters. The scan runs every two seconds; an alarm repeating every two seconds until the player finds the block turns a hint into a punishment. It is needed once because a wall is usually opened by a creeper, and at that moment the player is looking somewhere else. After that the particles do the work: they are unobtrusive, and they are visible the second the player turns round.

Smoke is now the only particle a breach gets. It used to come with angry-villager puffs, and the play session threw them out: over a wall they read as cartoon clouds rather than as a fault marker.

The assembly sound is the same ANVIL_LAND the distillation column plays when its tower forms. That is deliberate: "a multiblock came together" should sound the same across the mod, whichever multiblock it was.

Painting the formed flag

The controller is the only thing that sets the formed and edge blockstates, and it sets them on the whole shell, not just on itself. It also turns the room's lights on (details in "The seamless look" and in the lamp spec).

Why the box is passed in rather than taken from the scan result. A failed scan measures no box — its maxX < minX. A sweep driven by the result could therefore physically only ever switch the flag on: a breached wall left the room seamless and lit as if nothing had happened. The first play session found exactly that. The controller now remembers the last box it accepted and clears it when a scan fails. The box is written to NBT (BoxMinX…BoxMaxZ): a chunk can unload whole and reload with a hole in it, and a controller that forgot its box would leave the shell looking "formed" forever.

The saving is not a micro-optimisation: the sweep runs on every scan, that is every two seconds for every controller in the world. Reading a thousand blockstates is cheap, rewriting a thousand is not, and a needless would additionally fire neighbour updates on every pass. Flag 2 without flag 1 is chosen for the same reason: the properties are cosmetic, so the client must hear about them and no neighbour needs to.

Energy

The front face is energy-inert by rule R-NRG-03: it carries the panel the player reads, and a cable sticking out of the middle of an interface would spoil both the look and the sense of it.

The 200,000 EU/FE buffer is a damper rather than a store: a grid that cannot take the power this instant must not stall the core mid-tick. At the ceiling that is 391 ticks (19.5 s) of output, and exactly as long to fill from empty. One electrum cable carries 192 EU/FE/t per segment, so a reactor running at the ceiling is drained by three independent lines — or by machines placed flush against its faces.

Block properties

The verdict is not written to disk: the room is the save. After a world load the very first scan re-derives the state from whatever stands around. A stored verdict could survive a world edit that took the walls away, and then it would be lying.

Only what cannot be re-derived from the world lives in NBT: the bounds of the last accepted box (BoxMinX…BoxMaxZ), the accumulated heat and the throttle position. The box is not a verdict but an address: it is what gives the next failed scan something to clear (see "Painting the flags"), and it cannot lie — if it is stale, the sweep merely clears flags where there were none. Heat and depth are machine state: a reactor that forgot them on chunk unload would cool for free and come back at full power on its own.

Sound

Once the gauge the reactor is judged by climbs past the warning threshold, the controller sounds a siren exactly once. For a sealed room that gauge is heat, for a bare reactor it is instability. The siren used to read heat alone, and a bare reactor, which has no heat, went through the whole accident countdown in silence. Neither the walls nor a closed airlock muffle it: it carries far beyond the room, because it is meant for whoever is not in the room. It sounds again only once the gauge has dropped below (60 %) — an alarm that fires on every wobble of the gauge stops being an alarm. A lava farm of three racks sits at about 90 % instability, and so it sounds once, at start-up.

A gauge pinned at the top is a different conversation. For as long as the heat stays at a hundred percent the siren keeps going, re-sounding every three to five seconds at irregular intervals, and it stops only once the temperature starts coming down. A single blast there would be the worst of both: a reactor in its most dangerous state would end up quieter than one that is merely hot.

The columns' hum holds for as long as the reaction runs, not for as long as the reactor sells energy: a full buffer does not silence it. The hum used to hang on output, and a reactor with a full buffer played its shutdown sound while it went on heating. Stopping the reaction itself — redstone removed, fuel spent, rods raised — answers with its own falling sound . The short chime of a room that has just formed and the sound of a breach are described above, in "Feedback in the world".

Recipes

Craft — ×1 at a time.

S C S S = shielding plate ×4
R A R R = reinforced shielding plate ×2
S D S C = reactor control circuit ×1
A = advanced machine casing ×1
D = control rod drive ×1

The control circuit is a separate item: 4 palladium plates, a resonance coil, 2 advanced circuits, an electronic circuit and redstone

The coil took the place of the unstable isotope that stood here in the first version. The isotope is a product of the Incubator, and the incubator branch has been dropped from the reactor's requirements: it sent the player into the mod's biological wing for a single item and made the nuclear branch a hostage of somebody else's chain. The resonance coil fits the role better — it already sits at the "endgame electronics" rung, the thermal centrifuge leads to it, and in required progress it is the isotope's equal.

Progression

Tier: HV — a producer of up to 512 EU/FE/tick. Requires: shielding and reinforced shielding plates (the chain is described under casing), an advanced machine casing, advanced circuits, palladium plates, a resonance coil. Unlocks: the reactor room itself — without a controller a pile of blocks stays a pile of blocks.

Related

Reactor Casing — what it scans the room out of, the geometry and the crafting chain. Airlock Door — the intended way into the room; if one stands in the shell, it has to form a real doorway. Reactor Glass, the Lamp and the Reactor Inlet — the other blocks the scanner counts as wall. Reactor Column — what it burns, boils and re-settles. Fuel Rod and the Fuel Rod Cladding the fuel it wears down and the casing that is left. Steam — the loop's working fluid. Steam Nozzle — the end of the loop; until it works the steam bar turns amber and the heat climbs. Reactor Button — the one block of the set the scanner does not count as wall. Resonance Chain — where the coil for the control circuit comes from. Distillation Column and the Incubator — the mod's two earlier multiblocks; both check a fixed shape, and the volumetric scanner was written here for the first time.

Crafting

Shaped Crafting

▶

Reactor Controller