Machine Monitors Placement Rather than Checking for Blocks
desagas opened this issue ยท 4 comments
compactcrafting-1.0.0-beta.2.jar; forge 36.1.16, in seaopolis B5.1
Three quick things:
A. If a craft is in progress, and you place blocks for a second recipe, there are one of two outcomes:
Part 1: If you complete that recipe BEFORE the active animation is complete, the first craft is completely voided, with no input materials or output materials returned, starting the next craft.
Part 2: If you try to start that craft AFTER the first craft has finished, none of the blocks you placed for the second craft are recognized as being valid, which means you have to break them all, and replace them.
This tells me that CC is not actually scanning for valid recipes in the area of the orange box, rather, it is only checking for changes within its area which form a valid recipe. This leads me to my next issue: If blocks have been placed before the four posts are properly set up, they are also ignored.
B. I have a 13x13x13 box. Outside of the middle block, all 4 cardinal directions, a valid max size post location is set, and an orange box forms within, 7x7x7, as intended, and should allow to craft using CC. HOWEVER, that is not the case. While the orange box is actively scanniing, it only looks that way. No placement within the orange box is recognized, regardless of items or blocks, or adding or removing already placed blocks. You can not craft. So, it looks as if two different bits of your code are competing/conflicting, one that says a valid 7x7x7 setup is complete, and one that says something is blocking the lasers, so do not craft.
Should now be closed as of beta 5; if this is still an issue, please reopen.
Beta 5 introduces proxies, which allow for improved redstone automation of fields. The field should also now deny block changes inside an actively-crafting field as well.
Demonstrated here, https://youtu.be/1UdrocxQlSg?t=738 starting at 12:18,
This is a result of the way Compact Crafting scans for blocks. It only scans once a block is placed by a user, and it is in the right state. To remedy this temporarily, you only need to break and replace one block to get it to recognize. However, the issue with the previous recipe being voided is a bug that should be fixed in an upcoming work-in-progress pull request by me.