Creators-of-Create / Create

[Forge Mod] Building Tools and Aesthetic Technology
MIT License
2.82k stars 891 forks source link

The Server Crushing when Pressing the Diorite to make Quartz Fiber #6668

Open handle233 opened 2 months ago

handle233 commented 2 months ago

Describe the Bug

crash-2024-07-07_11.13.38-server.txt Here is the crush report. Genuinely speaking, I have a server running with AE2 and create, then I use the Machenical press to press the diorite to make Quartz fiber in AE2, the time I finish all the diorite, the server will always crushed,and leave the same report.

Reproduction Steps

1.put the diorite on the machenical press. 2.wait until all the diorite has been pressed into Quartz fibers. 3.It crushed. ...

Expected Result

Please figure it out, and if it is not the bug from create, I expect to have a feedback. Thanks.

Screenshots and Videos

No response

Crash Report or Log

No response

Operating System

Windows 11

Mod Version

0.5.1f

Minecraft Version

1.20.1

Forge Version

47.2.0

Other Mods

please access to the crush report above.

Additional Context

No response

VoidLeech commented 2 months ago

Looks to be the same type of crash as (open) #6053, #6541 and (closed, cause found) #6529. If you check the usage recipes for quartz fiber, is there a pressing recipe without an output?

handle233 commented 2 months ago

Yes, I check this pack and see the recipe is added by some Javascript, loaded by KubeJS. The crush is very similar to #6053, but unlike the issue #6541 and #6529, the recipe doesn`t come with no output. I am glad to found it was figured out in a short time. Thanks. For another things, how about add additional null judging in the code. I know this is not create's fault, but just in case.

VoidLeech commented 2 months ago

Very similar to 6053 indeed then. Can you share the relevant kubejs script? There is already an earlier null check in that bit of code that shouldn’t be invalidated; something’s either wrong with the recipe, how the recipe gets added, actually in how Create handles it, or some mod messing with Create’s internals.

If you check the usage recipes for quartz fiber, is there a pressing recipe without an output?

Also I don't think you answered this question. Obviously the recipe for making quartz fiber exists, but is there a pressing recipe that takes quartz fiber (and potentially produces nothing)?

handle233 commented 2 months ago

I filtered the minimum mods list that causes the crush, and find out the js script that cause the crush. Details will be shown in the file below. I think the problem must comes from [Item.of('ae2:quartz_fiber').withChance(0.3)], and my tries to remove the call of 'Item' was listed as a note below in the code. It turns out this change fix the bug. And what I want to stress more is that the crush only happened at the moment the last diorite was pressed, and connect a Hopper or funnel doesn't make things better. The only way to avoid crush is take it out by hand before it pressed all the diorites I put on.

The crush log: crash-2024-07-10_10.15.35-server.txt I added additional mods to help to locate the bug.

The relavent KubeJS script: pressing.js.log The file is located at ./.minecraft/kubejs/server_scripts/ae/

Addition: Focusing to the question you stressed above, I do comparisons to check if it is the recipe that cause the crush rather than some recipe output nothing I haven't found it. I'm pretty sure there are no other recipe would define the action as sth unexpected. Both the comparative experiment and the JEI conclude that.

handle233 commented 2 months ago

I guess it is the .withChance() cause the null output like the #6053 you quote above. I found if I writes.withChance(1) it works well. And the crush happened only at the moment it finished. I'm not familiar with the code, but I have done more research. And I found the game crush only when the LAST pressing of diorite comes with a null output(The .withChance makes the press null by chance). That explains why the game only crush when all diorite is finished. And why the crush seems to be random. I noticed the heldItem does really cannot be null in DepotBehaviour.tick(), unless processBehaviour has something to do with heldItem, which demonstrates where the null come from.