Why bud switches should stay in minecraft

[Pokechu22]

In the new snapshots, BUD switches have been damaged. The following is a 5 paragraph essay I wrote, and it is kind of random. Enjoy! (Or not)

BTW, this is a draft, so if there is a issue, tell me.

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

The core principle of a block update detector 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 24by9 (9-tall) piston door, by <INSERT NAME HERE>, and viewable at <INSERT LINK HERE>, is 99% 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-lights. Furnace-traps. Furnace-Doors. (The furnace-bomb at the start of nightmare realms by Vechs). 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.

If you think I am one of those people who constantly complain without offering any advice, I have a complaint for you. (Wait, that makes me a complainer). Along with the previous possibility of two types of pistons, I have a few other suggestions. 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."

[NightKev]

Wait, they just outright removed block updates entirely? Do any mods use this feature?

I know this has ruined Amlup's Uncharted Territories 2 already :\ (as evidenced by Vechs' playthrough of it).

[freakachu]

they removed the quirky behavior that allowed a "BUD switch" to exist in the first place. I don't think anyone could argue that they made sense or were a thing that was intended, regardless of how useful they may or may not have been.

I bet this same argument was had when water ladders were removed, too.

[Pokechu22]

Block update detectors were not removed. Only the "chaining" property of block updates was removed. The addition of such principle to a game wouldn't make much sense, but 1, does much about minecraft make sense? 2,the principle is predictable and not buggy. 3, some of the most iconic things in minecraft are/were bugs. Creepers were from notch messing up pigs. And the chunk error is iconic too. This probably will not break any mods, but we can't be sure. Btw, I am using a phone rigt now, so there may be some typos. The behaivorur makes sense, but probably wasn't intended. (I would argue about watter laders, but my thumb is tired).

EDIT: And if you think they should be removed, explain the perks of doing so.

[freakachu]

buggy does not mean "inconsistent", it means it is the result of a bug. you can't tell me that behavior was planned from the get-go. there will be new wacky interactions that create odd and unexpectedly useful behaviors, I'm sure.

basically what I'm saying is, "D+ see me after class"

[Lothos]

If its only chains they removed, whats the loss? I only have ever used single block instances of BUD's myself.

[GreenWolf13]

basically what I'm saying is, "D+ see me after class"

You're too generous. I give him an F for failing to do research. If he had, he would have seen that Jeb plans on adding an actual Block Update Detector block.

[Pokechu22]

I did research, and such a block would be less useful than the current method. Things like this:

would be impossible. And as I said in the last paragraph of my essay, they definitely were accidental, but also beneficial. And yes, block updates don't chain, but that also includes to the piston. So they only detect changes of placing or breaking, and not the more subtle changes of state. And, this is partly a draft.

[Melfice]

Things like this:

would be impossible.

Is it?

Can you rig up a set-up with the Block Update Detector block that would (in theory) do the same thing as the video you linked?

[Pokechu22]

Is it?

Can you rig up a set-up with the Block Update Detector block that would (in theory) do the same thing as the video you linked?

Maybe, but it would require a flush, retractable triple piston extender, and space for the bussing. So probably not.

[CanVox]

Hey look it's a 2x2 trap door that's 1.5 compatible

[freakachu]

sounds like the OP got served

[Pokechu22]

@P is now depressed.

EDIT: How about this:

. It uses a principle of BUDS for updating pistons. And this:

is almost definitely impossible. (At least it will be if block updates are fully removed, it may still work in 1.5)