Draco18s

MinecraftForgeClient.registerItemRenderer(...) ?

You have to save the information somewhere. Then the right-click changes that datavalue, then the addInformation function interprets that datavalue as whatever you want it to say.

Dynamic, how? In any case, this might help: https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/item/ItemArtifact.java Look for addInformation(...)

I have this feeling you didn't read what they're trying to do.

In post init loop through the list of biomes: public static void generateBiomeData() { for (int i = 0; i < BiomeGenBase.biomeList.length; i++) { BiomeGenBase biome = BiomeGenBase.biomeList[i]; if (biome != null) if (biome.biomeName == null) { System.out.println("[Wispy] Biome (id " + i + ") has null name, could not build spawn information."); } else { String name = biome.biomeName.toLowerCase(); float E = biome.temperature; float F = biome.rainfall; float H = biome.minHeight; int I = biome.theBiomeDecorator.flowersPerChunk; int J = biome.theBiomeDecorator.grassPerChunk; int K = biome.theBiomeDecorator.treesPerChunk; } } } } There are other factors too, those just happened to be ones I was using for a mod (my variable names ended up coming from an excel spreadsheet. F was column F, etc).

I figured. I tend to do really bizarre things when I mod. Works out to be great examples in so many ways for much simpler purposes. I didn't know about multiple render passes when I did that block, though. It dates about six months older than the Item...I should redo how several of the blocks are rendered. The spikes block uses three textures (I could probably just use setTextureOffset instead!)

Oh good catch.

...Forge 737? What version of Minecraft are you trying to mod with here? If it's not "1.7.x" then Lex is just going to jump in here and say "Use the current version."

It saves all changes made to it. There are ways to set values, even if those values already exist. And one of the changes you'd have to save is its initial setup. Leave that out and the file will be blank!

It's because vanilla assumes that travelToDimension() needs to create a nether portal. The reason you're "ending up back in the nether" is that you transitioned to the overworld, vanilla placed a nether portal, and because you didn't have any teleport-cooldown set, you were instantly sent back to the nether (because you were touching the created portal). I had this problem and the only solution I found was to send the player to the overworld, then move them to a new location. Even then there's a small possibility of creating a nether portal (but the player doesn't end up touching it).

Huh. I've got no idea. And you're welcome for making it neater.

Yes. Use multiple passes. First pass renders the background, second pass uses the overlay. Here's an example for an Item, but I'm pretty sure Blocks can do it too. https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/item/ItemArtifact.java (Keeping in mind that I'm using NBT data to store which icon to use and the icons themselves are stored in an API referenced hashtable) If it doesn't work in a similar manner, an ISimpleBlockRenderingHandler will work https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/client/RenderArrowTrap.java Line 109 renders the base texture and the switch statement on 110 renders an overlay across one face. Not the best code in the world, but it works, so I haven't cleaned it up.

Know what's cool about Object... ? GameRegistry.addShapelessRecipe(new ItemStack(MyMod.MyNewBlock), new ItemStack(MyMod.MyOtherNewBlock), new ItemStack(Block.dirt)); Voila!

You don't need a TESR, I was asking if you were using one. For a full cube you can either go the standard block renderer route or you can go ISimpleBlockRenderingHandler, if the default renderer won't work for you. Likely the default renderer will work and you just need to write a getIcon() function to handle your needs. There's one in the Block class that has an IBlockAccess or World parameter passed to it. Use that parameter to get your TE and determine the state and which Icon should be returned as a result.

Super easy As long as you've set up your read/write NBT functions (inventory persists across a save/load boundary) then all you need is this: public Packet getDescriptionPacket() { NBTTagCompound nbtTag = new NBTTagCompound(); this.writeToNBT(nbtTag); return new Packet132TileEntityData(this.xCoord, this.yCoord, this.zCoord, 1, nbtTag); } public void onDataPacket(INetworkManager net, Packet132TileEntityData packet) { readFromNBT(packet.data); }

In your pre-init function (the @EventHandler that takes a FMLPreInitializationEvent, though the others work as well, but best practice is pre-init) do this: Configuration config = event.getSuggestedConfigurationFile(); BAM. Now you have access to the file. config.load(); //read the file config.getBlock("name", defaultID); config.getItem("name",defaultID); config.save(); //writes any changes to the file Example: https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/DragonArtifacts.java

How is your block being rendered? ISimpleBlockRenderingHandler, TileEntitySpecialRenderer, or neither?

Those are tooltips, not subscript. The OP wanted subscript.

FTFY

Noooooo.....Don't use the language registry. That's what language files are for! So much easier and it makes translation work easier because you don't have to write code to do it.

Dude, seriously? (I couldn't get a larger snap, but you're declaring a sided proxy INSIDE YOUR PROXY, WHY ARE YOU DOING THAT?) In the future, this is the first symptom of "the code you commented out is not at fault, the problem lies elsewhere." Which it did.

Mild correction: Learn programming with modding is a bad idea. I picked up Java syntax just fine just jumping strait into modding, but I've had extensive experience with related languages. Eclipse (and Javadoc) actually gave me a nerdgasm over how powerful it was and the features it had over other IDEs I'd used in the past. Its actually really frustrating working with them now, not having Eclipse.

Careful. Some external sites like to advertise a given mod as being for a version of Minecraft it actually isn't rated for. I found Mystcraft for 1.6.4 once (already aware that it hadn't been updated, as I stalk the dev on his forums) and the download link supplied the 1.5 version.

Generally speaking if the mod's thread says "1.7" in the title or if the mod zip/jar file has "1.7" in the file name. If it says "1.6.4" then it's not going to work. Easy as pie. If that isn't sufficient, then it's also probably not updated. Especially if you had the mod before 1.7 came out. NOTHING FROM 1.6 IS COMPATIBLE WITH 1.7 How hard is that?