Posts by radfast

    Use 238, not 237. Read what I wrote about ^^^^^ about how to use. It should work with GalacticGreg 0.4, but please note that I don't have a GregTech install myself to test this fully, so if any errors crop up please give details.


    Also, if you switch on "Enable debug" in Galacticraft core.conf it should log every time it calls the GalacticGreg worldgen in a chunk. That's just for now so we can see everything is working OK. If everything is good, I will take away that logging in a future build of Galacticraft.

    Please try out new build 3.0.6.238 with this.


    How this is intended to work:
    * in Galacticraft core.conf set "Generate other mods features on planets"=false
    * disable 'Experimental' mode in GalacticGreg


    The oregen of GalacticGreg should still generate ores in new chunks on Moon and Mars (and asteroids I guess if it works there as well) - and on any planets added by other addons.


    Blood Asp it works by duplicating the GameRegister call to your registered generator: generator.generate(fmlRandom, chunkX, chunkZ, world, chunkGenerator, chunkProvider);


    Please note that I have hard-coded this to use the generator named bloodasp.galacticgreg.GT_Worldgenerator_Space - so that generator, and only that generator, is whitelisted, if you change the name or package in future then this will stop working.


    Everyone, please let me know how you get on with this, as if it works then I will also whitelist CofHCore in the same way.


    -------


    Blood Asp it sounds like that large chunk generation search radius is certainly the cause of the "Already Decorating!" problem when that code is called via the GCCoreEventPopulate.Post event. I do not have any solution to that, but maybe we do not need a solution if the new approach of whitelisting your generator in the GameRegistry call works out OK?

    I'm pretty sure that should do the trick.


    Also afaik GT does not change the IC queue order. I'm just not sure how forge handles generations of objects that go outside of the currently generated chunk. GT Oreveins cover an area of 3x3, in extreme cases even 5x5 chunks, and they are generated in one go on calling the center chunk.

    OK I'll give that a go, I'll let you know when there's a commit for you to look at.


    I don't know how GT Oreveins work, but generally speaking any worldgen code which needs to do a getBlock() or setBlock() more than one chunk away from the chunk being currently populated will risk encountering the "Already Decorating!" problem. The reason is that getBlock() or setBlock() in an ungenerated chunk will cause that chunk to be newly generated.

    Hey Blood Asp and sorry if I repeated myself there!


    I saw this now: https://github.com/MinecraftForge/MinecraftForge/issues/1466
    I don't know the cause of the "chunk holes" issue you described there. LexManos seems to be suggesting that GT has changed the chunk IO queue order? (I'm fairly sure that's not something which GC has changed - I have thought about it but never done it.)


    My new plan is in next GC version to hook in to GalacticGreg specifically, at the same place the GameRegistry would normally call the registered worldgen, if "Enable other mods features on planets" is false. So you wouldn't need to use the GCCoreEventPopulate Is that good with you if I do that?

    Hey Blood Asp


    If "Generate other mods features on planets=false" it blocks the server from calling cpw.mods.fml.common.registry.GameRegistry.generateWorld(). As I'm sure you know, that generateWorld() code iterates through all registered world generators to generate each mod's features. Obviously, each mod's world generator is normally intended for use on the Overworld, and so it creates unwanted features (e.g. IC2 rubber trees, or Tinker's Construct slime islands) if the world generators are run on planets. So I normally recommend to players that that setting is kept to false.


    The problem is that setting that to false is disabling your mod, so I am looking at whether we can whitelist your mod there in the next version of Galacticraft.


    A better alternative could be for your mod to trigger its oregen on event GCCoreEventPopulate.Post.
    https://github.com/micdoodle8/…omeDecoratorMoon.java#L79


    I'm not sure about the "Already Decorating" type errors but I'm guessing that might also solve that problem as well.