Is it normal that the FPS drops to a screeching halt every time I load a world?

[Cynix32]

I was told to redirect the issue here, MercuriusXeno/Goo#122 MC 1.16.5 Forge 36.2.2 GraalVM Java8

Everytime I load a world, the FPS drops to literal 0 for quite some time (it takes really long) before returning to normal. Looking at the console, somehow aequivaleo and goo are trying to "scan" every single dimension present. It does not matter if the world is previously saved or is just a newly created worldJust wanna ask if this is normal behavior or is there something probably wrong? This is an extremely large modpack, but still, I find it somewhat absurd that loading every world would require a full 20 minute hiccup before I can actually start playing.

Console logs (only showing the point where aequivaleo tries to scan every dimension): https://gist.github.com/Cynix32/2a5750c055062106b396c4ef0010fc51

[marchermans]

GraalVM Java8 is not supported. Please ensure that you use a VM which is supported by Mojang itself.

Additionally from the log you posted it looks like something is producing invalid recipes and items. Are there any logs in: logs/aequivaleo/ingredient/ inside your minecraft directory.

Additionally if this happens everytime that means that something is busting your cache every single game load, in other words I would eventually also need graph analysis data to be able to analyze why the cache is being busted.

[Cynix32]

The logs/aequivaleo/ingredient directory is empty, aside from an error.log which is also empty. Where can I get this graph analysis data btw?

[Cynix32]

I am going to retest this by using another java runtime (OpenJDK) since you hinted that it is GraalVM is not supported. I am not going to migrate to Java 16 because most mods require java 8 and I have no intention of playing vanilla minecraft until caves & cliffs part 2 is released anyway.

[Cynix32]

Aight here's the thing: Using OpenJDK as my java runtime and increasing the allocated memory to 5 gigs caused an out of memory error. While using my original setup of GraalVM did not cause an out of memory error whilst only allocating 4.5 gigs of memory and thus going back to the full 20 minute hiccup with aequivaleo installed (hey at least I can actually play the world after the 20 minute hiccup).

Still, aequivaleo/ingredient is still empty.

[marchermans]

Okey so this will be annoying to track down for you. You will need to do a binary search in your mods list to track down the culprit mod of the cache trashing that seems to be occuring in your instance.

Todo that you will need to: 1) take half your mods list 2) run the game and load a world 3) close the game by saving and quitting 4) start the game again and reopen that world. Then check the logs. If you are on track to find the mod that is the culprit then you will see aequivalros rerunning its analysis. If not, and aequivaleo is staring that it is using a cached variant then you need to take the other half and start with that half at point 1).

The idea here is, is that there is likely some mod in your mod pack that breaks the way aequivaleo calculates the cache key. Which causes it to throw away the previously calculated values and makes it try again on every world load. Instead of when you just updated your mod or data pack.

You need todo this yourself since it is impossible for me to load a lot of mods in dev. But if you can get it reduced to 3 or 4 or just 1, i can load it in dev and then track down what the cause is for the cache key trashing and either implement a fix for it, or yell at the mod dev that he is doing something really stupid.

[Cynix32]

Found the culprit: OpenLoader and My own datapacks.

How I found out: As control, I ran an instance of minecraft with only aequivaleo and goo as it was the mod that had a dependency on aequivaleo. Control setup ran with no problems, so onward with experimentations:

1. I split the mods into 2 halves 2.When I tested those two halves separately, the problem did not appear.
2. However, combining them made the problem reappear again.
3. I then tried to DISABLE EACH MOD ONE BY ONE (but the control mods of aequivaleo & goo are still included) (dude i tell you I pulled an all-nighter on this one lmao). No problems
4. As I was testing, I removed the my datapack that contains various recipes that I made to complement and balance the modpack as I required to disable some recipes for the world to load (coz it throws a datapack load error without the mods called by the recipes in the datapack loaded, again I was testing each mod 1 by 1 so I had to temporarily disable the datapack)
5. for the entire duration of the 1 by 1 testing, no problem occured. I was at a loss.
6. I tried loading the datapack again into openloader.
7. Lo and behold the hiccup became so bad Java threw an OutofMemory Error even if I allocated 8 gigs of memory to it,
8. Openloader is not the main culprit, as I also tested it but without any kind of datapack loaded into it. It worked without problems

So as far as I can infer, it seems like aequivaleo literally rebuilds the cache everytime I load up a new world with the datapacks installed through openloader. Take note that I need openloader because it loads the custom recipes I made globally so that I don't have to set up the datapack everytime I want a new world. Why not use CraftTweaker you ask? well some mods have no crafttweaker documentation but instead use datapacks as their main way of configuring and adding recipes to the mod.

[marchermans]

Interesting.... This would mean something in the way the recipes are registered and loaded causes Aeq to not be able to calculate the same cache key.

[marchermans]

@Cynix32 Can you upload your OpenLoaders Data- and Resourcepacks? I think I can try to reproduce this then?

That is as long as you can reproduce this with that minimal test case (AKA Aeq + Goo + OL + Your packs) ?