fabricator77

You can just de-register dimensions -1 and 1, and put your own WorldProvider in their place. Look at forge's DimensionManager.

in WorldGenAPI ItemStack it = is[r.nextInt(amountOfItems - 1) + 1]; But your giving it only 1 for amountOfItems in WorldGenWorkShop End result, r.nextInt(0) which is returning -1 sometimes and crashing things. I'd fix placeChestWithContents and placeModdedChestWithContents, you've got multiple problems, for instance nowhere does it set the size of the itemStack placed in the chest inventory.

Try this, based upon differences between your code, and the renderer for Minecraft chests. public void renderTileEntityAt(TileEntity tileentity, double x, double y,double z, float f) { GL11.glPushMatrix(); GL11.glDisable(GL12.GL_RESCALE_NORMAL); GL11.glColor4f(1.0F, 1.0F, 1.0F, 1.0F); GL11.glTranslatef((float)x + 0.5F, (float)y - -1.5F, (float)z + 0.5F); GL11.glRotatef(180F, 0F, 0F, 1F); bindTexture(texture); GL11.glPushMatrix(); model.renderModel(0.0625F); GL11.glPopMatrix(); GL11.glDisable(GL12.GL_RESCALE_NORMAL); GL11.glColor4f(1.0F, 1.0F, 1.0F, 1.0F); GL11.glPopMatrix(); } It's most likely the normal code that is your issue.

pre 1.7.2 There is a list of biomes, you randomly choose one, then apply rivers and rare/edge/sub biomes. post 1.7.2 There is 4 separate lists of biomes, which are created in such a way as to apply all sorts of rules to what goes where. This is the main reason there isn't a simple GameRegistry.addBiomes any more. As you'd need to have 4 separate ones, plus some way to deal with Minecraft's own biome rules that make Mesa 50% of the desert biomes for instance. There are work arounds, which involve a lot of extra code to either: 1. Provide your own GenLayer replacement code to swap some biomes for your biome. 2. Paint a shape of your biome over the top of the end result (this is what Thaumcraft does with it's magical forest biome). 3. Hack into the Minecraft code using reflection to override their stuff. I could write up in detail how the current biome code works, but it would take up 4 or more pages. Suffice to say there are a few issues that need to be resolved before we could even consider a set of Forge biome registration system.

This should be made into a Forge pull request, as a number of modders are going to hit the same problem. MinecraftServer.java would be the one to patch to fix this right ? Add a check for every worldServer to see if all the players in that dim are sleeping.

Tinkers Construct for 1.7.2 https://github.com/SlimeKnights/TinkersConstruct/blob/master/src/main/java/tconstruct/items/Manual.java Been meaning to look at how it works myself, but got a bigger mod to finish first.

I think you'll find the real issues are memory and speed. How long does it take to generate a hash ? How long does it take to retrieve a set of values (from the hash table) for a single block ? How many blocks in world ? How much memory total for the number of blocks ? Even if you have a single one of your blocks visible, you need to have the data for all of them in memory. Also where do you plan to store the data itself ? Using a TileEntity is a much simpler method, especially if you need to add extra values for each block.

Maybe you've just included the wrong class in your header, for example there are multiple Block classes, only two of them are part of Minecraft.

I did ask if they had any more details on this, no reply. Most likely it's the Teleporter class, as that creates (and presumably hangs onto) a number of things like two WorldServers. Could also be a lot of different things in the world itself, like chunk loading/unloading.

So create a core mod, it's still possible to edit base classes that way.

It's failing to create the child process, which is the actual server that generates the world, saves it etc. Could be a security setting, in java or your anti virus. Try using a locally installed MinecraftServer, adding forge to it and see if that works.

In EntityEnderman.java another 256 block limit. private static boolean[] carriableBlocks = new boolean[256]; and if (carriableBlocks[block.getIdFromBlock(block)]) Another derp from Mojang, and yes it does crash at that if statement when the ID is above 255. Only fix at the moment is to use /gamerule mobGriefing false . Also none of the sound effects for the Witch mob work, not sure when/how that happened.

Could also try replacing the mob spawns with EntityTNTPrimed and let the mobs blow everything up for you.

OK I've got two @SubscribeEvent handlers Neither of them work for my purposes. This one is called when the Player is connected, which does work most of the time. However sometimes the data is needed before the world loads, which causes a crash. public void onPlayerLoggedIn(PlayerLoggedInEvent event) called earlier, seems ideal, but as client isn't initialized at this point, the packet send isn't received. I cut and pasted the packet send code into two classes, the other is a CommandBase (server chat command) so common code in both. public void onClientConnected (ServerConnectionFromClientEvent event) It's all very frustrating, the data is akin to block ids, needs to be registered before it tries to use it.