Anyway, I was making a chicken cooker/breeder in Creative and after loading my game this is what I found.. A piston that would not deactivate... Sorry about the awkward camera angle, my mother threw out the stool I used for recording beforehand.
You accidentally created a BUD. Pistons can update themselves when placed in a location where they would meet the requirements to become an update detector. Note how you broke the block directly above the piston. This had powered redstone dust on top of it. Once this was gone, the piston met the requirements necessary to retract upon the next update in an adjacent area. This is what happened when you broke the block directly under the piston.
Redstone and Pistons have some pretty severe bugs in the Xbox 360 Edition.
Not a bug... sort of. I'm not sure if this is 100% true, but I personally believe that BUD mechanics were born from a glitch, and that Mojang left them in after crafty redstone engineers reported how useful they could be. The upcoming PC update will scrap these mechanics, because they are adding a block whose dedicated purpose is update detection.
You accidentally created a BUD. Pistons can update themselves when placed in a location where they would meet the requirements to become an update detector. Note how you broke the block directly above the piston. This had powered redstone dust on top of it. Once this was gone, the piston met the requirements necessary to retract upon the next update in an adjacent area. This is what happened when you broke the block directly under the piston.
Not a bug... sort of. I'm not sure if this is 100% true, but I personally believe that BUD mechanics were born from a glitch, and that Mojang left them in after crafty redstone engineers reported how useful they could be. The upcoming PC update will scrap these mechanics, because they are adding a block whose dedicated purpose is update detection.
Nope, not a bud. There was no active redstone anywhere close to that piston I can assure you 100%. The redstone dust you saw fall was part of the inactive strand behind it.
Nope, not a bud. There was no active redstone anywhere close to that piston I can assure you 100%.
In that case, it was a corrupted block. The point is that the block directly above the piston was acting as a receiver. The piston itself was functioning exactly as if that were the case, which in itself isn't explainable by a bug. The block above the piston was definitely in a powered state. The block itself may be plagued by a bug, hence it being a corrupted block, that much I can't tell from the video. All I know is I saw that block, you broke it, among others, and I watched redstone dust fall down. Do you think you could record a video observing the whole mechanism, without breaking things? If you don't want to deal with recording and uploading, would you mind me personally taking a look?
In that case, it was a corrupted block. The point is that the block directly above the piston was acting as a receiver. The piston itself was functioning exactly as if that were the case, which in itself isn't explainable by a bug. The block above the piston was definitely in a powered state. The block itself may be plagued by a bug, hence it being a corrupted block, that much I can't tell from the video. All I know is I saw that block, you broke it, among others, and I watched redstone dust fall down. Do you think you could record a video observing the whole mechanism, without breaking things? If you don't want to deal with recording and uploading, would you mind me personally taking a look?
I looked it over before recording and I can tell you that the dust you saw fall was not active while I was playing with the piston. But it was definitely corrupted somehow... Although it was working perfect yesterday without a hitch, then all of a sudden, this happened today.
Also, I have created BUDs before, and there was no block in a position to do this. Nothing was keeping the piston head powered as the only blocks surrounding it were air (I made sure of that when I destroyed them).
Also, I have created BUDs before, and there was no block in a position to do this. Nothing was keeping the piston head powered as the only blocks surrounding it were air (I made sure of that when I destroyed them).
But there was, above the piston, directly on top of the air block adjacent to the piston. This block is definitely powered, possibly by a bug. The piston is functioning normally.
But there was, above the piston, directly on top of the air block adjacent to the piston. This block is definitely powered, possibly by a bug. The piston is functioning normally.
Well I loaded it again to show my friend and said piston is or block is still glitched.
Well I loaded it again to show my friend and said piston is or block is still glitched.
I'm not saying a bug isn't causing the error, quite the opposite actually. I'm just saying that the piston is functioning as it should. After studying the video, there are only two possible explanations.
A: The piston is hindered by a new bug that forces it to act as a BUD, in regards to a normal block in the +1 detection range. (Doubtful)
or
B: A block is acting as a receiver, due to the block corruption bug, whilst being within the piston's +1 detection range. (Probable)
I strongly believe the latter is what's happening here.
I'm not saying a bug isn't causing the error, quite the opposite actually. I'm just saying that the piston is functioning as it should. After studying the video, there are only two possible explanations.
A: The piston is hindered by a new bug that forces it to act as a BUD, in regards to a normal block in the +1 detection range. (Doubtful)
or
B: A block is acting as a receiver, due to the block corruption bug, whilst being within the piston's +1 detection range. (Probable)
I strongly believe the latter is what's happening here.
Ok, now I understand a bit more what you're saying. While the latter is more probable I want to point out that the former happens quite often with pistons, at least with me. Before TU8 I never had those issues and with TU9 it happens in almost EVERY device once and awhile.
Any doors using pistons rarely ever close at the same time and will quite often become stuck like said piston in this picture. The only difference is they always changed back upon updating a block near them, this one did not.
Its worth noting my creative word has quite a few piston with redstone creations and none of them had any issues until TU9.
Ok, now I understand a bit more what you're saying. While the latter is more probable I want to point out that the former happens quite often with pistons, at least with me. Before TU8 I never had those issues and with TU9 it happens in almost EVERY device once and awhile.
I really doubt the first explanation has ever happened. If it ever has, we wouldn't be able to tell because it would function in the exact same way as the latter conclusion. This is precisely the behavior taking place in your video. It's only theoretical, so it would be literally impossible to test. The only way to know this was happening would be to see it in the code itself. As far as I know, this is still not possible to do... unless you're a staff member of 4J Studios. Who knows, it may have leaked somewhere now, but that's beside the point. Block corruption is a real and confirmed bug that has been around since redstone was first debuted. A corrupted block will act as a receiver and an emitter, both at the same time. That is where I draw my result from.
Any doors using pistons rarely ever close at the same time and will quite often become stuck like said piston in this picture. The only difference is they always changed back upon updating a block near them, this one did not.
This is a different bug, but yes, the pistons are the problem here. I've seen this myself, though only while under particularly harsh lag loads, i.e. 160+ pistons firing in unison. I'm guessing your troubled doors were on a generated world? In superflat, I've only had this specific problem when a large amount of pistons were moving a large amount of blocks in sync. I once had to use a clock specifically to repeatedly update pistons so they wouldn't become "stuck" or refuse to extend when detection requirements were met.
Hes actually in a very unique zone, i've had this happen to me before, and you can use this 'location' for block damage id changes (not sure thats the correct name for it), but a special location that allows you to actually input 1 type of block and get another back. These locations will be gone very soon, so take advantage of them while you can. The stuck piston is one way of detecting this area, but since this happens rarely theres another way i just forget how. I believe jl2579 has a tutorial on how to build and test for these locations.
Don't let this stop you from creating farms, one piston that goes bad shouldn't be reason to 'put your builds on hold'. We've been working on a chicken farm for awhile now, and almost have a fully automatic chicken farm.
The way it works is quite simple, eggs are placed in a dispenser, you then press a 'hatch eggs' button, which will rapidly fire eggs for 30 seconds. The chickens float on a 5x5 water area, with currents pushing them to the center, once eggs are finished dispensing another dispenser fires off a piece of sand onto a pressure plate. This sand will despawn about 5 mins later, each despawn a memory cell is marked and a torch is lit up (4 torches in total), the process is repeated 4 times. As soon as the 4th torch lights up the chickens should be fully matured, and will begin laying eggs, which is routed to a nearby collection area.
However if a 3rd leaver is select to on position it will cut the water supply dropping the chickens to a flaming nether rack area where they will be cooked and then brought to the same collection point i spoke of above, the system then resets itself and starts hatching again.
Obviously to make it fully automatic it would need to be able to pick up the eggs and chicken and place them in a chest.
I did a spiral staircase up the inside of a tower that could be pulled back into the wall (causing people to fall to their death), so a very simple setup with just repeaters along the way, it never did work 100%. There would be a few random ones that wouldn't or would extend when the rest did or didn't. It was different ones everytime too, so it wasn't a problem with the circuit. Redstone is just buggy.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Anyway, I was making a chicken cooker/breeder in Creative and after loading my game this is what I found.. A piston that would not deactivate... Sorry about the awkward camera angle, my mother threw out the stool I used for recording beforehand.
Redstone and Pistons have some pretty severe bugs in the Xbox 360 Edition.
I've never seen anything that bad before. I was really hoping there was some explanation... I'll hold off on those contraptions a bit longer then.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffNot a bug... sort of. I'm not sure if this is 100% true, but I personally believe that BUD mechanics were born from a glitch, and that Mojang left them in after crafty redstone engineers reported how useful they could be. The upcoming PC update will scrap these mechanics, because they are adding a block whose dedicated purpose is update detection.
Nope, not a bud. There was no active redstone anywhere close to that piston I can assure you 100%. The redstone dust you saw fall was part of the inactive strand behind it.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffIn that case, it was a corrupted block. The point is that the block directly above the piston was acting as a receiver. The piston itself was functioning exactly as if that were the case, which in itself isn't explainable by a bug. The block above the piston was definitely in a powered state. The block itself may be plagued by a bug, hence it being a corrupted block, that much I can't tell from the video. All I know is I saw that block, you broke it, among others, and I watched redstone dust fall down. Do you think you could record a video observing the whole mechanism, without breaking things? If you don't want to deal with recording and uploading, would you mind me personally taking a look?
I looked it over before recording and I can tell you that the dust you saw fall was not active while I was playing with the piston. But it was definitely corrupted somehow... Although it was working perfect yesterday without a hitch, then all of a sudden, this happened today.
Also, I have created BUDs before, and there was no block in a position to do this. Nothing was keeping the piston head powered as the only blocks surrounding it were air (I made sure of that when I destroyed them).
-
View User Profile
-
View Posts
-
Send Message
Retired StaffBut there was, above the piston, directly on top of the air block adjacent to the piston. This block is definitely powered, possibly by a bug. The piston is functioning normally.
Well I loaded it again to show my friend and said piston is or block is still glitched.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI'm not saying a bug isn't causing the error, quite the opposite actually. I'm just saying that the piston is functioning as it should. After studying the video, there are only two possible explanations.
A: The piston is hindered by a new bug that forces it to act as a BUD, in regards to a normal block in the +1 detection range. (Doubtful)
or
B: A block is acting as a receiver, due to the block corruption bug, whilst being within the piston's +1 detection range. (Probable)
I strongly believe the latter is what's happening here.
Ok, now I understand a bit more what you're saying. While the latter is more probable I want to point out that the former happens quite often with pistons, at least with me. Before TU8 I never had those issues and with TU9 it happens in almost EVERY device once and awhile.
Any doors using pistons rarely ever close at the same time and will quite often become stuck like said piston in this picture. The only difference is they always changed back upon updating a block near them, this one did not.
Its worth noting my creative word has quite a few piston with redstone creations and none of them had any issues until TU9.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI really doubt the first explanation has ever happened. If it ever has, we wouldn't be able to tell because it would function in the exact same way as the latter conclusion. This is precisely the behavior taking place in your video. It's only theoretical, so it would be literally impossible to test. The only way to know this was happening would be to see it in the code itself. As far as I know, this is still not possible to do... unless you're a staff member of 4J Studios. Who knows, it may have leaked somewhere now, but that's beside the point. Block corruption is a real and confirmed bug that has been around since redstone was first debuted. A corrupted block will act as a receiver and an emitter, both at the same time. That is where I draw my result from.
This is a different bug, but yes, the pistons are the problem here. I've seen this myself, though only while under particularly harsh lag loads, i.e. 160+ pistons firing in unison. I'm guessing your troubled doors were on a generated world? In superflat, I've only had this specific problem when a large amount of pistons were moving a large amount of blocks in sync. I once had to use a clock specifically to repeatedly update pistons so they wouldn't become "stuck" or refuse to extend when detection requirements were met.
The way it works is quite simple, eggs are placed in a dispenser, you then press a 'hatch eggs' button, which will rapidly fire eggs for 30 seconds. The chickens float on a 5x5 water area, with currents pushing them to the center, once eggs are finished dispensing another dispenser fires off a piece of sand onto a pressure plate. This sand will despawn about 5 mins later, each despawn a memory cell is marked and a torch is lit up (4 torches in total), the process is repeated 4 times. As soon as the 4th torch lights up the chickens should be fully matured, and will begin laying eggs, which is routed to a nearby collection area.
However if a 3rd leaver is select to on position it will cut the water supply dropping the chickens to a flaming nether rack area where they will be cooked and then brought to the same collection point i spoke of above, the system then resets itself and starts hatching again.
Obviously to make it fully automatic it would need to be able to pick up the eggs and chicken and place them in a chest.