AE2 Does Not Show Stored Items and Eventually Crashes

[moonlee7777]

Your GTNH Discord Username

catbomb`

Your Pack Version

2.5.1

Your Server

private

Java Version

Java 21

Type of Server

Vanilla Forge

Your Actions

Nothing done, AE2 just randomly stops showing stored items sometimes. Reloading AE2 does not fix it, but might briefly show some stored items. Depending how severe it is, another AE network might show items, or it might not. Reloading the server sometimes fixes it, sometimes doesn't. When it doesn't, we need to roll back to a previous save. Sometimes instead of being blank, it shows all craftable items but not any stored items. I talked about it with Divran on discord a couple weeks ago, and he said that he had the same issues prior and could not fix it. There was another person who had the same problem in the discord a couple days ago, and he had to roll back to fix it as well. It's incredibly annoying and happens often enough that it's an active nuisance in our playthrough, and any help would be appreciated.

Crash Report

https://pastebin.com/gQTRnXct (most recent log, but each log looks a bit different. There was only a dual interface at the coordinate specified, breaking it didn't fix anything. I can provide regular server logs if necessary as well.)

Final Checklist

• I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying the crash still exists will prompt us to investigate and reopen it once we confirm your report.
• I can reproduce this crash consistently by following the exact steps I described above.
• I have asked other people and they confirm they also crash by following the exact steps I described above.

[moonlee7777]

Adding on, crafts still work fine when the AE system is broken (as in that it continues to run the crafts fine)

[oier-namespace-std]

Same thing happened to our server (multiple times, however can't reproduce) recently. :<

I think this issue should be on the todo-list of 2.6.0.

[chochem]

Same thing happened to our server (multiple times, however can't reproduce) recently. :<

I think this issue should be on the todo-list of 2.6.0.

Not much anyone can do without a way to reproduce it though.

[oier-namespace-std]

Same thing happened to our server (multiple times, however can't reproduce) recently. :<
I think this issue should be on the todo-list of 2.6.0.

Not much anyone can do without a way to reproduce it though.

Yeah, we need a simpler way to reproduce this problem (i.e. a minimal setup of ME network to trigger this).

In our server the problem happens always after a large crafting request with some failed attempts of crafting before (the stored material is consumed during the calculation)

[Ubus99]

crash-reports.zip
Similar problem, but slightly different,
my server crashed 200 times last night, so providing the world might be helpful.
Looking at the logs in comparison, it seems to be a bad null check in the crafting storage, coupled with something going wrong in the fluid discretizer and import bus. Might be a problem where machines simultaneously try to access fluids.

[Ubus99]

Broken world.

We had this bug before, but thought we were able to fix it:
We went online before the ME was fully initialized, and cut the cables to the crafting storage.
Later we were able to reattach them, indicating an initialization bug.

That being said, we never verified if that was really the issue, it might also be coincidence.
Update:

1. Loaded server, crashed again.
2. Removed Crafting CPUs from Network, stopped crashing.
3. Added back half of CPUs, crashed again
4. Removed them again, doesn't crash anymore
5. added CPU back, didn't crash this time
6. reloaded with connected CPUs, didn't crash, either.

maybe broken autocrafting job

[oier-namespace-std]

My crafting status also have such 'ghost fluid' craftings every time right before crash.

It seems that AE2FC is suspicious.

[moonlee7777]

For what it's worth, we managed to fix it with a custom jar provided by ghzdude. He said he added a null check for crafting jobs and that's what was causing the system to crash. Got the custom jar a month or so ago and the ae hasnt crashed since.

[oier-namespace-std]

For what it's worth, we managed to fix it with a custom jar provided by ghzdude. He said he added a null check for crafting jobs and that's what was causing the system to crash. Got the custom jar a month or so ago and the ae hasnt crashed since.

So can he open a PR for this problem before release of 2.6.0?

[moonlee7777]

For what it's worth, we managed to fix it with a custom jar provided by ghzdude. He said he added a null check for crafting jobs and that's what was causing the system to crash. Got the custom jar a month or so ago and the ae hasnt crashed since.

So can he open a PR for this problem before release of 2.6.0?

I dont want to bother him about it, since he just made it for us because we asked. I can post the code snippet he said he added here if it helps.

[moonlee7777]

OK I'm home, this is what he added.

if (this.finalOutput == null) { if (!errored) { StringBuilder builder = new StringBuilder(); if (!getName().isEmpty()) { builder.append(String.format("\"%s\" ", getName())); } builder.append(String.format("at \"%s\"", min)); AELog.warn("The final output of the Crafting CPU %s was null!", builder.toString()); errored = true; } return input; }

He said that the problem was the crafting cpu's finalOutput being null when it shouldn't be. @chochem if you want to take a look at this fix then it's right there, it worked perfectly for us.

[oier-namespace-std]

OK I'm home, this is what he added.

if (this.finalOutput == null) { if (!errored) { StringBuilder builder = new StringBuilder(); if (!getName().isEmpty()) { builder.append(String.format("\"%s\" ", getName())); } builder.append(String.format("at \"%s\"", min)); AELog.warn("The final output of the Crafting CPU %s was null!", builder.toString()); errored = true; } return input; }

He said that the problem was the crafting cpu's finalOutput being null when it shouldn't be. @chochem if you want to take a look at this fix then it's right there, it worked perfectly for us.

Checking finalOutput seems not to be a very good solution, even though it works well.

I wonder if it's the problem of this NULL check, or it has a even deeper reason?

Typechecks:

src/main/java/appeng/me/cluster/implementations/CraftingCPUCluster.java, L798: this.finalOutput = job.getOutput(); where job with type final ICraftingJob;

src/main/java/appeng/crafting/v2/CraftingJobV2.java, L37: return originalRequest.stack; where originalRequest with type CraftingRequest<IAEItemStack>;

Further investigation needed. I'm not familiar with Java. :(