Java Edition:Update Suppression
Update suppression prevents block updates from being processed. This is done by throwing a Java exception before the game can process all of the updates. Not to be confused with update skipping, which uses intentional update limitations introduced by Mojang in 22w11a (a 1.19 snapshot). This has many applications, such as removing a block without updating the surrounding blocks, slicing nether portals, duplication, and item shadowing. This method is very powerful, but can be very dangerous, potentially making the world unplayable. Use update suppression with caution, and always create backups of your world.
General Information
Update suppression heavily relies on the fact that all block updates will always be processed in a certain order. This order is west, east, down, up, north, and finally south. By chaining the updates from one side of a block into a device that throws a Java exception, the remaining sides can be skipped, allowing the updates to never be processed. All sides except west may be suppressed, as the west side is the first in the update order and cannot be skipped.
The only type of update that can be safely chained into a suppressor are player updates as they are handled through a try catch block, which allows the exception to be safely handed. Before 14w21a (a 1.8 snapshot), update suppression must be done on a multiplayer server as the internal server's connection was not handled in a try catch block. This would cause any update suppression to crash the game, which can corrupt or delete the level.dat file. The player must be careful when performing update suppression on block removals when playing on a laggy server or poor connection, as the block's removal might be scheduled for a later game tick if the server believes it was mined too quickly, which results in the updates not being processed in a try catch block and crashing the game. A filter can be built for such events as showcased by FloppyDonkey.
Videos explaining the basics of update suppression, including subjects such as update order and safe usage:
Methods
Stack Overflow Exception
From the earliest versions[1][2] of Java Edition to 1.19 Deep Dark Experimental Snapshot 1, all block updates were handled with recursive methods. As more and more blocks are updated at once, the Java stack size will increase linearly with each block updated. If this stack exceeds the Java stack limit (the Java stack limit can vary from operating system, Java version, Java flags, hardware, etc.), a StackOverflowException will be thrown.
In 22w11a (a 1.19 snapshot), the recursive update stack was replaced with a queue[3][4], which avoids recursive function calls which patches this method.
This method can be accomplished by updating 2,000-3,000 blocks at once, though this can be lowered by changing the -Xss Java flag which determines the maximum size of the Java stack. The smallest this Java flag can be set to is -Xss160k, which reduces the blocks needed down to only a few hundred. One of the easiest methods is chaining signs or banners off of each other, attached to the block that is being suppressed. Although the signs and banners will drop once broken, they have to be placed back again making this a one-time use. Reusable suppressors typically use BUD powered rails, which can both chain the updates into the suppressor and do the actual suppressing.
Other reusable designs utilize unintentional recursive feedback loops.
Subtract Mode Comparator
When the instant tile ticks flag is enabled, comparators will instantly process their updates. When a subtract mode comparator's output loops into its input and receives a block update, the comparator will process itself continually until suppression.
BUD Powered Dispenser
When the instant tile ticks flag is enabled, dispensers will instantly process their updates. This can be abused by updating a BUD powered dispenser containing either a water or lava bucket. Dispensers do not set themselves as powered until after the liquid has been placed and the updates from that placement finish processing, so once the liquid is placed for the first time, it updates the dispenser again which triggers another fluid placement, which will repeat until suppression occurs.
Trapdoor Dust Loop
An oversight in the 1.16 trapdoor code with redstone dust redirection allows for the creation of an update feedback loop. This method works from 20w18a (a 1.16 snapshot) to 1.19 Deep Dark Experimental Snapshot 1, but it can also be used as an update skipper until 1.20 Pre-release 1.
Some examples of reusable designs:
- Xcom6000 (rail based)
- FloppyDonkey (rail based)
- Sensei (rail based)
- LuisitoLapapa (trapdoor dust loop based)
A banner based suppressor (one time use).
A rail based suppressor.
An instant tile tick based suppressor using a subtract mode comparator.
An instant tile tick based suppressor using a BUD powered dispenser.
A trapdoor dust loop based suppressor.
Six Sided Piston
Six Sided Pistons are pistons with a data value of 6, 7, 14, and 15 those with a data value of 6 and 14 are especially dangerous. These are created through block transmutation, this method works from Beta 1.7 until they are removed in 14w02a (a 1.8 snapshot). Data value 6 pistons, when powered throw an ArrayOutOfBoundsException upon receiving an update, and data value 14 pistons will throw the exception regardless of whether it is powered or not.
Data value 6 pistons will sometimes check if they are receiving direct power upon being loaded from the disk, if the piston realizes that its hard powered when loaded, it can result in a crash loop until they are removed in 14w02a (a 1.8 snapshot)[test]. This can be prevented by BUD powering the piston, this will allow the block updates to throw the exception, but will not potentially cause a crash loop.
A BUD powered, data value 6 piston.
Note Block Class Cast Exception
Before 1.13, note blocks used tile entities to track their pitch, and before 1.8, the note block directly cast all tile entities fetched from its location to the note block tile entity class. If a different tile entity was swapped into the note block, it would throw a ClassCastException. This was fixed in 14w29a (a 1.8 snapshot) to check that the fetched tile entity was the proper tile entity.
Shulker Class Cast Exception
Using update suppression, tile entities can be swapped with other tile entities. By suppressing the removal of a tile entity then placing another tile entity in its place, the tile entities can be swapped.
When comparators receive an update, they attempt to update their power level depending on the tile entity they are reading. Shulker boxes specifically contain a direct cast of the tile entity at their location to the Inventory interface within these methods. If the tile entity fetched from the shulker box's position does not implement this interface, a ClassCastException exception will be thrown.
There are two tile entities that meet the requirements of both sending comparator updates and not implementing the Inventory interface: lecterns and jukeboxes. These tile entities also do not intuitively send comparator updates in many versions, so be sure to see the tutorial videos below for your specific version. By suppressing their removal and placing a shulker box at their previous location, the shulker box will then contain a tile entity that does not implement the Inventory interface. This suppressor can be disabled by hard powering a solid block between the shulker box and the comparator, as the comparator will read a signal strength of 15 which prevents the comparator from attempting to read the shulker box's fill level.
This method can help overcome the removal of recursive block update suppression as it can be created prior to when recursive suppression was patched, allowing one to maintain an easy to use suppressor in 1.19 and above. This method works from 16w39a (a 1.11 snapshot) to 23w33a (a 1.20.2 snapshot).
Additional resources:
- Igna778 - reveal video
- Captain_S0L0 - tutorial for 1.11 to 1.12
- Captain_S0L0 - tutorial for 1.13
- Captain_S0L0 - tutorial for 1.14 to 1.16
- Captain_S0L0 - tutorial for 1.17 to 1.20
Lectern tile entity preservation setup.
Updates chained to the comparator are suppressed.
Lever/Button & Shulker Box Null Pointer Exception
In 17w18a (a 1.12 snapshot), when a lever or button (wooden or stone) is updated when placed above a shulker, a NullPointerException exception will be thrown[5]. Any updates chained into the lever or button will be suppressed. Toggling the lever or button will also throw the exception, but not in a useful manner.
A lever above a shulker.
Sound Suppression
To do: https://youtu.be/77M8Adnxmsw
23w13a_or_b's less_interaction_updates Vote
In the April Fools' version 23w13a_or_b the less_interaction_updates vote results in an effect that is similar to update suppression. Any block updates that would be produced from the player placing or breaking blocks are ignored while this vote is active. Other sources of updates (like redstone) still process their updates as they normally do. Do note that no actual errors are thrown, so this can not be used to swap block entities, create shadow items, or duplicate items. However, it can still create many discontinued block configurations, including those on the west side of blocks which normal update suppressors are unable to do.
Out Of Memory Exception
When traditional update suppression was removed in 22w11a (a 1.19 snapshot), a new method was developed which utilizes the OutOfMemoryException exception. This method is tricky to use as it requires filling up the game's Random Access Memory (RAM) to a very specific amount to allow the upsizing of a Set or HashSet to cause the Java Virtual Machine to be completely out of RAM, throwing the exception. This can be accomplished in two ways: either using the synced block event queue or the server entity manager's various trackers.
These methods work from at least 22w11a (PLEASE use StackOverflowException instead if you're in a version before 22w11a) until 24w38a (present), but they are particularly tricky as everyone's world will most likely need different contraptions to fill RAM to the proper amount.
Synced Block Event Queue
The synced block event queue is used to ensure some blocks have consistent update orders. These scheduled events are usually ticked and discarded quickly, but by triggering pistons or noteblocks that are within border chunks, those events will not tick and will remain in the queue. This mechanic is used to bring the list to the brink of upsizing without having to trigger all the necessary block events from the suppressor BUD line.
The suppressor BUD line must run through two high data chunks, utilized to fill the majority of the game's RAM. The amount of data required in these chunks will vary from setup to setup and will have to be determined experimentally. The data required should be roughly split between the two chunks and the two chunks should not be within render distance of each other, as loading both at the same time in normal gameplay would likely cause the game to crash. At the end of the suppressor BUD line, several floating comparators are updated as they handle updates through a necessary try catch block. The floating comparators must update a handful of pistons to schedule enough sync block events to cause the list to upsize, throwing the exception.
The table below provides the values where the set upsizes and how much RAM is necessary for each, or in other words, you need to have less than Y bytes available when the upsize occurs at X entries to throw the exception.
| Block Event Upsize Values | ||
|---|---|---|
| Resize Value | RAM needed (<32 GB allocated) | RAM needed (>=32 GB allocated) |
| 0 | 192 bytes | 256 bytes |
| 13 | 384 bytes | 512 bytes |
| 25 | 768 bytes | 1.0 kilobytes |
| 49 | 1.5 kilobytes | 2.0 kilobytes |
| 97 | 3.0 kilobytes | 4.0 kilobytes |
| 193 | 6.0 kilobytes | 8.0 kilobytes |
| 385 | 12.0 kilobytes | 16.0 kilobytes |
| 769 | 24.0 kilobytes | 32.0 kilobytes |
| 1,537 | 48.0 kilobytes | 64.0 kilobytes |
| 3,073 | 96.0 kilobytes | 128.0 kilobytes |
| 6,145 | 192.0 kilobytes | 256.0 kilobytes |
| 12,289 | 384.0 kilobytes | 512.0 kilobytes |
| 24,577 | 768.0 kilobytes | 1.0 megabytes |
| 49,153 | 1.5 megabytes | 2.0 megabytes |
| 98,305 | 3.0 megabytes | 4.0 megabytes |
| 196,609 | 6.0 megabytes | 8.0 megabytes |
| 393,217 | 12.0 megabytes | 16.0 megabytes |
| 786,433 | 24.0 megabytes | 32.0 megabytes |
| 1,572,865 | 48.0 megabytes | 64.0 megabytes |
| 3,145,729 | 96.0 megabytes | 128.0 megabytes |
| 6,291,457 | 192.0 megabytes | 256.0 megabytes |
| 12,582,913 | 384.0 megabytes | 512.0 megabytes |
| 25,165,826 | 768.0 megabytes | 1.0 gigabytes |
| 50,331,651 | 1.5 gigabytes | 2.0 gigabytes |
| 100,663,301 | 3.0 gigabytes | 4.0 gigabytes |
| 201,326,601 | 6.0 gigabytes | 8.0 gigabytes |
| 402,653,201 | 12.0 gigabytes | 16.0 gigabytes |
| 805,306,401 | IllegalArgumentException thrown | |
Server Entity Manager
The server entity manager contains 4 hashsets used for keeping track of loaded entities. Whenever an entity is loaded, the game will add its information to these sets. Entities can be loaded however one likes to fill the set, but its highly recommended to place these entities within border chunks. This will prevent them from being ticked by the game, greatly improving performance and allowing one to load potentially millions of entities at once.
The suppressor BUD line must run through two high data chunks, utilized to fill the majority of the game's RAM. The amount of data required in these chunks will vary from setup to setup and will have to be determined experimentally. The data required should be roughly split between the two chunks and the two chunks should not be within render distance of each other, as loading both at the same time in normal gameplay would likely cause the game to crash. At the end of the suppressor BUD line, a BUD powered trapdoor is opened which allows a precise amount of support blocks (like signs) to be broken off resulting in item entities, bringing the set close of upsizing. This buffer is necessary to accommodate any normal entities that can load into the world normally before performing suppression. Lastly, BUD powered TNT underneath the rails is updated, causing the entity lists to upsize, throwing the exception.
The table below provides the values where the sets upsize and how much RAM is necessary for each, or in other words, you need to have less than Y bytes available when the upsize occurs at X entries to throw the exception.
| Entity Upsize Values | ||
|---|---|---|
| Resize Value | RAM needed (<32 GB allocated) | RAM needed (>=32 GB allocated) |
| 0 | 384 bytes | 576 bytes |
| 13 | 768 bytes | 1.1 kilobytes |
| 25 | 1.5 kilobytes | 2.3 kilobytes |
| 49 | 3.0 kilobytes | 4.5 kilobytes |
| 97 | 6.0 kilobytes | 9.0 kilobytes |
| 193 | 12.0 kilobytes | 18.0 kilobytes |
| 385 | 24.0 kilobytes | 36.0 kilobytes |
| 769 | 48.0 kilobytes | 72.0 kilobytes |
| 1,537 | 96.0 kilobytes | 144.0 kilobytes |
| 3,073 | 192.0 kilobytes | 288.0 kilobytes |
| 6,145 | 384.0 kilobytes | 576.0 kilobytes |
| 12,289 | 768.0 kilobytes | 1.1 megabytes |
| 24,577 | 1.5 megabytes | 2.3 megabytes |
| 49,153 | 3.0 megabytes | 4.5 megabytes |
| 98,305 | 6.0 megabytes | 9.0 megabytes |
| 196,609 | 12.0 megabytes | 18.0 megabytes |
| 393,217 | 24.0 megabytes | 36.0 megabytes |
| 786,433 | 48.0 megabytes | 72.0 megabytes |
| 1,572,865 | 96.0 megabytes | 144.0 megabytes |
| 3,145,729 | 192.0 megabytes | 288.0 megabytes |
| 6,291,457 | 384.0 megabytes | 576.0 megabytes |
| 12,582,913 | 768.0 megabytes | 1.1 gigabytes |
| 25,165,826 | 1.5 gigabytes | 2.3 gigabytes |
| 50,331,651 | 3.0 gigabytes | 4.5 gigabytes |
| 100,663,301 | 6.0 gigabytes | 9.0 gigabytes |
| 201,326,601 | 12.0 gigabytes | 18.0 gigabytes |
| 402,653,201 | 24.0 gigabytes | 36.0 gigabytes |
| 805,306,401 | IllegalArgumentException thrown | |
Additional Resources
The following resources give more information on this method:
A simplified chunk overview of the BUD line setup.
The relation between the sync update list and the RAM it uses, by Igna778.
Uses
Alternative Discontinued Feature Methods
Update suppression can be used as an alternative to obtain discontinued block configurations. Any block with placement restrictions, such as support blocks or those only placeable on certain blocks, can have their restrictions bypassed by suppressing the removal of its supporter block and the placement of the invalid block. An example of this would be getting a Wither Rose on Nether Bricks as they are not normally able to be placed on Nether Bricks. This list includes, but is not limited to:
- Block Replacement Bypass
- Cactus Next to Invalid Block
- Concrete Powder Next to Any Waterlogged Block
- End Portal in the Nether
- Floating Gravity Block
- Floating Nether Sprout
- Floating Pointed Dripstone
- Flowing Lava on Top of Soul Soil and Adjacent to Blue Ice
- Full Block Chest
- Half Bed
- Half Door
- Half Double Chest
- Half Double Plant
- Invalid Block on End Portal Frame
- Invalid Flowing Liquids
- Invalid Nether Portal Configuration
- Invalid State Grass Block
- Moving Piston
- No Bubble Column on Soul Sand/Magma Block
- Occupied Bed
- Open Barrel
- Permanently Powered Lightning Rod
- Permanently Powered Target
- Plants Touching Liquids
- Short Lava Stream in the Nether
- Spawner with Chest Data
- Sugar Cane on Any Block
- Unconnected Chorus Plant
- Unconnected Dripleaf Stem
- Underwater Torch
- Vine on Invalid Block
A Wither Rose on Nether Bricks.
Tile Entity Swap
Using update suppression, tile entities can be swapped into other blocks. This occurs because comparator updates are sent before the tile entity is removed. By suppressing the removal of a tile entity, it may be kept when another block is placed into its location, such as creating a cactus with an inventory. Only tile entities that send comparator updates can be swapped due to normal block updates being sent after the tile entity is removed.
Another tile entity must be placed in the old tile entity's location if one wishes to preserve it upon reloading, otherwise the tile entity will remove itself upon loading if a non-tile entity block is in its location. Tile entities in invalid tile entity blocks can be updated up to 1.21. In 1.21.1 Release Candidate 1 and later, tile entities in invalid tile entity blocks are corrected when they're loaded.
- Banner
- Barrel
- Beacon
- Beds
- Bee Nest
- Beehive
- Bell
- Blast Furnace
- Brewing Stand
- Campfires
- Chest
- Command Blocks
- Comparator
- Conduit
- Dispenser
- Dropper
- Enchanting Table
- End Gateway
- End Portal
- Ender Chest
- Furnace
- Hopper
- Jigsaw Block
- Jukebox
- Lectern
- Shulker Boxes
- Signs
- Skulls
- Smoker
- Spawner
- Structure Block
- Trapped Chest
Additional resources:
Duplication
When a player places a block, all updates are processed before the block is removed from the player's inventory. If an exception is thrown while the game is processing the updates from placement, the code to remove the item from the player's inventory will not be called, allowing blocks to be duplicated. Suppression occurs before tile entity loading occurs, so placing shulker boxes will not duplicate the contents.
When a player places an item into an item frame, if a floating comparator is updated behind the item frame and the update is suppressed, the code to remove the item from the player's inventory is skipped, allowing for items to be duplicated. This does preserve item data, so duplicating shulker boxes with items will duplicate the contents as well.
A setup that suppresses comparator updates from an item frame.
Item Shadowing
From 14w21a (a 1.8 snapshot) to 1.19 Deep Dark Experimental Snapshot 1, update suppression could be utilized to duplicate references of a single ItemStack, allowing for an item to be in two places at once. This could be used for many things, some examples include creating automatically repairing tools by having a player with an instance of a tool with Mending AFK at an XP farm, or automatically siphoning resources to your base as you mine them. These duplicated references also allow for item duplication in a number of ways.
From 1.8 to 1.11, the only inventory manipulation method which preserved the ItemStack reference was the direct swapping of an item with another item that it cannot stack with in the cursor. To shadow items create the below setup, with the rail line pointing to your suppressor of choice. Place a sacrifice item into the container and another into your inventory, then suppress the removal of the block below the comparator to leave it floating. Open the container and take out the stack which you want to shadow, click once on the sacrifice item in the container, click once on the item in your inventory, click on an empty slot, then close and re-open the container.
1.8-1.11 item shadow setup example
From 1.12 to 1.17, the slotClick was rewritten and allowed for number key swapping to preserve ItemStack references, this is used to split the references. To shadow items create one of the below setups, with the rail line pointing to your suppressor of choice. Either suppress the removal of the block below the comparator, or open the trapdoor below the comparator to leave it floating. Open the container and number key the stack you wish to shadow into the container, then close and re-open the container.
1.12-1.13 item shadow setup example
1.14-1.17 item shadow setup example
From 1.18 to 1.19 Deep Dark Experimental Snapshot 1, number key swapping was patched to prevent item shadowing, so the direct swapping on an item with another item it cannot stack with must be used to split the references. The shadow items create the below setup, with the rail line pointing to your suppressor of choice. Place a sacrifice item into the container and another into your inventory, then open the trapdoor below the comparator to leave it floating. Open the trapdoor below the comparator to leave it floating. Open the container and take out the stack which you want to shadow, click once on the sacrifice item in the container, click once on the item in your inventory, click on an empty slot, then close and re-open the container.
1.18 item shadow setup example
To do: https://youtu.be/HSOSWHIg7Mk
Examples and resource on creating, utilizing, and duplicating with item shadowing:
- Fallen Breath - lots of information on handling shadowed items
- FX - PR0CESS - practical utilization of shadowed items with redstone
Waterlogging Falling Blocks
Update suppression can can be used on falling blocks to obtain that falling block with its waterlogged state. When falling blocks land in water, if they are waterloggable, the falling block will set itself to waterlogged for a brief moment as it places itself into the world. If the updates from that placement are suppressed then the falling block may be recovered, but as its waterlogged variant. This can be performed on falling blocks obtained from any falling block in 1.12.
These falling blocks can be used in 24w19a (a 1.21 snapshot) or above for water in the nether.
Additional resources:
Population Suppression
Update suppression can be applied to world generation. This can be used to toggle hidden and extremely powerful game flags which allow the player to access many unique mechanics and asynchronous exploits.
See also
- Update Skipping
- Chunk Savestating
- Chunk Regeneration
- Parallel Asynchronous Threads
- Population Suppression
Notes
- ↑ Prior to 1.17, comparators did not have complete update code for jukeboxes, so workarounds need to be used to allow jukeboxes to be tile entity swapped. From 1.5 to 1.12.2, the player must suppress the insertion of a music disk into the jukebox: this prevents the tile entities cashed block state from being cleared which allows another check when breaking the jukebox to produce comparator updates. From 1.13 to 1.16.5, the player must directly replace the jukebox with a non-air block to allow comparator updates to occur when breaking, which can only be done by generating a Nether portal (directly replaces the jukebox with obsidian). Nether portal placement can only be suppressed without crashing on a multiplayer connection. End portals can only be used to swap a jukebox into an end portal as end portals cannot be removed in a way that preserves the jukebox tile entity.
- ↑ Prior to 1.17, comparators did not have complete update code for lecterns, so workarounds need to be used to allow lecterns to be tile entity swapped. The player must place a book with 2 or more pages into the lectern then suppress the block updates from the block location below the lectern which receives updates upon the lectern switching to its powered state when turning the books pages. This will produce a permanently powered lectern which allows for updates to be provided again to the block location below the lectern upon breaking the lectern in the correct phase of block breaking to preserve the lectern tile entity.