[Neo/Forge 1.20.1 MV: 1.2.0] Trading with Piglin Travelers can cause an infinity freeze with nothing in the logs...
Jusey1 opened this issue · 8 comments
As shown in video, the game will do a complete lag-freeze where the client is confused but once the next trade is initiated, it completely bogs down into a complete frozen state with the game not responding anymore, have to use the Task Manager to close down Minecraft. However, no crash log is made and both the normal log and debug log shows nothing. I took a bit to post this bug report because I wanted to do intensive testing to see if I can get this issue to log literally anything but nothing is logged, it just completely breaks down and dies. I have literally nothing to show on how to figure out what is going on other than information about my modlist and what not which will be below...
Minecraft: 1.20.1
Neoforge: 47.1.104
Modlist: Modlist.txt
I'm gonna keep trying to test things out and see if I can get a log created to help gather information.
Trying to debug this myself right now and no results so far so I will have to ask a few questions:
- Does this just happen when trading with the traveler regularly?
- Does this still happen when the mod is alone?
- If not, what specific mods in your modlist are causing it?
I suggest you also try to do a thread dump while this bug is happening and send the .pid file generated as that can help us tremendously (or send your mods.zip file if you can't figure that out)
Working on it right now, sorry. Was doing DnD for a while. Currently gonna do a test run with the mod by itself and gonna see if it happens due to a specific issue with another mod and go from there. Will update once I do heavy testings. I do now know that the mod by itself is fine.
Will confirm, trading directly or dropping gold ingots causes the same issue no matter.
👍
Yeah I was able to get a thread dump from a personal modpack I was playing and stuff is fucky wucky to say the least. What makes it even more so is the fact when I test it out in a dev environment it just works somehow.
I'm trying to investigate more right now but real life is pooping on me hard so I don't know how soon the fix will be out, sorry for the inconvenience.
My hunch is that somehow Yung's Fortress' is causing it, but that's just a tinfoil hat thing since we both have it in our modpacks (i also need to add it to the default config lmoa)
Okay, I deleted my last comment because yeah, it's an issue with Yung's Better Fortresses. I assume this is because the original Fortress is disabled while Yung's mod is installed, so that's probably what is causing the issue. Might need to add a different kind of check using a tag perhaps which has both the vanilla and Yung's Better Fortress within it? That's my guess.
zipfilesogithubdoesntcomplain.zip
Thanks for the help so far, could you try this .jar file out? I just added the Yung's Better Fortress id into one of the tags. (its in a .zip file so you'll have to extract it and put it in manually)
Actually if that doesn't work I will probably have to manually make a separate data pack for this mod and place it front in center in the curseforge page for people using Yung's Better Fortresses( unless we think of a better solution) considering this seems like a whole issue with that mod.
I thinking you could do an "is mod loaded" check and then either just use a different tag if Yung's Better Fortresses is loaded or modify the tag in java by removing "minecraft:fortress" and adding "betterfortress:fortress" automatically. The second idea would require an additional check to see if "minecraft:fortress" is currently tagged before removing and adding just in case if someone made a datapack to remove it themselves, then you wouldn't want the mod to automatically add the other tag.
But yeah, having "minecraft:fortress" tagged, no matter what, causes the crash unless it is currently generating in the game's world.
Specifically completed in f6cb86b :) I ended up discarding the fortress entry at runtime if yung's nether fortresses is installed