[MC-108] Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above Created: 24/Oct/12 Updated: 20/Dec/24 Resolved: 01/Jul/13 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Minecraft 1.4.2, Minecraft 1.4.5, Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w01a, Snapshot 13w01b, Snapshot 13w02a, Snapshot 13w02b, Snapshot 13w03a, Snapshot 13w04a, Snapshot 13w05a, Snapshot 13w05b, Snapshot 13w06a, Snapshot 13w07a, Snapshot 13w09a, Snapshot 13w09b, Snapshot 13w09c, Snapshot 13w10a, Snapshot 13w10b, Minecraft 1.5, Snapshot 13w11a, Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w18c, Snapshot 13w19a, Snapshot 13w23b, Snapshot 13w24a, Snapshot 13w24b, Snapshot 13w25a, Snapshot 13w25b, Snapshot 13w25c, Minecraft 1.6.1, Minecraft 1.6.2, Minecraft 1.11.2, Minecraft 17w17b, Minecraft 17w18a, Minecraft 17w18b, Minecraft 1.12 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Tavis | Assignee: | Unassigned |
| Resolution: | Works As Intended | Votes: | 139 |
| Labels: | BUD, block-update, dispenser, dropper, piston, quasiconnectivity, redstone, sticky_piston | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
What I expected to happen was...: In this image, the pistons should accept any power from the green blocks, check to see if the orange blocks would notify it before accepting power from them, and not accept power from any of the stone blocks:
What actually happened was...: Example of odd effects this has: https://www.youtube.com/watch?v=JqU0Kmb_bFA Steps to Reproduce: Edit: Image now allows for more interesting new types of redstone components and less invasive implementation. Original:
Moderator Note Discussion in regards to this report, such as its functionality, usefulness, and comparison with |
| Comments |
| Comment by MMK21 [ 26/May/20 ] | |||||||||||||||||||||||||||||
|
The linked Reddit thread is archived. | |||||||||||||||||||||||||||||
| Comment by [Mod] CubeTheThird [ 22/Jun/19 ] | |||||||||||||||||||||||||||||
|
Valiant70, in the future, please do not comment on old resolved reports like this unless there is a regression being introduced, or something similar. For discussion about tickets, please use the Mojira subreddit. While there is an old thread there about this ticket, it may be prefereable to start a new one, if so desired. | |||||||||||||||||||||||||||||
| Comment by Valiant Seventy [ 22/Jun/19 ] | |||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||
| Comment by Daniil Aripov [ 10/Sep/17 ] | |||||||||||||||||||||||||||||
|
What may happen if random tick updates piston? | |||||||||||||||||||||||||||||
| Comment by Meri Diana [ 22/Aug/16 ] | |||||||||||||||||||||||||||||
|
TheMeaningOfBlah How about reading the WHOLE post until the very end? };] "We’re not done yet, either! We’ll continue listening to what you folks have to say and refine redstone accordingly. | |||||||||||||||||||||||||||||
| Comment by Dlawso the Really Lucky Rabbit [ 22/Aug/16 ] | |||||||||||||||||||||||||||||
http://mojang.com/2016/08/whats-happening-with-redstone-on-pocket-win-10/ Welp, I suppose that's the final nail in the coffin for people wanting to get that fixed. This report can finally be "closed". | |||||||||||||||||||||||||||||
| Comment by Meri Diana [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
(Sorry, can't help the meta comment now, scold me mods, but my mother or empathy instinct is too strong) <mother-mode> (Change your username again, don't take it so much to your heart, the mods have to be strict here or the bugposts would drown in comments that don't really help the bugs itself };]) | |||||||||||||||||||||||||||||
| Comment by Bengineer8 [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
i, bengineer8, hereby will stop spamming forever and in the proccess of undoing all that i have posted, i am truly sorry and will delete this comment and never post again. | |||||||||||||||||||||||||||||
| Comment by Fabian Röling [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
@Bengineer8 Just stop spamming, stop spamming about spam, stop spamming about spam about spam, ... Just stop it! | |||||||||||||||||||||||||||||
| Comment by Fabian Röling [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
Mod by Myren Eario with BUD pistons and working pistons: http://www.youtube.com/watch?v=VxSSh0GqZCo | |||||||||||||||||||||||||||||
| Comment by Meri Diana [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
Post on Mojira Reddit for further discussion, incl. links to a mod that removes QC towards negative X for the community to help Mojang figuring out the future of Redstone. | |||||||||||||||||||||||||||||
| Comment by [Mod] CubeTheThird [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
Bengineer8, as you were previously asked, please do not post ascii art on the bug tracker. If we find another instance of this, you will be removed from the tracker. | |||||||||||||||||||||||||||||
| Comment by Fabian Röling [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
I thought it was the opposite because the readme file said it so. | |||||||||||||||||||||||||||||
| Comment by Fabian Röling [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
Oh, it does work, but for the NEGATIVE x coordinate! \o/ | |||||||||||||||||||||||||||||
| Comment by Fabian Röling [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
I watched about the second half of that stream. | |||||||||||||||||||||||||||||
| Comment by Meri Diana [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
FaRoGaming + others: If you want to help the discussion, please mod a 1.9.2 MC version (installation/how-to tutorial in a README.txt file in the mod-zip), fiddle with the world provided, and send via links in the video's comments section your contraptions that are only possible WITH or only possible WITHOUT quasi-connectivity. We will likely stream next week again and have the community's input (contraptions) built up so we can continue to discuss that topic, if a possible QC removal would cause us to lose what we can't replace at all with the current MC version, or what we could even gain with a possible QC removal, or how to create workarounds for some contraptions to make them work again after QC removal. Droppers and Dispensers are not shown (yet), but I'll make sure to have some QC-affected droppers/dispensers contraptions built up before the next stream, and to make it clear: Thanks in advance for your help! }=) In case it's not clear, or if you don't watch the video long enough: (If you use the provided world download) The side with the brown clay patches (neg X) is the one without QC, the fully green clay side (pos X) is with the regular QC, as of the current 1.9.2 release version. | |||||||||||||||||||||||||||||
| Comment by Fabian Röling [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
About your "over all it has helped me more than it has hurt me": For me it's the exact opposite: I tried three bigger redstone projects yet, one of them I stopped because it kept breaking just because of BUDs at random places. | |||||||||||||||||||||||||||||
| Comment by Chloe Idun Anderson [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
@Bengineer8 Nah, I've recently taken to deleting some emails because they're literally just spam, but I usually never even clear my trash. That said, I don't delete anything from JIRA, or anything else like this, so I have 20,000 or 30,000 emails in my account surely. Hold on, I'll send that along. | |||||||||||||||||||||||||||||
| Comment by Chloe Idun Anderson [ 05/May/16 ] | |||||||||||||||||||||||||||||
|
@Bengineer8 Please freaking stop with the repeated editing that comment. I got like 10 emails about this and it's freaking annoying. | |||||||||||||||||||||||||||||
| Comment by [Mod] Torabi [ 12/Feb/15 ] | |||||||||||||||||||||||||||||
|
KingSupernova, even if "Won't Fix" was a more appropriate resolution, it was grum who resolved it as "Works As Intended", and thus we won't be changing it unless directed to do so by Mojang. Beyond that, while grum has stated that he shares the opinion that this is a bug, it would appear that jeb and dinnerbone both consider it to be intentional behavior. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 12/Feb/15 ] | |||||||||||||||||||||||||||||
|
It's my understanding that: | |||||||||||||||||||||||||||||
| Comment by KingSupernova [ 12/Feb/15 ] | |||||||||||||||||||||||||||||
|
Yeah, I got that. I just don't understand how that comment is related to mine. | |||||||||||||||||||||||||||||
| Comment by Dlawso the Really Lucky Rabbit [ 12/Feb/15 ] | |||||||||||||||||||||||||||||
|
Grum decided to resolve it as intended by popular demand, but he said they might consider it if alternatives can be made to structures affected by this "bug". | |||||||||||||||||||||||||||||
| Comment by KingSupernova [ 12/Feb/15 ] | |||||||||||||||||||||||||||||
|
I don't see what your comment has to do with mine. | |||||||||||||||||||||||||||||
| Comment by Dlawso the Really Lucky Rabbit [ 12/Feb/15 ] | |||||||||||||||||||||||||||||
|
Issac, once again, Grum's comment:
| |||||||||||||||||||||||||||||
| Comment by KingSupernova [ 12/Feb/15 ] | |||||||||||||||||||||||||||||
|
This was originally a bug (as Grumm admitted himself). It was not intended behavior when pistons were first added, it was a bug. Mojang decided not to fix it. Therefor, it should be marked as "Won't fix" | |||||||||||||||||||||||||||||
| Comment by KingSupernova [ 18/Dec/14 ] | |||||||||||||||||||||||||||||
|
I'm not saying that the bug should be fixed, I'm saying that since it is a bug, the resolution should be "won't fix" instead of "works as intended". There have been several other bugs that Mojang has stated they won't fix, and that is what the "won't fix" resolution is for. This is the same circumstance. | |||||||||||||||||||||||||||||
| Comment by Joshua Walker [ 17/Dec/14 ] | |||||||||||||||||||||||||||||
|
Thank you Keybounce you beat me to the post. Sonic, the most reasonable (IMO) solution that this thread created was nicely outlined by Pokechu22 about a year an a half ago. I really hope this counts as "If you can make alternatives for all the existing structures we might consider it", and that at the very least this bug will get an in-game workaround. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 17/Dec/14 ] | |||||||||||||||||||||||||||||
|
Wasn't there a followup to Grum's post that did in fact show how to rebuild all those things with properly behaving pistons? More to the point, given all the builds that make use of it, wasn't the "best practice" suggestion to leave the existing blocks as "quasi-pistons", and make a new block "normal-pistons"? Giving both backwards compatibility and forwards reasonableness? | |||||||||||||||||||||||||||||
| Comment by Dlawso the Really Lucky Rabbit [ 17/Dec/14 ] | |||||||||||||||||||||||||||||
|
Issac, Grum's comment from well over a year ago:
The mod that Grum is referring to is this comment from Tavis:
| |||||||||||||||||||||||||||||
| Comment by KingSupernova [ 17/Dec/14 ] | |||||||||||||||||||||||||||||
|
The resolution of this bug should be "won't fix", as it was originally a bug. Mojang just decided to leave it in since it was useful. | |||||||||||||||||||||||||||||
| Comment by Markku [ 06/Nov/14 ] | |||||||||||||||||||||||||||||
|
@Mark, before throwing "Does anybody at Mojang even read any of this", perhaps read through the comments yourself first (I admit, lots of them by now, and for a good reason, too). As a hint: 10/Jul/13 8:05 PM (The decision by Mojang was very bad imho (and many others think so, too), but Mojang has the right to do even bad decisions, even when given plenty of better choices. Then again, that and quite a few other bad decisions by Mojang has since made my decision easy, too.) | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 06/Nov/14 ] | |||||||||||||||||||||||||||||
|
Not only that, but if you had something that would transmit power through an extended piston, then depending on how the timing actually works, it could be a cheap, sequenced activation detector. | |||||||||||||||||||||||||||||
| Comment by [Mod] CubeTheThird [ 06/Nov/14 ] | |||||||||||||||||||||||||||||
|
@Mark, I'm sure there are other things, but one example is placing a piston facing upwards, with a slime block on top, then a redstone block on that. This acts as a BUD, and uses the upward piston powering mechanism. | |||||||||||||||||||||||||||||
| Comment by Mark Dowes [ 06/Nov/14 ] | |||||||||||||||||||||||||||||
|
Does anybody at Mojang even read any of this? If yes please comment, tell me why you cannot make it so power does not travel through extended piston, and keep everything else the same? I am yet to see one single invention that requires power travelling through an extended piston end. | |||||||||||||||||||||||||||||
| Comment by dragonkiller1 [ 06/Nov/14 ] | |||||||||||||||||||||||||||||
|
This is technically a bug, but i doubt mojang would ever fix this as it might break many maps. | |||||||||||||||||||||||||||||
| Comment by Mark Dowes [ 21/Oct/14 ] | |||||||||||||||||||||||||||||
|
SO is this a bug or not? I am trying to make a long trap door, i want to pull a redstone block downwards, and cannot, because the piston remains extended when holding a redstone block upwards. Seems silly that it acts as expected in every other direction, but not upwards, obviously this is due to the redstone block powering the piston 2 blocks under it, with the power travelling through the piston-extension. Can't this still be the case, that redstone blocks can power blocks 2 bellow,, just don't allow power to travel through the piston extension? | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 01/Jul/14 ] | |||||||||||||||||||||||||||||
|
The reason why slabs (and glowstone) work is because they are transparent. It's the same reason why you can make a "ladder" out of them. Glowstone or slabs can always be used to avoid this. But it probably shouldn't break your everything, unless your everything was a concept, as it's been around for several years. | |||||||||||||||||||||||||||||
| Comment by Paul Smith [ 01/Jul/14 ] | |||||||||||||||||||||||||||||
|
Nevermind. I found a solution: put a slab opposite of the piston extension. I don't know why it works, but it works! | |||||||||||||||||||||||||||||
| Comment by Paul Smith [ 01/Jul/14 ] | |||||||||||||||||||||||||||||
|
Is there a way to avoid this? It broke my everything. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 23/May/14 ] | |||||||||||||||||||||||||||||
|
The other thing to consider is that Grum (I believe) has said that the current focus is on refactoring and cleaning up the current code mess that is Minecraft. It is entirely possible, if not probable, that the existing code would make it hard to clean this up, and implement cleanly. If that is the case, then we should ... encourage the cleanup of the redstone codebase, so that trying to maintain the existing behavior winds up looking like a mess in the code; that alone might be enough to convince talented, observant programmers to implement a clean alternative in time for 2.1. (we already had 2.0, but it had even more redstone bugs.) | |||||||||||||||||||||||||||||
| Comment by [Mod] Torabi [ 23/May/14 ] | |||||||||||||||||||||||||||||
|
I agree that recent additions to the game, such as blocks of redstone and slimeblocks, provide alternatives to at least some of the buggy piston behavior. However, Grum has said that it probably won't be reconsidered unless it can be shown that all, or at least most, of the devices that depend on this bug can be reproduced without it. See this comment for an explanation. The current behavior makes independently controlling pistons that are stacked on top of each other impossible in almost all cases. I believe I've seen one design that depended on manipulating block updates, only worked on a single tower, and still required activating undesired pistons to reset it. Ideally, the current behavior would be replaced with something intentional, intuitive, and consistent. It may be some time before such mechanics are implemented, however. As multiple people have commented, including grum, it would be very helpful to have a list of the devices that depend on the current behavior, so we could determine what solutions need to be developed. With all the people interested in seeing this fixed, it should be possible to produce such a list, and alternative designs that don't depend on the current behavior. | |||||||||||||||||||||||||||||
| Comment by kbk [ 23/May/14 ] | |||||||||||||||||||||||||||||
|
@Pokechu22 | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 22/May/14 ] | |||||||||||||||||||||||||||||
Part of the reason why this hasn't been changed is the fact that a ton of older stuff still uses it. I'm not going to argue too much, as I have done so for a looong time, but just keep in mind that a change could break a ton of stuff. Minor and potentially faulty comparison: Imagine what would happen if electricity suddenly stopped working the same way. | |||||||||||||||||||||||||||||
| Comment by Marcono1234 [ 22/May/14 ] | |||||||||||||||||||||||||||||
|
Please reopen, I guess because you have now slime blocks, BUDs are no longer needed | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 10/Apr/14 ] | |||||||||||||||||||||||||||||
|
Hello. I am going to argue with you.
Sure, but anything would. But once you understand it it is easy; and it is a simple rule.
The issue isn't only buds. Most devices that use pistons are subtly using this: Most doors larger than 3by3, and even some that are 3by3, use this behaviour. As was described earlier in these comments (way up; it makes sense if you didn't read them as it is large), a valid compromise would be creating more pistons: A quasi-conectivity enabled set and a disabled set. Existing pistons would remain the same, and first-time users would craft the regular set. But the other way should remain craftable. If you disagree with the above compromise, please explain why and what you would prefer. | |||||||||||||||||||||||||||||
| Comment by Anthony Thyssen [ 10/Apr/14 ] | |||||||||||||||||||||||||||||
|
This bug breaks more things in unexpected ways than it helps. There are other ways to generate BUD's that does not involved this issue. So it will break devices that use it. These devices are only using it because that could. NOT because they should be using it. Better to fix this problem once and for all than just stick your head in the sand!!!! FIX IT! If you are not sure... put it to the serious redstone players.... Sethbling, Etho, DocM, and other players on the ZipCrowd. Most of them have already said they would prefer it fixed, rather than the current illogical behaviour. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 15/Feb/14 ] | |||||||||||||||||||||||||||||
|
@acidnine | |||||||||||||||||||||||||||||
| Comment by Brandon [ 15/Feb/14 ] | |||||||||||||||||||||||||||||
|
Yo, MOJANG. Now that you're breaking EVERY SINGLE old build that used a number to give something you should probably consider FIXING this too. THANKS!!! Yes, people got used to /give # for 1.5 years and now they get to change all their old builds. Have fun | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 11/Feb/14 ] | |||||||||||||||||||||||||||||
|
Because we use the behaviors already; and have for over 3 years. Also, dispensers and droppers experience it too (which is much more confusing, as you can't really see it). I just use it a lot, and it makes sense. The rules are very predictable, and are equally logical to things like "Redstone torches placed only effect the blocks above them", except they are slightly more complicated. Removal would result in breaking many devices. The best solution, and the only one that keeps both things functional, is two types of pistons. | |||||||||||||||||||||||||||||
| Comment by [Mod] Torabi [ 11/Feb/14 ] | |||||||||||||||||||||||||||||
|
But it contradicts redstone behavior in other cases, making it confusing to understand the general logic of it. Now if they made a block that specifically emitted a redstone signal that travels through multiple blocks, like how repeaters strongly power a block, that would be one thing. But otherwise, how is it supposed to work? If the signal doesn't transmit that far, then how does the piston detect it? Why doesn't it update? Just because you can memorize and use the behavior doesn't make it make sense. It breaks the illusion. Block updates aren't a game mechanic – they're an artifact of the code, an optimization technique. Players shouldn't have to be aware of them, once again, because it breaks the illusion, makes them aware that they're using a piece of software, rather than immersing themselves in the game world. If they designed an intentional mechanic that accomplished this goal of remotely powering blocks, that would be one thing. But counter-intuitive, self-contradictory behavior only irritates players who don't understand it, and makes many of those who do understand it irritatingly smug. I would hope that jeb would apply the same attitude towards this as he does mob farms: intentional, well-communicated mechanics are better game design that inconsistent, unclear rules. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 11/Feb/14 ] | |||||||||||||||||||||||||||||
|
@_alf: There are few cases where this behavior is trobblesome. Here's all you need to know: Blocks marked "░░" are ones which do not transmit power to a piston at all. Blocks marked "██" power the piston and provide it a block update. Blocks marked "▓▓" are in a neutral state: They give power, but you must provide a block update. " ☰ " is the piston. ░░░░░░░░░░ It can be confusing, but it is a fundamental principle of pistons, used in any large piston door, and also in bud switches. | |||||||||||||||||||||||||||||
| Comment by Ralf [ 11/Feb/14 ] | |||||||||||||||||||||||||||||
|
In my opinion, its a bug and should be fixed because it's breaking redstonephysics. Maybe it seems interesting, because it introduce something like a thyristor, except that a thyristor resets when loosing power at all and you might do things with a repeater energizing a block and with it all redstone surrounding it. It's not logical what happens to the piston in my video and you are doomed when trying to trigger a piston from above - it even has unpredictable (at least i and friends cannot) behavior depending where you have a triggering button put on (height, distance to piston). | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 11/Feb/14 ] | |||||||||||||||||||||||||||||
|
[quote]how should i interpret "resolved" and "Works As Intended" ???[/quote] The answer is both simple and complex. It comes from ... Grum?, I think; it's basically saying that Mojang, at that time, had no plans to change the behavior. Why it is "Works as intended" instead of "Wont fix" remains a mystery known only to Mojang. "Works as intended" means that it was always the case that Mojang intended for these strange, active-but-unpowered devices. That it was always intended for something that was otherwise a good state-based cellular automata system to suddenly be broken and behave strange. "Won't fix" means that while the behavior was not intended, it is more desirable to leave it as-is than to fix it. This whole issue – and please tell me, are there any other "resolved" issues still being debated – could be resolved by either changing it to "won't fix", or by adding new pistons that behave properly in addition to the current funky ones. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 11/Feb/14 ] | |||||||||||||||||||||||||||||
|
The colors I'm using are from MC-11193. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 10/Feb/14 ] | |||||||||||||||||||||||||||||
|
It's resolved as works as intended. It's due to bud behavior and the usefulness as a whole. The exact behavior you are having with is update order, which is a separate bug. To avoid it, use slabs. Whichever mod marked _alf's bug | |||||||||||||||||||||||||||||
| Comment by Ralf [ 10/Feb/14 ] | |||||||||||||||||||||||||||||
|
Is this bug beeing fixed sometime or how should i interpret "resolved" and "Works As Intended" ??? My own bug report is marked as duplicat, so can someone please explain me why an extended piston, staying that way without any source of redstonepower, is called "works as inteded" !?! | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 28/Jan/14 ] | |||||||||||||||||||||||||||||
|
The entire system is labeled as "Works as intended" right now. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 28/Jan/14 ] | |||||||||||||||||||||||||||||
|
The bottom piston should not be powered in that picture. | |||||||||||||||||||||||||||||
| Comment by Mathias Kim Luckow [ 28/Jan/14 ] | |||||||||||||||||||||||||||||
|
2013-01-27_19.55.26.png (the first uploaded picture) does not include a picture of this bug, the repeater "powers" the sandstone, making the sandstone power the piston, that is a feature. | |||||||||||||||||||||||||||||
| Comment by Deleted account [ 27/Jan/14 ] | |||||||||||||||||||||||||||||
|
Confirmed for Minecraft 1.7.4 to 14w04b. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 19/Nov/13 ] | |||||||||||||||||||||||||||||
|
Reddit minecraft suggestions. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 19/Nov/13 ] | |||||||||||||||||||||||||||||
|
I agree as well. I should have mentioned that in my other posts. | |||||||||||||||||||||||||||||
| Comment by [Mod] CubeTheThird [ 19/Nov/13 ] | |||||||||||||||||||||||||||||
|
Either suggestions (in which case reddit may be more appropriate), or Redstone discussions, depending on the desired conversation. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 19/Nov/13 ] | |||||||||||||||||||||||||||||
|
Alright; should it be in the "Discussions" section, in the "suggestions" section, in the "Redstone discussions" section, or somewhere else? And if you do make an official forum-thread followup, please post a link here from there, and there from here. | |||||||||||||||||||||||||||||
| Comment by [Mod] CubeTheThird [ 19/Nov/13 ] | |||||||||||||||||||||||||||||
|
To all users still commenting on this issue, it is recommended that all discussion be kept on / moved to the Minecraft forums, as this website is mainly intended to be used as a bug tracker. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 19/Nov/13 ] | |||||||||||||||||||||||||||||
|
The behavior can be justified. I use it. People who don't use it, and don't know it, don't want it. Isn't that basically saying "well, because that physicist takes more time than a plumber (totally random analogy, don't ask), then the plumber is smarter than the physicist." I see no harm in adding non-effected pistons. The current recipe could be replaced, but removing this behavior entirely would be unnecessary: I'm not against having the current piston on a new recipe.
I see some major tone issues. And I will be annoying with logic now: A personal opinion cannot be a fact, and cannot be lied to portray as one. Saying an opinion is a fact is a lie. And I say it will not be removed because it would be bad. | |||||||||||||||||||||||||||||
| Comment by Tim H [ 19/Nov/13 ] | |||||||||||||||||||||||||||||
|
@Pokechu22 It's funny how you always state "The behavior wont be removed" as a fact and say "This still is considered not a bug" even though Grum, AFTER marking this at "intended", clearly said, i quote: "I share the opinion that this 'non-direct-connectivity-still-powers-a-piston' is a bug. It's confusing for everyone but a small niche of experienced redstoners. ... So in order to possibly get this non-direct-connected-powering removed, I think we need to solve all the problems above, which in theory shouldn't be too hard if we work together." So please stop lying to people to portray your personal standpoint as irreversible fact. Fact is, though, that this IS a bug (clearly and undeniably so) that negativly affects the gameplay experience of countless players (pretty much everyone who ever used or ever will try to use pistons). Calling it a "feature" won't make it go away because it won't stop to negativly affect the experience of players. And that's why complains will never stop until the regular crafting recipe will create pistons that are bugfree and work just as one would expect. Pistons are supposed to have only one behavior, to be extended when powered in an obvious way and retracted when not. Nothing else. Nothing intermediate. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 18/Nov/13 ] | |||||||||||||||||||||||||||||
|
@Mattias Kågström | |||||||||||||||||||||||||||||
| Comment by Mattias Kågström [ 18/Nov/13 ] | |||||||||||||||||||||||||||||
|
http://minecraft.gamepedia.com/Issues/Piston_Quasiconnectivity_Bug | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 18/Nov/13 ] | |||||||||||||||||||||||||||||
|
Nothing has been changed from when pistons where implemented several years ago. Don't expect any changes soon. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 18/Nov/13 ] | |||||||||||||||||||||||||||||
|
So nothing's changed? | |||||||||||||||||||||||||||||
| Comment by Galaxy_2Alex [ 03/Nov/13 ] | |||||||||||||||||||||||||||||
|
It's as simply as that: | |||||||||||||||||||||||||||||
| Comment by Mattias Kågström [ 03/Nov/13 ] | |||||||||||||||||||||||||||||
|
"Resolution: Works As Intended" what? doesn't redstone power thru air break the redstone rules? | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 26/Oct/13 ] | |||||||||||||||||||||||||||||
|
I'm one of the people who use it a lot. If you look at the way it opens, you can see how quasi-connectivity is usefull. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 26/Oct/13 ] | |||||||||||||||||||||||||||||
|
Because seamless glass doors taking several minutes to open are the veryday use of pistons … Sorry, but no. This does not justify anything! It’s just a but no-one at Mojang is willing to fix because they don’t want to upset big Redstoners at YouTube (as they did with parcours makers when removing the “hitbox” of ladders and adding them back as several big YouTubers complained about that useful change). | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 26/Oct/13 ] | |||||||||||||||||||||||||||||
|
OK, I found a video that shows what quasiconnectivity is good for: Oh, and I can tell that this is a kind of useless post, but I like giving justification. Also, I'm going to run a test in beta 1.7 to see how it worked then. EDIT: After experimenting, it seems like this behavior was always with pistons. | |||||||||||||||||||||||||||||
| Comment by James [ 18/Oct/13 ] | |||||||||||||||||||||||||||||
|
I know Setblock has nothing to do with pistons, but in some cases, it can remove the need for them, hence avoiding the hassle of bud behavior. That's all I was saying | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 18/Oct/13 ] | |||||||||||||||||||||||||||||
|
What? What does "setblock" have to do with pistons? | |||||||||||||||||||||||||||||
| Comment by James [ 18/Oct/13 ] | |||||||||||||||||||||||||||||
|
If you want bud tech use pistons, if you want no bud issues, use the new setblock command for command blocks thats in the 1.7 snapshots. Pretty simple happy world with that | |||||||||||||||||||||||||||||
| Comment by Nick Bennett Smith [ 15/Oct/13 ] | |||||||||||||||||||||||||||||
|
Honestly, I can see some uses for this, but usually it is just an annoyance. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 12/Oct/13 ] | |||||||||||||||||||||||||||||
|
I hope that they’ll accidentally fix it while fixing another bug as they did with the Far Lands | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 12/Oct/13 ] | |||||||||||||||||||||||||||||
|
Mojang includes "Won't Fix" as a resolution, which they've used in the past. I'd argue that they should have used it here, too, but that's really the least important thing in this issue. I agree with Keybounce - it would be nice if they could fix this without breaking pre-existing builds. And I don't see why the tracker should let you lock discussions. It's bad enough that it lets you lock votes. If you don't want to participate in the discussion, and don't want to be reminded of this thread anymore, then simply click "Stop watching this issue" at the top of the page. Considering Grum said he may reconsider the resolution if there's enough of a push for it, it doesn't make sense to lock the discussion. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 12/Oct/13 ] | |||||||||||||||||||||||||||||
|
In short, the entire problem is because the bugtracker can't let you lock it, and Mojang only includes a few resolutions. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 12/Oct/13 ] | |||||||||||||||||||||||||||||
|
>I, as redstoner, I don't want this "BUG" (not in my opinion a bug) to be removed. All systems will break with BUD-switches You don't understand. I'm not asking / wanting the behavior of piston block 33:0 or sticky piston block 29:0 (I hope I have those numbers correct – odd that they are not adjacent numbers) to change. I don't think anyone else contributing to this thread is asking for existing behavior to change. I want them relabeled to something like "Quasi Piston", or "Quasi Sticky piston". I want the crafting recipe for them changed, with the redstone in an odd place, to indicate that they can get power from an odd place. I want new pistons added – either new blocks or new meta data – that behave sanely. I fully agree with Mojang that "Fixing this would break too many things". Never mind that the timing changes to pistons in 1.5 broke things, and as far as I can tell, ruined dependability (if a piston is guaranteed to make its state change in 1.5 redstone ticks, then you know exactly what the status will be at 1 redstone tick, and at 2 redstone ticks. If the piston is guaranteed to make its state change in 2 redstone ticks, then is it at the beginning of that tick before anything else happens, somewhere in the middle, at the end, how does it interact with other things happening, etc.) Mojang has a history of "We will break things". "Works as intended" is not a valid resolution. The current system makes little to no sense, causes all sorts of problematic work-arounds, and yet still has uses. I really cannot believe "This was the goal from day one" ("working as intended") is accurate. | |||||||||||||||||||||||||||||
| Comment by karstvgl [ 12/Oct/13 ] | |||||||||||||||||||||||||||||
|
Can't We Just Lock This Page? | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 09/Oct/13 ] | |||||||||||||||||||||||||||||
|
Try this: {color:brown} ▂▂ {color}
▀▀┯
{color:white}██{color}██
| |||||||||||||||||||||||||||||
| Comment by Lake nonofyourbisnus [ 09/Oct/13 ] | |||||||||||||||||||||||||||||
|
8 = PISTON ........................ This kind of setup doesn't work due to this bug. when the piston extends, it wont deactivate due to the pressure plate now powering it. Below is the piston pushing the block level to the pressure plate. ................_O Even if the signal cuts off, the piston stays in place due to its extended head counting as a redstone block type. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 09/Oct/13 ] | |||||||||||||||||||||||||||||
Ah, that problem. Yea, that's the one major problem with this behavior: it can make that almost impossible. | |||||||||||||||||||||||||||||
| Comment by [Mod] Torabi [ 09/Oct/13 ] | |||||||||||||||||||||||||||||
|
I haven't found a way to independently control rows of pistons (in a vertical grid) due to this behavior. It may allow some designs to be more compact, but it makes others completely impossible. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 08/Oct/13 ] | |||||||||||||||||||||||||||||
By it counting as a redstone block when extended, do you mean that it can receive redstone? | |||||||||||||||||||||||||||||
| Comment by Lake nonofyourbisnus [ 08/Oct/13 ] | |||||||||||||||||||||||||||||
|
I understand that, it's a useful tool. But the fact that the piston 'head' counts as a redstone block when extended is the annoying part. It makes it so you cannot put pressure plates within the vicinity of it. I do wish that part could be fixed, with the current piston or a new one. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 08/Oct/13 ] | |||||||||||||||||||||||||||||
1, I would like to see some stats on that. It is rather annoying. Generally, play around with using upsidedown slabs (/give @p 44 1 8) to insulate from this behavior. It wont be changed, so figure out how to avoid it until you start using it. | |||||||||||||||||||||||||||||
| Comment by Lake nonofyourbisnus [ 08/Oct/13 ] | |||||||||||||||||||||||||||||
|
Someone please fix this glitch, whether it is intentional or not the majority of us find it annoying. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 19/Sep/13 ] | |||||||||||||||||||||||||||||
|
@Paul Smith What are you trying to do with your contraption? If the issue you are having is actually related to MC-11193 (this video:http://www.youtube.com/watch?v=e5hUYLC8Tms), then slabs MAY fix your problem, but so could a number of other things. If need be, you can upload a picture of your contraption and I can try to fix it. | |||||||||||||||||||||||||||||
| Comment by Paul Smith [ 19/Sep/13 ] | |||||||||||||||||||||||||||||
|
Is there any known way to work around this? It ruined my contraption. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 25/Aug/13 ] | |||||||||||||||||||||||||||||
|
...No, wha? Nothing has changed... | |||||||||||||||||||||||||||||
| Comment by OxORRR [ 25/Aug/13 ] | |||||||||||||||||||||||||||||
|
So you mean that the piston no longer responds to redstone/block updates? | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 19/Aug/13 ] | |||||||||||||||||||||||||||||
|
If I were to retype what I had said before 20 times, I would be able to answer every duplicate statement. IE, @Keybounce, don't you realize that I posted the design earlier? I wish that we had both kinds, but if they don't implement this, its better to keep it like this. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 19/Aug/13 ] | |||||||||||||||||||||||||||||
|
> This behavior is highly useful. The problem is: Proper behavior is also highly useful.
It is apparently easier to mimic the bugged useful behavior with a proper piston than to mimic the proper useful behavior with a bugged piston. The whole issue can be solved by having both kinds of pistons. Either form, by itself, will make some things easier and some things harder. But what is currently there is inconsistent, and confusing. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 19/Aug/13 ] | |||||||||||||||||||||||||||||
|
@Dirk Sohler | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 19/Aug/13 ] | |||||||||||||||||||||||||||||
|
Iirc there are already videos proving that this is possible. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 19/Aug/13 ] | |||||||||||||||||||||||||||||
|
@Dirk Sohler
(That's from grum in the comments a while ago) | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 19/Aug/13 ] | |||||||||||||||||||||||||||||
Mainly because some AAA Youtubers will be pissed if Mojang would fix that bug because it brakes their Redstone builds causing bad promotion and possible loss of said Youtubers and thereby less Minecraft sales. Assumption: Not fixing the bug is mainly a promotional issue. (And you can’t prove me wrong!) | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 19/Aug/13 ] | |||||||||||||||||||||||||||||
|
@Zachary | |||||||||||||||||||||||||||||
| Comment by Zachary [ 18/Aug/13 ] | |||||||||||||||||||||||||||||
|
Tails, screenshot2-.jpg depicts of the situation I've been talking about. The piston remains extended even after receiving no power because the redstone block still powers it at an incorrect position. ~Jouster500 | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 03/Aug/13 ] | |||||||||||||||||||||||||||||
|
@Lewis Moore | |||||||||||||||||||||||||||||
| Comment by Lewis Moore [ 03/Aug/13 ] | |||||||||||||||||||||||||||||
|
This really needs to be fixed | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 02/Aug/13 ] | |||||||||||||||||||||||||||||
|
@Tim H
Never thought about it in that way, it seems like really good idea. @William Pearson | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 02/Aug/13 ] | |||||||||||||||||||||||||||||
That isn't really a compromise, though. The typical survival player doesn't use redstone. And the budding pistons are used in most large doors and stuff, such as 3by3's, so a crafting recipe would be nice to keep so that I don't need to go and make 2000000 pistons so that I can have bud pistons. IE, those who would want it would want it, and you shouldn't make it annoying; that's basically removing bud pistons but not breaking builds, but it would break designs that already exist. Even if the recipe is surrounding a piston with redstone in the crafting grid or using a repeater or torch instead. Some recipes:
Yes, this is sugestiony, but I feel like we need to show the recipies, and I didn't feel like trying to use symbols. | |||||||||||||||||||||||||||||
| Comment by mike [ 02/Aug/13 ] | |||||||||||||||||||||||||||||
|
That's a good idea. I think that idea is probably the best way to solve the problem unless someone else comes up. | |||||||||||||||||||||||||||||
| Comment by Tim H [ 02/Aug/13 ] | |||||||||||||||||||||||||||||
|
I don't think it's necessary to have a recipe for the BUD pistons at all. Usual survival players don't know of the BUD behaviour and expect a bugless piston. Bugless survival mode should be the goal to strive for after all. Those who use BUDs rather use it for mapmaking or experimental builds and would use the creative menu or the /give command to get the pistons anyway. | |||||||||||||||||||||||||||||
| Comment by mike [ 02/Aug/13 ] | |||||||||||||||||||||||||||||
|
Another idea is to keep the old recipe, but have two outputs. Them being the BUD and non BUD pistons. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 02/Aug/13 ] | |||||||||||||||||||||||||||||
|
@Keybounce It should use the same block id. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 01/Aug/13 ] | |||||||||||||||||||||||||||||
|
I have an idea, moving forward, for how to distinguish the two pistons. The new, "properly functioning" piston has the same recipe we now have – three wood on top, stone edges, iron and redstone in the middle. The old, "oddly diagonally powered" piston gets a new recipe – the redstone dust is moved from position #8 (bottom middle) to position #1 (top diagonal corner). The wood block goes where the redstone was. Does that make sense? As much sense as the behavior of the old piston. But it seems that two different piston blocks is the only workable solution that makes everyone happy. | |||||||||||||||||||||||||||||
| Comment by mike [ 01/Aug/13 ] | |||||||||||||||||||||||||||||
|
Couldn't agree with you more. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 31/Jul/13 ] | |||||||||||||||||||||||||||||
|
@William Pearson
Nice way to tell someone to just be quiet because you have run out of arguments, also there's a "Stop watching this issue" link, if you are so worried about spam. @Alex Taffe
Agreed, with this, let's move on and try to think of solutions that will make both groups happy. 1. I think that fixing BUD behaviour and adding a bug-free BUD block would be the best option, in my opinion. 2. Spliting pistons with inverted recipes is nice idea but as the gamerule idea, I think keeping bugs like this in the game for backwards-compatibility would only let them grow even less stable. But at this point, I think they just don't care anymore. But I would like to make one last appeal. | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 31/Jul/13 ] | |||||||||||||||||||||||||||||
|
I would say keep all current pistons as BUD pistons. That way nothing breaks. The crafting recipe could just reverse the redstone and iron or just use more redstone for the BUD piston. | |||||||||||||||||||||||||||||
| Comment by Albert R. Gonzalez [ 31/Jul/13 ] | |||||||||||||||||||||||||||||
|
If we were to split into two types of pistons the old ones would become BUD pistons if they kept the same block ID | |||||||||||||||||||||||||||||
| Comment by mike [ 31/Jul/13 ] | |||||||||||||||||||||||||||||
|
I agree with you. I would choose the split too. But would the old pistons be converted to the BUD pistons? | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 30/Jul/13 ] | |||||||||||||||||||||||||||||
|
Grum, I think we need your input on this issue again. This comment section has just turned into a massive argument over nothing. You said that you would try to put a game rule in, and I think that stirred up commotion. I think the options to resolve this problem are: add a game rule(not optimal), remove the BUD, name it as a feature and disable comments here, make a BUD block, or split the piston into a BUD piston and a non-BUD piston. My opinion lays with the split, but other people may have differing opinions. Love to hear what you think and hope it can resolve some of these arguments. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 29/Jul/13 ] | |||||||||||||||||||||||||||||
Negative response. | |||||||||||||||||||||||||||||
| Comment by Marios [ 29/Jul/13 ] | |||||||||||||||||||||||||||||
|
At this point Mojang probably doesn't care (or ever did) about feedback but anyway my feedback is, big thumbs down to Mojang for closing this as intended behavior. I prefer predictability rather than having extended unpowered pistons, etc. Instead of fixing this bug as early as possible, you allowed for all these possible contraptions to be built and now you say that we will have to live with it because you can't just break all these contraptions and that the community demands it to not be fixed. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 18/Jul/13 ] | |||||||||||||||||||||||||||||
This just shows that there IS a lot to discuss. Simply closing with “Works As Intended” just don’t works here. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 18/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Brandon Look through all the comments. | |||||||||||||||||||||||||||||
| Comment by Brandon [ 17/Jul/13 ] | |||||||||||||||||||||||||||||
|
Is it just me or does it appear that @William Pearson is the only one who wants this to stay WAI? | |||||||||||||||||||||||||||||
| Comment by Tavis [ 17/Jul/13 ] | |||||||||||||||||||||||||||||
I posted a screenshot of a working 3x3 door and have built half of a 4x4 door that operates by manually toggling levers. The design can be mirrored and the lever flipping can be automated.
You're getting a bit ridiculous here, but I suspect that those would be possible to build using redstone blocks.
Name one useful thing besides this that aiming a repeater at the side of another repeater does. I'd also like to point out that it is immediately obvious that something is happening.
Two systems that are normally not used together and don't normally interfere can break when they are both activated at the same time. You may notice that this bug was reported before 1.5.
That is neither an obvious solution nor solves all of the problems with this bug.
They don't need to be compact for this to be a problem. A single wire in the wrong place is all it takes.
How about experimenting with redstone and building up your knowledge? How do you think people managed to write the wiki in the first place?
This is pretty much what already happens because, short of using a mod, we can't test the circuit to make sure it would work. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 17/Jul/13 ] | |||||||||||||||||||||||||||||
I'm saying good things come from bugs sometimes.
For one, you have a strongly negative attitude. However, the second paragraph is the optimal case. And saying illogical/non-obvious things should be removed? And, you can generaly curcimvent this behavior with slabs. And, I have had my own circuits broken by this. | |||||||||||||||||||||||||||||
| Comment by Tim H [ 16/Jul/13 ] | |||||||||||||||||||||||||||||
|
Yes, bugs can lead to good things, that is, if they don't negatively affect the experience of players. This bug, however, HAS a negative effect that leads to illogic behaviour (pistons getting stuck in states they shouldn't be in, etc.) and prevents people from building machinery that SHOULD work by all logic means. I can't believe keeping a bug like this in game is even open for discussion, let alone accepting it as "intended". If a bug is needed to provide functionality that the main game doesn't provide, then something is fundamentally wrong. If the functionality is necessary, provide an item or method that provides it WITHOUT negatively affecting the experience of legit players. That the bug has always been in the game is not a valid argument for it's existence. Also, a fix breaking existing machinery is not an argument either, because everyone who (ab)used it could clearly see that the illogic behaviour could have never been intended and thus might get fixed in the future. However, all idealism aside, keeping the current Block IDs as pistons with the bug for the sake of backwards-compatibility and having new fixed piston blocks for crafting and the creative menu would be a compromise that should acceptable for everyone, because all would get what they want and noone would get harmed in the process. Legit players would have a bugless experience, existing contraptions would not break and mapmakers who like to use the bug can just spawn in the old pistons via /give command. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 16/Jul/13 ] | |||||||||||||||||||||||||||||
And then Notch just gave up and left them with a pig skin and dropping pork. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 16/Jul/13 ] | |||||||||||||||||||||||||||||
|
Well, in my opinion, it has become too usefull to remove, even if it experiences bug-like side effects. Bugs can lead to good things. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 16/Jul/13 ] | |||||||||||||||||||||||||||||
|
@William Pearson
I see what you're trying to say, but to me that is an invalid argument. You could just say that about every other bug: "don't fix this bug, just get over it". I'm sure there are bugs some people love and some people hate, but despite that, keeping a known bug in the game is not right. I stand by my points and have nothing else to say. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 16/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Zé Carlos There are a fair amount of things. Saying "I Don't understand this help plz!111!!!" (Which you didn't, this is intentionally exadurated) is not the correct response to a behavior that can be worked around, is stable, and has been in the game for 2 years. My first reaction was confusion too. But it has been very helpful sinse I got over that. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 15/Jul/13 ] | |||||||||||||||||||||||||||||
|
I'm not saying that they cant be done. I'm saying that many prevalient designs have it used. The upper and lower lines trigger seperatly. ████▂▂▂ | |||||||||||||||||||||||||||||
| Comment by Tavis [ 15/Jul/13 ] | |||||||||||||||||||||||||||||
|
Here's a much more flexible piston toggle. The repeater is required when it is facing most directions, but in some cases it can be omitted. The input can come from any direction, the output can be taken from any side of the redstone block, and the output piston can be rotated in any direction except towards the input. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 15/Jul/13 ] | |||||||||||||||||||||||||||||
|
@William Pearson I was saying if you have some old designs that use this bug that there are ways around and just as compact and if that design is massive more of a reason to use them because of less lag.
what would be a removal without a replacement? | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 15/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Zé Carlos
Then how does this effect you? Are you trying to remove this because it broke one of your machines? And it would be a removal without a replacement. Unlike minecart boosters (with parallel minecarts). | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
|
@William Pearson | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Zé Carlos And that was just a example. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Dirk Sohler
Couldn't have said any better. @William Pearson
Just do a hopper t-flip flop | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
|
I have. There's many. It's hard to figure out which ones actualy are broken. So far, we have found 2 broken systems, one of which is the most common t-flipflop in the world, and will break 90% of all maps if broken. (That may be an exaduration, but it is a common design). | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
|
Re-read the comments and check the so-called “broken” builds created with that mod. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
No. The behavior has a ton of uses, including in piston doors and everything. Fiddle around with the mod mentioned earlier, you'll see what's broken. It's hard to figure out. Not only buds. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
|
I’m pretty sure “the community” we’re talking about on here is only a few big redstoners with a lot of subscribers on Youtube. Most of the community either doesn’t care or wants the bug being fixed. | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 14/Jul/13 ] | |||||||||||||||||||||||||||||
|
Keybounce, that was a very helpful comment. I agree with 90% of what you said truly. I think before every block in the game receives a random tick update, the rendering engine needs to be overhauled. We need things like: Anisotropic Filtering, Antialiasing, OpenGL 4, vRAM compression, Dynamic Chunk Updates, multicore, multithread, the move away from Java to native binaries, etc. This will allow the game to run more smoothly, even on older hardware. This is needed, because certain laptops (which a large percentage of minecrafters play on) get terrible FPS without Optifine, and a majority of users don't know how to add mods. The random tick update will surely cause a further decrease in FPS. Even so, having water updated every tick will subsequently break many builds. This is also the case with the quasiconnectivity BUDs being removed, but the BUDs are more of an inconsistent "feature" (bug) than water not being updated. And if the water were random ally updated, players may not know why. The random tick should only be used for things like crops, soil hydration, or burned out redstone torches, in my opinion. I think the BUD should just be removed all together, but I feel that the community of some of the experienced redstoners who refuse to upgrade to the piston can't push piston head BUD will cause too much fuss for that too occur (I do realize that it wont power a piston two blocks lower, but for something like a sugarcane farm). I think that the only way to fix this is two piston types, a BUD block, or complete removal of the BUD. I don't know if Jeb and Dinnerbone are just appeasing the people who want it by dubbing it a "feature", but it honestly seems way too confusing for the average user who doesn't know why their build isnt working, even though it should in theory work. Grum, I'd love to hear your latest thoughts on this issue and what your other ideas on future implementation might be. I think that this comment thread just needs to pick one way to go with this and then help you move forward with that idea with ways to implement it, how it would work, etc. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
BUDS are fundamentally a way of detecting "The neighbor block has been updated". There is a way for blocks, in the code, to notify their neighbors that they have changed. Minecraft, at its heart, is a cellular automata. Any time a state change is not accurately propagated – even in the case of "which way does water flow from here" – it is possible for the "current state of the world" to be strange. And if a block, upon being notified, makes a change from the inconsistent state into the consistent one, then there is something to detect. Do you think Etho's old "Boat Bud" should not exist? In general, if I have a water source that wants to go either to an immediate fall in one direction, or has to go a longer distance in another direction, even if that direction's length is controlled by a piston, then it is possible for the water source to not notice a "change" that has range 2. And if you teach it to look at range 2, I can set up a bud at range 3. Etc. I see no cheap solution to that. === There are only two choices: If you want to use #1 (no buds at all), then a perfect examination of the environment is probably not possible because of time. You can either say "Regardless of CPU power, each block we want to check the environment will sample one or two random blocks in range each update tick", or you can say "Each block that that is environment sensitive will add itself to a current recheck list; each time through the main game loop, some blocks on that recheck list will make some attempts to recheck, and the total amount of rechecks made will depend on CPU power, such that more powerful machines will see a world become more consistent faster", with the length of that list being a trigger for removing older blocks from the list (and possibly a block being smart enough to say "I have now checked everything around me, remove me from the list even if there is spare CPU"). The first of those two choices – regardless of CPU power, each environment sensitive block makes one or two random checks each time it gets a random update tick – is probably the better, more consistent one. And if you want to use #2 – buds should exist in some form – then there is no reason not to have a single block bud. Either an omnidirectional bud (any change in any neighbor sends a notice to 5 other sides), or a redstone-torch like "single direction in, fixed outputs". I personally would prefer to be an omni-buds-man. === Entirely separate from the question "Should there be buds?" is the question, "Should this piston behavior continue?". Should pistons be changed? We've had a major change to piston timings already. So we already have precedent for changing things. Should old redstone behavior be changed? We already have seen timings of redstone torches, and the behavior of torch and repeater loops destroyed from 125 singleplayer to anything later (bug #2523, that actually kills much of what I was going to use redstone for in my world. https://mojang.atlassian.net/browse/MC-2523). We've seen really long insta-wire loops that propagated through unloaded chunks in one tick in single player turn into loss-of-sync, multiple tick signals. And yes, insta-wire can be used as a denial of service attack on a server. Arbitrary inst-computations have been demonstrated as a proof of concept (both instant nand and instant nor gates). But there are no "gamerule" settings – or server.property settings, or anything – for a server to indicate how much instawire / redstone torch updates / etc they are willing to put up with in a tick, and the default settings are too low for doing anything interesting. === Bottom line: Mojang has repeatedly broken builds in the past. I think we, the community, have gotten used to, almost expecting this to continue. To now turn around and say "It's broken, but won't be fixed" makes very little sense. And if you are going to say "Promoted to official feature", then consider just how little sense it really makes – I could not describe it accurately if I had to, other than to say: "Generally speaking, a piston can be 'powered' if either the block above it would power a piston, or if while extended, the extended arm is powered and then power removed from the base". I think that's accurate. And if it's not, how would you describe it such that others can understand it, and be accurate? | |||||||||||||||||||||||||||||
| Comment by Tavis [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
@grum Floating sand, breaking and placing blocks, flowing water, etc. would still need to be updated somehow. If everything were simulated the simulation could also take into account any blocks that should respond to such changes. | |||||||||||||||||||||||||||||
| Comment by [Mojang] Grum (Erik Broes) [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Tavis:
If you were to simulate redstone and flush out the deltas into the world there would not be anything like 'buds'. Buds are leaks of implementation, they should not serve any true purpose to build upon. | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Zé, that isn't possible though for servers, like the mindcrack server, and I'm sure that no one would want to have to keep 2 version of their single player LP world up to date. The only time when the game rule might be helpful is for things like CTM or PVP maps. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
Although I would like to see quasiconnectivity fixed, I have to agree with you that the community would end up demanding it for everything. But not fixing bugs because the community like them may just result in the same situation. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
That would power the piston you can't see behind the block the repeater is on. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
I would also like to vote against adding a gamerule. Utilizing gamerules for optional forward compatibility has never happened before, and if you do it once everyone will end up demanding it for everything. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Tavis: Can't you make the lower row piston, block, repeater, wire – giving you two rows of wire, with a block separating them? In either case, treating redstone as "Always has an update range of 2" – such that the upper repeater, and the lower piston are distance 2, so the lower piston will just work – does make sense. In fact, as I look at that, why use a repeater there at all? Why not redstone dust normally? If a redstone dust is powered, and the rule is "redstone dust powers anything in range 2", then the lower piston is powered. And, that fits the "repeaters act as signal isolators, and only power the blocks right in front of them" behavior, which would not power the lower piston. In other words, what seems to be "reasonable, expected" behavior is that using dust instead of a repeater would power both (as well as the one above them if there was a third), and a repeater would only power the one. (I am not a redstone expert; I've had too much "fun" with torch bugs and repeaters not working right in loops.) | |||||||||||||||||||||||||||||
| Comment by Tavis [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
My implementation of the bug fix allows repeaters to power the piston below and in front of them. I think that behavior is useful and intuitive enough to keep, and I'm not quite sure how I would be able to fix this particular device if it was removed: Powering individual rows of a wall using pistons and redstone blocks is possible with this implementation but quickly gets quite bulky. Powering rows of wall has always been pretty much impossible, so I think it might be worth looking into adding a mechanic to remedy that. You still can't do it with a wall of RS torches, but that's objectively less useful than pistons. | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
That would mean you can't get new content and still keep this behavior - you'd have to make a choice between quasiconnectivity and everything added in all future versions. Thus, there's a rationale in simply having it as an option that can be switched on. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Why a game rule? The launcher can manage multiple versions of Minecraft. If people want to have the bug, the can simply run an older version of the game. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
I think the gamerule would solve this and leave everyone happy.
Alex, that player would just have to create 2 diferent saves, one with gamerule and the without. | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Sorry for all of the comments, but I was thinking, one of the reason that BUDS are used is because they can power blocks two below them. What if another block were added to the game that was kind of like a vertical repeater. It could work by placing it like: redstone It could then transmit the redstone signal downwards, or it could act as a BUD block. The piston would then only react to Quasi connectivity when this block is placed near the piston. | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Tim, pistons cannot be strongly powered. This build would work perfectly with the quasi BUD removed. | |||||||||||||||||||||||||||||
| Comment by Tim Gunderson [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Alex, that design in my mind would cause 2 or 3 rows to fire on the rows where the repeater directly touches the piston due to the piston block being strongly powered. | |||||||||||||||||||||||||||||
| Comment by [Mojang] Grum (Erik Broes) [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Excellent, that would even be an improvement over what we have now! | |||||||||||||||||||||||||||||
| Comment by Alex Campbell [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Tim: Which design using this bug does allow rows to be controlled independently? Edit: This would allow each row to be controlled independently if not for this bug: http://puu.sh/3AWbM.jpg | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Grum, thanks so much for all the help. I think a game rule would definitely be a good idea. Enable it by default for existing maps and then give people the option to enable on new maps, with off being the default settings. My only worry with that option and not splitting into non-BUD | |||||||||||||||||||||||||||||
| Comment by [Mojang] Grum (Erik Broes) [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
I've been requesting this issue to get a resolution for as long as I've heard about it. I've started the discussion in the office (and before I moved to Sweden) more times than I can remember. Always the opposing arguments have always been: I just put a resolution on the ticket after asking Jens to do so and somehow that got forgotten (even after repeating the question). I share the opinion that this 'non-direct-connectivity-still-powers-a-piston' is a bug. It's confusing for everyone but a small niche of experienced redstoners. It seems that after removing quasi-connectivity there are still working budswitches. Eventhough I think bud-switches shouldn't ever be available because they are based on leaked implementation, I'd be perfectly fine for them to be confined just to pistons & boats (as shown in Sethblings video: http://www.youtube.com/watch?v=Qp4_oQuReuE ). So in order to possibly get this non-direct-connected-powering removed, I think we need to solve all the problems above, which in theory shouldn't be too hard if we work together. I can fix the first point by adding a gamerule that allows the old behavior to happen. So people on old maps can still 'toggle quasiconnectivity-mode' while the default normal gameplay wouldn't have that. I'm not star at redstone, so I have no idea how many contraptions would be unreproducible, I'm quite sure some will be or take significantly more space. I think that if the damage is 'low enough' there might still be a chance that this gets past Dinnerbones & Jeb's scrutiny. But this really will be up to you guys to provide. | |||||||||||||||||||||||||||||
| Comment by Tim Gunderson [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
You can't control each horizontal row independently with that design the way you can with quasiconnectivity. | |||||||||||||||||||||||||||||
| Comment by Alex Campbell [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
Here's a piston wall that actually doesn't depend on this bug: (the previously-posted one does) | |||||||||||||||||||||||||||||
| Comment by Peter Hunt [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
I have a build that I believe requires quasiconnectivity. However, I'd like to see if people can build it without using quasiconnectivity. Please check out this world: http://www.uploadmb.com/dw.php?id=1373602193 In this world, I have built a wooden wall where a vertical slice of the wall can be extended two blocks and retracted. A very important aspect of this build is that it is flush. No redstone is visible from the outer portion of the wall. The wall can be made longer in any direction (left, right, up, down) without interfering with the redstone and while remaining completely flat. I don't believe that this can be implemented without quasiconnectivity, particularly the flush aspect of this build. However, please feel free to prove me wrong | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 12/Jul/13 ] | |||||||||||||||||||||||||||||
|
so the worst case for debugging hoppers is far better than the worst case for debugging quasiconnective pistons.
{/quote}
Let me just say one thing. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
You might also remember that at one point wooden stairs and fences didn't burn. Slabs got a new block because fire and tool properties are based on block ID, and removing the old blocks would have replaced all the existing ones with air or a different type of slab. | |||||||||||||||||||||||||||||
| Comment by Zé Carlos [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
My taughts on this matter are that this is a bug. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
Piston doors and buds are the primary use.
No, they were kept so that not everything was destroyed on the change. | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
Keybounce and Alex Campbell, I agree with both of you. I know that it is possible to make BUDs without the quasi connectivity, I personally use them in my builds to avoid anything breaking. Sethbling even made a video on how to build them (http://www.youtube.com/watch?v=Qp4_oQuReuE). The only reason that I brought up Mumbo Jumbo's idea is to keep everyone happy. I'm sure some people would still love to have the quasi BUDs, even though they tend to be larger, they are often more easily tileable. But, the reason I feel that the current piston should have the functionality removed and a BUD piston added is more for inexperienced players. If some inexperienced kid starts playing the game for the first time and puts a redstone block on top of a piston, it'll just get stuck and they'll have no clue why. And Mojang could determine if the new piston gets the BUD or the current keeps it, which would allow for older builds to break, but easily be fixed, or just add a new BUD less piston that wouldn't affect any builds. Besides, most the quasi BUDs aren't really ever used as a BUD. They used to be used to transmit power via a fence gate or trapdoor, but that is now broken. The X x X doors are the only thing that I can think of the really rely on it. Something like a sugar cane farm can just rely on the piston can't push a extended piston arm thing. | |||||||||||||||||||||||||||||
| Comment by Alex Campbell [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
The old wooden slabs are only kept for technical reasons. Edit: In fact, it was possible to make a non-quasiconnectivity piston BUD in beta 1.7. No redstone blocks required. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
I want a properly working piston/sticky piston. Period. If it takes having both "older, compatible blocks" as well as "newer, better blocks", so be it. We have – still, today, fully functional – stone slabs that happen to look like wood, but fireproof and using picks. | |||||||||||||||||||||||||||||
| Comment by kbk [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
Dear Alex and Keybounce. The invention of redstone block made BUD designs without quasiconnectivity possible. All those people above are trying to tell Grum that BUD ≠ quasiconnectivity and the latter is a pure bug, that deserves to get squashed. Yet you guys want Mojang to add not one block but 4 redstone devices with this illogical behavior. Why'd you want that? | |||||||||||||||||||||||||||||
| Comment by Albert R. Gonzalez [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
Here's "Jeb"(seamless and flush 2-wide) door that doesn't use quasiconnectivity to function. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
<blockquote>I personally think that Mojang should take Mumbo Jumbo's suggestion (http://www.youtube.com/watch?v=QYe_xe7SNKY) about splitting the piston. Change the name of the original piston to something like piston (BUD) </blockquote> YES! Keep the old block, with a changed name. Add in a new, better, fixed block. It's like the old "wooden slab" that was kept, and different from the new, current, wood slabs. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
I personally think that Mojang should take Mumbo Jumbo's suggestion (http://www.youtube.com/watch?v=QYe_xe7SNKY) about splitting the piston. Change the name of the original piston to something like piston (BUD) and that has the same block ID that would be crafted slightly differently and then add a new piston and sticky piston that use the original texture and crafting recipes that don't work in slightly unexpected ways | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
Ok, I have found that it is realy realy hard to track what will be broken. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
That's a problem with hoppers not having any externally visible or audible indication that they are being powered. They respond immediately to changes that affect them, so the worst case for debugging hoppers is far better than the worst case for debugging quasiconnective pistons. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
Ok, first, the argument of this being non-obvious: | |||||||||||||||||||||||||||||
| Comment by Kevin Reid [ 11/Jul/13 ] | |||||||||||||||||||||||||||||
|
I'm not big on following ”the Minecraft community”, but I think that the community was kind of expecting this to be fixed back when Mojang announced the Redstone Update — which was specifically described, if I recall correctly (I didn't find any text of the original announcement), as potentially breaking existing redstone machines. (I've personally had at least two otherwise-straightforward mechanisms broken by this bug, when I tried to use pistons to transfer a signal vertically in a constrained space. Why should up-and-down work differently from sideways?) | |||||||||||||||||||||||||||||
| Comment by Inquisitribble [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
As Gerrard asked, I too would like to see a list of devices that rely on this bug. Personally, I have only found it to be needlessly frustrating when attempting to debug a redstone mechanism. Sure, if this would be fixed/removed, we would lose our brainless BUDs, which I personally have found useless, and to those that would lament the loss of their current BUD designs that rely on this, there are plenty of other BUD designs that don't rely on the bug and are sometimes/generally more compact. Also, this behavior makes no logical sense whatsoever. Using current redstone mechanics, there is no valid reason why a piston should exhibit this behavior. tl;dr: What this bug giveth, it taketh away. Many users, myself included, have had to work around this bug just to get things to work properly. I have found little use in it other than the occasional one-time-use BUD and to troll somebody building something with redstone. | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Thank you, Grum, for choosing to keep accepting community input here. I've probably made it clear that I am also of the opinion that this bug should be fixed for the sake of coherent, intuitive redstone behavior, even at the cost of breaking existing maps. I'm glad to see that you're willing to consider reverting if we can prove that this change won't make particular devices impossible. I just have one open question - can supporters of this bug-as-feature provide a comprehensive list of constructs which "rely" on this bug? This can help us streamline the process of settling the claim of whether fixing this bug makes things "impossible" or merely changes the way redstoners build things. And yes, I understand that Grum only said he'd consider it - but by all means, if I find the time, I'll be glad to try my hand at making alternatives to devices which meaningfully use this bug. Also, can we please put an end to the argument "but then we'll have to rebuild some of our existing machines!"? I gladly accepted the original dispenser bug fix even at the cost of having to scour a massive dungeon and replace 226 broken machines. I think you'll manage, regardless of the scale of your project - if you found the time to make it, you or someone else can find the time to repair it. | |||||||||||||||||||||||||||||
| Comment by [Mod] Torabi [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Grum, what about the BUD behavior? Is that part of what you're calling feature/WAI, or are you just talking about quasiconnectivity? | |||||||||||||||||||||||||||||
| Comment by kbk [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Grum, can you (or anybody else) please provide any decent list of all the useful designs that will probably be mourned about if quasiconnectivity would ever be disabled? | |||||||||||||||||||||||||||||
| Comment by Brandon [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Grum, Thank you for the reply (really appreciated). I still don't know where this was voted on by the "community", last vote I recall was Notch and his moon vote I accept the Mojang stance but would like to challenge you on your "do not fix since it will break OLD builds" position. This awesome new launcher supports versions and so you really shouldn't worry about breaking RS builds anymore. When a map maker builds a map I would hope them to be expected to know that it will possibly only work with that build (at least that's how I think when I play with making maps.. and I happily fix my RS if it does break because I know it's for the greater good as well as efficiency). Anyway, thanks again and keep up the good work. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
Challenge accepted. If you don't want to see a bunch of pistons being placed click here instead. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Yes for predictability’s and consistency’s sake! Please “break” some stuff by fixing a bug that was declared as feature after it was reported. A bug is still a bug, even if you call it “feature”. | |||||||||||||||||||||||||||||
| Comment by [Mojang] Grum (Erik Broes) [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Actually it is working as intended because it is a bug turned feature by demand of the community. Would you rather have is break all existing maps and make certain constructs impossible? Try making a 10x10 wall of pistons that all move together without this quasiconnectivity (use that mod above). If you can make alternatives for all the existing structures we might consider it. | |||||||||||||||||||||||||||||
| Comment by Brandon [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Yup, I'm quite frustrated at this "resolution" as well. SethBling used this once and now we're going to keep it forever because he told Grum that Buds were useful (he trained him in redstone). Community proven solution (to make most everyone happy) is a bud block and killing quasi connectivity, but that won't happen because of the Jeb door which is extremely ancient, but hey, it's Jens most proud creation apparently. Ooh, and lets not forget we can't release something that will break even 1 RS build. RS community has been dying and now I see exactly why... sad thing was that after 3 years it was only RS that kept me playing. I do not mod my game, the devs have been given the code for the solution to this bug but they choose to live in denial and warmly welcome most all undocumented features. I'm done. Enjoy a broken and illogical game everyone. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
So, someone doesn't make a change to a behavior that was in the game for 2 years, and you get extremely mad? | |||||||||||||||||||||||||||||
| Comment by Daniel "Glampkoo" [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
"What? There is a feature that I consider a bug and I want my money back" Calm the heck down. | |||||||||||||||||||||||||||||
| Comment by Paul Pinterits [ 10/Jul/13 ] | |||||||||||||||||||||||||||||
|
Works as intended? ARE YOU FREAKING SERIOUS? I'll go demand my money back and then I'm gone for good. Bye. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 03/Jul/13 ] | |||||||||||||||||||||||||||||
|
I wrote a mod that removes this behavior: http://www.minecraftforum.net/topic/1874049-sspsmp-pistondispenser-quasiconnectivity-fix/ | |||||||||||||||||||||||||||||
| Comment by t00thpick1 [ 03/Jul/13 ] | |||||||||||||||||||||||||||||
|
Is there any chance an option in the form of a GameRule could be added that would allow servers to toggle whether pistons work with current behavior or with the behavior asked for by this bug report? | |||||||||||||||||||||||||||||
| Comment by [Mod] Torabi [ 02/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Grum: What about pistons being powered/unpowered, but not updating their state until they receive a separate block update? Is that WAI, or should it be filed as a separate bug? | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 02/Jul/13 ] | |||||||||||||||||||||||||||||
|
Tee hee. Yes, "Won't Remove", or "Promoted to official feature", sound like better resolutions than "Works as intended". Either way, it won't change. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 02/Jul/13 ] | |||||||||||||||||||||||||||||
|
His comment implies that it is a bug that they won't fix "because users love bugs." | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 02/Jul/13 ] | |||||||||||||||||||||||||||||
|
Both of those imply some state; Won't fix implies that it is a bug, while works as intended implies it was intended in the first place. Thus, we need something like "Won't remove". | |||||||||||||||||||||||||||||
| Comment by Tavis [ 02/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Grum In that case wouldn't a more appropriate resolution be "Won't Fix?" | |||||||||||||||||||||||||||||
| Comment by [Mojang] Grum (Erik Broes) [ 02/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Gerrard Lukacs: because users love bugs ... and they want us to keep them. So we'll just do so. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 02/Jul/13 ] | |||||||||||||||||||||||||||||
|
@Tim Gunderson | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
I can see why this behavior might be marked as intended for pistons, but can we please have any explanation for why it exists on droppers and dispensers as well? Does Mojang intend to migrate this behavior to other blocks, such as command blocks, hoppers, and TNT as well? | |||||||||||||||||||||||||||||
| Comment by Tavis [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
The 2 by X wall would be possible without quasiconnectivity by alternating powering the sides and backs of the pistons or blocks behind the pistons, e.g. power the back of the bottom ones, sides of the second ones, back of the third ones, etc. | |||||||||||||||||||||||||||||
| Comment by SewdiO [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
@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 : 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 ! | |||||||||||||||||||||||||||||
| Comment by Tim Gunderson [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
I'm presuming that the BUD behavior is being marked WAI, but I'm curious if redstone blocks on top of a stuck-extended piston are WAI, because no amount of block-updating can make that thing retract. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
Show what you are trying to do, and I will show you how to do it. | |||||||||||||||||||||||||||||
| Comment by CJ [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
------ and you guys say these problems can be worked around? show me how! cause I have nor freak clue how to make stuff that should logically work, do so when because of this weird happening, don't. (again, tried halfslab, did freakin nothing) | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
Thank you grum for intendifiying it. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
I'd like to thank Mojang for officially confirming that this is intended and will not be changed. Meanwhile: Anyone got a good way to make a tall, two-wide set of pistons work without this? We've run into this issue on other builds by accident, and while small builds can be adjusted, I don't see how to do it on bigger stuff. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
I know people are saying that you can use halfslabs or stairs to isolate pistons to get the "proper" behavior. I'd like to actually SEE a working system, with 4 pistons in a 2x2 vertical grid, each one activateable independently from the others. And, as I say that, I realize that a trivial solution is to power the bottom two "normally", and the top two from "above". So make that a 2 wide x3 tall grid – how do you get the middle ones to work without issues? | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
|
And also, it is realy only a problem when the top piston "jams", there are other uses. And you can avoid it any way. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 01/Jul/13 ] | |||||||||||||||||||||||||||||
GAH. | |||||||||||||||||||||||||||||
| Comment by adsfasdf [ 30/Jun/13 ] | |||||||||||||||||||||||||||||
|
this really should be fixed, using the BUD designs that don't rely on quasi are better any way, and this prevents a lot of cool things with redstone blocks from being done like: piston piston because the redstone block powers the lower piston even though they aren't touching. Please remove this mojang! | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Jun/13 ] | |||||||||||||||||||||||||||||
|
The orange blocks are just placeholders for repeaters or similar blocks. | |||||||||||||||||||||||||||||
| Comment by Matt Lafreniere [ 26/Jun/13 ] | |||||||||||||||||||||||||||||
|
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. | |||||||||||||||||||||||||||||
| Comment by David Harmon [ 26/Jun/13 ] | |||||||||||||||||||||||||||||
|
Tavis has got it – the problem is getting power to pistons on several adjacent levels, which is awkward without quasiconnectivity, even with the expensive "orange blocks". And yeah, not being able to retract a BRS vertically is slightly annoying, but on consideration I can live with it. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Jun/13 ] | |||||||||||||||||||||||||||||
|
I don't think anyone cares too much about redstone blocks. The uselessness of sticking a redstone block on top of a piston is immediate obvious so people don't do it. A more annoying point is that mechanisms can interact with no immediately obvious symptoms of that interaction. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
The power but don't update approach worked well until you stopped being able to use fence gates to update pistons. | |||||||||||||||||||||||||||||
| Comment by Matt Lafreniere [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
How does quasiconnectivity help with piston walls as mentalmouse 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. | |||||||||||||||||||||||||||||
| Comment by [Mod] Torabi [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
Although Dinnerbone's tweet specifies that Pistons can be powered from two blocks above them, neither he, nor any other official source, has ever indicated that that the BUD behavior (pistons not extending/retracting without a separate block update even though they're powered/unpowered) is intended. As mattlafy has said, there are three possible directions to go with this: I think the last option is clearly the best, though there are of course going to be people who are comfortable with the current behavior, and don't want to have to change. I just think it's better to do the the that makes the most sense, rather than being held hostage by the past. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
Yeah, I wish there were a happy middle. If only we could have 2 types of pistons, one that had it and one that didn't. But, as a mod said, that would be confusing. | |||||||||||||||||||||||||||||
| Comment by David Harmon [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
The quasiconnectivity feature may be tricky to use, but it makes pistons far more versatile and useful. Besides the BUD thing, others have mentioned piston walls, and I've also seen it used for other circuits. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
I supported power and no update, but power and an update works now since nothing gives updates anymore. You used to be able to do | |||||||||||||||||||||||||||||
| Comment by Matt Lafreniere [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
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" 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? | |||||||||||||||||||||||||||||
| Comment by CharlesC [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
Remember 2 glitches that people wanted to keep : Here we have 2 solutions : Arguing is pointless because there are always people who want "nothing changes" and other "everything changes". Only Mojang will do (or no)t things related to this. | |||||||||||||||||||||||||||||
| Comment by karstvgl [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
Because you can place a normalblock and place redstone over it. U can use a upsidedown halfslab to fix this. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
Please explain what you mean, "just use a half slab". I do not understand your comment. | |||||||||||||||||||||||||||||
| Comment by karstvgl [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
easy to fix. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
The claim "it will break builds" is not acceptable. Piston timings changed, breaking systems. Redstone torch accuracy broke from 125 single player to 125 multiplayer and everything since, breaking systems and actually giving some timing loops zero chance of working properly. (Bug number ... 2523, https://mojang.atlassian.net/browse/MC-2523). The point is this: We've (our server) had "buds" from what should have been simple piston builds that DID NOT WANT BUD BEHAVIOR!
It has interfered with some relatively simple designs. If there is a good reason for this – if there is something that you want to do with pistons that cannot be done without this – then please indicate what it is. "Block Update Detector" is not a good reason. That should be a new block, perhaps using nether quartz. | |||||||||||||||||||||||||||||
| Comment by Zatherz [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
Like Dinnerbone said, pistons CAN be powered with 2 blocks away, and not only with redstone blocks. Try to create something like that: i ........ Try to build it in ANY versions after the version where the pistons are added (1.7 probably?) | |||||||||||||||||||||||||||||
| Comment by CJ [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
sighs those who use this bug, a single bluck for an update detector is far better than a strange pistons switch setup anyways. get rid of your piston and switchs and put in the detector block. big woop. "but my redston will break!" do as I just said and it will be fixed. to lazy to go and fix the redstone? then you didn't need it anyways. basically all the people who have used this, don't want it to go cause they've used it. | |||||||||||||||||||||||||||||
| Comment by karstvgl [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
I still think we should stop this. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
… but as of now we have broken pistons and bug using as BUD mechanism. | |||||||||||||||||||||||||||||
| Comment by Keybounce [ 25/Jun/13 ] | |||||||||||||||||||||||||||||
|
Block update detectors are useful for people who want block update detectors. Properly working pistons are useful for people who want properly working pistons. If you have broken pistons that act as buds, then people who need proper pistons are out of luck and have no work-around. If you need a bud, and pistons don't do buds, then you have options. Perhaps not compact. If you need both compact buds, and proper pistons, then you have to break the broken pistons and add in a proper bud block. | |||||||||||||||||||||||||||||
| Comment by mike [ 23/Jun/13 ] | |||||||||||||||||||||||||||||
|
Confirmed in 12w25b and c | |||||||||||||||||||||||||||||
| Comment by Caleb J [ 15/Jun/13 ] | |||||||||||||||||||||||||||||
|
I don't see why this isn't fixed by now. If they consider quasiconnectivity a feature, then it is a useless and VERY annoying one. There are so many ways to make bud switches besides this bug; an example is sethblings video here: http://www.youtube.com/watch?v=Qp4_oQuReuE | |||||||||||||||||||||||||||||
| Comment by Tavis [ 08/Jun/13 ] | |||||||||||||||||||||||||||||
|
Vanilla Minecraft has a ton of things that don't "fit" Minecraft. There is absolutely no precedent for most of the things they added in 1.5. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 08/Jun/13 ] | |||||||||||||||||||||||||||||
|
Better than wolves has a ton of things that don't "fit" minecraft. | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 08/Jun/13 ] | |||||||||||||||||||||||||||||
|
Well if a BUD block makes you shudder then stay away from Better Than Wolves, because it has one | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 25/May/13 ] | |||||||||||||||||||||||||||||
|
I've been saying that it should be separated into several parts: Dropper/Dispenser quasiconectivity, General piston quasiconectivity, and redstone block quasiconectivity. | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 24/May/13 ] | |||||||||||||||||||||||||||||
|
William Pearson, BUD does not necessarily need to be the name or even the functionality. A number of other concepts could explain a very similar set of behavior - for example, a Motion Sensitive block of some sorts. Such a block need not accommodate invisible block updates such as sapling maturity state, but could accommodate the majority of practical uses (block removal/placement/motion, door opening/closing, etc.). This would not be unnecessary, as it would implement a block with the feature of this sort of behavior, rather than relying on a number of implementation side-effects which keep changing (see And even if integrating BUD behavior into pistons "worked well" and actually made sense, why leave this bug for Dispensers and Droppers? I've had to redesign countless circuits thanks to interference in signals because Dispensers and Droppers exhibit the same behavior. | |||||||||||||||||||||||||||||
| Comment by Matt Lafreniere [ 24/May/13 ] | |||||||||||||||||||||||||||||
|
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? | |||||||||||||||||||||||||||||
| Comment by Tavis [ 24/May/13 ] | |||||||||||||||||||||||||||||
|
A BUD would be a block that emits a redstone signal when a block next to it changes. The implementation could vary, but the basic idea makes sense. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 24/May/13 ] | |||||||||||||||||||||||||||||
|
As I have said before, the main cause of annoyance with this behavior is when you get it when you don't expect it. Specifically, Redstone blocks and dispensers. | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 24/May/13 ] | |||||||||||||||||||||||||||||
|
They've already removed several BUD features (e.g. fencegates, doors, cauldron contents, etc. no longer work with BUDs). They said if the BUD gets completely removed, they'll make a dedicated replacement - one that won't gradually decay into uselessness with every single bugfix. Would you honestly have the BUD in its current, stripped form, or would you rather have a BUD that Mojang openly calls a feature and doesn't break more and more of with every update? And can you please tell me how it's even remotely useful to have this bug apply to dispensers and droppers? I've yet to see any compact BUDs or other practical things make use of that - it mostly just causes problems. Also, there are plenty of BUD designs that don't rely on this bug, and they're very compact and significantly less bug-like in appearance as well. | |||||||||||||||||||||||||||||
| Comment by karstvgl [ 24/May/13 ] | |||||||||||||||||||||||||||||
|
This is not a Bug/Glitch it is really really usefull for redstone meganics. If they fix this, the BUD gets removed again. Dont remove this awesome feature!!! | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 16/May/13 ] | |||||||||||||||||||||||||||||
|
What was that with the new attachments of exe's? Were they viruses? | |||||||||||||||||||||||||||||
| Comment by fake fakes [ 15/May/13 ] | |||||||||||||||||||||||||||||
|
In 13w19a | |||||||||||||||||||||||||||||
| Comment by Jacob Vorland [ 14/May/13 ] | |||||||||||||||||||||||||||||
|
A block being powered by a repeater where the redstone block is in this post has the same effect | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 29/Apr/13 ] | |||||||||||||||||||||||||||||
|
Just a note to people who still feel like defending this bug's existence because of their use in compact BUDs: There are several very compact piston BUD designs which don't even rely on this bug. I personally will be using these until an official BUD block is created (oh, and here's an idea: an official BUD block could be able to output 15 unique signals for different types of block updates, going with 1.5's theme of analogue output). There's no excuse for leaving this bug in the game except "it will break pre-existing builds". That wasn't enough to keep Mojang from eventually fixing the dispenser powering bug, and I had to replace roughly 226 mechanisms relying on the bug in an adventure map. It shouldn't be a valid excuse here if it wasn't there. Fixing this bug won't make any Minecraftian problems impossible to solve - at most, it'll change your solution a bit here and there, and I'm sure we'll see revised compact piston door designs well within a week of the snapshot that fixes it. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 27/Apr/13 ] | |||||||||||||||||||||||||||||
|
Ok, here is why it should not power with Redstone blocks: | |||||||||||||||||||||||||||||
| Comment by David Harmon [ 10/Apr/13 ] | |||||||||||||||||||||||||||||
|
If you place an upward facing piston, then put a block of redstone on top of it, it does not extend. This is reasonable, but if you trigger the piston some other way, it will not retract. Further experimentation indicates that an upward-facing piston can be powered in general from the block above the extended shaft, but not from the block they would be pushing. However, horizontal pistons can nowise be powered from the block at their face, extended or retracted. This seems peculiar, and I'm guessing it's connected to this. ETA: Updates don't seem to help, as I tried placing and breaking blocks adjacent to piston, shaft, and BoR | |||||||||||||||||||||||||||||
| Comment by Mattias Kermer [ 07/Apr/13 ] | |||||||||||||||||||||||||||||
|
I as well am experiencing such problems with pistons although i am not sure weather or not to report it as a new bug. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 03/Apr/13 ] | |||||||||||||||||||||||||||||
|
I was using a different definition of signal strength in which "strong" is coming from anything that isn't a block and "weak" is coming from opaque blocks powered by a strong signal. It's an implementation detail that only applies to a special case involving pistons, and the end result would actually be quite intuitive to players. | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 02/Apr/13 ] | |||||||||||||||||||||||||||||
|
Yeah, I've been talking about strength since the discussion started. I might have misunderstood, but I thought someone had commented that it should matter what signal strength a mechanism is powered by. | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 02/Apr/13 ] | |||||||||||||||||||||||||||||
|
Wait, have you been talking about the redstone's signal strength this whole time? Because strong/weak is something completely different, as opposed to the signal strength conveyed by the brigthness of a wire. If you mean signal strength, that actually ranges from 0 to 15, not 0 to 16. Most mechanisms don't care what exact strength it's being powered with: 0 means not powered, anything else means powered. The only exception to this is the comparator, and special reactions to different signal strengths are kind of its entire purpose. In your example, the power cuts out at the 16th block. If the 16th block is a repeater, it can take the (very weak) signal at the 15th block, and output a refreshed signal. If the 16th block is a mechanism, such as a door, dispenser, or piston, it will still be powered. It already is basically how you suggested: you just have to remember to restrengthen your signal every 16 blocks. Hint: if the wire isn't producing particles, that means its signal strength is 0 - make sure your wires aren't longer than 15 without repeaters. If there are particles, it has at least 1, which is enough to power things. | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 02/Apr/13 ] | |||||||||||||||||||||||||||||
|
Okay. You have a line of Redstone wire, 20 blocks long. After 16 blocks, then the Redstone current needs to be refreshed with a repeater. But if we don't include a repeater, it cuts out at 16. As long as I don't put a mechanism past 16 blocks, it should power, as there is still Redstone current in that part of the wire. So, even though the power cuts out after 16 blocks, it's still power. And, if any mechanism accepted any level of power, then you would only need to remember to restrengthen it after 16 blocks. | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 02/Apr/13 ] | |||||||||||||||||||||||||||||
|
Can you give an example where you have to purposely make your power weak or strong for a machine to activate? Redstone wire is not a machine, and it is the only thing that cares whether your power is weak or strong. Can you come up with a solution that doesn't get rid of strong/weak power, but somehow still manages to make it so the player never has to worry about its existence? | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 02/Apr/13 ] | |||||||||||||||||||||||||||||
|
@Gerrard: | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 02/Apr/13 ] | |||||||||||||||||||||||||||||
|
The change log was erronous; try it yourself. This bug has not been fixed in Minecraft 2.0, red, blue, or purple flavors. In fact, it also fails to spawn redstone bugs, which is itself a bug. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 01/Apr/13 ] | |||||||||||||||||||||||||||||
|
Fixed in 2.0! See Mojang.com | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 01/Apr/13 ] | |||||||||||||||||||||||||||||
|
FireHunterX,
Strong and weak power has been in the game ever since redstone was added - even since before the repeater was added. It's not an unreliable or inconsistent concept at all. Blocks can be strongly or weakly powered, and this is based solely on what is powering them. Redstone wire only weakly powers blocks, while redstone torches, repeaters, comparators, buttons, pressure plates, etc. strongly power them. The only difference between strong and weak power is that a weakly-powered block will not power redstone wire: it still powers all other redstone devices. If the distinction between strong and weak power did not exist, then you could alternate blocks and wire indefinitely for a zero-delay wire which never loses power. You also would be unable to isolate wires in most situations. Consider the following design: #_ That's a cross-section of a simple setup to have two wires run in parallel in a 2x2 space. # represents blocks while _ represents redstone wire. Right now (and ever since redstone was first created), this works: the wires do not touch and do not interfere. Under your proposal, the wire on the top-right would power the blocks below it (as it does right now), and these blocks would propagate that power to the lower line of wire: the wires are not isolated. I don't honestly see why you're complaining here. All mechanisms, with the exception of redstone wire, do accept both strong and weak power, and treat them in the exact same way. Redstone wire accepts only weak power, else countless issues would be caused (difficulty in isolating wires, crash-inducing zero-tick loops from self-sustaining wire, etc.). No device only accepts strong power and not weak power - literally the only difference between strong and weak is that strong can power wires in addition to everything weak can power. All redstone components capable of outputting power will output strong power, with the exception of redstone wire and blocks, which output weak power (note that this does not make wires/blocks weakly powered themselves, as they can both still power wires. The strong/weak rule only applies to blocks being powered). The rules are very consistent and exist for good reasons; remove the concept altogether and you'll break far more redstone than any Minecraft update ever has. | |||||||||||||||||||||||||||||
| Comment by Daniel "Glampkoo" [ 01/Apr/13 ] | |||||||||||||||||||||||||||||
|
If we all want a BUD block like they promised us someone(me) should make a petition: •insert ad here• http://www.change.org/petitions/mojang-ab-minecraft-developers-add-bud-block-to-minecraft | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 01/Apr/13 ] | |||||||||||||||||||||||||||||
|
Oh my god why? So like I already said, implement a BUD Block and keep the functionality of pistons. It's like saying the majority vote loses! Oh, and what exactly did 1.5 do to Redstone? It's unbelievably unreliable now! Strong power, Weak power, same thing! It's power regardless! All mechanisms should accept POWER. Not WEAK POWER only or STRONG POWER only, just POWER. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 31/Mar/13 ] | |||||||||||||||||||||||||||||
|
Dispensers have always worked that way, but since they ejected items on every redstone update it wasn't nearly as noticeable. If you had something powering one and you powered it with something else it would still fire, now it won't. Fixing the original bug revealed a second bug that needs to be fixed just as badly. There are some special cases that pistons need to take into consideration, but that doesn't require quasiconnectivity. | |||||||||||||||||||||||||||||
| Comment by WolfieMario [ 31/Mar/13 ] | |||||||||||||||||||||||||||||
|
"Pistons do(and always did) get powered from 2 blocks above" This fails to hold true for dispensers, but suddenly that's how it works now. I already had to replace about 226 dispenser-utilizing devices (that's the number of individual devices, scattered throughout a 113-room dungeon) after the dispenser powering bug was fixed - now, I'll accept that, as the change made was a fix to a bug, making redstone more consistent. However, this change does not make any sense, and I'm afraid I have no trivial way to work around it until it is fixed - either it won't work now, or it won't work once this bug is fixed (if ever). I'd personally rather that Mojang remove this nonsensical behavior altogether, and make pistons, droppers, and dispensers behave the same as any other redstone component would - with no spooky action from a distance. As far as BUDs, I'm sure most of the community will agree that an actual, bug-free BUD block is the best option, rather than keeping bugs like this in the game for backwards-compatibility and letting them grow even less stable. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 28/Mar/13 ] | |||||||||||||||||||||||||||||
|
@kbk A few things I can think of that would break with this implementation: All devices relying on quasiconnectivity, piston walls powered by redstone torches, and pulse limiters using a repeater and a block attached to an upward-facing sticky piston. The other option I presented would likely result in the desired functionality being unimplemented in new repeater-like devices. | |||||||||||||||||||||||||||||
| Comment by kbk [ 28/Mar/13 ] | |||||||||||||||||||||||||||||
|
@dirk | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 28/Mar/13 ] | |||||||||||||||||||||||||||||
|
What about a radical approach? Only directly powered (directly powered block touching the base, Redstone torch, powered Restone dust) pistons extend. | |||||||||||||||||||||||||||||
| Comment by kbk [ 28/Mar/13 ] | |||||||||||||||||||||||||||||
|
@tavis | |||||||||||||||||||||||||||||
| Comment by Tavis [ 28/Mar/13 ] | |||||||||||||||||||||||||||||
|
What I think is your point: "Don't let anything be powered by any blocks in front of it." That would work for the case where redstone blocks make pistons get stuck, but it's still only fixing one symptom of the problem. Repeaters and dispensers don't need that limitation to function correctly. Pistons have that limitation so they don't automatically break any redstone torches that happen to be placed in front of them. | |||||||||||||||||||||||||||||
| Comment by kbk [ 27/Mar/13 ] | |||||||||||||||||||||||||||||
|
IMO it'd be a good solution to redstone block problem when redstone devices that have a "face" (namely droppers, dispensers, pistons and future similar blocks) would be unable to receive power diagonally through their "faces" (similar to repeaters/comparators). This has only been implemented with pistons and for the directly opposite strongly powered blocks only, which results in such redstone block (mis)behaviour. Such partial implementation doesn't include other blocks in 3x3x2 space in front of a device, allowing for undue diagonal and - in the case of device facing upwards - vertical powering. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 27/Mar/13 ] | |||||||||||||||||||||||||||||
|
Better Than Wolves has had a functional non-tile-entity BUD block for a long time. The pseudocode for your suggestionwould be if (!(block at y + 2 == redstone)) if (block at y + 2 is providing weak power downwards) return powered; located in BlockPistonBase.java. If they ever added more pushable powered blocks they would need to do if (!(block at y + 2 == redstone || block at y + 2 == pushablePower || block at y + 2 == anotherPushablePower ...)) if (block at y + 2 is providing weak power downwards) return powered; That only fixes one problem which only surfaced after this bug was initially reported. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 27/Mar/13 ] | |||||||||||||||||||||||||||||
|
The reason for no bud block is that a bud block would be a pain, and it would probably need a tile entity if it were to be customizable. But if it had a tile entity, there would be no way to move it, so it would break bud trapdoors, and other things. Oh, and the explanation on why it works is great. Oh, and separating the redstone blocks and repeaters/levers may be good because it makes pistons jam and become unusable. For this, it could be that a redstone block doesn't power pistons facing upwards from 2 blocks above. (see image) | |||||||||||||||||||||||||||||
| Comment by Tavis [ 27/Mar/13 ] | |||||||||||||||||||||||||||||
|
If you are correct redstone lamps would exhibit the same behavior. They don't. In this diagram the redstone is strongly powering the block which is weakly powering the spaces next to the block which do not transmit any power. The piston is below one of those spaces, therefore it should not receive power. If you replaced the piston with a redstone lamp, which can be weakly powered, it would not light up. _ █ ▒┫ There are two distinct definitions of the term "weak" power. One of them refers to a block being able to activate redstone devices next to it by "weakly" powering them, and another refers to any power provided by redstone dust, which redstone dust will happily ignore if it isn't connected to the source of that power. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 27/Mar/13 ] | |||||||||||||||||||||||||||||
|
FireHunterX: The strong power can travel two blocks downward becoming weak power, that is one of the functions of redstone, redstone dust can only pick up strong power while devices like pistons catch the weak power. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
The behavior with redstone blocks is identical to the behavior of blocks powered by repeaters or levers. The only difference is that redstone blocks can't be turned off. Therefore it is the same bug. I agree with separating the dispenser bug. | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
The point is: If it happens, then it should be consistent! But this only happens on a certain side of a piston, so my question is "Why?" | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
This page should probably be divided into several reports: The behavior with droppers and dispensers, the behavior with Redstone blocks, and the behavior with pistons in general. The behavior that let dispensers fire multiple times (on rising and falling edges) was useful. Real-life circuitry is all about finding quirky behaviors and exploiting them. The transistor, a fundamental element of computing, essentially exploits a behavior that silicon exhibits. The effect of droppers and dispensers experiencing quasiconectivity is extremely annoying BECAUSE it is unavoidable. The same thing can be said for piston quasiconectivity with Redstone blocks. But with pistons in general, it is always avoidable using slabs, except in cases where the piston would still be powered if the behavior was removed. After: | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
Well, if this is supposed to be intended, then: The whole reason Redstone blocks were implemented were as a portable power source. Well, they aren't as portable as you would expect them to be, because you can't use them vertically (up). This is a really, really, REALLY annoying issue. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
Jeb implemented pistons, but I don't think anyone at Mojang understands the issue fully. At most they're trying to not break stuff and avoid having to implement a BUD block. 140 plus people have reported duplicates of this bug. I would estimate that about 30 of those people reported the dispenser/dropper version, which leaves 110 who reported the piston version. I don't know of any other bug that is that well known but still that hard to search for. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
Travis Hansen: This is not my argument, the fact that I am trying to reinstate is Dinnerbone's confirmation of that side of this issue being intentional. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
"Worlds do (and always have) an invisible wall around them." - Anyone before InfDev. "Redstone torches do (and always have) fired one tick sooner if you orient the stack in the north-south direction." - Anyone before 1.5 "Pistons do (and always have) been able to duplicate diamond blocks." - Anyone before that was fixed Incorrect or illogical behavior doesn't suddenly become correct or logical just because it has always worked that way. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
CJ: That is intentional "Pistons do(and always did) get powered from 2 blocks above" - Quote courtesy of Dinnerbone. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 26/Mar/13 ] | |||||||||||||||||||||||||||||
|
Yes, the whole Redstone mechanics are a long-term issue of inconsistent and unpredictable behavior. Not only affects droppers, dispensers and pistons but all contraptions. They mostly work because of all that weird Redstone quirks starting with “directional” problems like the north-west-problems or the weird diagonal powering behavior and not ending here (top-down powers, but sideways not?). I’m pretty sure this will not be fixed until Minecraft 2.0, because it needs major Redstone mechanics changes to make it completely consistent and predictable. (And IF Redstone will ever be fixed it likely breaks ALL Redstone stuff people built so far.) | |||||||||||||||||||||||||||||
| Comment by David N. Thomas [ 25/Mar/13 ] | |||||||||||||||||||||||||||||
|
I have also noticed that pistons seem to be erroneously powered when the piston arm is extended into a space that would be powered. For example, place a piston 1 below and 1 below a block such that the extended arm will be directly below said block. Then place a redstone torch on the back of the block to power the piston. Now place a button on the block and press it. The only time the piston retracts is for the brief moment when the button power has ended and the torch has yet to update. In other words, the extended piston SEEMS to be powered both by the torch AND by the button if it is extended. Removing the torch and pressing the button does not power the piston which indicates it is not getting power diagonally from the button but is instead being powered through the piston arm. Whether this is a long-standing issue or not it is still irrational if not inconsistent behavior that does hinder the process of making some rational designs compact, even if it can be used in irrational ways to make other designs compact. | |||||||||||||||||||||||||||||
| Comment by CJ [ 25/Mar/13 ] | |||||||||||||||||||||||||||||
|
it seems that when a sticky piston (and I imagine normal pistons to) push a redstone block in any direction, they can the retract when no more power is being sent to them. with the exception of when the piston is pushing a redstone block up. when pushing a redstone block up the piston will remain extend even when power is no longer hitting the piston. also, when sticky pistons are placed side by side faceing up, and a redstone block is placed ontop 2 or more pistons beside each other, the first of the 2 pistons to have a redstone block placed on top will extend and then stays powerd by the second redston block on the piston beside it, it will refuse to go down even when the redstone block ontop of it is broken. it would seem that when the second redstone block is placed beside the first, the power of the second redstone block travels through the first redstone block and then down to the piston below it, and once that piston extends it would seem that second redstone block then continues powering that piston through the extended part. but that's just my theory. but also, with 2 upward faceing pistons are side by side with a redstone block placed atop 1 piston, and redston power is sent through a repeater into the redstone block, both pistons extend. but I have only seen this happn in my world once and have not been able to re-create this last glitch. now I imagine some of what I said has been stated already, and I have read some of the comments. but either I did not understand it in the same way that I have just written it, which would then make this explination of it plenty helpful to some people may have also not totally been able to understand other explinations of it in the way that they may with this one, or I'm try to adress a differen part of it. | |||||||||||||||||||||||||||||
| Comment by dirk (switched to Minetest) [ 23/Mar/13 ] | |||||||||||||||||||||||||||||
|
As described in the so-called “dublicate” this happens under other conditions, too: https://mojang.atlassian.net/browse/MC-12639 | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 22/Mar/13 ] | |||||||||||||||||||||||||||||
|
Why is this not fixed yet? It's been around for SOOO LOOONG! | |||||||||||||||||||||||||||||
| Comment by Daniel "Glampkoo" [ 21/Mar/13 ] | |||||||||||||||||||||||||||||
|
Oh my god so many dups! | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 20/Mar/13 ] | |||||||||||||||||||||||||||||
|
@ Dominik Banaszak It seems to still be annoying, can you give me a practical use of the part with redstone blocks? It latches the piston permanency. <rant>General quasiconectivity is nice, but these specific cases, the ones that Mojang wants to keep, seem very useless and inhibiting. </rant> | |||||||||||||||||||||||||||||
| Comment by Zatherz [ 20/Mar/13 ] | |||||||||||||||||||||||||||||
|
The piston bug with redstone block isn't a bug. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 18/Mar/13 ] | |||||||||||||||||||||||||||||
|
The droppers/dispensers being powered the same way is a different bug and should be marked as related instead of duplicate. Pistons are not and should not be powered the same way as most other blocks, and both being in the same report prevents one from being marked resolved while the other isn't fixed. | |||||||||||||||||||||||||||||
| Comment by Julian Wright [ 18/Mar/13 ] | |||||||||||||||||||||||||||||
|
Ok that makes more sense. To test it I removed the middle piston, and now the other two pistons only extend or retract after an adjacent block update. Regardless, something has changed between 1.4.7 and 1.5 with respect to these updates, such that now the middle piston is updating the two side pistons whereas before it did not. Maybe it's the new 2-ticks-to-extend piston timing. I think I'll just add my vote to this issue and hope it gets corrected soon. | |||||||||||||||||||||||||||||
| Comment by Anon Ymus [ 18/Mar/13 ] | |||||||||||||||||||||||||||||
|
That is only because the extending piston is updating the other pistons, not the block being powered itself. (See | |||||||||||||||||||||||||||||
| Comment by Julian Wright [ 18/Mar/13 ] | |||||||||||||||||||||||||||||
|
If you build the structure referenced in my report Therefor, under 1.4.7, the middle block is powering all three pistons, but only updating the middle one. If you then try it under 1.5, you will find that powering the middle block causes all three pistons to extend. Hence my observation that it appears that updates are being propagated now. Ultimately though, my main problem is that I don't think the two pistons to the sides should be getting power from the middle block, let alone needing to be updated. | |||||||||||||||||||||||||||||
| Comment by Anon Ymus [ 17/Mar/13 ] | |||||||||||||||||||||||||||||
|
I cannot confirm that that block is updating the piston. | |||||||||||||||||||||||||||||
| Comment by Julian Wright [ 17/Mar/13 ] | |||||||||||||||||||||||||||||
|
Looks like my recent report But I still have a problem with the other half of the bug - pistons diagonally adjacent to a powered block shouldn't be powered by it. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 16/Mar/13 ] | |||||||||||||||||||||||||||||
|
The behavior with dispensers and droppers allows for dispensers buds. Or more like dispenser rs nor latches without a reset. So it is annoying. The piston behavior can always be escaped, usually with a slab where it would receive power. Hopefully this helps. | |||||||||||||||||||||||||||||
| Comment by George Gates [ 16/Mar/13 ] | |||||||||||||||||||||||||||||
|
EDIT: Auto-parsing FTW, thanks. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 16/Mar/13 ] | |||||||||||||||||||||||||||||
|
@George Gates, when referring to other issues, you do not have to use a complete link to the issue, you can just use something like | |||||||||||||||||||||||||||||
| Comment by Eddie [ 15/Mar/13 ] | |||||||||||||||||||||||||||||
|
Well, the problem I reported | |||||||||||||||||||||||||||||
| Comment by George Gates [ 15/Mar/13 ] | |||||||||||||||||||||||||||||
|
This bug has existed for many, many versions, it's not new to 1.5. If your redstone contraptions broke, it's most likely due to this change... Or this new bug... | |||||||||||||||||||||||||||||
| Comment by Eddie [ 15/Mar/13 ] | |||||||||||||||||||||||||||||
|
Many of my contraptions are broken after updating to 1.5 from 1.4.7. I hope they change this soon. :C | |||||||||||||||||||||||||||||
| Comment by Griffin [ 13/Mar/13 ] | |||||||||||||||||||||||||||||
|
Seriously? 1.5, the update meant to make redstone and pistons more reliable, didn't fix this hair-puller of a bug? | |||||||||||||||||||||||||||||
| Comment by Richard Walton [ 12/Mar/13 ] | |||||||||||||||||||||||||||||
|
This very odd piston behavior has been the bane of my existence. using pistons in a compact fashion when they pull power THROUGH the air makes me pull my hair out. It is a bug that needs fixed. | |||||||||||||||||||||||||||||
| Comment by Anonymous User [ 08/Mar/13 ] | |||||||||||||||||||||||||||||
|
I honestly think the redstone blocks should power the pistons like they do currently, because you can make really nice RS-nor latches, for displays. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 07/Mar/13 ] | |||||||||||||||||||||||||||||
|
1: It would still behave in a buggy manner | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 07/Mar/13 ] | |||||||||||||||||||||||||||||
|
@Tavis Hansen, I never said that Redstone blocks should be removed. Just that they don't power pistons like they do, fixing that problem. Also, the bud piston idea would probably be the best compromise, is there anything wrong with that? | |||||||||||||||||||||||||||||
| Comment by Tavis [ 07/Mar/13 ] | |||||||||||||||||||||||||||||
|
@William Pearson, redstone blocks will enable many of the things that otherwise wouldn't be possible without quasiconnectivity. Things may not be as compact, but why do they need to be? If you really want something, you can make space for it. As for the benefits of removing quasiconnectivity, we don't really know what will become possible because we haven't had a chance to use pistons that aren't affected. One thing that will definitely benefit is the ability of players who are inexperienced with redstone or the intricacies of block updates to design complex things. | |||||||||||||||||||||||||||||
| Comment by Tim H [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
@William Pearson: Keeping a bug in the game that destroys legit and logical mechanisms in order to allow other illogic mechanisms that exploit bugs and were never meant to be in the game in the first place, where's the logic in that? If certain things like some piston doors or 1x1 displays can only be achieved by exploiting bugs then it has to mean one of those two things: | |||||||||||||||||||||||||||||
| Comment by Tavis [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
Dispensers did the same thing in 1.4.7, it was just less noticeable because they only responded to redstone-initiated block updates. Simple removal of an "or" statement would fix that one. They are opaque, so putting two on top of each other with a dispenser facing them would have the desired effect anyway. | |||||||||||||||||||||||||||||
| Comment by James [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
perhaps give pistons, dispensers and droppers an option to toggle this bug, so it could be a feature. If that was possible everyone would be satisified I reckon | |||||||||||||||||||||||||||||
| Comment by Tails [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
Since 13w10b Dispensers and Droppers show the same behaviour as Pistons when powered diagonally or 2 blocks above. | |||||||||||||||||||||||||||||
| Comment by James [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
A bud piston would be good | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
A bud block can NOT replace the functionality of quasiconectivity, because it is used in other cases (EG piston doors). That's why it wont be fixed. Quasiconnectivity with Redstone blocks is annoying, and can be said a bug, because it breaks many logical things. Quasiconectivity with pressure plates... I need a picture, your design is non-intuitive (it sounds like you are trying to break the pressure plate). I wouldn't mind a bud piston, that might be a good compromise. | |||||||||||||||||||||||||||||
| Comment by CharlesC [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
Still in 13w10b ->can one Mojang DEV take care of this one ? or at least explain why my strange_behaviour.png is normal (though I doubt it) | |||||||||||||||||||||||||||||
| Comment by Brad Corbin [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
I've encountered this bug in a few ways, makes redstone contraptions operate in strange, non-intuitive ways. 2 specific, recent examples that have caused me issues: 1. A piston pushing a redstone block up can never be retracted without breaking the redstone block. This is massively non-intuitive, and dramatically reduces the utility of the redstone block/piston combination. 2. I had a pressure plate on the ground, and an upward-facing sticky piston buried under the adjacent block. Stepping on the pressure plate doesn't activate the piston (as it shouldn't), but if I activate the piston another way (a lever, for example), standing on the pressure plate prevents the piston from retracting, even if I turn off the lever. Again, this is massively non-intuitive, and breaks otherwise functional designs. Please fix this before the redstone update! | |||||||||||||||||||||||||||||
| Comment by James [ 06/Mar/13 ] | |||||||||||||||||||||||||||||
|
Still persistent in 13w10b, and I would like to see the bud functions from this bug made into a sperate feature/item as Tim H said | |||||||||||||||||||||||||||||
| Comment by CharlesC [ 04/Mar/13 ] | |||||||||||||||||||||||||||||
|
EDIT:Comments removed as link to MC-11193 | |||||||||||||||||||||||||||||
| Comment by Tim H [ 04/Mar/13 ] | |||||||||||||||||||||||||||||
|
Thanks to this bug pistons are severely messed up and building any larger piston mechanism becomes a guess-game and timing hell. I can't believe this bug still isn't fixed or at least scheduled for fixing. | |||||||||||||||||||||||||||||
| Comment by Brian Chung [ 02/Mar/13 ] | |||||||||||||||||||||||||||||
|
This is the trouble I'm getting... | |||||||||||||||||||||||||||||
| Comment by George Gates [ 27/Feb/13 ] | |||||||||||||||||||||||||||||
|
William, quasi-connectivity being linked to pistons is a problem. It's limiting. Pistons are useful, and if they worked the same no matter their orientation and took power CORRECTLY, they'd be even more useful. BUD update behavior is useful, and if it could be used outside of a piston it'd be even more useful. | |||||||||||||||||||||||||||||
| Comment by Matt Lafreniere [ 27/Feb/13 ] | |||||||||||||||||||||||||||||
|
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? | |||||||||||||||||||||||||||||
| Comment by Tavis [ 27/Feb/13 ] | |||||||||||||||||||||||||||||
|
Here's an infinitely expandable version. (display_demo.zip) My point is that I figured out how to do it without hitting my head on my desk. IMO that's a little more important than compactness, but I think this may be a bit more compact that DicotheRedstoner's display anyway. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 26/Feb/13 ] | |||||||||||||||||||||||||||||
|
Even though I STRONGLY feel that quasiconectivity is useful, with Redstone blocks it brakes tons of things. That is a bug. BUT, I am not asking for general quasiconectivity to be removed. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Feb/13 ] | |||||||||||||||||||||||||||||
|
This is not the only way to make a BUD with pistons, and dinnerbone did say they would implement a BUD block if they broke this. Try putting a block in front of a piston, obsidian in front of that block, powering the piston, and breaking the obsidian. | |||||||||||||||||||||||||||||
| Comment by CharlesC [ 25/Feb/13 ] | |||||||||||||||||||||||||||||
|
It would be useful if reliable (ie possibility to put power on/off). Here the problem is that it isn't reliable (piston extended and remains until you create an update of it) above the fact that it is not linked to the "normal way" redstone power is provided. | |||||||||||||||||||||||||||||
| Comment by George Gates [ 25/Feb/13 ] | |||||||||||||||||||||||||||||
|
The BUD functionality is useful, so removing it entirely would break a lot of things. | |||||||||||||||||||||||||||||
| Comment by Alex Campbell [ 25/Feb/13 ] | |||||||||||||||||||||||||||||
|
Didn't Jeb say this wouldn't be fixed, some time in 2011? | |||||||||||||||||||||||||||||
| Comment by CharlesC [ 21/Feb/13 ] | |||||||||||||||||||||||||||||
|
Hi, Regards | |||||||||||||||||||||||||||||
| Comment by Marios [ 20/Feb/13 ] | |||||||||||||||||||||||||||||
|
Thanks Tails | |||||||||||||||||||||||||||||
| Comment by Tails [ 20/Feb/13 ] | |||||||||||||||||||||||||||||
|
Not only related but same issue. | |||||||||||||||||||||||||||||
| Comment by Marios [ 20/Feb/13 ] | |||||||||||||||||||||||||||||
|
I don't want to make a duplicate. So can someone tell me if this: http://youtu.be/99qSwa0Hyn4 and | |||||||||||||||||||||||||||||
| Comment by Tavis [ 20/Feb/13 ] | |||||||||||||||||||||||||||||
|
I went ahead and built a 1:1 pixel vertical display without quasiconnectivity. I'm attaching a zip containing the display and the mod (for 13w05b). Edit: 13w05b, not 13w05a. | |||||||||||||||||||||||||||||
| Comment by Matt Lafreniere [ 20/Feb/13 ] | |||||||||||||||||||||||||||||
|
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. | |||||||||||||||||||||||||||||
| Comment by Wesley [ 19/Feb/13 ] | |||||||||||||||||||||||||||||
|
@William Pearson We see what you're saying. It's an invalid argument. You could post that exact same argument on every single bug on this site. Bugs are bad. This bug is bad. In some rare cases a bug can give you an idea to make something good, but that bug should still be fixed, and the idea implemented as a feature. We're not saying you shouldn't be able to detect block updates (that's a separate discussion that I'm sure would be quite heated) or that you shouldn't be able to power walls of pistons with (relative) ease. We're saying that the fact that power will travel through air in one direction and one direction only, and power one and only one device, is a bug that should be fixed. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 18/Feb/13 ] | |||||||||||||||||||||||||||||
|
... That was a cool video, but it isn't survival-feasible (or even non-mcedit creative). So even though it is cool, it still leaves some emptiness. And yes, creepers aren't bugs, But they were bugs, and then made into a feature. See what I'm saying? | |||||||||||||||||||||||||||||
| Comment by George Gates [ 18/Feb/13 ] | |||||||||||||||||||||||||||||
|
Here's an interesting 1:1 pixel display in the snapshot. Creepers themselves aren't a bug. The change of the model from the pig was, but then he skinned it and gave it an AI (explosiveness, etc.) on purpose. | |||||||||||||||||||||||||||||
| Comment by [Mod] Pokechu22 [ 17/Feb/13 ] | |||||||||||||||||||||||||||||
|
If they add a bud block it would be impossible to do things like 1:1 pixel displays. It already is impossible because of the trapdoor change. There was a design, but now there isn't. The best solution is a bud piston that behaves as it is now (then there could also be a bud block, but it would not break anything). It also breaks 4by4 and larger piston doors. I actually wrote a essay on this, so I guess I will put a link to it. *The creeper was originally a modeling error by notch while he was trying to make pigs. | |||||||||||||||||||||||||||||
| Comment by xfallxcuav [ 12/Feb/13 ] | |||||||||||||||||||||||||||||
|
wow this means that i had 2 bugs at once in 13w05b for | |||||||||||||||||||||||||||||
| Comment by Kimitsu Desu [ 11/Feb/13 ] | |||||||||||||||||||||||||||||
|
@xfallxcuav, yeah it's the same. normally powered pistons cause update on diagonally powered ones and due to some underlying processing order it results in such pattern. | |||||||||||||||||||||||||||||
| Comment by xfallxcuav [ 11/Feb/13 ] | |||||||||||||||||||||||||||||
|
not sure if this is the same bug, don't want to make duplicate posts | |||||||||||||||||||||||||||||
| Comment by Tavis [ 09/Feb/13 ] | |||||||||||||||||||||||||||||
|
@Yoerie Dinnerbone said they would add a block specifically to detect block updates if this got fixed. It would be much more compact than this and pistons would be easier to understand and use. | |||||||||||||||||||||||||||||
| Comment by George Gates [ 08/Feb/13 ] | |||||||||||||||||||||||||||||
|
Ronald, this doesn't just affect pistons facing up or towards the block (if diagonal). It also affects pistons facing away and down, where the arm/head doesn't make contact with the powered block. | |||||||||||||||||||||||||||||
| Comment by malacvadasz [ 05/Feb/13 ] | |||||||||||||||||||||||||||||
|
This bug made some of my redstone structures not working. Please fix it in the 1.5 update!!! | |||||||||||||||||||||||||||||
| Comment by Yoerie Wolvekamp [ 03/Feb/13 ] | |||||||||||||||||||||||||||||
|
This is the BUD-Bug which is very useful in redstone contraption so far the minecraft devs have decided not to fix it for that reason. | |||||||||||||||||||||||||||||
| Comment by Ronald Schoonover [ 03/Feb/13 ] | |||||||||||||||||||||||||||||
|
Redstone block provides power to extended piston head which provides power to main piston block causing it to loop on itself and keep extended. Maybe make Piston heads not hold a redstone signal? I don't know. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 01/Feb/13 ] | |||||||||||||||||||||||||||||
|
You can link to issues with "[ | |||||||||||||||||||||||||||||
| Comment by Justin Yang [ 01/Feb/13 ] | |||||||||||||||||||||||||||||
|
The pictures i have added are things caused by this bug to reproduce follow instructions that are here - https://mojang.atlassian.net/browse/MC-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel | |||||||||||||||||||||||||||||
| Comment by Justin Yang [ 01/Feb/13 ] | |||||||||||||||||||||||||||||
|
Things caused by this bug in the latest snapshots : 13w05a and 13w05b | |||||||||||||||||||||||||||||
| Comment by Kimitsu Desu [ 29/Jan/13 ] | |||||||||||||||||||||||||||||
|
@Arthur Uzulin you mean | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 29/Jan/13 ] | |||||||||||||||||||||||||||||
|
If anybody wants to stop the BUD behavior, Dinnerbone has added a small feature where if the Comparator is facing a piston for example, the piston would not behave as a BUD. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 29/Jan/13 ] | |||||||||||||||||||||||||||||
|
@SewdiO: This is a problem whenever someone wants to use pistons for anything that does not involve block updates. Even if it is a relatively small problem, it takes time and mental effort to solve, and anyone who does not understand it will tend to develop superstitions and/or a fear of redstone. Compact builds that rely on special case behavior tend to break between updates, so using them is a risk in and of itself. - You don't want it removed because compactness isn't a problem, then proceed to protest it's removal because it would break compactness. - When the bug occurs, it may seem inconsistent, which can be just as bad as something that actually is inconsistent. However, this bug also introduces general inconsistencies with other blocks and devices in Minecraft. There is also a distinction between temporal consistency and spatial consistency. Most redstone blocks are spatially consistent*: if the world around the block is in state "A" the block is in state "X", if the world is in a second stable state "B" the block is in state "Y", etc. Each block has exactly one state that can be derived from every world state, while each block state can correlate to more than one world state. Spatial consistency is much easier to understand than temporal consistency. Most bugs are very self consistent, at least temporally. Debugging a consistent bug is much easier than debugging an inconsistent bug, but it doesn't make it less of a bug. - Knowing how glowstone and slabs work is irrelevant to this bug, which requires neither. The minecart booster bug was very useful, too. It got replaced by a legitimate method of boosting minecarts. ;P - I do not think the trapdoor "fix" was intended to address this bug, but it wouldn't be a problem if this bug didn't exist in the first place. * Assuming the state of the world is stable, e.g. all blocks have had a chance to finish processing all inputs they have received. | |||||||||||||||||||||||||||||
| Comment by George Gates [ 28/Jan/13 ] | |||||||||||||||||||||||||||||
|
When it comes to powering with redstone, pistons are the inconsistent ones. Doors, redstone lamps, etc. do not get powered the same way. Pistons getting power diagonally and needing an update to extent/retract is an obvious bug. HOWEVER, block update detection is very useful for a wide variety of situations. http://www.youtube.com/watch?v=XTUr3akixVk EDIT: Prepended the protocol on the link. | |||||||||||||||||||||||||||||
| Comment by SewdiO [ 28/Jan/13 ] | |||||||||||||||||||||||||||||
|
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. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 28/Jan/13 ] | |||||||||||||||||||||||||||||
|
The block is actually powered, and this is useful for a whole bunch of memory-latch designs. | |||||||||||||||||||||||||||||
| Comment by MrCheeze [ 28/Jan/13 ] | |||||||||||||||||||||||||||||
|
And of course compatibility with previous circuits should not be a factor. Leaving the game broken forever to prevent a couple minor circuit changes is never a good idea, especially in the update that exists so that all broken circuits will happen in the same update. | |||||||||||||||||||||||||||||
| Comment by MrCheeze [ 28/Jan/13 ] | |||||||||||||||||||||||||||||
|
There are TONS of problems caused by this bug and no real use for it besides detecting block updates. I know Mojang is currently planning to ignore the bug, but I would strongly recommend reconsidering. | |||||||||||||||||||||||||||||
| Comment by Birk Aigner [ 28/Jan/13 ] | |||||||||||||||||||||||||||||
|
I have to say that this bug, even though it has become a "feature" in many persons eyes, ruins some of the consistency we want in minecraft. I support the idea of a block made to be a BUD! Mojang, fix this bug, and add something that can please those who are going to miss it! | |||||||||||||||||||||||||||||
| Comment by Jack D. [ 28/Jan/13 ] | |||||||||||||||||||||||||||||
|
I had the same issue in my game. causing a lot of problems; please fix! | |||||||||||||||||||||||||||||
| Comment by Chu Wy Ton [ 27/Jan/13 ] | |||||||||||||||||||||||||||||
|
I'm pretty sure this is implied, but the bug persists even if the piston is broken and replaced. | |||||||||||||||||||||||||||||
| Comment by George Gates [ 26/Jan/13 ] | |||||||||||||||||||||||||||||
|
I make use of BUD switches using pistons in my builds, but even so I'd still like a BUD block as replacement for getting the piston bugs fixed because it'd make things easier, less messy, and give more possibilities. | |||||||||||||||||||||||||||||
| Comment by Wesley [ 26/Jan/13 ] | |||||||||||||||||||||||||||||
|
Then explain in the image why the first piston is retracted and the second one is extended. If what you (Arthur Uzulin) say is true those should be reversed, no? Also, if "redstone signal travels two blocks down" then explain why a redstone lamp placed in the same place does NOT light under ANY circumstances? Why are pistons special? Why did they intend that? Also, you can cause different, conflicting behavior by breaking that block in the middle sometimes. You can actually get the piston to be extended or not depending on the ORDER you do things, which is a flat out bug no matter what they intended. Using this bug, I was able to get a piston extended with NO blocks at all within 10 blocks of it. See the new screenshot. This ONLY works if you start by powering it from 2 blocks above and then remove the blocks around it in a certain order. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 26/Jan/13 ] | |||||||||||||||||||||||||||||
|
The thing is that redstone signal travels two blocks down, and it was always that way. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Jan/13 ] | |||||||||||||||||||||||||||||
|
I highly doubt that pistons were initially intended to produce all of the behavior that they exhibit, specifically BUD behavior. I do not think the initial intention has changed, but that Mojang has been receiving pressure to not remove the behavior. The intention to not break stuff (and upset a bunch of people) has overridden the initial intention of pistons being pistons. Tying a mechanic that is completely unrelated to (and occasionally contradicts) the expected behavior of something so closely to it's core function is unhelpful for everyone, especially for people who are new to redstone, but even experienced redstoners have to deal with the additional mental burden and space restrictions required to avoid the mechanic when they don't need it. If you were replying to the side note in my previous comment which is only tangentially related to this bug: | |||||||||||||||||||||||||||||
| Comment by Daniel [ 25/Jan/13 ] | |||||||||||||||||||||||||||||
|
It isn't WAI. Because mojang said that they are gonna make the BUD switch. Redstone Block isn't one. | |||||||||||||||||||||||||||||
| Comment by fuj1n (Arthur Uzulin) [ 25/Jan/13 ] | |||||||||||||||||||||||||||||
|
Works as intended, the Redstone Block is powering the piston. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 22/Jan/13 ] | |||||||||||||||||||||||||||||
|
@Michael: Pistons do not constantly check their state, otherwise it would be impossible for them to be used as BUD switches. If you were referring to the videos of sethbling showing grum how redstone works, grum thought it was a bug and sethbling told him that Mojang wasn't going to fix it. @Mojang: If you didn't intend this behavior and/or do intend to fix it, I suggest stating publicly as soon as possible that it WILL be fixed eventually and to take that into consideration when building new stuff. You may even want to provide a build that includes the fix so people can proactively test and fix their contraptions. Side note: Piston powered redstone block walls aren't as fun as I thought they'd be. Pistons don't cause updates when they extend, and when they retract they apparently update before pulling the redstone block. I also got a nice mess when I depowered them that seems to be affected by the size of the redstone hashset. | |||||||||||||||||||||||||||||
| Comment by Markku [ 21/Jan/13 ] | |||||||||||||||||||||||||||||
|
Could you perhaps provide a link to the specific video... Going to check if that is either made by dev or contains a dev stating that this is intended. | |||||||||||||||||||||||||||||
| Comment by Michael Hubbert [ 21/Jan/13 ] | |||||||||||||||||||||||||||||
|
This is intended. | |||||||||||||||||||||||||||||
| Comment by Kimitsu Desu [ 17/Jan/13 ] | |||||||||||||||||||||||||||||
|
As of 13w02b, you can't force update on a piston with a trapdoor or a redstone lamp, making this "feature" even less useful. Get us rid of it and give us a BUD!!! | |||||||||||||||||||||||||||||
| Comment by Daniel [ 12/Jan/13 ] | |||||||||||||||||||||||||||||
|
Very annoying bug! PLEASE MOJANG FIX IT! IT WILL RUIN MY MAP!!! | |||||||||||||||||||||||||||||
| Comment by Glampkoo [ 11/Jan/13 ] | |||||||||||||||||||||||||||||
|
Confirmed in 13w02b | |||||||||||||||||||||||||||||
| Comment by Viktor [ 10/Jan/13 ] | |||||||||||||||||||||||||||||
|
This is really annoying. I tried to turn on redstone lights using a redstone block and sticky piston powered by detector rails, but it didn't retracted. Same bug. | |||||||||||||||||||||||||||||
| Comment by Sam Sartor [ 09/Jan/13 ] | |||||||||||||||||||||||||||||
|
Some demonstrations similar bugs: Please fix this, it has made redstone contraptions and logic difficult. | |||||||||||||||||||||||||||||
| Comment by Wesley [ 05/Jan/13 ] | |||||||||||||||||||||||||||||
|
See the screenshot I just posted. Piston will extend if there is a power block 2 meters above it. | |||||||||||||||||||||||||||||
| Comment by FireHunterX [ 05/Jan/13 ] | |||||||||||||||||||||||||||||
|
Due to the piston head being a separate block from the piston, it is counted as such. And as another bug report stated, "Powering the block on top of a piston extends the piston", the same concept applies here. The Redstone block is powering the piston head, which is a separate block and it is on top of the piston. And by the way, Better Than Wolves had a BUD block. It shouldn't be that hard to make it. (I'm referring to the "Buddy Block".) | |||||||||||||||||||||||||||||
| Comment by Wesley [ 04/Jan/13 ] | |||||||||||||||||||||||||||||
|
This is going to become a bigger issue in 1.5 (and is in 13w01a), as now if you use a piston to push a redstone block up, the piston won't retract due to it accepting the redstone block as a power source. So, you can set up 4 pistons to push a redstone block around in a circle horizontally, but you cannot do the same thing vertically because one of the 4 pistons (the one aiming upward) will never retract. | |||||||||||||||||||||||||||||
| Comment by Mikael H. Karlsson [ 03/Nov/12 ] | |||||||||||||||||||||||||||||
|
I would be fine with this bug getting fixed just as long as a dedicated BUD block was made and released at the same time. | |||||||||||||||||||||||||||||
| Comment by Tavis [ 26/Oct/12 ] | |||||||||||||||||||||||||||||
|
Then they need to make a block for that purpose. 1.5 is supposed to change some redstone stuff, so people will need to update their builds anyway. | |||||||||||||||||||||||||||||
| Comment by Thue [ 26/Oct/12 ] | |||||||||||||||||||||||||||||
|
Piston quasiconnectivity is very useful for BUD switches (Block Update Detector). The Minecraft devs are already aware of it, and have so far chosen not to fix it because of its usefulness to redstone contraption builders. | |||||||||||||||||||||||||||||
| Comment by Do [ 26/Oct/12 ] | |||||||||||||||||||||||||||||
|
Nice bug report. I'm updating the summary to be a little more precise (just quoting from your description). |