"Update suppression" no longer works
As of 22w11a, the update order has been changed from a stack to a queue.
This means update suppression no longer works, removing the ability to obtain many block states and multi-block combinations.
In the video, a stone block with a sand block on top is placed next to an update suppressor line.
When the stone is broken, the update should be suppressed and the sand should not fall. However, the sand falls.
Environment
OS: Linux Mint
Linked Issues
Created Issue:
Update Suppression No Longer Works
As of 22w11a, update suppression no longer works, removing the ability to obtain many block states and multi-block combinations.
Environment
OS: Linux Mint
As of 22w11a, update suppression no longer works, removing the ability to obtain many block states and multi-block combinations.
In the video, a stone block with a sand block on top is placed next to an update suppressor line.
When the stone is broken, the update should be suppressed and the sand should not fall. However, the sand falls.
As of 22w11a, update suppression no longer works, removing the ability to obtain many block states and multi-block combinations.
In the video, a stone block with a sand block on top is placed next to an update suppressor line.
When the stone is broken, the update should be suppressed and the sand should not fall. However, the sand falls.As of 22w11a, the update order has been changed from a stack to a queue, reversing the order in which block updates occur.
This means update suppression no longer works, removing the ability to obtain many block states and multi-block combinations. Other contraptions relying on block update order have also broken.In the video, a stone block with a sand block on top is placed next to an update suppressor line.
When the stone is broken, the update should be suppressed and the sand should not fall. However, the sand falls.
UpdateSuppression No Longer WorksUpdate Order Reversed
Are you sure that the update order was changed and that this is not just a side effect of
MC-248858?
UpdateOrderReversedUpdate order reversed / "update suppression" no longer works
Update order reversed /"update suppression" no longer works
As of 22w11a, the update order has been changed from a stack to a queue
, reversing the order in which block updates occur.
This means update suppression no longer works, removing the ability to obtain many block states and multi-block combinations.Other contraptions relying on block update order have also broken.In the video, a stone block with a sand block on top is placed next to an update suppressor line.
When the stone is broken, the update should be suppressed and the sand should not fall. However, the sand falls.
relates to
"update suppression" no longer works"Update suppression" no longer works
Update suppression was never truly a feature to begin with.
Possible dupe of
MC-248200Going by what this type of update suppression caused, this seems to be most definitely "Works as intended".
Alugia Imo no dupe of
MC-248200, andMC-248200should/could also be resolved now, if there's no stack overflow anymore.(Not tested myself ingame, just concluding, maybe ask OP of
MC-248200to test if still present.)Reversed update order / update suppression no longer working should be two distinct bugposts.
The description says that the update suppression no longer working is caused by the reversed update order, so wouldn't they be the same issue?
[Mod] ampolive Update suppression in this form was an exploit which allowed you to crash servers, whereas reversed update order changes behaviour of Redstone and hence very much indeed sounds like it could be a valid issue and thus bugpost.
Both were caused by the same change, however, they are two different, distinct consequences, caused by this change.
Update Suppression could be used to crash servers, but it is way too technical for the average player. There are much easier ways to crash servers than update suppression.
WyvernElement Seems logical anything causing servers to crash to be seen as issue, no matter the effort needed.
Update suppression was a toy opening up new possibilities, I can get where you come from.
I also dislike some changes. If it were after me e.g. bedrock breaking in full Vanilla (dragon eggs/lazy chunks) should also still be a thing, even though it's quite easy to do. I'm also all for sand duping at this point in time.
But if we continue to discuss without bringing in something substantial to your bugpost here, the moderators are going to warn us that this is not a discussion forum and might shadowban our comments.
Update supression is probably a bug yeah but its been used in the game for years.
It was treated like a mechanic by the players - as far as Im concerned its the lesser of the 2 problems.
I could see why they removed this feature any day.
What Im more concerned with is the fact that rail update order changed.
This would mean about half of our server would need rebuilding from all the instant lines and advanced contraptions that use it.
While removing update supression does not actively break anything on the server the other change does.
Rail update order is relied upon. Yet it was changed because reversing it would easily fix another thing they wanted to fix.
That other fix was only made because that would easily fix another bug caused by their rendering engine.
Now this is just lazy coding. You can keep update supression when you just properly fix the rendering engine.
You can keep the rail update order if you would just implement a lifo stack for all the blocks that need updating.
These are all actions that could have been taken to keep a block interaction as it is in a game that is based around block interactions.
As it stands the server we have probably will not update - I imagine most others that are hit by this would do the same.
Reversed rail update order is now tracked in
MC-249181.Update suppression is a block physics bug, also used as an exploit to crash servers if you just follow a step by step tutorial, no need to be an expert or to use extra client mods (also, https://xkcd.com/1172/)
Yes, it is most definitely a bug, but its removal was unannounced and not mentioned in the changelogs, not even as a private issue, so it is safe to assume that this was not intentionally fixed.
Hi,
It's important to remember how this behaviour (update suppression) works in the current release version of the game (1.18.2). By recursively performing updates, the block physics propagation code is vulnerable to a stack overflow if enough updates are performed. This is what causes the suppression to happen. While most block update code can fail at any point during its execution without corrupting the world, this is not always the case. If a chunk load were to occur, you are in monstrous trouble. I have seen crashes on Paper servers (which do try and catch the StackOverflow to prevent a total crash, but this fix is from Spigot) that have resulted from exactly that. Modded servers typically have plugins that listen and have behaviours on the block physics as well, and it is not unlikely that a stack overflow may corrupt a plugin's state. However, any logic called by the block tick is vulnerable to crash unpredictably and as such this issue has a very wide surface area of attack for a wide variety of purposes - duplication, crashing, etc. To summarize, this behaviour is dangerous and prone to cause all kinds of problems, especially on modded servers - and honestly, this should be a private issue due to that. We shouldn't be inviting this kind of attention to a bug with a scope like this.
I am glad to see that this bug is modified so that the recursive updates no longer occur. And yes it is a bug, nobody is insane enough to write recursive code like this with the intention of allowing physics to break.
The block update order can be changed with the current code to be DFS (as it is currently in 1.18.2) instead of BFS with the current code as-is (i.e by polling the last added item, rather than the oldest), without requiring recursion to take place. However a BFS update order can be optimised quite well compared to the old. But that is a discussion not meant for this specific issue.
WAI? I understand this decision, but anyways, that's sad 😥
@Spottedleaf
the order is still DFS, the stack is just on the heap, and updates from an update are collected and put on the stack, then executed. this change the order of state updates vs block updates,but not block updates themselves