Game crashes when an accelerated Extended Export Bus feeds a Trash Can

The short answer

1. Read from the jars, not run in game: the Extended Export Bus asks for far more than 99 items at once. The amount is the AE2 card value times 8 at the default multiplier: 8, 64, 256, 512 or 768 items at 0, 1, 2, 3 or 4 speed cards. Go to How much the bus moves at once.

2. Read from the jars, not run in game: two other buses can ask for as much. ExtendedAE's Precise Export Bus does, outside pulse mode, by the research's inference about the multiplier reaching it. AdvancedAE's ME Advanced IO Bus does, up to its configured amount. Go to Which buses ask for more than 99 and The Precise bus and the ME Advanced IO Bus.

3. Read from the jars, not run in game: Trash Cans 1.1.0 takes the whole stack and then cannot save it. Minecraft's save format allows a stack count of 1 to 99. Go to Why the Trash Can crashes.

4. Trash Cans 1.1.1 is reported to fix it. All the Mods 10 8.2 ships 1.1.0. The confirmation was in All the Mons, not in All the Mods 10. Go to What Trash Cans 1.1.1 changed.

The reports are in The report, the one action is in What to do, and the limits are in What is not settled.

Applies to All the Mods 10 8.2, Minecraft 1.21.1, NeoForge, with Trash Cans 1.1.0 (trashcans-1.1.0-neoforge-mc1.21.jar) ExtendedAE 1.21-2.2.38-neoforge (ExtendedAE-1.21-2.2.38-neoforge.jar) and AdvancedAE 1.6.12-1.21.1 (AdvancedAE-1.6.12-1.21.1.jar). The jars are the source. Nothing on this page was run in game.

The report

AllTheMods/ATM-10 issue 4423, [Crash]: Extended Export Bus Acceleration with Trash Cans, is open. It was created 2026-09-22 against pack 8.2 with no mods added. The reporter says an Extended Export Bus from ExtendedAE feeding a Trash Can with 4 acceleration cards crashes the game at once, and again on world load. A regular export bus is fine, also accelerated. The Extended Export Bus is fine with no cards.

A commenter quotes the log: Error saving [768 mysticalagriculture:allthemodium_essence]. Original cause: java.lang.IllegalStateException: Value must be within range [1;99]: 768. The same commenter says it also happens with a logistics network that uses a netherite upgrade, with a batch of 10000, into a Trash Can. A second comment says it should be fixed in Trash Cans 1.1.1.

The matching Trash Cans issue 58 was closed on 2026-09-25. The reporter used Trash Cans 1.1.0 in All the Mons 1.3.0 with 2 or more acceleration cards. The maintainer wrote that Minecraft 1.21 and later throws an error when saving a stack larger than 99, and that it should be fixed in Trash Cans 1.1.1. The reporter later wrote that everything works now.

The Extended Export Bus is ExtendedAE's. The only 8.2 jar that contains ex_export_bus is ExtendedAE-1.21-2.2.38-neoforge.jar. The upstream issue title says AdvancedAE, and the ATM reporter wrote ExtendedAE. AdvancedAE has its own buses, so "AdvancedAE" in an issue title may mean them. Go to The Precise bus and the ME Advanced IO Bus.

Sources: Trash Cans file, "The two issues", "Short answer".

How much the bus moves at once

The chain, each link read:

1. PartExExportBus extends AE2's ExportBusPart. It multiplies the operations per tick by EAEConfig.busSpeed, and has 8 upgrade slots.

2. AE2's IOBusPart.getOperationsPerTick() gives 1 for no cards, then 8, 32, 64 and 96 for 1, 2, 3 and 4 speed cards.

3. busSpeed is the config value device.extended_io_bus_multiplier, with a default of 8, a minimum of 2 and a maximum of 128.

4. The bus takes at most 4 speed cards.

5. For item keys the amount asked equals the operations per tick.

6. The bus then asks the neighbour's item handler to take the whole amount in one insertItem call. The stack is made with copyWithCount(amount), with no clamp to the item's stack size.

With the pack's default of 8:

The amount moved is at most what the ME network holds of that item, and at most what its energy can pay for. A network holding fewer than 99 of the item cannot push a stack over 99.

The config file is config/extendedae-common.toml. That name is read from the naming code in FML 4.0.44, not from a directory. The pack ships no ExtendedAE config file in ServerFiles-8.2.zip. A search of config/, defaultconfigs/ and kubejs/ found no setting for the multiplier. The bus id appears only in a quest item filter (config/ftbquests/quests/chapters/extended__advanced_ae.snbt). So the default of 8 applies to the shipped files. The research expects, as an inference, that the mod writes its default file on first run, and a player or server owner could edit it afterwards. At the config's minimum of 2, 4 cards give 192, which is still over 99.

A plain AE2 export bus gives at most 96 with 4 cards, which is under 99. That fits the reporter's "regular export bus, accelerated, no issues". The research did not test either.

Sources: ExtendedAE file, "Answer", "The chain", "Amount per card count", "What else caps the amount".

Which buses ask for more than 99

The Tag, Mod and Threshold buses do not override the operations-per-tick method, so they use AE2's plain table of 1, 8, 32, 64 and 96. The Threshold bus asks for the smaller of that and its maximum output. The same holds for the two AdvancedAE buses with no override. This page does not call them safe beyond "read as 96 or less".

Two things that do not change the amount, read from the jars: AdvancedAE's MixinIOBusPartInvoker only adds a way to call IOBusPart's updateState, and the AE2 Import/Export Card mod attaches its cards to terminals and to its own card items, never to a bus.

Sources: other-buses file, "Answer", "Bus by bus"; mixin and card file, "(1)", "(2)", "(3)".

The Precise bus and the ME Advanced IO Bus

Precise Export Bus. Its operations per tick are AE2's value times busSpeed, the same as the Extended bus. In normal mode it asks the network for the operations count, then pushes the largest multiple of its configured precise amount that fits into the neighbour. With 256 operations and a precise amount of 64 or less, that is at least 193 when the stock allows. At 1 card the operations are 64, so at most 64. In pulse mode it asks only for the precise amount.

Inferred: that the multiplier of 8 reaches the Precise bus follows from how Java dispatch works, and was not observed. The 64 cap on the precise amount assumes an item unit of 1, which is also inferred.

ME Advanced IO Bus. Its operations per tick are AE2's value times 8, a literal that is not configurable: 8, 64, 256, 512, 768 at 0 to 4 cards. It exports through the Stock Export Bus's work loop, which asks for the smaller of the operations and the configured amount minus the neighbour's current stock.

A Trash Can reports a current stock of 0. Its item handler has one slot, and getStackInSlot always returns an empty stack. The Trash Can jar names no appeng class, so it offers no AE2 storage capability. So the bus asks for the smaller of the operations and the configured amount, every cycle. A configured amount over 99 at 2 or more cards therefore asks for over 99.

The configured amount has no useful limit on the server. The bus's config inventory allows overstacking with no capacity set, so its per-slot maximum is Long.MAX_VALUE for items, and the server's set-amount handler applies no upper clamp. The largest amount the client screen lets a player type was not decoded.

Sources: other-buses file, "Precise bus"; mixin and card file, "(3)"; Advanced IO stock file, "Answer", "(1)", "(2)".

Why the Trash Can crashes

• TrashCanItemHandler.insertItem accepts a stack of any size. Its slot limit is Integer.MAX_VALUE. It copies the stack into a "last deleted items" list through pushDeletedItem and returns an empty stack, so the whole stack is accepted.

• pushDeletedItem joins the new stack onto the newest entry if it is the same item and components. Otherwise it adds it at the front of a list trimmed to 6 entries. Nothing caps an entry's count, so a 768 stack stays 768.

• TrashCanBlockEntity.writeData saves each deleted item with vanilla's ItemStack.save.

• In vanilla 1.21.1, ItemStack's count codec is built with ExtraCodecs.intRange(1, 99). The text "Value must be within range" is in ExtraCodecs. That matches the quoted error.

So a stack above 99 is deleted at insert time, and then the block entity cannot be saved.

Sources: Trash Cans file, "What 1.1.0 does with a stack over 99".

What to do

1. Do not feed an Extended Export Bus, or a Precise Export Bus outside pulse mode, with 2 or more speed cards, at the default multiplier, into a Trash Can. Do not feed a ME Advanced IO Bus with 2 or more speed cards and a configured amount over 99 into one. At 2 cards the Extended bus asks for 256 items in one call. The Precise bus asks for at least 193 when the stock allows, by the research's inference. The ME Advanced IO Bus asks for the smaller of 256 and its configured amount. These are over the 99 the save format allows. This is read from the jars and not tested in game.

What Trash Cans 1.1.1 changed

Read from a byte comparison of the 1.1.0 and 1.1.1 jars. 1.1.1 is not in the pack. It was read from Modrinth.

• Only two classes differ: TrashCanBlockEntity and TrashCans.

• The item handler and pushDeletedItem are byte for byte the same logic. 1.1.1 still accepts and stores a big stack in memory.

• New in TrashCanBlockEntity: a codec with the item id, a count that must be positive with no 99 cap, and components. writeData and readData now use it for the deleted-items list.

• The 1.1.1 changelog says: "Fixed crash when saving deleted items with stack size of greater than 99".

1.1.1 was published on 2026-09-25, after 8.2's jars were built. The report that it works came from All the Mons, not from All the Mods 10. The research did not install 1.1.1 into the pack, so "1.1.1 fixes it in 8.2" rests on the code comparison and that report.

Sources: Trash Cans file, "What 1.1.1 changed", "Not settled".

What is not settled