Leaderboard

Cool. Yeah I really hate the convolution between all these classes. they have classes that point to each other, classes with similar names, and overall it is hard to tell what really matters. I find that going "full custom" (i.e. make your own version of everything) is safer than pointing to vanilla classes. Glad you got it sorted out.

I would probably follow these instructions: http://mcforge.readthedocs.io/en/latest/gettingstarted/

Okay, except comparing your code to the vanilla Overworld chunk it seems you have some relevant changes. I expect that many of these are changes you've done while debugging but I just want to make sure. Some things that are different from vanilla: - in the generateChunk() method you have removed all the parts where it generates most features like caves, ravines, villages, monuments, mineshafts, etc. - in the populate() method you have removed the woodland mansion generation. - your code has a method called getScatteredFeatureSpawnList() which in my Forge Reference Library seems to now be getMonsters(). I guess they changed that between your version of 1.12.2 and mine. None of the above should be an issue and I assume you probably did the removing of features as part of the debug, right? Okay, looking further at your code, in your WPMedieval class you are associating a biome provider for a single biome that is your custom Generizer.MEDIEVAL. Since that isn't a copy of vanilla I wonder if your problem is actually with your biome stuff. I'm not that experienced in custom biomes, but I'd suggest greatly simplifying that as a debug step. Only register one biome and don't remove any vanilla, or maybe even just do nothing in terms of new biomes, and see if the problem still exists. Now one thing that I always run into trouble with regarding world gen is that the relationship between classes is very convoluted. It is possible you're running into such trouble. For example in your WPMedieval you specify that the DimensionType is OVERWORLD, but if you look at OVERWORLD it is defined to have a WorldProviderSurface. In other words your world provider is pointing to a dimension type that says it has a different world provider. I have no idea if that is an actual problem, but doesn't seem "healthy". Frankly the way that the world gen classes over-reference each other can cause some weird things like that. You might want to try creating a custom DimensionType that properly points to your world provider and clean up any other such things you might find. Similarly you might want to try making a custom WorldType instead of using the vanilla one because again it might have references to a different IChunkGenerator or other stuff that conflicts with your stuff. You also have two custom IWorldGenerator classes registered. Have you tried isolating to see if they are causing trouble? -- like don't register them and see if issue goes away. Also, in your IWorldGenerator classes you end up calling the CustomGenMinable class which extends the WorldGenerator class. So you're kind of mixing the Forge IWorldGenerator class with the vanilla WorldGenerator class. I don't know if that is a problem, but I think the idea is modders should use IWorldGenerator purely. Just some ideas. -

One last update and then I'll let this die, since people were wondering what I'd figure out: First, vanilla terrain gen in 1.10.x is more memory intensive than I realized at first. The last time I looked at that it was for an older version (probably 1.6). It seems my system may not actually use much if any more memory, and if a lot of terrain is generated quickly (e.g., flying around at high speed in spectator mode) with no modded world shows that vanilla will run out of memory and start to choke at least as fast (maybe faster, it seemed that way but I didn't time it). My system also seems to generate terrain a bit faster than vanilla (though it has no rivers or beaches). So maybe that isn't a problem. Second, I think I've isolated the source of the extra save files, and know why they're so small. It seems that the method areBiomesViable() in BiomeProvider is frequently run on random seeming, distant chunks. The extra files also will appear without any modded world gen in 1.10, but do not appear in 1.12. So I suspect these are being generated by an attempt to find a locations for large structures (woodland mansions?), and the generated region files is a side effect of generating these chunks which then get saved, a minor problem that was fixed in newer game versions -- and that it has nothing to do with the mod, and was never really an issue. So that's it basically -- I was overly concerned about nothing, mistaking normal game behavior for a problem I'd caused; looking for solutions for problems that weren't really there because I didn't have a good understanding of how it was supposed to work. If I get more done on this, the next post will probably be in a new thread in the mods section, and not too soon (I'm very busy again now). Thanks everyone for all the help and advice.

jeffryfisher doesn't just mean using the actual debugger. He's suggesting that you take the normal debugging steps. Like profiling, printing to logger or console and such. How can people on a forum guess what is lagging your particular code? First off, you say that a chunk event is only happening once every 5 to 30 seconds. But you don't want to check how often a chunk event happens you want to check how long it takes to execute. Once every 5 seconds might actually be an indication of significant lag. I think there is already some profiling (timing) code in some of the world generation, but you may need to add your own. Time how long each thing takes. If something takes too long then you've found the lag.

This is where you lose me. What exactly is it that I'm storing in this variable? And are you referring to each of the four possible properties? Are these what I need to be storing in variables? getActualState returns a value of type IBlockState , you need to store this value in a variable. So here you mean instead of having state.getValue(BACK) I should be putting state.getValue(variable that stores the state.withProperty(BACK, back)? Instead of calling state.getValue(...) , call actualState.getValue(...) ; where actualState is the variable storing the value returned by getActualState .