Minecraft Wiki
Follow the Minecraft Wiki on Discord or our social media pages!
Tutorials/Update suppression
- View history
- Talk (0)
Update suppression is the practice of forcing the game to skip block updates. Update suppression has potential applications for portal slicing, block duplication, controlled crashing, and placing blocks in otherwise impossible locations, such as a sign or torch floating in mid-air, or a flower on non-dirt-based blocks.
With the changing of update order in Java Edition 22w11a, stack overflow update suppression was «fixed». This was intended as MC-249082 was resolved as «Works As Intended». Nevertheless, the change was reverted in 22w12a and a separate but related bug report, MC-249181 , showed that the «bug» was fixed in this snapshot.
Java Edition : Update Suppression
Update suppression is a very powerful method that can be used to prevent a block from receiving an update. Update suppression prevents updates by causing a Java exception before the game can process all of the updates. There are many methods of update suppression, the longest lasting of which involves causing a StackOverflowError by updating a large (
2000-3000) number of blocks in a single action. In 22w11a, the recursive update stack was replaced with a queue, which avoids the recursive function calls and removes this mechanic.
Update suppression has wide range of applications, including removing a block without updating surrounding blocks (which can allow for one to «place» blocks in invalid locations), slicing nether portals, item / block duplication, and item shadowing. Update suppression can be very dangerous and lead to a world becoming unplayable. Use with caution, and always back up before attempting to be safe.
Contents
The Mechanics of the StackOverflowError
Updates in Minecraft occured using a recursive method in Java. Recursive methods can cause a StackOverflowError if it calls itself too many times and fills the Java stack. If the game reaches this limit (this exact number differs for every computer and Java environment), then two different things can happen. On a multiplayer server, direct player updates (something directly done by a player eg. placing a block, mining a block) will catch this exception and not result in a game crash. All non-player and singleplayer updates will cause a game crash, and may lead to the deletion of the level.dat file of your world, rendering it unplayable unless the level.dat_old is used to restore it. As a result of the StackOverflowError, the update chain will be broken before all block updates have been processed, and result in blocks that should have received updates not receiving them. The order updates occur is west, east, down, up, north, and south.
The Mechanics of Other Errors
Any other exception that may be thrown during the processing of block updates (e.g. OutOfMemoryError or ArrayOutOfBoundsException) will result in the same functionality of the StackOverflowError, but just with different methods of triggering.
Set Ups
Sign / Banner Chain
Probably the lowest effort method is to make a long row of banners or signs, all supported by the west face of a block, to cause the stack overflow. The signs and banners will drop as item entities and be reusable, but one must place them again.
Budded Redstone
The budding of large amounts of redstone components can be utilized to chain enough updates together to throw a StackOverflowError. The most commonly utilized component is rails due to their ease of budding. Other components such as redstone dust or noteblocks may be used, but are generally unfavorable due to a variety of factors.
Six Sided Piston
Block transmutation allows for creating a six sided piston with data values 6 or 15. Powering them, or updating whilst quasi-powered, will throw an ArrayIndexOutOfBoundsException until 1.8 [test] . The direct powering of a data value 6 piston will result in the world being unplayable until their patch in 1.8 [test] , as upon reloading, the piston will realize it is powered. If the piston is powered with quasi-connectivity, then this will not occur.
Instant Tile Tick
Instant Scheduling alters the behavior of many redstone components, which can cause recursive update calls. Repeater, comparator, and observer clocks, dispensers, droppers, pressure plates and other contraptions can cause stack overflows from updates or changing state.
A setup with a budded subtract mode comparator that allows for easy update suppression of the obsidian block when combined with Instant Scheduling.
Support Block on Invalid Block
All support blocks can be made floating without making them break. They can also be placed on invalid blocks by replacing their supporting block.
Floating Gravity Block
Supporting blocks for gravity blocks can be removed without making them fall. These can also be replaced with block they’d normally fall into, such as tall flower.
Cactus Next to Full Block
Any full block can be placed to cactus without making it break. Cactus must be placed first because player can’t place cactus next to full block.
Invalid Flowing Liquid
Direction of liquid flow can be manipulated by removing or placing blocks where liquid could flow.
Invalid Nether Portal Configuration
Nether portals can be sliced and arranged in many ways, that’d normally break.
Non-snowy Grass Block with No Snow on Top
To make grass block have non-snowy state while there is snow on top, snow has to be adjacent to update suppressor rails, then any block must be placed next to grass block.
Half Block
Two tall or two wide blocks can have one part destroyed, without making the second half break. Then any block can be placed in the place of destroyed half.
Block Entity Swap
Using update suppression, any block entity that can be placed, can have data of almost any block entity that sends comparator signal.
Blocks Able to Be Placed
Player must place block entity and comparator that’s reading it, facing to update suppressor 1 block away from it. Then comparator must be made floating. Easiest way to do this is placing a line of banners/signs leading from comparator’s support block to rails, then support block can be broken. Then block entity can be broken, leaving it’s data at the place of this block entity. Now finally any block entity can be placed here to give it data of destroyed block.
Keep in mind that it only works for block entities, placing any other block will result in deleting block entity data after reloading.
End Portals and End Gateways
Steps to do this are simillar, with the difference being that end portals and end gateways must be generated.
- Videos on topic:
Block Duplication
If a player places a block next to update suppressor, the block item is still going to be in its inventory.
Disconnection of Duplicated Item Instance
From 1.12.2 [test] to 21w43a update suppression can be used to have one instance of an item in two places at once, which is also known as «item shadowing». This bug can be also used for duplication.
First player needs to place a comparator on a trapdoor. The comparator must be facing the update suppressor, one block away from it. Then the player can place any container for the comparator to read (except trapped chest). Then the trapdoor should be opened. Now all the player has to do is to is insert a stack into the container. After reopening it, the duplicated instance of the stack will appear in player’s inventory.
To perform the dupe, they have to be separated. The easiest way to do this for singleplayer, the player can relog. For multiplayer, the duplicated item instance can be thrown at the ground and picked up, while being careful to not merge duplicated item instances.
Videos on topic by discoverers of this bug:
Waterlogging Falling Blocks
Item Frame Dupe
From 1.12 [test] to 1.20.1 (present) an item duplication method using update suppression can be performed. After building an update suppressor player needs to place a comparator facing the update suppressor rails on top of a trapdoor. Then item frame must be placed so it’s being read by that comparator. To finish the setup trapdoor has to be opened. Now to perform the dupe player has to put an item in the item frame. The item will stay in both player’s inventory and in the item frame.
Руководство по созданию эффективного супрессора в Minecraft Bedrock: секреты и советы
В Minecraft Bedrock игроки сталкиваются с постоянными атаками враждебных существ. Супрессор – это устройство, которое помогает защитить базу от нападений мобов. В этом руководстве мы рассмотрим ключевые аспекты создания эффективного супрессора и поделимся секретами, помогающими сделать его более эффективным.
Шаг 1: Выбор места для установки
Первым шагом в создании эффективного супрессора является выбор подходящего места для его установки. Учтите следующие факторы:
- Базовая безопасность: Выберите место, где мобам будет сложнее проникнуть. В идеале, это должно быть закрытое помещение или островец, окруженный водой или пропастью. Такие места могут значительно увеличить эффективность супрессора.
- Близость к порталу: Чем ближе супрессор расположен к порталу, тем быстрее новые мобы будут попадать в зону действия устройства. Стремитесь разместить его в максимальной близости к порталу или в другом месте, где мобы часто появляются.
Шаг 2: Создание эффективного дизайна
При разработке дизайна супрессора стоит учитывать следующие моменты:
- Защита платформы: Убедитесь, что платформа супрессора достаточно защищена от мобов. Используйте стекла, заборы или другие материалы, обеспечивающие видимость и предотвращающие проникновение мобов.
- Разделение мобов: Создайте механизм, который позволяет разделить мобов по типам. Это может быть достигнуто с помощью пульта управления или использования разных зон для разных типов мобов. Таким образом, вы сможете контролировать поток мобов и устанавливать разные правила для разных видов.
- Механизмы уничтожения: Разработайте эффективные убивалки для мобов, такие как ловушки, полы с водой или ловушки с лавой. Обратите внимание на мощность и скорость работы этих устройств, чтобы убедиться, что они справятся с любым количеством нападающих мобов.
- Материалы и блоки: Используйте блоки, которые мобы не могут легко разрушить. Некоторые блоки, такие как наблюдатель или пистон, могут быть использованы для создания эффективных механизмов уничтожения или автоматической перезагрузки супрессора.
Шаг 3: Улучшение эффективности
Улучшить эффективность супрессора можно, следуя некоторым секретам и советам:
- Оптимизация потока мобов: Используйте механизмы, которые направляют мобов в определенное место убийства. Например, можно использовать воду или транспортеры, чтобы перемещать мобов к убивалкам.
- Управление искусственным светом: Засверлите отверстия в потолке супрессора и установите факелы или иные источники света, чтобы предотвратить появление мобов внутри платформы.
- Автоматическая перезагрузка: Разработайте механизм для автоматической перезагрузки супрессора после каждой волны нападений. Это поможет предотвратить перерывы в работе и сохранит его эффективность.
Заключение
Создание эффективного супрессора в Minecraft Bedrock может значительно улучшить безопасность вашей базы и помочь вам избежать постоянных нападений мобов. Следуя руководству и используя секреты и советы, вы сможете создать мощное устройство, которое будет отличным защитником вашей базы. Не забывайте экспериментировать и настраивать супрессор в соответствии с вашими потребностями и предпочтениями. Удачи в строительстве и отпугивании мобов!
Update Suppression
Update Suppression is a method of stopping the execution of certain code by intentionally causing an exception while the game is running, usually a Stack Overflow. An exception will normally cause the game to stop all processing and crash. However, if the initial action that led to the exception (including the case where an update from said action was propagated through a chain of “instant updaters” like rails, redstone dust, signs that are resting on eachother, etc.) was caused by a player input, then the exception will get caught by a try-catch statement. This means that the the updates that would have been caused otherwise do get cancelled, but the game keeps running regardless.
Updates that are not directly caused by player updates, such as the ones scheduled by redstone components with delay, from pistons moving, from mobs, randomticks, the weather, or the environment otherwise will cause a crash. These things might still have valid use-cases and applications, but are less repeatable at larger scales.
Update suppression prior to 1.19
The most common form of update suppression before the 1.19 update was to cause a Stack Overflow by overloading what’s known as the hardware function call stack. You can imagine a Russian Nesting Doll-type of situation where one block update being processed calls the block update method of the next block, which in turn calls another, which calls another, which recursively does the same until Java’s call stack no longer has space keep track of all the nested updates and throws a Stack Overflow Exception. The way this is usually done in practice is using many lines of activator rails or powered rails that are “bud-powered”, meaning that they believe they are powered when in reality they shouldn’t be, as these update (depower) in a very predictable manner. Something like redstone dust in comparison is very erratic in that it updates other blocks up to two blocks away in a mostly random order that depends on where in the world you build it (often called locationality).