TopSecretPorkChop

Thanks. That did it. When I stepped into the WorldGenMinable.generate() function, I noticed that the vein size was set to 0. The method was doing exactly what I asked it to do, which was of course not what I wanted it to do. I tracked the error down to my configuration code which was loading the wrong values into the vein size settings.

I have created several custom ores. I followed this tutorial, but they are not being generated in the overworld (or any dimension for that matter. I can't find anything wrong with my code, but obviously something is not right. Here is my code (my custom ores are removed for brevity, but I left my test where I try to populate the chunk with diamond blocks.) The Log shows that generateUndergroundOres IS being called! Here it is just in case. Please Help!

Thanks all. I didn't see that constructor because it was added by forge and "under the line" (i.e. at the bottom below the separator comment). I'm used to constructors being at the top of a class by convention, so I didn't look down there. I agree that is the one to use, now that I know it's there.

I'm wanting to create a custom WorldType (similar to BOP), but the WorldType class has only private constructors. What's the best way to get around this -- using Access Transformation, or Reflection? I've looked at BOP, and it seems to be using Access Transformation since the WorldType class has public constructors there. I understand how to use reflection for normal fields and methods, but I'm wondering how it could be used for a constructor since the super() call has to be the first line in the subclass's constructor. Thanks for your assistance!

There is no code that explicitly generates air. In fact air is not an actual block at all, but just an id (0) which is conveniently the default value that the byte array used in terrain generation. So essentially, any block that is not set to something else is, by default, air. That being said, a short explanation of the terrain generation process. The generation of the basic terrain is entirely contained in the ChunkProvider class. First the generateTerrain method creates the basic shape of the chunk by placing stone. First it randomly calculates the height of each of the 256 columns (16 x 16) in the chunk, and then sets the id of each block in at or below that height to stone. Then the replaceBlocksForBiome method replaces some of these stone blocks with the biome's (for that column -- each column in a chunk can have a different biome) top and filler blocks. By default this is dirt and grass, and this method is how the chunks get covered in dirt and grass (or sand in a desert biome). Incidentally, (and this is probably the part you will be most interested in) any air blocks below a certain level are already being replaced by water in the vanilla chunk generator. You could create a custom ChunkProvider class with a modified value for this variable (such as 256?) and a modified replaceBlocksForBiome method that places your custom fluid instead of water. In 1.6.4, this is done in the replaceBlocksForBiome method, but in 1.7.2 (at least the version I downloaded), this appears to be done in the generateTerrain method. Look for a variable that is set to 63 in the vanilla code. In 1.6.4, it is a class field, but in 1.7.2 it seems to be local to generateTerrain. One thing that must be said here is that in 1.6.4 any block which you want to be placed by the ChunkProvider class must have an id below 256 since generateTerrain and replaceBlocksForBiome use an array of bytes to hold the block Ids for the chunk (256 is the highest value that can be held by a byte variable). In 1.7.2 these functions use an array of Block objects to hold this data, so block ID is not an issue. (Before anyone tells me that there aren't block Ids in 1.7.2, there are. It's just that modder's don't have to worry about them anymore -- FML handles all that now). So bottom line, look into ChunkProviderGenerate (if you want more than one biome -- ChunkProviderHell otherwise) and create a custom ChunkProvider that sets the sea level (what I've taken to calling that variable) higher and possibly places your custom fluid block.

I have made a custom fluid (whose Material is Material.water -- more about that later). And placed blocks of it into the world to test what happens when the player is inside it. Just sitting there, the player doesn't drown (as I would expect from reading the EntityLivingBase.onEntityUpdate() method). When I swim upward, there is a point (and it is very short-lived) where the breath meter shows up, but it goes away quickly. My question is two-fold. First, what else would I need to do to get people to drown in my fluid? Second, is there not some hook to allow customizing an entity's behavior in a custom fluid? I want entities (well most of them) to drown in my fluid, but not be able to swim in it, or see the little blue bubbles. Here is my Fluid and Block code:

It is a Gui Button (not the vanilla class, though) that I'm trying to overlay a texture onto. Basically, I'm trying to make a button (have made actually, just not the texture part) that you can set an icon/texture overlay for as a label. This texture would then be rendered on top of the generic button texture.

I'm trying create a generic button class that can take a texture file and render it on top of the button (is a sort of label) without making a different texture for each button. I'm kindof stuck as to how to load a texture into an Icon (for rendering using drawTexturedModelRectFromIcon). I've tried creating an TextureMap instance in my GuiHandler class, but whenever I try to draw an Icon obtained using TextureMap.registerIcon(string), I get a NullPointerException. Any help on the proper way to obtain an Icon outside of the Block and Item mechanisms would be appreciated. Here is the the line I used to declare my TextureMap instance: textureMapGuis = new TextureMap(2, Textures.BLANK_TEXTURE_PNG, Textures.GUI_TEXTURE_PATH, new BufferedImage(64, 64, 2) ); I've checked to make sure that the Icon is not null (i.e. I've printed icon.getName(), and icon.minU... to the log), and it is not.

I am making a mod that includes certain recipes that combine two or more of an Item in a container (e.g. bowlSoup). The crafting result, also has a container. (Imagine combining two different types of stew to make a third type.) My problem, is how to enforce conservation of containers (i.e. neither create nor destroy bowls). So far, I can either designate a containerItem for both Items, or not which effectively boils down to, when the recipe is used either: [*]two containers go in, one container is produced, and both originals remain behind ==> 2 (originals) => 1 (result) + 2 (remaining) = 3 containers, or [*]two containers go in, one container is produced, and both originals are destroyed ==> 2 (originals) => 1 (result) = 1 container Ideally I should get: 2 (originals) ==> 1 (result) and 1 stays behind (or goes to the player inventory) = 2 containers, thus the player starts with two containers and ends with two containers. Any ideas how to do this? Thanks in advance!