This is a essay I wrote. It is about why block updates should stay. Please state your views on this, and if you think the bud should be removed, explain why*.
*This is so I can prove you wrong and make you look stupid. (JK)
Have you ever experienced a well-known, established behavior suddenly disappear? The hours, days, weeks of time invested in a creation, suddenly for naught? This is how thousands of Minecrafters would feel – are feeling – because block updates (a core Minecraft behavior) are being changed. By writing this, I hope to show why BUD switches, and also just block updates, are critical to Minecraft gameplay. I will also cover many of the circuits that break by this almost useless change. I would cover all circuits, but then this short essay would be over 9000 pages.
If you have no idea what a block update is, then you should read this paragraph. Block updates are a by-product of Minecraft’s use of a lazy-update system. If you are reading update as in software update, that may cause confusion. In this case, it means an in-software state alert. The block update serves to tell blocks that are in illegal states to fix their state, which is a common method when there are too many objects to update every one every tick (1/20th of a second). A block update detector is a system that can be used to detect block updates.
The core principle of a block update detector switch (abbreviated BUD switch or BUD) is simple: detect when a neighbor block changes state, and then emit a signal, usually redstone. The most common designs rely on piston Quasiconnectivity (Literally meaning false connectivity). This is a principle of pistons that allow them to be powered diagonally above them and two blocks above them, but the piston doesn’t immediately realize it is powered. When that piston perceives a block update, it realizes it is powered and extends. This is usually used by having it put a block over a torch, to give a signal, but it is sometimes used in other ways. After that, it typically turns off the power, resetting the device, and then activates it so it is in the false state again. The BUD switch can be triggered in almost any way, but especially placing and breaking blocks, opening or closing doors, trapdoors, or fence gates, redstone ore activating or deactivating, tilling land, planting crops, crops growing, and almost any other thing that involves a block changing its state. (The main exceptions are pistons extending, and trees growing, though trees only fail to trigger water-based buds.) Unfortunately, in 1.5, BUD switches are broken. Piston Quasiconnectivity still exists, and the piston still doesn’t detect the change of state. So what breaks BUD switches? The answer is that block updates themselves are gone. Even if a BUD block were added, it would be almost useless without the concept of block updates. This change could be compared to the beta 1.6 update. (In this update, if you don’t know, removed the old type of minecart boosters and added the booster rails). However, unlike 1.6, which offered the powered rail as a replacement, 1.5 doesn’t provide a replacement for the broken functionality. You would think that the removal of BUD switches would only cause pains to devices that use BUD switches, and anything else that would be broken would be easy to fix, but then you would be WRONG.
An amount of devices to long to list are broken by this unnecessary change. What is added in 1.5 is definitely cool, but it will be useless if the current behavior is not returned. Most 4by4 piston doors are broken and, it would be near-impossible to make a 5by5. The epic 11by8 (8-tall) piston door, by a youtuber named magavara2 and viewable at, requires many of the principles of BUD, and quite complex, and therefore would be IMPOSIBLE to rebuild without block updates. Often, bussing (wiring that only serves to connect) uses the block update principle. As in it has a piston facing downward with a fence gate (sometimes a lamp) to update the piston and send a downward signal. More non-obvious thing broken: Etho’s record player lights, a really cool invention that shows weather there is a disk in a jukebox using block updates. And jukebox traps. Redstone Ore doors. The old day-night sensors. (The one that detect grass, used in some custom maps, so there is some reason to keep them even though we have a day-night sensor block). Furnace based timers. Door traps. 1by1 pixel displays. And what benefit does this change have?
The removal of block updates does almost NOTHING to improve Minecraft gameplay. It may have been intended to reduce lag, but how much lag is caused by 6 block updates? I doubt there will be any FPS increase, certainly not a noticeable one. However, there may be some issues with Block Updates. One possible problem is that sometimes Quasiconnectivity confuses newer players. One solution – and I do not encourage any of these changes, they are just if the old method can’t be returned – is to add a new type of piston without Quasiconnectivity. Give it the old crafting recipe, but a new block ID (leave the old piston with its old ID). The old piston can have a new recipe, such as using quartz and gold. Another problem is that it might cause lag. In response, I ask: How much? Does it seem that there will be a FPS increase if 6 calls to the update() function are removed? Most blocks just ignore it anyway. And now for some more general solutions.
I have some solutions other than the previously mentioned piston one. These are not the most optimal solutions, and I will point out the problems with them. One of them is a fake update system. In this, Pistons are alerted every tick and they check for neighbor block state changes. If so, the piston extends, but otherwise, it does not “realize” that it is in an improper state. I personally think this is dangerous, because if you have a superflat world made out pistons, then you have, per chunk, 256 pistons per layer. If it is a full world, that it 65536 pistons per chunk, and there are about 400 chunks loaded at a time. Another option is to add blocks that preform all of the broken functions. There are three problems with this, though. 1, there are too many things broken to add blocks for these purposes, and also, I doubt any advanced users will be happy to have the time invested in making a giant door to become obsolete to a block that preforms the same purpose. (The third point is that some designs are infinitely expandable, but I doubt that it is possible to make a block that is both one position and infinite). The best solution is to re-add block updates.
In conclusion, BUD switches are crucial to Minecraft gameplay. Out of all of the recent changes, I think this will affect redstone the most, not the change of analog redstone. I feel the new content will be interesting and useful, but I probably won’t update, because too many of my constructions will be broken. I would like to end this with a quote from Mumbo Jambo (A YouTuber): “Just because the BUD was a mistake doesn’t mean its negative. If we go back in time a bit, the discovery of penicillin was a complete and utter mistake. It was discovered because the guy had a messy laboratory. However it was one of the biggest advances in modern medical history.”
One final thing to note: Piston quasiconectivity has not been removed, but trapdoors and fence-gate updates have. So most of the subtle but practical uses are gone, but the obvious, weirdish uses are not.
They never intended for the BUD to be removed; they say it might be broken due to the changes they will do to Redstone. And with all the snapshots raking in the coming months, the BUD still exists as far as I know.
They never intended for the BUD to be removed; they say it might be broken due to the changes they will do to Redstone. And with all the snapshots raking in the coming months, the BUD still exists as far as I know.
The bud isn't broken, but this is why it shouldn't be broken. And in a way the more useful aspects of piston quasiconectivity have been taken away. The use of trapdoors means that they can be used to update pistons. And a BUD block would make this imposible.
The bud isn't broken, but this is why it shouldn't be broken. And in a way the more useful aspects of piston quasiconectivity have been taken away. The use of trapdoors means that they can be used to update pistons. And a BUD block would make this imposible.
So this would be more persuasive if I removed some persuasion? I think it is both.
YOu don't seem to understand that Mojang does note intend to remove this 'feature'. And never did. As has been stated they said they would only add a BUD block IF they accidentally broken BUD switches while adding the new redstone features. But they didn't so they aren't going to add a BUD block. So your entire wall of text is rather pointless. This is like walking into a store and explaining they should continue to offer X service when they didn't plan on doing away with said service.
Rollback Post to RevisionRollBack
Humanity is the creation of Logic and Emotion, Calculation and Imagination, Cold Analysis and Blind Faith. This is why I believe it is a strange Human that would prize one while shunning the other. For a calculator can do math just as well as you, but a calculator can not use math to make the world a better place.
Why do you think block updates are being removed? Where did you read/hear that?
This.
Not sure what OP is on about. If block updates were removed then water wouldn't spread, redstone dust wouldn't power, doors would split in two when opened, and the game would be fairly well broken. I don't think that's something Mojang has planned.
If I understand correctly, piston BUDs work precisely because they DON'T receive a timely block update that should cause them to react right away.
I think piston quasi-connectivity should go for the same reason as the old boosters: It's bizarre and deserves a proper implementation.
Piston quasiconnectivity stops an ingenious vertical transmission method: alternating sticky piston, Redstone block, and air. I would support removal of piston quasiconnectivity and implementation of a new BUD block.
YOu don't seem to understand that Mojang does note intend to remove this 'feature'. And never did. As has been stated they said they would only add a BUD block IF they accidentally broken BUD switches while adding the new redstone features. But they didn't so they aren't going to add a BUD block. So your entire wall of text is rather pointless. This is like walking into a store and explaining they should continue to offer X service when they didn't plan on doing away with said service.
True, but if you like service X and you don't want it removed, it still is logical to provide additional reasons why, right?
Why do you think block updates are being removed? Where did you read/hear that?
The block update is not fully removed, but many thing no longer emit it. For instance, trapdoors and fence gates. Meaning I can no longer build a display like this:
And I can tell I am not the only one woed about this, cubehamster's snapshot video shows the pros and cons.
Not sure what OP is on about. If block updates were removed then water wouldn't spread, redstone dust wouldn't power, doors would split in two when opened, and the game would be fairly well broken. I don't think that's something Mojang has planned.
If I understand correctly, piston BUDs work precisely because they DON'T receive a timely block update that should cause them to react right away.
I think piston quasi-connectivity should go for the same reason as the old boosters: It's bizarre and deserves a proper implementation.
I tought Mojang isn't planning removing them and promised to make a BUD block if it accidentally happens? Yeah, good essay but kind of pointless since no one even wants them to be removed?
Yeah, it is confusing. I think I mentioned it as an example somewhere in a crevice in my wall of text. But the problem is, even a bud block would not provide a replacement for quasiconectivity, as can be seen in the video linked above.
Piston quasiconnectivity stops an ingenious vertical transmission method: alternating sticky piston, Redstone block, and air. I would support removal of piston quasiconnectivity and implementation of a new BUD block.
Half-true. I may be a genius for suggesting this repair:
(I know there is some kind of block rule, but I have no idea how to insert it)
P
R
A
D
S
...
Where P is a downward sticky piston, R is a redstone block, A is air, D is redstone dust, and s is a solid block. It could be stacked. And most cases where quasiconectivity is interfering can be solved with glowstone.
What? He said it's a big wall of text. Break it up into paragraphs.
Actually, it seems you did. But to make it easier to tell them apart, add an empty line between them like I just did.
Sorry, for some reason it was deleted from my word document. I also cant use the enter key here easily, for some reason it rejects it. I have to paste a preexisting one. However, I will try doing as you said, and also adding indents.
Penicillin is useful, but we still don't want mold growing everywhere.
The change they did make actually makes a legitimate general purpose BUD switch as impossible as a piston based one has become, but if they did implement a BUD block it would be an official feature that they would need to maintain properly.
That essay was great. I read the whole thing. Your thesis was great, and your essay well written.
Based on my knowledge of the issue, I would have to say that I agree with you. These block updates are fundimental to many of the functions of Minecraft. They are both wasting their time trying to remove/replace it, and they are making things more difficult for players by simply adding these "Bud Blocks" people are mentioning.
Because of the way Minecraft works, block updates are undeniably quintessensial to the functioning of the game. All block movements risk being effected if they change it. It's fine the way it is.
EDIT: Being a public poll, I don't feel it is efficient to your cause. Some people may be shy about their opinions, meaning they likely won't post their answers. You should make it private.
EDIT: Being a public poll, I don't feel it is efficient to your cause. Some people may be shy about their opinions, meaning they likely won't post their answers. You should make it private.
Oh, I was confused. I thought it needed to be public to set it so I could see the total votes, but if I change it now will it reset the votes?
True, but if you like service X and you don't want it removed, it still is logical to provide additional reasons why, right?
No. Because they never planned on removing the service. So you would be trying to justify keeping something that wasn't going to be removed and simply wasting everyones time.
Rollback Post to RevisionRollBack
Humanity is the creation of Logic and Emotion, Calculation and Imagination, Cold Analysis and Blind Faith. This is why I believe it is a strange Human that would prize one while shunning the other. For a calculator can do math just as well as you, but a calculator can not use math to make the world a better place.
I don't really have a horse in this race, but you seem to have put a lot of thought and effort into that essay, so I thought I would mention something you might want to address:
Quasiconnectivity (Literally meaning false connectivity).
I think you might be confusing "quasi-" with "pseudo-." The latter means "false," while the former means "resembling" or "almost." "Pseudoconnectivity" would be connectivity that is fake or not real--that is, not actually connectivity at all. "Quasiconnectivity" would be something that seems to be connectivity but isn't--or is not quite--connectivity. The truth is that there is some overlap in common usage, and it generally boils down to your intentions. For example, if you call someone a "pseudo-friend," you might have thought at one point that this person was a friend and later found out that he or she was not really a friend. On the other hand, a "quasi-friend," might be someone who is in that gray area between "acquaintance" and "actual friend."
Your intention here seems to be to point out that this is not real connectivity, so I would probably go with "pseudoconnectivity." If "quasiconnectivity" is really what you're after, though, I would change the parenthetical to "resembling connectivity" instead.
*This is so I can prove you wrong and make you look stupid. (JK)
Have you ever experienced a well-known, established behavior suddenly disappear? The hours, days, weeks of time invested in a creation, suddenly for naught? This is how thousands of Minecrafters would feel – are feeling – because block updates (a core Minecraft behavior) are being changed. By writing this, I hope to show why BUD switches, and also just block updates, are critical to Minecraft gameplay. I will also cover many of the circuits that break by this almost useless change. I would cover all circuits, but then this short essay would be over 9000 pages.
If you have no idea what a block update is, then you should read this paragraph. Block updates are a by-product of Minecraft’s use of a lazy-update system. If you are reading update as in software update, that may cause confusion. In this case, it means an in-software state alert. The block update serves to tell blocks that are in illegal states to fix their state, which is a common method when there are too many objects to update every one every tick (1/20th of a second). A block update detector is a system that can be used to detect block updates.
The core principle of a block update detector switch (abbreviated BUD switch or BUD) is simple: detect when a neighbor block changes state, and then emit a signal, usually redstone. The most common designs rely on piston Quasiconnectivity (Literally meaning false connectivity). This is a principle of pistons that allow them to be powered diagonally above them and two blocks above them, but the piston doesn’t immediately realize it is powered. When that piston perceives a block update, it realizes it is powered and extends. This is usually used by having it put a block over a torch, to give a signal, but it is sometimes used in other ways. After that, it typically turns off the power, resetting the device, and then activates it so it is in the false state again. The BUD switch can be triggered in almost any way, but especially placing and breaking blocks, opening or closing doors, trapdoors, or fence gates, redstone ore activating or deactivating, tilling land, planting crops, crops growing, and almost any other thing that involves a block changing its state. (The main exceptions are pistons extending, and trees growing, though trees only fail to trigger water-based buds.) Unfortunately, in 1.5, BUD switches are broken. Piston Quasiconnectivity still exists, and the piston still doesn’t detect the change of state. So what breaks BUD switches? The answer is that block updates themselves are gone. Even if a BUD block were added, it would be almost useless without the concept of block updates. This change could be compared to the beta 1.6 update. (In this update, if you don’t know, removed the old type of minecart boosters and added the booster rails). However, unlike 1.6, which offered the powered rail as a replacement, 1.5 doesn’t provide a replacement for the broken functionality. You would think that the removal of BUD switches would only cause pains to devices that use BUD switches, and anything else that would be broken would be easy to fix, but then you would be WRONG.
An amount of devices to long to list are broken by this unnecessary change. What is added in 1.5 is definitely cool, but it will be useless if the current behavior is not returned. Most 4by4 piston doors are broken and, it would be near-impossible to make a 5by5. The epic 11by8 (8-tall) piston door, by a youtuber named magavara2 and viewable at, requires many of the principles of BUD, and quite complex, and therefore would be IMPOSIBLE to rebuild without block updates. Often, bussing (wiring that only serves to connect) uses the block update principle. As in it has a piston facing downward with a fence gate (sometimes a lamp) to update the piston and send a downward signal. More non-obvious thing broken: Etho’s record player lights, a really cool invention that shows weather there is a disk in a jukebox using block updates. And jukebox traps. Redstone Ore doors. The old day-night sensors. (The one that detect grass, used in some custom maps, so there is some reason to keep them even though we have a day-night sensor block). Furnace based timers. Door traps. 1by1 pixel displays. And what benefit does this change have?
The removal of block updates does almost NOTHING to improve Minecraft gameplay. It may have been intended to reduce lag, but how much lag is caused by 6 block updates? I doubt there will be any FPS increase, certainly not a noticeable one. However, there may be some issues with Block Updates. One possible problem is that sometimes Quasiconnectivity confuses newer players. One solution – and I do not encourage any of these changes, they are just if the old method can’t be returned – is to add a new type of piston without Quasiconnectivity. Give it the old crafting recipe, but a new block ID (leave the old piston with its old ID). The old piston can have a new recipe, such as using quartz and gold. Another problem is that it might cause lag. In response, I ask: How much? Does it seem that there will be a FPS increase if 6 calls to the update() function are removed? Most blocks just ignore it anyway. And now for some more general solutions.
I have some solutions other than the previously mentioned piston one. These are not the most optimal solutions, and I will point out the problems with them. One of them is a fake update system. In this, Pistons are alerted every tick and they check for neighbor block state changes. If so, the piston extends, but otherwise, it does not “realize” that it is in an improper state. I personally think this is dangerous, because if you have a superflat world made out pistons, then you have, per chunk, 256 pistons per layer. If it is a full world, that it 65536 pistons per chunk, and there are about 400 chunks loaded at a time. Another option is to add blocks that preform all of the broken functions. There are three problems with this, though. 1, there are too many things broken to add blocks for these purposes, and also, I doubt any advanced users will be happy to have the time invested in making a giant door to become obsolete to a block that preforms the same purpose. (The third point is that some designs are infinitely expandable, but I doubt that it is possible to make a block that is both one position and infinite). The best solution is to re-add block updates.
In conclusion, BUD switches are crucial to Minecraft gameplay. Out of all of the recent changes, I think this will affect redstone the most, not the change of analog redstone. I feel the new content will be interesting and useful, but I probably won’t update, because too many of my constructions will be broken. I would like to end this with a quote from Mumbo Jambo (A YouTuber): “Just because the BUD was a mistake doesn’t mean its negative. If we go back in time a bit, the discovery of penicillin was a complete and utter mistake. It was discovered because the guy had a messy laboratory. However it was one of the biggest advances in modern medical history.”
One final thing to note: Piston quasiconectivity has not been removed, but trapdoors and fence-gate updates have. So most of the subtle but practical uses are gone, but the obvious, weirdish uses are not.
1.8 / 1.9 / 1.10 / 1.11 / 1.12 / 1.13 / 1.14 / 1.15 / 1.16 World Downloader mod maintainer
Moderator on the mojang bugtracker, and also pretty deeply involved with the protocol documentation on wiki.vg.
The bud isn't broken, but this is why it shouldn't be broken. And in a way the more useful aspects of piston quasiconectivity have been taken away. The use of trapdoors means that they can be used to update pistons. And a BUD block would make this imposible.
So this would be more persuasive if I removed some persuasion? I think it is both.
1.8 / 1.9 / 1.10 / 1.11 / 1.12 / 1.13 / 1.14 / 1.15 / 1.16 World Downloader mod maintainer
Moderator on the mojang bugtracker, and also pretty deeply involved with the protocol documentation on wiki.vg.
YOu don't seem to understand that Mojang does note intend to remove this 'feature'. And never did. As has been stated they said they would only add a BUD block IF they accidentally broken BUD switches while adding the new redstone features. But they didn't so they aren't going to add a BUD block. So your entire wall of text is rather pointless. This is like walking into a store and explaining they should continue to offer X service when they didn't plan on doing away with said service.
Not sure what OP is on about. If block updates were removed then water wouldn't spread, redstone dust wouldn't power, doors would split in two when opened, and the game would be fairly well broken. I don't think that's something Mojang has planned.
If I understand correctly, piston BUDs work precisely because they DON'T receive a timely block update that should cause them to react right away.
I think piston quasi-connectivity should go for the same reason as the old boosters: It's bizarre and deserves a proper implementation.
Mostly moved on. May check back a few times a year.
What? He said it's a big wall of text. Break it up into paragraphs.
Actually, it seems you did. But to make it easier to tell them apart, add an empty line between them like I just did.
True, but if you like service X and you don't want it removed, it still is logical to provide additional reasons why, right?
The block update is not fully removed, but many thing no longer emit it. For instance, trapdoors and fence gates. Meaning I can no longer build a display like this:
And I can tell I am not the only one woed about this, cubehamster's snapshot video shows the pros and cons.
Yeah, it is confusing. I think I mentioned it as an example somewhere in a crevice in my wall of text. But the problem is, even a bud block would not provide a replacement for quasiconectivity, as can be seen in the video linked above.
Half-true. I may be a genius for suggesting this repair:
(I know there is some kind of block rule, but I have no idea how to insert it)
P
R
A
D
S
...
Where P is a downward sticky piston, R is a redstone block, A is air, D is redstone dust, and s is a solid block. It could be stacked. And most cases where quasiconectivity is interfering can be solved with glowstone.
Then click the plus 1 button
Sorry, for some reason it was deleted from my word document. I also cant use the enter key here easily, for some reason it rejects it. I have to paste a preexisting one. However, I will try doing as you said, and also adding indents.
1.8 / 1.9 / 1.10 / 1.11 / 1.12 / 1.13 / 1.14 / 1.15 / 1.16 World Downloader mod maintainer
Moderator on the mojang bugtracker, and also pretty deeply involved with the protocol documentation on wiki.vg.
I don't think people break stuff on purpose...
They said if they broke it (by fixing other bugs) they would replace it with a block
Nobody is purposefully removing anything.
Snowey1994: There dispensers
The change they did make actually makes a legitimate general purpose BUD switch as impossible as a piston based one has become, but if they did implement a BUD block it would be an official feature that they would need to maintain properly.
ObamaMojang isn't taking yourgunsblock updates away.Based on my knowledge of the issue, I would have to say that I agree with you. These block updates are fundimental to many of the functions of Minecraft. They are both wasting their time trying to remove/replace it, and they are making things more difficult for players by simply adding these "Bud Blocks" people are mentioning.
Because of the way Minecraft works, block updates are undeniably quintessensial to the functioning of the game. All block movements risk being effected if they change it. It's fine the way it is.
EDIT: Being a public poll, I don't feel it is efficient to your cause. Some people may be shy about their opinions, meaning they likely won't post their answers. You should make it private.
Oh, I was confused. I thought it needed to be public to set it so I could see the total votes, but if I change it now will it reset the votes?
EDIT: It turns out that quasiconectivity is in active danger of being patched. See https://mojang.atlassian.net/browse/MC-108
1.8 / 1.9 / 1.10 / 1.11 / 1.12 / 1.13 / 1.14 / 1.15 / 1.16 World Downloader mod maintainer
Moderator on the mojang bugtracker, and also pretty deeply involved with the protocol documentation on wiki.vg.
No. Because they never planned on removing the service. So you would be trying to justify keeping something that wasn't going to be removed and simply wasting everyones time.
I think you might be confusing "quasi-" with "pseudo-." The latter means "false," while the former means "resembling" or "almost." "Pseudoconnectivity" would be connectivity that is fake or not real--that is, not actually connectivity at all. "Quasiconnectivity" would be something that seems to be connectivity but isn't--or is not quite--connectivity. The truth is that there is some overlap in common usage, and it generally boils down to your intentions. For example, if you call someone a "pseudo-friend," you might have thought at one point that this person was a friend and later found out that he or she was not really a friend. On the other hand, a "quasi-friend," might be someone who is in that gray area between "acquaintance" and "actual friend."
Your intention here seems to be to point out that this is not real connectivity, so I would probably go with "pseudoconnectivity." If "quasiconnectivity" is really what you're after, though, I would change the parenthetical to "resembling connectivity" instead.