Im wondering if 4j ever plans on fixing the lag issue when it cones to redstone. Probably my favorite things to do is build redstone creations and one thing i really wanna be able to do it build a piston elevator and have it work MOST of the time atleast. Not like 10% of the time.
Basically i wanna know of they will ever fix this or if they even can.
a: presuming 4J sees this as a true bug and not an interaction of individual hardware with an extremely taxing program
b: presuming 4J can do anything about it.
It's not 4J's fault. The XBox is pretty old technology...you ever try to play Minecraft on a 9 year old computer? Trust me I would love to see redstone not lag, but hey if your creative enough there are workarounds (such as adding a couple extra ticks of delay to your circuits)
It's not 4J's fault. The XBox is pretty old technology...you ever try to play Minecraft on a 9 year old computer? Trust me I would love to see redstone not lag, but hey if your creative enough there are workarounds (such as adding a couple extra ticks of delay to your circuits)
Bah, the same crap occurs on pc's, when it comes down to it, red stone, especially pistons are extremely unreliable, and can bog things down.
a: presuming 4J sees this as a true bug and not an interaction of individual hardware with an extremely taxing program
b: presuming 4J can do anything about it.
It is a bug, in the fact that rapidly moving blocks tend to lose their hitboxes for a split second. It only really effects piston elevators though, which are the least efficient type of elevator, the slowest, and the least resource-friendly. Not to mention, elevators are probably the most useless machine you could ever build with pistons. As long as your piston creation's purpose isn't to transport a person through pushing blocks in quick succession, I promise it can work perfectly.
Bah, the same crap occurs on pc's, when it comes down to it, red stone, especially pistons are extremely unreliable, and can bog things down.
Ehh, I wouldn't say that. Poor architecture and faulty design are unreliable. Redstone will never be a solid power source, like electricity, but I don't have all that many problems with it. Most people just tend not to see their own errors, blame the game, and call it a bug.
It is a bug, in the fact that rapidly moving blocks tend to lose their hitboxes for a split second. It only really effects piston elevators though, which are the least efficient type of elevator, the slowest, and the least resource-friendly. Not to mention, elevators are probably the most useless machine you could ever build with pistons. As long as your piston creation's purpose isn't to transport a person through pushing blocks in quick succession, I promise it can work perfectly.
Ehh, I wouldn't say that. Poor architecture and faulty design are unreliable. Redstone will never be a solid power sources, like electricity, but I don't have all that many problems with it. Most people just tend not to see their own errors, blame the game, and call it a bug.
Ugh, I'm afraid I have to agree with the OP and Nose_Job to some extent. I build with redstone and pistons alot, and have noticed considerably more lag in the 1.8.2 worlds as opposed to my old one. Example, I built an auto melon farm, with 3 piston nodes, 20 pistons each, for 60 total. They are sticky pistons with dirt on top, and the dirt will be left floating in the air if I don't put a 4 tick delay in between each array. I'm not one to complain, so I haven't bothered to, but damn. It just feels like sloppy programming to me, especially given that large and complex machines are guaranteed to be built with them. I do agree that many issues can be attributed to sloppy design, but not this. There is nothing to my melon farm, no complex mechanisms besides the bud switch.
Ugh, I'm afraid I have to agree with the OP and Nose_Job to some extent. I build with redstone and pistons alot, and have noticed considerably more lag in the 1.8.2 worlds as opposed to my old one. Example, I built an auto melon farm, with 3 piston nodes, 20 pistons each, for 60 total. They are sticky pistons with dirt on top, and the dirt will be left floating in the air if I don't put a 4 tick delay in between each array. I'm not one to complain, so I haven't bothered to, but damn. It just feels like sloppy programming to me, especially given that large and complex machines are guaranteed to be built with them. I do agree that many issues can be attributed to sloppy design, but not this. There is nothing to my melon farm, no complex mechanisms besides the bud switch.
I'm pretty sure that's user error, in your machine's case. I've made accidental block-droppers countless times, as well as created them on purpose. It's all a matter of finding your mistakes and correcting them. Eventually, when a piston creation becomes huge, the drop in framerate will inevitably cause things to go horribly wrong. But, a mere 60 pistons is nowhere near enough to cause an issue.
It's not 4J's fault. The XBox is pretty old technology...you ever try to play Minecraft on a 9 year old computer? Trust me I would love to see redstone not lag, but hey if your creative enough there are workarounds (such as adding a couple extra ticks of delay to your circuits)
I play Minecraft on an 8 year old laptop... it's HORRIBLE!
I'm pretty sure that's user error, in your machine's case. I've made accidental block-droppers countless times, as well as created them on purpose. It's all a matter of finding your mistakes and correcting them. Eventually, when a piston creation becomes huge, the drop in framerate will inevitably cause things to go horribly wrong. But, a mere 60 pistons is nowhere near enough to cause an issue.
^^^ If this can work, (with a bit of trickery) I guarantee a melon farm is easily possible.
I'm afraid i dissagree N_J. This system couldn't be simpler and I'll prove it with a SS when I get home tonight. Btw, I saw that earlier, nice one buddy, I particularly liked the history story. Anyway, the pistons are arranged to push a dirt block up and then bring it back down, no pusher pistons in the machine. So each array is simply two rows of 10 pistons facing up. You will laugh when I show you, I kept it incredibly simple, and I don't really mind having to delay each array as it doesn't affect production, but I do notice the issue. Anyway, I look forward to your input and maybe if I did f it up and I can learn from it.
I'm afraid i dissagree N_J. This system couldn't be simpler and I'll prove it with a SS when I get home tonight. Btw, I saw that earlier, nice one buddy, I particularly liked the history story. Anyway, the pistons are arranged to push a dirt block up and then bring it back down, no pusher pistons in the machine. So each array is simply two rows of 10 pistons facing up. You will laugh when I show you, I kept it incredibly simple, and I don't really mind having to delay each array as it doesn't affect production, but I do notice the issue. Anyway, I look forward to your input and maybe if I did f it up and I can learn from it.
Yeah, I get that it's a different concept, that was just an example that pistons aren't as glitchy as folks make them out to be. I suppose it could be some sort of bug, anything is possible. From my experience, when someone has this issue it means that somewhere along the line pistons are receiving a 1-tick pulse, turning them into block droppers. I just don't see how firing 60 pistons at once can cause so many bugs when a machine that fires up to 160+ pistons simultaneously can work perfectly, even after it has been running for over 4 hours.
I think the fact that I build on a superflat world has a lot to do with it. People on the forum complain of more framerate drops, while the game has been running significantly more smoothly from my perspective. Recreating your machine on a superflat world would prove whether this is a new bug, or simply another issue we have due to poor hardware. That is, if there is no design flaw. From your explanation, I don't think there is, but it's possible.
Aha! See thats what I thought. We were both right. I was unaware about the 1 tick issue with pistons, as I haven't built anything with a one tick pulse going to a piston array. The bud switch gives a one tick pulse and when it was directly connected, thats when I had the issue. When I installed a repeater in between them, trying to lengthen the pulse, it corrected itself. Thanks Nose_Job. Come to think of it i remember seeing that problem on this forum before, maybe even from one of your posts....derp!
Ehh, I wouldn't say that. Poor architecture and faulty design are unreliable. Redstone will never be a solid power source, like electricity, but I don't have all that many problems with it. Most people just tend not to see their own errors, blame the game, and call it a bug.
You my friend are blowing chunks out your butt, you may know a lot about red stone in general but i am afraid you have little knowledge when it comes to servers and working with multiple users within them. Timings can be....erratic to say the least.
Devices that are heavily reliant on timings will break period end of story, nearly every PC player who plays with red stone will tell you this, especially when it involves pistons, there is no 'bad design' crap here, its just unreliable, unpredictable and if you say otherwise then you need to prove it, put your money where your mouth is and prove it so that pc servers might start implementing 'your super duper killer redstone that don't break' designs, where you succeed and nearly every other has failed.
If this sounds harsh it was meant that way i certainly don't appreciate your 'bad design' remarks. Point is i've seen devices work correctly for many hours on end, but the minute a laggy player enters the game, they break, adjusting timings while he is within the game and they work correctly, however when he leaves they break again.
You my friend are blowing chunks out your butt, you may know a lot about red stone in general but i am afraid you have little knowledge when it comes to servers and working with multiple users within them. Timings can be....erratic to say the least.
Devices that are heavily reliant on timings will break period end of story, nearly every PC player who plays with red stone will tell you this, especially when it involves pistons, there is no 'bad design' crap here, its just unreliable, unpredictable and if you say otherwise then you need to prove it, put your money where your mouth is and prove it so that pc servers might start implementing 'your super duper killer redstone that don't break' designs, where you succeed and nearly every other has failed.
If this sounds harsh it was meant that way i certainly don't appreciate your 'bad design' remarks. Point is i've seen devices work correctly for many hours on end, but the minute a laggy player enters the game, they break, adjusting timings while he is within the game and they work correctly, however when he leaves they break again.
Woo, time to type this message all over again! I love storms.
Now you're arguing a completely different point from what you started with. If you would've said online multiplayer is unreliable, I probably wouldn't have replied. (Though that has nothing to do with what the OP wants to know.) But no, you said, "Red stone, especially pistons, are extremely unreliable and can bog things down." which just isn't true. It's not perfect and never will be, but overall it's a fairly stable conduit. Redstone items themselves have a pretty low chance of failure, which I wouldn't call extremely unreliable.
Also, I'm not sure if you play with 8 people constantly, or if you/your friends have terrible internet connection. Yesterday, me and a couple friends were yacking while my cubinator was running. It ran for a little over 2 hours before breaking, just like it always does, even when offline. At this point, updaters can be attached and the machine will run perfectly for another 2 hours, until the storage is full. My guess is someone needs a new ISP, or you're overlooking a workaround.
EDIT: I also want to mention my new world is superflat, which I believe makes a huge difference when it comes to framerate drops and redstone issues.
Yesterday, me and a couple friends were yacking while my cubinator was running. It ran for a little over 2 hours before breaking, just like it always does, even when offline.
And even then it was only ONE piston that "broke" down out of 600+ pistons. Funny how that works.
And even then it was only ONE piston that "broke" down out of 600+ pistons. Funny how that works.
Yup, and it's always one of the "detector" pistons, which has literally nothing to do with timing. And those aren't all that stable to begin with, even when offline.
I made a lighthouse using 4 pistons that moved dirt blocks in front of burning netherrack. It was an offline lag generator when I put the simple timing circuit on the ground and ran redstone up the tower steps with repeaters. When I moved the timer to just below the pistons, the lag vanished.
I spent a good deal of time working with piston elevators and have one that works pretty reliably, is something like 30 blocks tall by now, and it causes zero lag when it runs.
I guess the take-away is there are designs that are problematic, and designs that are not. Designs that don't work very well aren't "bugs," they are poor designs.
To further complicate things, we need to aslo take into effect chunk loading/unloading which can cause pistons to 'double push' blocks. On the PC we can use mods to prevent chunk unloading but on the xbox we must painfully plan for this if you don't want a double push to occur, especially important if your working with arrays. I've pulled my hair out trying to solve this one, but can't seem to find a viable solution, and worse yet it only seems to happen 'randomly'. If 'P' marks a piston and B is a block and '.' is air, and we have a setup like 'PB', obviously when the piston fires we should end up with 'P.B', which happens 99.9% of the time, however when chunks are unloaded and then reloaded you can end up with 'P..B' (note the double air space, I believe whats happening is that as the chunk is unloading the piston fires, giving us 'P.B'. When the chunk is reloaded the block receives another move command moving it another space resulting in 'P..B'. This happens both on the xbox and PC.
Again placing a unmovable block works but obviously shouldn't be needed. There are other areas with red stone that can also become unreliable at times as well, but i won't get into details on those at this time.
I apologize for venting last night, was tiered and took your post to heart, which i shouldn't have.
To further complicate things, we need to aslo take into effect chunk loading/unloading which can cause pistons to 'double push' blocks. On the PC we can use mods to prevent chunk unloading but on the xbox we must painfully plan for this if you don't want a double push to occur, especially important if your working with arrays. I've pulled my hair out trying to solve this one, but can't seem to find a viable solution, and worse yet it only seems to happen 'randomly'. If 'P' marks a piston and B is a block and '.' is air, and we have a setup like 'PB', obviously when the piston fires we should end up with 'P.B', which happens 99.9% of the time, however when chunks are unloaded and then reloaded you can end up with 'P..B' (note the double air space, I believe whats happening is that as the chunk is unloading the piston fires, giving us 'P.B'. When the chunk is reloaded the block receives another move command moving it another space resulting in 'P..B'. This happens both on the xbox and PC.
Again placing a unmovable block works but obviously shouldn't be needed. There are other areas with red stone that can also become unreliable at times as well, but i won't get into details on those at this time.
Now this, I don't know much about. All of the automated systems I've built aren't really required to be running at times when I'm out of the area. I knew this was a huge problem on PC, but thought it wouldn't be on 360, where our chunk loading is a bit different. All I know is that clocks will operate correctly when out of render distance, from an experiment I performed quite some time ago. This double-pushing piston phenomenon is definitely something that could be considered a bug.
Flashing is not quite the same as a double push, and even to this date the problem still exists on PC's, my clock which uses a piston array will double push from time to time if the chunk unloads, and I've already tried it in current version 1.4.x and still does the same thing, the only way as i have already mentioned fixing the problem is to place a unmovable block where blocks shouldn't be pushed to anyhow, and that does for the most part fix it.
Basically i wanna know of they will ever fix this or if they even can.
a: presuming 4J sees this as a true bug and not an interaction of individual hardware with an extremely taxing program
b: presuming 4J can do anything about it.
Bah, the same crap occurs on pc's, when it comes down to it, red stone, especially pistons are extremely unreliable, and can bog things down.
It is a bug, in the fact that rapidly moving blocks tend to lose their hitboxes for a split second. It only really effects piston elevators though, which are the least efficient type of elevator, the slowest, and the least resource-friendly. Not to mention, elevators are probably the most useless machine you could ever build with pistons. As long as your piston creation's purpose isn't to transport a person through pushing blocks in quick succession, I promise it can work perfectly.
Ehh, I wouldn't say that. Poor architecture and faulty design are unreliable. Redstone will never be a solid power source, like electricity, but I don't have all that many problems with it. Most people just tend not to see their own errors, blame the game, and call it a bug.
Ugh, I'm afraid I have to agree with the OP and Nose_Job to some extent. I build with redstone and pistons alot, and have noticed considerably more lag in the 1.8.2 worlds as opposed to my old one. Example, I built an auto melon farm, with 3 piston nodes, 20 pistons each, for 60 total. They are sticky pistons with dirt on top, and the dirt will be left floating in the air if I don't put a 4 tick delay in between each array. I'm not one to complain, so I haven't bothered to, but damn. It just feels like sloppy programming to me, especially given that large and complex machines are guaranteed to be built with them. I do agree that many issues can be attributed to sloppy design, but not this. There is nothing to my melon farm, no complex mechanisms besides the bud switch.
I'm pretty sure that's user error, in your machine's case. I've made accidental block-droppers countless times, as well as created them on purpose. It's all a matter of finding your mistakes and correcting them. Eventually, when a piston creation becomes huge, the drop in framerate will inevitably cause things to go horribly wrong. But, a mere 60 pistons is nowhere near enough to cause an issue.
http://www.minecraftforum.net/topic/1556751-ze-cubinator/
^^^ If this can work, (with a bit of trickery) I guarantee a melon farm is easily possible.
I play Minecraft on an 8 year old laptop... it's HORRIBLE!
I'm afraid i dissagree N_J. This system couldn't be simpler and I'll prove it with a SS when I get home tonight. Btw, I saw that earlier, nice one buddy, I particularly liked the history story. Anyway, the pistons are arranged to push a dirt block up and then bring it back down, no pusher pistons in the machine. So each array is simply two rows of 10 pistons facing up. You will laugh when I show you, I kept it incredibly simple, and I don't really mind having to delay each array as it doesn't affect production, but I do notice the issue. Anyway, I look forward to your input and maybe if I did f it up and I can learn from it.
Yeah, I get that it's a different concept, that was just an example that pistons aren't as glitchy as folks make them out to be. I suppose it could be some sort of bug, anything is possible. From my experience, when someone has this issue it means that somewhere along the line pistons are receiving a 1-tick pulse, turning them into block droppers. I just don't see how firing 60 pistons at once can cause so many bugs when a machine that fires up to 160+ pistons simultaneously can work perfectly, even after it has been running for over 4 hours.
I think the fact that I build on a superflat world has a lot to do with it. People on the forum complain of more framerate drops, while the game has been running significantly more smoothly from my perspective. Recreating your machine on a superflat world would prove whether this is a new bug, or simply another issue we have due to poor hardware. That is, if there is no design flaw. From your explanation, I don't think there is, but it's possible.
You my friend are blowing chunks out your butt, you may know a lot about red stone in general but i am afraid you have little knowledge when it comes to servers and working with multiple users within them. Timings can be....erratic to say the least.
Devices that are heavily reliant on timings will break period end of story, nearly every PC player who plays with red stone will tell you this, especially when it involves pistons, there is no 'bad design' crap here, its just unreliable, unpredictable and if you say otherwise then you need to prove it, put your money where your mouth is and prove it so that pc servers might start implementing 'your super duper killer redstone that don't break' designs, where you succeed and nearly every other has failed.
If this sounds harsh it was meant that way i certainly don't appreciate your 'bad design' remarks. Point is i've seen devices work correctly for many hours on end, but the minute a laggy player enters the game, they break, adjusting timings while he is within the game and they work correctly, however when he leaves they break again.
Woo, time to type this message all over again! I love storms.
Now you're arguing a completely different point from what you started with. If you would've said online multiplayer is unreliable, I probably wouldn't have replied. (Though that has nothing to do with what the OP wants to know.) But no, you said, "Red stone, especially pistons, are extremely unreliable and can bog things down." which just isn't true. It's not perfect and never will be, but overall it's a fairly stable conduit. Redstone items themselves have a pretty low chance of failure, which I wouldn't call extremely unreliable.
Also, I'm not sure if you play with 8 people constantly, or if you/your friends have terrible internet connection. Yesterday, me and a couple friends were yacking while my cubinator was running. It ran for a little over 2 hours before breaking, just like it always does, even when offline. At this point, updaters can be attached and the machine will run perfectly for another 2 hours, until the storage is full. My guess is someone needs a new ISP, or you're overlooking a workaround.
EDIT: I also want to mention my new world is superflat, which I believe makes a huge difference when it comes to framerate drops and redstone issues.
Yup, and it's always one of the "detector" pistons, which has literally nothing to do with timing. And those aren't all that stable to begin with, even when offline.
I spent a good deal of time working with piston elevators and have one that works pretty reliably, is something like 30 blocks tall by now, and it causes zero lag when it runs.
I guess the take-away is there are designs that are problematic, and designs that are not. Designs that don't work very well aren't "bugs," they are poor designs.
Again placing a unmovable block works but obviously shouldn't be needed. There are other areas with red stone that can also become unreliable at times as well, but i won't get into details on those at this time.
I apologize for venting last night, was tiered and took your post to heart, which i shouldn't have.
It's fine, I do it too from time to time.
Now this, I don't know much about. All of the automated systems I've built aren't really required to be running at times when I'm out of the area. I knew this was a huge problem on PC, but thought it wouldn't be on 360, where our chunk loading is a bit different. All I know is that clocks will operate correctly when out of render distance, from an experiment I performed quite some time ago. This double-pushing piston phenomenon is definitely something that could be considered a bug.
BEHOLD:
http://www.minecraftforum.net/topic/1507138-disappointed-about-the-lack-of-bug-fixes/