Java Edition:Update Suppression

Warning: Corruption 

This feature can corrupt your world. Perform at your own risk.

Warning: Game Crash 

This feature can crash your game. Perform at your own risk.

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 contraption 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 chained into a suppressor without crashing the game are player updates, as they are handled through a try catch block which safely handles any exception^{[note 1]}. 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 the game crashing. A filter can be built for such events as showcased by FloppyDonkey.

Any update suppression method that uses an Error (stack overflow, out of memory) can only be performed without crashing the game in 1.4.3 and above, due to the addition of an additional try catch block that catches any Throwable from the block neighbor update process and re-throws it within a crash exception that can be caught by the packet try catch block. In 24w33a (a 1.21.2 snapshot) and above, if the crash exception catches an out of memory error, the game will not catch the exception and will crash.

Videos explaining the basics of update suppression, including subjects such as update order and safe usage:

• Xcom6000
• Sensei
• Panda4994
• Kahzerx

Methods

Stack Overflow Error

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 StackOverflowError 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 14w02a (a 1.8 snapshot). 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 block entities to track their pitch, and before 1.8, the note block directly cast all block entities fetched from its location to the note block block entity class. If a different block 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 block entity was the proper block entity.

Shulker Class Cast Exception

Using update suppression, block entities can be swapped with other block entities. By suppressing the removal of a block entity then placing another block entity in its place, the block entities can be swapped.

When comparators receive an update, they attempt to update their power level depending on the block entity they are reading. Shulker boxes specifically contain a direct cast of the block entity at their location to the Inventory interface within these methods. If the block entity fetched from the shulker box's position does not implement this interface, a ClassCastException exception will be thrown.

There are two block entities that meet the requirements of both sending comparator updates and not implementing the Inventory interface: lecterns and jukeboxes. These block 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 block 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 block 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

This section is a work in progress. 

Please help in the creation of this article by expanding or improving it.
To do: expand vibrations table to include which ones can safely be suppressed without causing a crash

Using update suppression, block entities can be swapped with other block entities. By suppressing the breaking of a sculk sensor with the sculk_sensor_phase:active block state, the block entities can be swapped. This can be done with the sculk sensor from 20w49a (a 1.17 snapshot) (sculk sensors were only first obtainable in survival in 1.19 Deep Dark Experimental Snapshot 1) to 1.21 and the calibrated sculk sensor from 23w12a (a 1.20 snapshot) to 1.21.

To swap the sculk sensor block entity, construct the setup below and break the sculk sensor while it has the active block state. A good hoe (e.g. diamond hoe with Efficiency 5) to break the sculk sensor quickly is recommended.

• 

  A setup to block entity swap sculk sensors.

When any block entity other than a sculk sensor is placed into the sculk sensor's position, any vibration within range of the sculk sensor (an 8 block radius for sculk sensors, a 16 block radius for calibrated sculk sensors) will be update suppressed with an IllegalArgumentException, as the sculk sensor code attempts to fetch the sculk_sensor_phase block state from the block at its position, which is not used on any other block. Note that this occurs before the wool occlusion check, so wool cannot be used to prevent vibrations from being heard!

Using a sculk sensor as an update suppressor is extremely dangerous, as there is no way to disable it except for breaking the block entity that contains the sculk sensor, which will destroy the suppressor. It will also suppress any vibration frequency, so any vibration not explicitly produced from a player packet, several of which can be produced without player interaction, will crash the game.

It is highly recommended to use the calibrated sculk sensor variant, as with this variant it is possible to select which vibration frequencies to suppress. To do so, the block entity to be placed must have the "horizontal" facing property (the horizontal facing property has only east, north, south, and west as valid values). These block entities are:

• Banner (wall)
• Bed
• Mob head (wall)
• Signs (wall)
• Hanging Signs (wall)
• Beehive
• Bee Nest
• Blast Furnace
• Campfire
• Chest
• Chiseled Bookshelf
• Decorated Pot
• Ender Chest
• Furnace
• Lectern
• Redstone Comparator
• Smoker
• Soul Campfire
• Trapped Chest
• Vault

The suppressor can have the frequency to suppress controlled by a redstone signal provided to the block in the opposite direction of the facing value (e.g. if the block has a facing value of east, the signal must be provided on the west side). The easiest way to do so is to have a lectern with a 15 page book and a comparator power the suppressor, as the lectern and book allows for easy channel selection. No channel is perfectly safe as each has non-player triggers that can cause a crash. Safer channels include 8 and 9. 8 can cause a crash if a player, panda, wandering trader, or witch drinks or eats in range. 9 can cause a crash if redstone components deactivate or if the player closes a container in range.

• 

  A calibrated sound suppressor using a bee nest and a lectern.

Additional resources:

• Igna778 reveal video

23w13a_or_b Votes

Warning: April Fools' 

This method requires April Fools' versions and may require the use of file modifications to load. See the tutorial for information on loading these versions.

The April Fools' snapshot 23w13a_or_b introduced several methods to obtain normally unobtainable features.

• The less_interaction_updates vote, when applied, suppresses certain block updates from the player, allowing the player to make certain block configurations.

The less_interaction_updates vote suppresses any block update from the player breaking or placing blocks, although other sources of block updates (e.g. redstone) will still create block updates normally. Because of this, blocks which are affected by block updates, like sand or water, can be put into abnormal or discontinued configurations. Unlike update suppression, this works with features on the west side of blocks. No exceptions are thrown, so not everything that update suppression can be used for can be replicated with this vote.

Out Of Memory Error

When traditional update suppression was removed in 22w11a (a 1.19 snapshot), a new method was developed which utilizes the OutOfMemoryError 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 StackOverflowError instead if you're in a version before 22w11a) until 25w42a (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 BUD powered pistons or noteblocks to schedule enough sync block events to cause the list to upsize and throw 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.

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 and throw 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.

Additional Resources

The following resources give more information on this method:

• FXPR0CESS - reveal video
• Igna778 - reveal video
• Igna778 - more details video
• Igna778's Discord

• 

  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:

• 

  A Wither Rose on Nether Bricks.

Block Entity Swap

In 1.21 and before, block entities can be swapped into other blocks using update suppression. By suppressing the removal of a block entity, it may be kept when another block is placed into its location. The update that is suppressed must be created before the block entity is removed, such as observing comparator updates, which is the primary method for block entity swapping.

Another block entity must be placed in the old block entity's location to preserve it upon reloading, otherwise the block entity will remove itself upon loading. Block entities in mismatched block entity blocks can be updated up to 1.21. In 1.21.1 Release Candidate 1 and later, block entities in mismatched block entity blocks are deleted and set to the correct block entity when loaded.

Additional resources:

• JKM - tutorial & explanation
• JKM - end gateway swap setup
• observr - end portal swap setup

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 the block entity data of an item is applied, 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 any item to be duplicated. Unlike block placement, this preserves the item's data, so duplicating a shulker box with items duplicates 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 can be utilized to duplicate references of a single ItemStack, allowing for an item to be in two or more places at once. These duplicated references also allow for item duplication in a number of ways.

Resources on performing item shadowing and utilizing shadowed items:

• Fallen Breath - information on performing item shadowing, handling shadowed items, and how to duplicate items
• FX - PR0CESS - examples of practical utilization of shadowed items with redstone

• 

  14w21a to 1.13 item shadow setup
• 

  1.14 to 1.19 Deep Dark Experimental Snapshot 1 item shadow setup

Cursor Swap

From 14w21a to 1.19 Deep Dark Experimental Snapshot 1, suppressing the direct swapping of an item with another item that it cannot stack with in the cursor can shadow items. To shadow items, create the below setup with the rail line pointing to your suppressor of choice. Place a sacrificial item that does not stack with the item to shadow into the container and another into your inventory. Either suppress the removal of the block below the comparator or open the trapdoor below the comparator to leave it floating, whichever is applicable. Open the container and place the stack which you want to shadow into the cursor, click once on the sacrificial item in the container, click once on the item in your inventory, and click on an empty slot. Close and re-open the container to fix any inventory desync that may have occurred.

Number Key Swap

From 1.12 to 1.18^[test], suppressing the usage of the number keys to insert items into an inventory from the hotbar can shadow items. To shadow items, create the below setup 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, whichever is applicable. Open the container and use the number keys to move the stack to shadow into the container. Close and re-open the container to fix any inventory desync that may have occurred.

Furnace Recipe Book

This section is a work in progress. 

Please help in the creation of this article by expanding or improving it.
To do: https://youtu.be/HSOSWHIg7Mk

Sound Suppression

This section is a work in progress. 

Please help in the creation of this article by expanding or improving it.
To do: https://youtu.be/77M8Adnxmsw

Invalid Exit Portal

When the dragon is summoned/dead, if the end portal/bedrock is suppressed, it will create an invalid end exit

It also has the side effect of replacing bedrock and end portal with endstone when summoning a dragon and causing the dragon to be "suppressed from death" when killing a dragon

Summon Dragon

When the dragon is summoned, the exit portal will be updated in order west, north, south, east(in individual blocks). From 1.10.2 to present, when summoning a dragon, the exit portal will be processed in the following steps: replace the old structure (including bedrock blocks and end portal) with endstone, delete blocks in range, place the new structure. By suppressing the bedrock, end portal or torch in the respective directions or bedrock/end portal is inserted into another block of the gate (e.g. the bedrock replaces the end stone and is suppressed), the bedrock and end portal that have not been updated in order will turn into endstone including the blocks placed by the player within the exit portal range(all blocks with height between top bedrock and bottom endstone and in 7*7 square containing the exit portal). However that also led to the dragon summoning failing and make exit portal removal inactive. One special thing is that the torch will always be placed if there is no block occupying the space.

• 

  The exit portal is completely replaced by the end stone.

From 19w41a to present, if the suppressed block has been destroyed (e.g. the endstone or bedrock block is broken by the player and it was suppressed when summoning dragon) and this is not the first dragon summon , this will result in the dragon still being summoned while the portal is in an invalid state.(Placed end crystals will not have a summoning animation). This will result in the endstone being replaced from the south to the straight line of the suppressed block. Note that channels 12 of sound suppression will also achieve the same effect with other suppression methods

• 

  Exit portal with south turning into endstone, suppress by channels 12

Killing Dargon

After dragon has complete its death animation, game will try enable exit portal by placing blocks in rows starting from north, then removing the block that occupies the empty space within range (From 15w31a to 17w47a, game will delete blocks in range) and create end gateway. Finally game will marked dragon died, remove dargon hp bar and set DragonKiller parameter turn into 1 . If exit portal is suppressed, exit portal will become invalid state and dragon will die incorrectly. Howerver, since code change in some version, so this method not work in some version. From 15w31a^[test] to 17w47a^[test], suppressing the bedrock in the bedrock pillar will prevent the dragon from dying and the end portal will be created from the north to the line of the suppressed block. Also torch only create in the south of exit portal. However, the dragon will attempt to die, causing the exit portal to continuously regenerate, resulting in the portal returning to its normal state.(this happens because every suppression method in these versions is either in delete blocks in range scope, resulting in a crash that will then remove the budded rail connected to the suppressor, the number of crashes is based on the number of budded rails connected to the suppressor e.g. 4 CCE shulker suppressions will crash 4 times in order of exit portal update)

From 1.17 to present, if the suppressed block has been destroyed and not the top bedrock(e.g. the endstone or bedrock block is broken by the player and it was suppressed when killing dragon ), dragon will die, but will be stuck in a "dead" state and the end portal will be created from the north to the suppression block's path similar to the old version. One special thing is that because the end stone is created before the end portal, suppressing the end stone will prevent the end portal from being created. Note that channels 12 of sound suppression will also achieve the same effect with other suppression methods

From 1.14 to 1.16.5 this method does not work

• 

  Exit portal with north side fully formed, suppress by channels 12

Dragon in a "dead" state will drop xp indefinitely, fly to infinite heights and prevent new dragons from being summoned with end crystals even though it do not exist as entities. This is because DragonKiller is set to 1 when a dragon is killed, but suppressing exit portal causes this parameter to remain at 0. The simplest way to fix this is to use chunk regeneration that contains the dragon's main hitbox.

Waterlogging Falling Blocks

Update suppression 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:

• Comedy - tutorial & explanation

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

References