Top piece of staircase redstone dust doesn't power blocks on the same height in the direction it is powered from unless only connected to something on the other side
See attached screenshots. The piston is not powered by the redstone dust behind it even though the dust is pointing into the piston. The piston only becomes powered once you connect that piece of redstone dust with something else, like a lever/button/redstone dust/redstone block. This can be on the same level, below or above (if applicable). The piece of redstone dust may not be connected to anything on the side, otherwise the piston won't be powered either.
I'm not even going to attempt explaining what logic error caused this bug.
Linked Issues
is duplicated by9
relates to4
Created Issue:
Powered redstone wire not triggering piston
Redstone wire not updating piston unless wire extended one block more than needed. See screenshot for details. Video can be submitted if needed.
Environment
Windows XP, latest Java, Browser version.
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Windows XP, latest Java, Browser version.
Powered redstone wire not triggering pistonTop piece of staircase redstone dust doesn't power blocks on the same height in the direction it is powered from unless only connected to something on the other side
Redstone wire not updating piston unless wire extended one block more than needed. See screenshot for details. Video can be submitted if needed.See attached screenshots. The piston is not powered by the redstone dust behind it even though the dust is pointing into the piston. The piston only becomes powered once you connect that piece of redstone dust with something else, like a lever/button/redstone dust/redstone block. This can be on the same level, below or above (if applicable). The piece of redstone dust may not be connected to anything on the side, otherwise the piston won't be powered either.
I'm not even going to attempt explaining what logic error caused this bug.
relates to
is duplicated by
is duplicated by
A comment with security level 'global-moderators' was removed.
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Duplicate of MC-9405. Wow, that took a lot of searching. (No sarcasm intended)
This is a bug but won't be fixed, because fixing this will break many redstone circuits, see MC-9405 Edit: Fix link
This report and MC-9405 have nothing to do with BUD's, QC or block updates
This bug actually breaks circuits more than it fixes them
@urielsasis After investigation it seems that your bug is MC-9405
Related, but resolved as won't fix.
[~Markku]
"breaking BUDs is something people (including Mojang dev(s), IIRC) have used to justify not fixing a clear bug"
Well, that's bad then. Was that before observers existed or after?
Also, Mojang sometimes changes their mind. MC-9405 was "won't fix" at first and then it was fixed (that snapshot even got released while the report was still marked as resolved). And whether MC-108 is a bug or a feature depends on which dev you ask, on what day, at what weather seemingly, …
"I gave up years ago on trying to use proper reasoning and good programming habits/rules when it comes to Minecraft development."
You shouldn't. Just because many people ignore best practises doesn't mean they should be ignored by everyone. It is already the case in most software projects that most best practises are ignored by most people, but every bit helps.
The thing is, BUDs (without observers) are based on bringing something to an "invalid state" and then detecting when the game finally notices and auto-fixes it. Sounds like the prime example of "bug-using" to me.
"without limits the logic will be correct (door will open/close... eventually) but its desired function will not be correct"
So you mean after the limit is reached, block updates will be moved to the next tick? That is less bad in some simple cases, but those simple cases already aren't a problem for performance anyway and the more complicated cases would completely break with it.
BTW, this report is not about performance.
Precursor You can tag people with
[~name]
, but that only makes it link to the profile and it updates the displayed name when the person's name changes, it changes nothing about notifications or similar.
Also, the "preview" button is sadly gone, but you can use Ctrl+A Ctrl+C to copy your text, click the "visual" button to see how it looks and then switch back to "text" and restore everything that the visual mode messed up (which it sadly often does) with Ctrl+A Ctrl+V. Your many edits causes 105 times as many mails to be sent, that's multiple thousands in total from this conversation today.






If you place a block next to the pistons that aren't extending, do they update and extend?
No, they are not waiting for an update.
I was hoping it was a new way for a bud switch, but sadly no. lol
Added image so its clearer for you guys.
Confirmed.
I as well am experiencing such problems with pistons although i am not sure weather or not to report it as a new bug.
(pistons powered with a redstone block forced into place above the now bugged piston, by a non effected stick piston are powering other pistons diagonally and will not retract after the power"redstone block" source is retracted "only will retract after redstone block and others nearby are destroyed" and so not helping my constant testing for a perfect fully automatic sugarcane farm)
If this is a new bug please contact me and i can provide more details and screen shots.
due to BUD this may have to stay as is, however I have found some fun uses for it.
Still a concern in 1.7.5 and 14w08a
Confirmed for 14w18a
Won't fix because the risk is too high that something else changes behavior.
The bug is that when a block (or piston, redstone lamp, trapdoor etc) checks to see if redstone is pointing towards it
It actually checks to see if the dust is pointing away from it AND if its not pointing to the left or right
(Theres a seperate check to see if the dust is a dot, rather than a line)
A simple fix that works 100% is...
Inside the BlockRedstoneWire.class
At the bottom of the method getWeakPower()
Just below
and above
add
(It fixes all except the slab tower, which is another bug)
Fixed 20w18a