How is this possible (using Minecraft Java 1.13.2):
As you can see, the target block is a minecraft:attached_pumpkin_stem. But there is no attached pumpkin besides.
FWIW, I noticed that issue when my pumpkin farm production dropped. It is based on placing an observer to watch the stem state change (you can see the observer on the very left of the screen capture) where it watches another stem out of screen. But half of my pumpkin stems are in the same state so they do not produce pumpkins anymore.
How fast do the pistons operate? I dunno if this was ever changed for 1.13 and later, but if it powers, moves, and unpowers too fast the game will not even see the block state change but will still have the pumpkin item to deal with.
Missed block updates seem the most likely issue (but see below for some diagnostic questions).
Preventing these could be done by using a repeater to extend the pulse from the observer, but wouild make the harvesting system slightly more comples and considerably less compact.
Have you been able to discern any pattern(s) in which stems are being affected? (Direction and distance from the observer would be the first two criteria I'd check.)
Is the space to which the pumpkin stem appears to be attached actually empty? (as opposed to a 'ghost' pumpkin)
Related to the above, does the piston extend through the block at which the stem is pointing when powered?
Can the stem be reset by forcing a block update? (Two cases: placing either dirt or another pumpkin opposite the 'ghost' pumpkin.)
What happens if dirt (or similar) is placed where the pumpkin should be? (And if the dirt is then removed?)
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
How fast do the pistons operate? I dunno if this was ever changed for 1.13 and later, but if it powers, moves, and unpowers too fast the game will not even see the block state change but will still have the pumpkin item to deal with.
Since the observer watch the stem, I suspect the piston is triggered by two rapid redstone signals in a raw: once when the pumpkin spawn and the stem change to attached state. Then, a second time when it changes beck to non-attached state after the pumpkin has dropped as an item.
Concerning your questions @Scots:
Have you been able to discern any pattern(s) in which stems are being affected? (Direction and distance from the observer would be the first two criteria I'd check.)
I can't see any obvious pattern. I rebuild the system in isolation in creative mode on a flat world. But I was unable to reproduce the issue:
EDIT: in my "main" world, if I put a repeater on the redstone line connection the observer to the pistons, the issue doesn't seem to appear bewond the point where the diode is. Just like if the diode had filtered out some high frequency redstone signal.
Is the space to which the pumpkin stem appears to be attached actually empty?
Related to the above, does the piston extend through the block at which the stem is pointing when powered?
Yes, it is really empty: I can walk, jump and place block there. The piston can extend over that empty block.
Can the stem be reset by forcing a block update? (Two cases: placing either dirt or another pumpkin opposite the 'ghost' pumpkin.)
I didn't try (will update this answer when tested).
What happens if dirt (or similar) is placed where the pumpkin should be?
Nothing: the stem stay attached.
Worth mentioning that quitting the game and reloading the world fix the issue with the stem being reloaded in non-attached mode. All that looks like an inconsistency between the client and the server regarding the stem state. Is that what you've called a "missed update"?
"missed update" was meant to explain the stem not recognizing that the pumpkin had been detached; the client and server having differing 'opinions' as to the state of the block could be caused by one not being properly updated (ie missing an update). [In this case the suspect would be the server being updated with the piston retracting before it registered the pumkin breaking (the latter of which would be expected to cause a check for a stem).]
The diode filter effect [a repeater acts as a de facto pulse extender where the input is <1 RS tick] and the fix by quitting and reloading both support the idea that the cause is piston speed leading to the stem block not properly updating when the pumpkin is removed.
That the issue cannot be duplicated with a copy in an empty world suggests either
that there is a directional component (unless the copy is in the same NSEW orientation [It might also need to be in the same world quadrant ie NW, NE, SE, SW from 0,0])
or that the additional 'things'n the survival world are causing enough lag (which may be quite small) to throw things off.
[Operating pistons in 'super-fast' mode can cause 'unusual' (and often useful) behaviors, and either of these factors can affect if and what results.]
(Not strictly relevant to fixing the problem, but it would be interesting to know if forcing the chunks to reload via f3+A also works…)
RE adding repeater(s)
From your description it sounds like you added a repeater to the RS line behind one of the stems, which has the advantage of not increasing the farm footprint, but leaves the two growth spaces next to the observer unprotected by the diode.
An alternative (which has as its downside increasing the space needed behind each observer) would be to place the repeater directly behind the observer powering RSD that loops back to either side…
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
Thanks for your explanations Scots. That mostly confirm my understanding of the issue.
I tried to put the diode right behind the observer. The resulting design is not as elegant as it was without it, but it seems to work pretty well: I left the game running unattended today for a couple of hours without seeing an unattached attached_stem anymore.
Rollback Post to RevisionRollBack
Please, support the sledgehammer tool!
I ♥ Linux. Thanks Mojang for providing a game that runs natively on that OS!
How is this possible (using Minecraft Java 1.13.2):
As you can see, the target block is a minecraft:attached_pumpkin_stem. But there is no attached pumpkin besides.
FWIW, I noticed that issue when my pumpkin farm production dropped. It is based on placing an observer to watch the stem state change (you can see the observer on the very left of the screen capture) where it watches another stem out of screen. But half of my pumpkin stems are in the same state so they do not produce pumpkins anymore.
Please, support the sledgehammer tool!
I ♥ Linux. Thanks Mojang for providing a game that runs natively on that OS!
How fast do the pistons operate? I dunno if this was ever changed for 1.13 and later, but if it powers, moves, and unpowers too fast the game will not even see the block state change but will still have the pumpkin item to deal with.
Missed block updates seem the most likely issue (but see below for some diagnostic questions).
Preventing these could be done by using a repeater to extend the pulse from the observer, but wouild make the harvesting system slightly more comples and considerably less compact.
Have you been able to discern any pattern(s) in which stems are being affected? (Direction and distance from the observer would be the first two criteria I'd check.)
Is the space to which the pumpkin stem appears to be attached actually empty? (as opposed to a 'ghost' pumpkin)
Related to the above, does the piston extend through the block at which the stem is pointing when powered?
Can the stem be reset by forcing a block update? (Two cases: placing either dirt or another pumpkin opposite the 'ghost' pumpkin.)
What happens if dirt (or similar) is placed where the pumpkin should be? (And if the dirt is then removed?)
Since the observer watch the stem, I suspect the piston is triggered by two rapid redstone signals in a raw: once when the pumpkin spawn and the stem change to attached state. Then, a second time when it changes beck to non-attached state after the pumpkin has dropped as an item.
Concerning your questions @Scots:
EDIT: in my "main" world, if I put a repeater on the redstone line connection the observer to the pistons, the issue doesn't seem to appear bewond the point where the diode is. Just like if the diode had filtered out some high frequency redstone signal.
Yes, it is really empty: I can walk, jump and place block there. The piston can extend over that empty block.
Worth mentioning that quitting the game and reloading the world fix the issue with the stem being reloaded in non-attached mode. All that looks like an inconsistency between the client and the server regarding the stem state. Is that what you've called a "missed update"?
Please, support the sledgehammer tool!
I ♥ Linux. Thanks Mojang for providing a game that runs natively on that OS!
"missed update" was meant to explain the stem not recognizing that the pumpkin had been detached; the client and server having differing 'opinions' as to the state of the block could be caused by one not being properly updated (ie missing an update). [In this case the suspect would be the server being updated with the piston retracting before it registered the pumkin breaking (the latter of which would be expected to cause a check for a stem).]
The diode filter effect [a repeater acts as a de facto pulse extender where the input is <1 RS tick] and the fix by quitting and reloading both support the idea that the cause is piston speed leading to the stem block not properly updating when the pumpkin is removed.
That the issue cannot be duplicated with a copy in an empty world suggests either
that there is a directional component (unless the copy is in the same NSEW orientation [It might also need to be in the same world quadrant ie NW, NE, SE, SW from 0,0])
or that the additional 'things'n the survival world are causing enough lag (which may be quite small) to throw things off.
[Operating pistons in 'super-fast' mode can cause 'unusual' (and often useful) behaviors, and either of these factors can affect if and what results.]
(Not strictly relevant to fixing the problem, but it would be interesting to know if forcing the chunks to reload via f3+A also works…)
RE adding repeater(s)
From your description it sounds like you added a repeater to the RS line behind one of the stems, which has the advantage of not increasing the farm footprint, but leaves the two growth spaces next to the observer unprotected by the diode.
An alternative (which has as its downside increasing the space needed behind each observer) would be to place the repeater directly behind the observer powering RSD that loops back to either side…
Thanks for your explanations Scots. That mostly confirm my understanding of the issue.
I tried to put the diode right behind the observer. The resulting design is not as elegant as it was without it, but it seems to work pretty well: I left the game running unattended today for a couple of hours without seeing an unattached attached_stem anymore.
Please, support the sledgehammer tool!
I ♥ Linux. Thanks Mojang for providing a game that runs natively on that OS!