Im not sure where too post this, I apologize if it is the wrong place. I have the xbox 360 version. I am designing a massive tree harvester, that will harvest a row of 6 trees at a time, then go to the next row of 6. This is using a modified version of The sand Tree Harvester set up by Pearl Squirrel, .
I have removed the reset timer and set up a detector that sees when the machine runs out of sand.
Once it runs out of sand it returns to its off state, using a monostable to prevent power from always running to the second row, I start the second row. The only problem is once the second row starts It starts the pistons get out of sync. If run on there own it works fine. Does anyone have any idea what might be causing this?
I can't find it right now, but someone wrote a bunch of suggestions to improve redstone efficiency on the XBox 360.
one of the suggestions was to try and identify your Chunkspace and try very hard to work exclusively within that Chunkspace, the reason being is that there is some redstone lag when redstone crosses into a separate chunk, and other problems occur when you travel too far away from one of those chunks, but not the other.
The other really strong suggestions was lighting, the area illumination that the 3D graphics accelerator in the 360 has to compute is strained when redstone is turning on/off frequently in a dimly lit area. By illuminating the redstone circuit areas, you reduce the strain on recalculating lighting due to redstone changes, which enhances the overall redstone performance.
I can't find it right now, but someone wrote a bunch of suggestions to improve redstone efficiency on the XBox 360.
one of the suggestions was to try and identify your Chunkspace and try very hard to work exclusively within that Chunkspace, the reason being is that there is some redstone lag when redstone crosses into a separate chunk, and other problems occur when you travel too far away from one of those chunks, but not the other.
That could very well be the problem. The whole setup stretches across multiple chunks. I'll have to think about the issue and see what i can come up with. Thank you very much for the reply
Edit:
My tip for finding your chunks is to use a slime chunk tool. Just my two cents.
I didn't see that video before, but it does a good job about talking about the redstone chunk lag.
Also, you can just divide the X & Z coordinate that you are in by 16, and take the nearest whole number above and below that value, multiply these values back out by 16 to get a rough outline of the chunk border (2 sides, 1 X and 1 Z side, will be just inside the chunk space ... which should be the lower values, the other 2 will be just outside the chunk space...which should be the upper values)
Example: for X = 241 & Z = -23
X :=
241/16 = 15.0625 (15 to 16) ==>
15 * 16 = 240 & 16 * 16 = 256 ==>
X = (240 to 255) (upper range is one less)
Z:=
-23/16 = -1.4375 (-2 to -1) ==>
-2 * 16 = -32 & -1 * 16 = -16 ==>
Z = (-32 to -17) (upper range is one less/the least negative # is the upper range)
Thank you guys for the help. Now I figured out a solution to the problem. I just had to design a new circuit to start the next row of tree punchers a little slower. I think it was a mixture between chunk lag and general lag from too much going on at once.
I have built this harvester, and it will break over time, under various loads, usually occurring when a player enters or leaves the game. I'm not entirely sure why but its similar to redstone elevators, timings seem to break with different loads.
The plus is that I have stabilized and gotten this to work perfectly under all workloads. Perl's version relies heavily on smart pistons, and a self resetting nor latch, which is reset after a large number of repeaters completes its loop. I modified this to use a detector circuit for the sand and to have a timer, its about half the speed but it doesn't break sand or fail mid way through harvesting the tree.
Another issue I ran into is 'jamming' in the stacking, and had to solve this by using smart pistons with timers built in to automatically keep retrying if a jam occurs. For some reason in stacking process jams always occur and fail and without such circuitry it will jam eventually.
Your welcome to take a peek at my changes if you wish just hit me up with a message, my GT is the same as my forum name.
Red stone circuits baffle me and I have total respect for people that seem to grasp this aspect of the game. I wish I understood it it but I was never much good at electronics at school. One thing I will say is that often the red stone contraptions that people build generally look quite ugly. Yours, sir, look very elegant indeed. Well done.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I have removed the reset timer and set up a detector that sees when the machine runs out of sand.
Once it runs out of sand it returns to its off state, using a monostable to prevent power from always running to the second row, I start the second row. The only problem is once the second row starts It starts the pistons get out of sync. If run on there own it works fine. Does anyone have any idea what might be causing this?
one of the suggestions was to try and identify your Chunkspace and try very hard to work exclusively within that Chunkspace, the reason being is that there is some redstone lag when redstone crosses into a separate chunk, and other problems occur when you travel too far away from one of those chunks, but not the other.
The other really strong suggestions was lighting, the area illumination that the 3D graphics accelerator in the 360 has to compute is strained when redstone is turning on/off frequently in a dimly lit area. By illuminating the redstone circuit areas, you reduce the strain on recalculating lighting due to redstone changes, which enhances the overall redstone performance.
That could very well be the problem. The whole setup stretches across multiple chunks. I'll have to think about the issue and see what i can come up with. Thank you very much for the reply
I didn't see that video before, but it does a good job about talking about the redstone chunk lag.
Also, you can just divide the X & Z coordinate that you are in by 16, and take the nearest whole number above and below that value, multiply these values back out by 16 to get a rough outline of the chunk border (2 sides, 1 X and 1 Z side, will be just inside the chunk space ... which should be the lower values, the other 2 will be just outside the chunk space...which should be the upper values)
Example: for X = 241 & Z = -23
X :=
241/16 = 15.0625 (15 to 16) ==>
15 * 16 = 240 & 16 * 16 = 256 ==>
X = (240 to 255) (upper range is one less)
Z:=
-23/16 = -1.4375 (-2 to -1) ==>
-2 * 16 = -32 & -1 * 16 = -16 ==>
Z = (-32 to -17) (upper range is one less/the least negative # is the upper range)
The plus is that I have stabilized and gotten this to work perfectly under all workloads. Perl's version relies heavily on smart pistons, and a self resetting nor latch, which is reset after a large number of repeaters completes its loop. I modified this to use a detector circuit for the sand and to have a timer, its about half the speed but it doesn't break sand or fail mid way through harvesting the tree.
Another issue I ran into is 'jamming' in the stacking, and had to solve this by using smart pistons with timers built in to automatically keep retrying if a jam occurs. For some reason in stacking process jams always occur and fail and without such circuitry it will jam eventually.
Your welcome to take a peek at my changes if you wish just hit me up with a message, my GT is the same as my forum name.