mojira.dev

Matt Lafreniere

Assigned

No issues.

Reported

No issues.

Comments

That does not rely on quasiconnectivity. The point of the term quasiconnectivity is that you are taking power from somewhere that doesn't update. Getting a proper update from the 2 blocks away power source would not affect your ability to power a piston wall.

How does quasiconnectivity help with piston walls as @unknown says above? Wouldn't you want all your pistons to update when powered for a piston wall? It seems to me that the current power but don't update approach has the potential to leave some pistons retracted. I keep reading that this bug is useful but I have yet to see a good explanation why.

We need to discuss whether the desired solution is the elimination of powering at a distance or the elimination of powering without an update. These are two distinctly different possible solutions if this is considered a bug.

There's a group of people arguing that this isn't a bug, but I wonder if they all agree that the blocks indicated in orange in the image should not provide an update and that they should power the piston. There's also a group of people arguing that this needs to be fixed, but should it be fixed by making pistons not take power from the orange blocks, or by making pistons receive an update from the orange blocks?

Currently we are divided into 2 groups, "fix it" and "do nothing"
We should be talking about "no power and no update" vs "power and an update" vs the current "power and no update"

To those arguing that power and no update is the best option, we've seen that BUDs can be built without quasi-connectivity, do you have another reason?
Personally, I would like to see power and an update. It would be hard to wire an entire wall of pistons to move or to get power to some carefully hidden pistons if they only responded to direct power, but I can't stand having pistons whose behaviour depends on block updates when that's not what I'm trying to build.

The video linked in Gerrard Lukacs' post shows a few very simple BUD design that do not involve quasi-connectivity. Is there a non-BUD argument for keeping this bug?

I am still experiencing this with 1.5

Wasn't the whole point of doing a dedicated restone update to make the major changes to the way redstone works all at once? How can the 1.5 pre-release be due on thursday without a resolution to this? Is that the devs officially saying that we're stuck with broken pistons more or less forever?

why not give hoppers their own enderchest inventory? That way enderchests can still be used normally by players, but hoppers can also use them for instant automated transportation. Obviously there's a potential issue of having multiple hoppers emptying multiple enderchests at once, but I would assume they would just each take an item in a somewhat random order.

Reading people claim that something or other can't be compact without the existing BUD bugs makes me wonder about the math on that one. There are around 20 useful distinct-function items/blocks for redstone contraptions. If all items could be placed anywhere then a 4x4x4 contraption would have 64 blocks.

The attachment blocks required for dust, torches, repeaters, etc would limit the freedom. I think it's reasonable to assume that around half the blocks in a contraption are prescribed to allow these attachments. That leaves 32 positions on average that are free to to be any of the useful blocks.

With 20 items/blocks to choose from and 32 positions, that's around 4.3x10^41 possible contraptions. It seems to me that with such a massive number of possibilities anyone who claims to know for certain what can and cannot be built is overconfident.