Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abnormal behavior of Pattern Provider in "lock crafting until redstone pulse is received" mode #7179

Closed
trunksbomb opened this issue Jun 4, 2023 · 2 comments · Fixed by #8172
Labels
bug Self explanatory?

Comments

@trunksbomb
Copy link

trunksbomb commented Jun 4, 2023

Describe the bug

Pattern Provider's "Lock crafting until redstone pulse is received" mode is behaving oddly. Expected behavior is to output one recipe then lock and only output the next recipe after a redstone pulse is received (as it does when you begin a crafting job with this setting enabled). My limited testing indicates that the length and side of the redstone leading into it can allow the Provider to output a recipe on both the rising edge and falling edge of the input redstone signal.

The sidedness comes into play in that it seems to take a shorter length of redstone dust to enable this behavior on some sides. In the example, the erroneous behavior only manifests after making a redstone line of length 4 to the north, but only a length of 2 to the east. Behavior is apparent with both buttons and levers. The rising/falling edge behavior is more apparent with a lever. The Pattern Provider unlocks and outputs a recipe and then locks again (as expected) when the lever is first powered on, but (when the lever is sufficiently far away) it also unlocks and outputs a recipe and then locks again when the lever is powered off.

https://streamable.com/c3bsfg (I'm looking at the item quantity changing at the top of my screen when hovering over the chest after pressing the button/lever instead of opening the chest every time to check its contents)

How to reproduce the bug

  1. Create a basic AE2 network with any Crafting Storage and any Storage method
  2. Place a Pattern Provider (either version) facing into an inventory
  3. Create any Processing Pattern, doesn't matter if it's valid. It's easiest to observe if the input only has a single item
  4. Change the mode of the Pattern Provider to "Lock crafting until redstone pulse is received"
  5. Place a button or lever adjacent to the Provider
  6. Begin a crafting job of any amount >4 for the Processing Pattern. If you choose 4, you'll have to redo this step multiple times during testing. Put enough items in your storage and craft a big enough job (20+) to annoy yourself less.
  7. Observe that a single recipe is in the target inventory after beginning the job, and that the Provider is locked and awaiting a redstone pulse
  8. Activate the button or lever
  9. Observe that a second recipe (and no more) has been inserted into the target inventory (if using a lever, turn it off and observe no additional recipes in the target inventory beyond the two we expect to be there)
  10. Move your button or lever one block farther away and lay redstone dust to reach the Provider
  11. Activate the button or lever again and observe contents of the target inventory
  12. Repeat steps 10-11 until you observe the button or lever inserting more than one recipe at a time into the target inventory

It should be noted that this does not appear to be a matter of redstone power level at the Provider. Placing the button or lever on a block above the redstone dust line leading into the Provider and extending redstone dust away from the Provider shows the same effect, even though the source of the redstone signal doesn't move and the power level (15) going into the Provider never changes when doing it this way.

The behavior is also present when a Redstone Repeater is powering the Provider.

Expected behavior

No matter the distance, side, or configuration for providing a redstone pulse to the Pattern Provider, I expect that the Provider will always allow a single recipe in per pulse (no matter the length of the pulse).

Additional details

v12.9.4 in the Valhelsia 5 modpack (5.0.18a)

Which minecraft version are you using?

1.19

On which mod loaders does it happen?

Forge

Crash log

NA but here's the mod list: https://pastebin.com/YbjvRtg3

@trunksbomb trunksbomb added the bug Self explanatory? label Jun 4, 2023
@trunksbomb
Copy link
Author

Doing some more testing.. the abnormal behavior is present up until 12 blocks out. The buttons marked red will move 2 recipes per pulse, but the buttons marked green move 1 recipe per pulse.

image

@SiebsJ
Copy link

SiebsJ commented Dec 2, 2023

Hello,
I was unable to find another report for this issue and I am similarly experiencing this. I have a chamber set up for creating withers and I have the configuration set to only craft one at a time. When sending a job for more than 2 stars, my second and every craft after that attempts to send 2 of the recipe ingredients before locking again. I also was under the impression that the 'lock crafting until redstone pulse was received' mode acted under 2 conditions. Firstly, the lock activating after a single "craft" operations (ex. sending 1 set of ingredients). Secondly, that the 'pulse' referred to was the combination of a rising and falling edge, not either/or. Is this a misunderstanding of the setting or a bug with the Pattern Provider? I am on version Forge 1.19.2 using mod version 12.9.8. None of the mods listed under 'unsupported' are on my profile.

shartte added a commit that referenced this issue Dec 7, 2024
With this change pattern providers will check if they already have a
redstone signal when locking, and if so they will wait for the signal to
depower and then power again. This fixes odd behavior with a constant
redstone signal and block updates leading to unlocking without a
'pulse'.

![2024-08-28_17 50
27](https://github.com/user-attachments/assets/f9725586-6202-42b8-bd6c-71414059f551)

Fixes #7179

---------

Co-authored-by: Sebastian Hartte <[email protected]>
shartte pushed a commit that referenced this issue Dec 7, 2024
With this change pattern providers will check if they already have a
redstone signal when locking, and if so they will wait for the signal to
depower and then power again. This fixes odd behavior with a constant
redstone signal and block updates leading to unlocking without a
'pulse'.

![2024-08-28_17 50
27](https://github.com/user-attachments/assets/f9725586-6202-42b8-bd6c-71414059f551)

Fixes #7179

---------

Co-authored-by: Sebastian Hartte <[email protected]>
(cherry picked from commit a1211bc)
shartte pushed a commit that referenced this issue Dec 8, 2024
With this change pattern providers will check if they already have a
redstone signal when locking, and if so they will wait for the signal to
depower and then power again. This fixes odd behavior with a constant
redstone signal and block updates leading to unlocking without a
'pulse'.

![2024-08-28_17 50
27](https://github.com/user-attachments/assets/f9725586-6202-42b8-bd6c-71414059f551)

Fixes #7179

---------

Co-authored-by: Sebastian Hartte <[email protected]>
(cherry picked from commit a1211bc)
(cherry picked from commit 7de2565)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Self explanatory?
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants