gnembon / fabric-carpet

Fabric Carpet
MIT License
1.72k stars 276 forks source link

Fabric 1.19.2 - Carpet spams server log with errors when handling Twilight Forest mobs #1647

Closed EvionFox closed 1 year ago

EvionFox commented 1 year ago

MC Version: 1.19.2

Fabric Loader: 0.14.12 Fabric API 0.73.0 - 1.19.2

Twilight Forest: 1.19.2 - 4.2.333 Fabric Carpet 1.19.2 1.4.84+v221018

What is happening: When in the Twilight Forest on a dedicated server, the console is spammed with "[Server thread/ERROR]: Failed to handle entity type entity.twilightforest.**" This resulted in the server bogging down and restarting. I posted a Gist of the server log, it starts around line 670+ https://gist.github.com/EvionFox/5de5dd820b02608bc5b84793b89810c5

I originally posted this bug to Twilight Forest, and they pointed out it's an error on Carpet's side: https://github.com/TeamTwilight/twilightforest-fabric/issues/168#issuecomment-1409700265

Note: This same server thread error occurs for entities from Vinery (Let's Do Wine) with the Mules and Wandering Wine Seller.

altrisi commented 1 year ago

This actually tends to be an issue with some other mod (normally a carpet extension) loading the carpet class that prepares the handling too early so we can't prepare to handle some entities.

Do you have a complete log? I can't remember rn one mod that initialized it too early, but I may find it by looking at the log and the mod list if it's the same one.

EvionFox commented 1 year ago

Thank you for the insight! I do have Carpet-Fixes installed as well.

I've taken some time to run tests to see if the behavior persists and collect the logs. Converted to text files for uploading.

Test 1 with both Carpet and Carpet-Fixes enabled: Client log: carpet1client_latest.txt Server log: carpettest1server-latest.txt

Test 2 with Carpet enabled, Carpet-Fixes disabled: Client log: carpet2client_latest.txt Server log: carpettest2server-latest.txt (Server log spam still present)

Test 3 with both Carpet and Carpet-Fixes disabled: Client log: carpet3client_latest.txt Server log: carpettest3server-latest.txt

It does look to be Carpet that is causing the issue as disabling carpet removed the Console log spam. Please let me know if there is any other information or files I can provide to help!

altrisi commented 1 year ago

It is Carpet, yes, but with just Carpet (and TF/other mods adding entities) it shouldn't happen (though I haven't looked at how they're registering entities, but I assume it's correct).

I can't seem to find much more information in the log though. Could you try with this build (1.19.2) that should give more information about to the log if we initialize too early and send the logs again?

I'm trying to make this issue not really possible to happen in newer versions, though I don't think it'll be backported to 1.19.2.

EvionFox commented 1 year ago

Apologies I wasn't able to get a chance to test the build until this evening! Here is a server log with the files from that build:

2023-02-03-5.txt

I did notice this message specifically: [08:54:29] [main/WARN]: Event server was initialized too early, this may create log spam! java.lang.Throwable: null at carpet.script.CarpetEventServer$Event.(CarpetEventServer.java:391) ~[fabric-carpet-1.19.2-1.4.84+v230202.jar:?] at org.samo_lego.taterzens.fabric.compatibility.carpet.ScarpetProfession.(ScarpetProfession.java:28) ~[taterzens-1.11.1-fabric.jar:?] at org.samo_lego.taterzens.fabric.TaterzensFabric.onInitialize(TaterzensFabric.java:31) ~[taterzens-1.11.1-fabric.jar:?] at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke0(EntrypointUtils.java:47) [fabric-loader-0.14.13.jar:?] at net.fabricmc.loader.impl.entrypoint.EntrypointUtils.invoke(EntrypointUtils.java:35) [fabric-loader-0.14.13.jar:?] at net.fabricmc.loader.impl.game.minecraft.Hooks.startServer(Hooks.java:62) [fabric-loader-0.14.13.jar:?] at net.minecraft.server.Main.main(Main.java:101) [server-intermediary.jar:?] at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:461) [fabric-loader-0.14.13.jar:?] at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74) [fabric-loader-0.14.13.jar:?] at net.fabricmc.loader.impl.launch.knot.KnotServer.main(KnotServer.java:23) [fabric-loader-0.14.13.jar:?] at net.fabricmc.loader.impl.launch.server.FabricServerLauncher.main(FabricServerLauncher.java:69) [fabric-loader-0.14.13.jar:?] at net.fabricmc.installer.ServerLauncher.main(ServerLauncher.java:69) [fabric-server-mc.1.19.2-loader.0.14.13-launcher.0.11.1.jar:0.11.1]

altrisi commented 1 year ago

That's exactly what I added, thanks for pointing to it directly!

Seems to be from Taterzens initializing their Scarpet API additions, I'll try to contribute a fix to them though I don't know if they'll backport it either, and I'm not sure if you can use custom builds in modpacks on Curseforge.

(I'd consider this to be mostly our issue due to not documenting it properly and being fragile, not fully Taterzens fault even if it's technically the cause)

altrisi commented 1 year ago

As a workaround adding the flag -Dfabric.debug.loadLate=taterzens may fix this if I understand how that flag works.

EvionFox commented 1 year ago

I understand if it ends up not being backported - that's a lot of work when I understand many have shifted focus to 1.19.3 and onwards. Hopefully this will help with future development at least. Thank you a bunch for your help troubleshooting!

altrisi commented 1 year ago

Did the flag work though? It should work in existing versions. Or does CF also not allow flags?

altrisi commented 1 year ago

I'm going to close this as the specific issue seems resolved.