SewdiO

@Keybounce

Your problem isn't dependant on BUD. You can't power each piston individually in any way, that's not possible (if you have a grid of at least 4x4), even without quasiconnectivity. This is because a repeater directed to a piston with another one below it will power both. So with or without BUDs, you can't do that.

To power a wall of pistons, you have to alternate between powering a line directly with a repeater (powering two lines at the same time), and through a repeater (BUDing the line below). While tricky, you can get around your problem by sending one tick pulses to the pistons. If you send it to a piston powered directly by repeater, you have to send another pulse to the piston below, which will retract the previously pushed block. To power the "through a block" pistons, you just have to make sure that you don't send the one tick pulse corresponding to the retraction at the same time as you send a pulse to the pistons above.

Let's say that even rows are powered through a block, and odd rows are powered directly. If you want to load an image stored in some memory to the screen, the powering order goes like that :
1. one tick pulse to the even pixels you want to activate, pushing them and the ones below
2. (one tick later) one tick pulse to the pixels below, retracting the odd blocks pushed (don't power all the odd line, only the pistons below the previously powered)
3. (two ticks later, so the blocks are pushed and don't stick) one tick pulse to the odd pixels you want to activate
4. restart the following tick, if you were to do 3. and 1. at the same time BUDs problems would occur

To clear it you send a pulse of at least two ticks to recover the blocks.

If you want to power pistons with levers (lever up : pixel on, lever down, pixel down, or the other way around) you do the same thing for the powering order. You have to hook to each lever a dual edge one tick monostable circuit, to send a pulse when flicking the lever in both directions.

If you want to do it with buttons, you just need a one tick monostable circuit for each button.

And really, all of these complications aren't because of quasiconnectivity. The only improvement possible would be to speed (point 4.), but that's a very poor improvement comparing to all what is possible with quasiconnectivity (if trapdoor, fence gates or redstone lamps still updated as it was before ; this was the most stupid "fix" to quasiconnectivity there has been as it only prevent from using it but still leave it there).

I hope that helps ! 😃

Anon, please give examples of situations where this is a problem (= can't be avoided, need a big "stretch" to avoid it), i'm not sure there are more occasion where it's better to remove it than keeping it.

Removing BUDs is effectively destroying any possibility of doing compact redstone builds that uses pistons. In this case it's not used to detect block updates, it's to power a piston from further away. I know that systems breaking isn't a factor, but here it's the whole case of compact builds that is affected. See cubehamster videos if you want some example.

Also, to Birk Aigner and everyone else too, it actually is very consistent. Each time you power a piston diagonally or from two blocks above, you get a BUD. There no "sometimes" in here, never.

So now that consistency isn't a reason anymore, why would there be a need to remove BUDs ? It's a bug but a non problematic one as long as you know how glowstone / slabs work in redstone, and a very useful one.

And, a little bit off topic, to Jeb(or Dinnerbone, don't remember who did the change) if you ever see this : Why did you "fix" trapdoors, redstone lamp and such ? It wasn't a bug that they updated, but you removed it anyway. It looks like it was to prevent people from using BUDs and not to fix them. If you're going to fix BUDs fix the piston connectivity, not how other blocks function. You just removed the thing that allowed us to avoid / control BUDs without removing the bug itself which makes it super annoying as of now as there is almost nothing at all we can do anymore to them.

It looks like the bug happens at the piston level, it may be because of the <1 tick pulse it receive.
http://imgur.com/T8bYBYz

Still there as of 13w04a

Yup you're indeed right. I still don't see it as a duplicate of MC-108 though, as it is the update that is the problem here, not the BUD itself (the redstone shouldn't update the piston to go along with the recent change of the fence gates, redstone lamps and such). Also not a duplicate of MC-1263 because in it the issue is the redstone powering the piston, not just updating (it oculd update just fine without powering the piston).

I apologies for the rudeness in the previous post.

It's not this. Did you even read the post ? The block should create a BUD, but does not in the condition said. I would never have listed the issue if it was what you said, i know BUDs enough for this.

It's quite frustrating to get an issue tagged as resolved for duplicate when reading it shows it's something different.

(Edit) Sorry if i sound aggressive.

(Edit2) Or maybe it is ? Does the redstone above the piston acts as the fence gates / redstone lamps did when working ? If it is i still think it should be fixed, but admit the duplicate.

I confirm. It makes any compact sorting system impossible as there is no priority that can be used to sort items. If this is intentionnal to prevent item sorting it's a very bad move, as making something random or even unpredictable is very confusing and prevent any automatic use of it (which is what was very much the point of the hoppers, at least what the community wanted them for).