Mystcraft 1.11.2 still has -2147483648 mystcraft test dimension, immense lag

[kragnoth]

This dimension isn't registering properly, and so allows forestry and other mods to run rampant trying to generate items in an unloaded dimension. This is causing cascading world gen lag.

I shall include a snippet of my 90 meg log file (its growing fast)

https://pastebin.com/s0mG3Vh2

[KristjanKr]

Enjoy this log too, related to the exact same issue: https://paste.ee/p/Bxlni

[kragnoth]

ok, so it looks like it is related to tick profiling. I wonder how long it runs for, or if its permanent in single player if you leave the background profiling on.

[HellFirePvP]

Its Mystcraft's Instability profiling, which is still a thing.

It performs a one-time instability calculation. Once it finished, it won't re-calculate instability. It exists to adjust instability levels of ores and other things to the current pack you're playing.

[kragnoth]

edit: I removed recurrent complex and generation time went from 2 hours to 30 minutes. Will probably try and reference this bug log there, but can probably be fixed by blacklisting this dimension.

[Ivorforce]

I recommend using either custom biomes that won't induce structure generation, or the dimension dictionary to register as a non-overworld biome. This was intended as a pull to Forge, but unfortunately still nothing has moved - so while you're at it please weigh in there since it was intended for these kinds of problems.

For ease of use, the dimension can be registered with a type through RC's FMLIntercommHandler, which will drop the UNCATEGORIZED tag and stop RC from spawning structures there.

[XCompWiz]

See #188 for more info. In short, I'm changing the baselining to only use biomes that generate in the Overworld, and to do fewer chunks overall. Should help.

As to other structure gen going on, it's possible some bugs exist in the chunk selection which confuse other mods. If we can isolate and identify these I'd be happy to fix them.

If @Ivorforce can provide a sample for the IMC messages to send I can try putting that in as well. I still feel dimensions should provide properties from which mods can apply logic to decide if they should modify the dimension. Having flat tags is rarely useful computationally; it only works well for human-readable initial categorization, and not as a final filter.

[kragnoth]

Thanks xcompwiz.

[HellFirePvP]

@Ivorforce Is the structure generation already prevented if you just register an empty list of types or does it have to have some type? And if so, is adding a new Type that's something along the lines of "PROFILING" or sufficient to prevent the spawning? - Looking through RecurrentComplex's source i couldn't find the answer to that..

[Sunconure11]

https://gist.github.com/Sunconure11/373b1363c86cbba3be6e1d13adf44599

Related.

[Ivorforce]

@XCompWiz I'd have hoped it would be easy enough to read from my intercomm handler itself but here you go. I should maybe make a dummy class for this kind of stuff.

    public static final String MOD_ID = "reccomplex";

    NBTTagCompound message = new NBTTagCompound();

    message.setInteger("dimensionID", dimID);
    NBTTagList types = new NBTTagList();
    message.setString("types", types);

    FMLInterModComms.sendMessage(MOD_ID, "registerDimension", message);

@HellFirePvP Good question, I had to check myself. It would be enough to register an empty list (though I definitely don't recommend it, at least TOP_LIMIT or NO_TOP_LIMIT (and vice versa with bottom) should be set, and perhaps a general indicator of which mod it belongs to. See https://github.com/Ivorforce/RecurrentComplex/blob/master/src/main/java/ivorius/reccomplex/dimensions/DimensionDictionary.java#L123.

[Robijnvogel]

This profiler causes the log to mention Tough As Nails as a cause of cascading worldgen lag. See @Sunconure11 's log. TAN is not a mod that does any worldgen at all. The only thing I can think of why it would load a new chunk, is because it is calculating the temperature around a player and encounters a new chunk in the process. This typically doesn't happen, because a real player would have loaded all chunks in a radius of +-10 chunks ages before.

So now my question is: Is your profiler using some kind of fake player? The log supports this, as most mentions of TAN loading new chunks occurs in groups of three or four lines and every chunk has four neighbouring chunks around it of which some may already be loaded/generated.

[XCompWiz]

@Robijnvogel Pretty sure there's no fake player involved. Also pretty sure there was some issues with the baseline profiler generating the wrong chunks, though, so that hopefully cleared up.