Quantum Computer does not work with ME Level Emitter

[maxnoller]

I tried setting up a level emitter to emit a redstone signal to craft Heavy Water from Mekanism in the ATM10 Modpack. It does not work when selecting the Quantum Computer as crafting CPU but works when using normal ae2 crafting cpus.

If you need any additional information or I can help in some way let me know!

[rjbowen97]

I am encountering this issue as well! I am playing as a part of All the Mods 10. Tried switching between "emit to craft" and "emit while crafting", but neither one works. Switching between these two settings does briefly turn on the level emitter though, but just for a split second

[pedroksl]

Hey, sorry for the long time to try and look at this issue.

I was trying to use the level emitter with the autocrafting setup that is in the ae2guide. It did bug out and never completed the craft. However that also happened with a standard ae2 computer. I also don't see how the quantum computer would be any different from a standard cpu in this case (except that it is consuming the entire cpu, which it shouldn't do, ever). I'll look into it and report back if I find something.

[sp1rr1t]

Hello everyone, I need help. My quantum computer does not work at all, it becomes a full-fledged structure and is visible on the network, but as soon as a request request appears, it just freezes and does nothing, while I cannot cancel the crafting. I play on ATM10

[pedroksl]

If you're using Level Emitters, unfortunately, that bug still hasn't been solved. I've stepped through the code multiple times and everything looks to be working perfectly, and then nothing happens. The only thing I can suggest, for now, is to remove the level emitter and use other methods (like requesters or the quantum crafter) and break the quantum computer and place it again, even though this may not fix it due to nbt data. Unfortunately, this is all I have for now...

If there are no level emitters in the network, there might be more troubleshooting possible. But I would suggest creating a new issue instead of reusing this one.

[ehrenfriedtim]

Maybe you could provide us an „Advance Level Emitter“, with the same Featureset, but tested/working with the quantum CPU ?

[Kribylet]

Having this issue too using an ME Level Emitter with craft setting, observed this:

Changing the emit style caused the emitter to trigger briefly.
Replacing an oversized ME interface on the same small ME cable started the emitter for a longer period of time, but not the duration of the craft.

[DenysChuhlib]

I also play ATM10 and when using a quantum computer, only after updating the network does the emitter turn on (operation mode during crafting) for a couple of seconds and then turn off, but when using a regular processor (from AE2) it works normally.

[Mithi83]

I tried to debug this from the AE2 side of things in AppliedEnergistics/Applied-Energistics-2#8251

My current finding is that somehow lastModifiedOnTick in AdvCraftingCPULogic is always 0 when using a Quantum Computer Core. I haven't had a deeper look at your code, but you seem to have copied a lot from AE2 and added some sort of wrapper for the individual crafting jobs you spawn dynamically. As far as I can see the intention of the AE2 code is that whenever a craft finishes and the result is returned to the appropriate crafting CPU this variable is updated. I don't know if you pass that event on to the dynamically spawned AdvCraftingCPULogic or if you handle this centrally for all crafting jobs running on a Quantum Computer Core. Maybe this can help a bit with your debugging efforts.

[pedroksl]

Thank you for taking your time trying to debug this issue. As you can see, this is a long standing bug, with no solution, still. You probably found that out by now, but most of this is handled in a mixin I have in the CraftingService. onServerEndTick is a very difficult method to inject because there are multiple places where changes are required and I would never want to simply override it to implement what I needed. What I did instead was inject at the end and try to replicate the required parts for the quantum computer to work properly. I still believe the issue might be somewhere in there, but I fail to see where. I'll try to do some more testing when I get some more free time. Again, thanks for taking your time, you definitely did not have to, I appreaciate it.

[Mithi83]

Thanks for the mixin hint, I wouldn't have found that one on my own any time soon. I'm not familiar with this construct, but what I gather from the wording there I can make an educated guess at what it does. This approach seems a bit fragile to me, but unfortunately I have no good idea how to improve it easily. You basically have a copy of the code that will run after AE2 handles all normal Crafting CPUs. This might lead to interesting effects (i.e. unexpected behavior) when crafting with normal AE2 CPUs and Quantum CPUs at the same time as events are sent on partial information at different stages.

Ideally you would hook into one singular part of that function (constructing the currentlyCrafting set) rather than doing it at the end and having to duplicate the notification part in the process. I'm not sure if mixins can target that precisely but if not you'd benefit from a refactor of the AE2 implementation that puts the code you want to amend in a separate function that you can then hook into with a more precise mixin. Looking at your code you probably only need the for (var cluster : this.advancedAE$advCraftingCPUClusters) if you could run your mixin before executing the notification stuff.

Comparing the copy to the original code revealed an interesting difference though and a quick test showed that it improved the situation a bit. You have var previouslyCrafting = this.currentlyCrafting; in there and that will probably not do what you want it to do, as you effectively have the same HashSet that you access via previouslyCrafting and currentlyCrafting. Creating the set difference below will thus always result in an empty set and thus never trigger the onRequestChange. Correct me if I'm wrong, Java is not my primary programming language.

I replaced it like this with code found in AE2, which does a deep copy instead:

@Inject(method = "onServerEndTick", at = @At("TAIL"))
private void tickAdvClusters(CallbackInfo ci) {
    Set<AEKey> previouslyCrafting = currentlyCrafting.isEmpty() ? Set.of() : new HashSet<>(currentlyCrafting);

I now get two breakpoint triggers, one when the first craft starts coming from your mixin and one after the last craft stopped, coming from the original AE2 CraftingService.onServerEndTick. In contrast to a normal AE2 Crafting CPU, the ME Level Emitter stays on continuously throughout all the crafts, whereas in the AE2 case it flickers rapidly between on and off for each individual craft. I have not yet understood why this happens, but maybe we're one step closer.

Edit: The last breakpoint trigger is caused because of the if (this.updateList), presumably because your dynamic crafting CPU for that job just expired. This resets lastProcessedCraftingLogicChangeTick to -1 and thus forcibly updates the onRequestChange. The proposed change is incomplete though, because the intermediate triggers are missing. This leads to a behavior where for multi-stage crafting jobs all ME Level Emitters turn on when they are supposed to turn on, but keep emitting until the entire crafting job finishes, even if the recipe in question is no longer actively crafting.

My intuition says to look for the part where finished crafting results come back to the CPU next, but not today.

[pedroksl]

Interesting find. My main language is also not Java, I come from C++. It's sometimes hard to wrap my head around everything being a pointer.

The main thing I wanted out of that mixin was to tick my crafting the jobs. All the rest is just me trying to mimic what normal jobs do when they tick. The easiest approach, by far, would be if AE2 had a separate method that did the ticking. I could mixin that method and simply add my own and change the returned "latestChange" appropriately, and the integration would be seemingless, as far as I know.

I tried so much to mixin right after that for loop but couldn't find the appropriate injection method to do so. This ended up in me landing in the current approach of trying to mimic everything. That said, maybe a PR to change that implementation and create a separate method is the easiest solution. But I would like some form of confirmation it works before doing so. I could maybe try to compile a different AE2 version with that change and mixin into that.