MC-18203Dispencer quasiconnectivity latch missbehaviour
Ok, first things first, this is half a duplicate of MC-108. You see, that bug covers everything, and this would be a bug even if that is valid behavior.
The problem I am having is that due to hash order (or something strange like that), dispensers can "latch" until they receive a block update. You can achieve this by building something like this:
◨██__
☲☲ ██
(☲☲ is a dispenser and ◨ is a button)
The first time you press the button, the dispencer fires.
The second time, it doesn't.
Even I, normally 100% for quasiconnectivity, can tell this is a bug.
What is likely happening is that on the tick where the button turns off, the dispenser is updated once, but it sees that it is still powered by the not-yet updated redstone dust. The redstone dust then gets updated, and turns off, but doesn't update the dispenser (due to quasiconnectivity updating behavior). The dispenser then thinks it is powered on the tick, because it hasn't realized it isn't. Then, when you press the button again, the dispenser is updated. It realizes the dust is off (since the redstone seems to be updated second), but the button is now on. This didn't occur in the past due to the dispensers firing again when powered behavior, but now it does occur. (I tested this with a 1.2.5 jar, and it worked properly).
This shows how hash order still is important. (I say hash, but I mean update. No idea where I got that behavior.)
The fix isn't necessarily to return the firing again behavior, I know it was removed due to block updates triggering it, but if the dispenser is powered again on the same tick it is unpowered, it should fire.
If you have any questions post them in the comments.
Linked Issues
Low
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
Created Issue:
Dispencer quasiconnectivity latch missbehaviour
Ok, first things first, this is half a duplicate of
MC-108. You see, that bug covers everything, and this would be a bug even if that is valid behavior.The problem I am having is that due to hash order (or something strange like that), dispensers can "latch" until they receive a block update. You can achieve this by building something like this:
◨██__
☲☲ ██
(☲☲ is a dispenser and ◨ is a button)
The first time you press the button, the dispencer fires.
The second time, it doesn't.
Even I, normally 100% for quasiconnectivity, can tell this is a bug.
What is likely happening is that on the tick where the button turns off, the dispenser is updated once, but it sees that it is still powered by the not-yet updated redstone dust. The redstone dust then gets updated, and turns off, but doesn't update the dispenser (due to quasiconnectivity updating behavior). The dispenser then thinks it is powered on the tick, because it hasn't realized it isn't. Then, when you press the button again, the dispenser is updated. It realizes the dust is off (since the redstone seems to be updated second), but the button is now on. This didn't occur in the past due to the dispensers firing again when powered behavior, but now it does occur. (I tested this with a 1.2.5 jar, and it worked properly).
This shows how hash order still is important. (I say hash, but I mean update. No idea where I got that behavior.)
The fix isn't necessarily to return the firing again behavior, I know it was removed due to block updates triggering it, but if the dispenser is powered again on the same tick it is unpowered, it should fire.If you have any questions post them in the comments.
- Unresolved
- Open
- Unconfirmed
- Dispencer block_update bud dropper hash redstone
- 1.5.2
Please attach a screenshot of your setup.
I attached a screenshot, although I drew the device using symbols as well. I confirmed that it happened with both droppers and dispensers, and also occurs in all directions and across chunk boundaries (both on them and not on them).
The same thing also happens with pistons, but since they retract on lost power, while dispensers do nothing, that could be harnessed and it is not necessarily necessary to fix (I'm only talking about the behavior with pistons here, not the whole thing).
Oh, and you need to press the button twice, the first time it works fine and drops, but it only latches the second time.
I found it originally in this world, and narrowed it down to what I show here, but strangely the first issue I found may be different since I cannot replicate it in any other position. The device I screenshoted can be found at the back, and I tested it and got it to do this in many positions.
This world is probably irrelevant to the bug, but it may show another case where it happens. Press the button directly infront to see what happens. (You may need to press it several times)
You know there is a related link on
MC-108that leads to MC-11193?This is different. Probably the first bug that I was getting in my world is MC-11193, but this has to deal with the order in which redstone and buttons update is constant but is not in the right order.
In this case, the device constantly gets stuck, because the block is not updated twice on the same tick, after the redstone is updated.
Never mind, it is a similar bug, though dispenser quasiconectivity and piston quasiconnectivity are way different in importance.