[Bug]: Server unable to boot with Gregtech 1.4.0
miyoshikai opened this issue ยท 4 comments
Possible Fixes
Yes
Modpack Version
0.3.2 and 0.3.1
What happened?
from 0.3.1 and 0.3.2 with the new update to gregtech 1.4.0, the server has been unable to boot using the server wrapper MC Server Soft and gets stuck on a fluidoutput chance 0 error (more details in log).
The server will begin looping the same error forever until I forcibly shutdown the server.
A new install of the modpack without any configuration had the same issue.
my suspicion was the change in 1.4.0 that changed how kubejs and java code for fluid worked, so I downgraded gregtech to version 1.3.1 which did not have the change to modify kubejs and java code, this allowed the server to boot without any issue.
The most confusing part is that the server can launch with gregtech 1.4.0 if launched through the CMD.
CMD=Windows Command Prompt
Log relevant to the issue:
https://mclo.gs/RwCxVly
latest.log
Developer reports
No response
Having this issue as well :/
Edit: this is an actual issue with the KubeJS script the Atm9 mod pack devs made.
GregTechCEu/GregTech-Modern#1958
the issue is also reported on gregtech's issues github and a contributor said it was the KubeJS causing this.
I have it too. Even with gtceu updated to 1.44 and ldlib 28 it doesn't work. Do you know wich part of KubeJS cause this ?
There is an error in the following script:
/kubejs/server_scripts/mods/gtceu/apiary_recipes.js
On line 117, the first integer in chancedFluidInput()
cannot be zero.
It can be fixed by changing
if (flower instanceof $FluidStackJS) {
recipeBuilder.chancedFluidInput(flower, 0, 0)
} else {
recipeBuilder.notConsumable(flower)
}
To
if (flower instanceof $FluidStackJS) {
recipeBuilder.chancedFluidInput(flower, 10000, 0)
} else {
recipeBuilder.notConsumable(flower)
}
Any number between 1 and 10000 can be used in theory, it just shouldn't have been 0.
I can confirm I am also getting this on a fresh install. Using the above fix worked but I'm not sure if it is technically the proper fix (who knows what chance they intended to actually be there)
There seems to be another line that could also potentially be an issue (but doesn't cause spam like the other):