A factory gauge shows ? and will not link

The short answer

1. A gauge that shows ? is not sending. That character is the count while the gauge is waiting on the network. Only the saved link list is stored, under the NBT key Links, and a link that unloads leaves its position there. Every gauge on that frequency then shows ?, and the request tick returns before it sends. A missing address is a different string. After a restart every saved position counts as unloaded until its block initializes. A position left behind keeps the gauges on ?. Go to The gauge shows a question mark and does not send.

2. Redstone 1 to 14 does not set stock-link priority. The level is stored and sorted, and findPackagersForRequest then throws that order away with nextInt. A packager on a real inventory has an id, so it is in that random group. Signal 15 removes the link. Create 6.0.10 still does this. Go to Redstone 1 to 14 does not set priority.

3. A recipe gauge can send again after a null inventory is stored as an empty snapshot. The next real read subtracts the whole inventory from the promise. The pack ships no factoryGaugeTimer. The default is 100. The 20-tick summary cache alone does not fire a second send at that default. Go to A recipe gauge sends another order.

The middle-face vault report was not found in these classes. Go to A stock ticker and the middle of a vault.

None of this was tested in a world. The limits are in What was not read.

Applies to Create 6.0.10, jar create-1.21.1-6.0.10.jar, Git-Hash ac0c444d9828da3453ae8cc65338e8de063286fb, built 2026-04-21, Minecraft 1.21.1, NeoForge, as shipped in All the Mods 10 8.2. The jar's neoforge.mods.toml records mod id create and version 6.0.10.

Three stuck moments are in that jar. A fourth, a stock ticker missing an item vault when the packager is on a middle face, is not in these classes.

The gauge shows a question mark and does not send

FactoryPanelBehaviour.getCountLabelForValueBox returns the literal ? when waitingForNetwork is set and a filter is set. The class file loads the string "?" immediately after reading that field. tickStorageMonitor sets the flag when the unloaded-link count is above zero. tick runs the monitor and then tickRequests, and tickRequests returns before it sends if the flag is set.

For an ordinary gauge that count is the size of the saved list minus the size of the loaded set. A restocker gauge does not use it. A restocker reports 1 only when it has no packager behind it, and 0 otherwise.

What is saved is the total, not the loaded set. LogisticsNetwork.write writes totalLinks under the NBT key Links. Each entry is Pos, plus Dim when the dimension is not the overworld. The saved-data name is create_logistics. loadedLinks is not among the keys that method writes.

linkAdded puts the position in the saved list and marks the data dirty. linkLoaded puts it in the loaded set only. linkRemoved takes it out of both and marks the data dirty. linkInvalidated, which runs when the linked behaviour unloads, takes the position out of the loaded set only and does not mark the data dirty. The saved position stays.

Every gauge on a frequency shows ? and sends nothing while any saved link position on that frequency is not loaded. After a restart every saved position counts as unloaded until its block entity initializes. A position that remains in the saved list after the block is gone stays unloaded, and the gauges stay on ?.

Sources: Create 6.0.10 FactoryPanelBehaviour (getCountLabelForValueBox, tickStorageMonitor, tick, tickRequests), GlobalLogisticsManager.getUnloadedLinkCount, LogisticsNetwork.write, linkAdded, linkLoaded, linkRemoved, linkInvalidated.

Redstone 1 to 14 does not set priority

PackagerLinkBlock.getPower takes the highest signal on every side except the side facing the packager. That level runs from 0 to 15. The block looks powered for any signal from 1 to 15, because the powered state is only whether the level is above 0. The level itself is stored as redstonePower, NBT key Power.

Signal 15 is the off switch, in three places. keepAlive returns immediately, so the link drops out of the live cache. redstonePowerChanged removes it. getPackager returns null, so the link has no inventory.

Signals 1 to 14 are stored. The present links are sorted by that stored level, lowest first, so a lower signal would be asked first. findPackagersForRequest asks for that sorted list and discards the order. Links that have an inventory id are put in one group, and the method picks one of them with nextInt. The shipped method contains two nextInt calls and does not read redstonePower. Those groups sit in a HashMap, so the order the chosen links are tried is not the signal order either.

A link with no inventory id keeps its place in the sorted list. A packager on a real inventory has an id, read from the packager's identified inventory, so the usual stock link is in the random group. Signals 1 to 14 do not change which of those is asked. This is the 6.0.10 jar, built 21 April 2026. The behaviour reported as still broken in 6.0.9 is the behaviour this jar ships. The redstone requester is a different block and is not this path.

Sources: Create 6.0.10 PackagerLinkBlock.getPower, redstonePowerChanged, keepAlive, getPackager, getAllPresent, findPackagersForRequest.

A recipe gauge sends another order

Recipe mode is the branch of tickRequests that is not a restocker. It reads each input from the 1-tick network summary, not the 20-tick one. If any input is short, it sends nothing. If all of them are present, it sends one order of the amounts on the gauge's links, then adds one promise of the gauge's own filter, on the gauge's own network. The promise is the output item, not the ingredients. That output count defaults to 1.

It sends again when the timer reaches 0, unless the gauge is satisfied, promise-satisfied, waiting on unloaded links, or paused by redstone. Satisfied means the 20-tick summary of the output item already covers the target. Promise-satisfied means that summary plus the live promise covers it. The timer resets to the full interval when the gauge sends, and it does not count down while the promise still covers the target.

factoryGaugeTimer is 100 in the class file, and the minimum is 5. All the Mods 10 8.2 does not set it. The string factoryGaugeTimer is absent from the client overrides and from the server pack's defaultconfigs, kubejs and datapacks. At 100, the summary the satisfied check reads is stale for at most 20 ticks, and the timer is sitting at 100 before it starts counting. The summary is rebuilt before a second send. That cache does not, by itself, make a default-timer gauge send one extra batch. A timer set to 5 would.

What subtracts too much is PackagerBlockEntity.getAvailableItems. If the target inventory comes back null, or is the packager's own item handler, the method stores an empty snapshot and returns. It does not record an arrival. The next read that sees the inventory compares that empty baseline with everything now in the inventory, and submits each of those stacks as a new arrival. Those stacks are subtracted from the promise queues on adjacent restocker gauges and adjacent stock links, up to the promised count for that item. A null read between two real reads therefore subtracts the whole inventory, not the items that arrived since the previous real read. The output promise drops. The gauge no longer counts itself promise-satisfied. When the timer expires it sends another ingredient order for items it had already counted.

The class file stores that empty snapshot and later submits the arrivals. The method has no client-side check. Whether a client and a server both subtract is not claimed here.

Those two methods do the same thing for every inventory they are given. They do not read which block it is. A report that one inventory stays on target and another does not was not found in either method, so that split stays open.

Create pull request 10496, opened 10 June 2026, names this null read. It is open and not merged. This jar was built 21 April 2026, so that change is not in it.

Sources: Create 6.0.10 tickRequests, LogisticsManager.getSummaryOfNetwork, CLogistics (factoryGaugeTimer), PackagerBlockEntity.getAvailableItems, submitNewArrivals, RequestPromiseQueue.itemEnteredSystem.

A stock ticker and the middle of a vault

The stock ticker's recent summary asks for the network summary with the accurate flag off. That walk adds every live link's inventory and skips a later link that has the same inventory id. It does not read which face the packager is on.

An item vault registers its item capability on every vault block. The direction it is handed is not read. A block that is not the controller copies the controller's combined inventory and the controller's id. A middle block sits inside that box. The check is the position, not the face. The controller is the corner the vault grew from. The code does not name a corner as the upper one.

A packager on a middle block of a formed vault therefore presents the same combined inventory and the same id as a packager on the controller. Moving the packager to a corner does not change what the ticker is offered. The vault's contraption-unmount path does not decide what a stock link sees.

The report stands. This jar does not account for it.

Sources: Create 6.0.10 StockCheckingBlockEntity.getRecentSummary, ItemVaultBlockEntity, ConnectivityHandler.formMulti, ItemVaultMountedStorage.

What was not read

The classes named above were read in create-1.21.1-6.0.10.jar at that git hash, and again in the class files. Create's three nested jars, Flywheel, Ponder and Registrate, do not contain the logistics classes. A sweep of the other 463 top-level jars in the pack, and of 164 nested jars one level under META-INF, found none of findPackagersForRequest, FactoryPanelBehaviour, submitNewArrivals or LogisticallyLinkedBehaviour. The behaviour on this page is this pack's copy of Create 6.0.10.