Draco18s

Just to clarify, SRG and Obfuscated are not the same. Obfuscated: af() SRG: func_173982_a() MCP: doSomething() The obfuscated ("notch") names are what you'd find if you examined the vanilla jar manually. The SRG names are run-time translations that Forge performs (Forge runs a class transformer on every vanilla class at priority 1000, most coremods run afterwards, but they can run first if they so desire). MCP ("Minecraft Coder Pack") names are the ones you see in the development environment, if they are available (otherwise you'll see the SRG names). SRG is intended as a "version agnostic" naming scheme so that mods do not depend on a specific version of Forge to run.

What.

Or you could use the getIcon(World, x, y, z) methods and ask the world what time it is...

if(player.posY < 64) { //probably underground }

Mouse over the function Right click Find references Magic

Processing power is irrelevant when all blocks that are identical use the same texture across all copies. You can put as much block as you want, it is literally irrelevant. If you want a block to have a different look, you need to be more clever than simply placing "more" of them.

Of you didn't figure it out: New ItemStack (MainModClass.yourItem)

Minor correction: Materials are a combination of things, the bit that "isn't supported" is likely the shader, which handles how lighting affects the object (hint: Minecraft has no lights).

Is in the Javadoc. 1 causes a block update. 2 sends the change to the client. 4 prevents it from being rerendered. Flags can be added together.

I would create a separate class to hold that last, too. Call it a recipe manager. It would then hold the relevant information about your custom recipes and you could have a method called isSolvent(item) which would check the passed stack/item against the list and return true or false.

When I did this for my millstone, I used metadata to define which block held which position. When the multiblock was incomplete, they are all metadata 0. When the 3x3 (just the stone portion, the windvanes and axel form a secondary multiblock) is formed, it updates the full form with each position's meta. Then when the user tries to interact I check the metadata and if its an "invalid" for the action, nothing happens. For what you're doing, you can do something similar. Simply pick a point in the formation that will act as the "master" and when the user tries to interact with any of them, just forward the interaction to the master block: you know where it is, so just call world.getBlock(masterX, masterY, masterZ).action(world, masterX, masterY, masterZ)

The Tessellator is just a wrapper around OGL calls, with the assumption that you want to draw quads. Quads are just four vertices specified in a specific order (counterclockwise, iirc). Cubes consist of 6 sides (12 if you count the inside faces) and 8 verticies. Drawing each set of 4 to make a side doesn't matter what direction you draw in, because you're going to draw in both in order to get the front face and the back face anyway. Anyway, glad you found setRenderFromInside(). I didn't know it existed, and thanks to elix for mentioning the caveat.

http://www.apostropheabuse.com/

I think you need a GL.end() and GL.start() in there somewhere if you want to change certain properties, like alpha, and not retro-actively overwrite. I can't tell from here, though.

Use the tessellator and do it manually, it's not that hard.

Minecraft "cube" rendering system has no notion of back faces. It is simply six single-sided quads.

If you want a hill, I wouldn't use perlin: your edges are too fixed to exterior constraints. I'd use the square-diamond algorithm.

Hopper doesn't count. The hopper checks every tick to see if there are any items above itself, which is not useful here.

Order matters.

Ahh, that's what I didn't know.

Even when the mods don't change? I thought it was at least stable under those conditions. And the hash is built during startup, IDs shouldn't change while the program is running and nothing about this data structure persists between runs (or even be relevant), it shouldn't even matter that the IDs changed due to a new mod install.

So I'm having an issue with a wrapper class I wrote, so I can map a block+metadata to another piece of information data. It works find in Eclipse, no problems, none. Yet I've got reports from players (of a specific modpack, none the less, I haven't had reports from anyone else) of some console spam that only shows up if there is no match between the block and the info in the hashmap. The console spam is just debug logging info trying to resolve the underlying problem. Here's a section of that logging info, note the 4th listed item: [15:43:27][com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:201]: Hard Ore block, tile.ore_diamond has no flower data. This is a bug! [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:203]: Listing all mapped blocks: [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:206]: tile.ore_iron:-1 false [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:206]: tile.ore_gold:-1 false [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:206]: tile.beyondrealitycore:oreCopper:0 false [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:206]: tile.ore_diamond:-1 true [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:206]: tile.beyondrealitycore:oreTin:0 false [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:206]: tile.ore_redstone:0 false [com.draco18s.ores.block.ores.BlockHardOreBase:func_149726_b:206]: tile.ore_redstone:1 false Here's the code that generates the logging: BlockWrapper bw = new BlockWrapper(this,-1); OreData dat = HardLibAPI.recipeManager.getOreList().get(bw); if(dat != null) { //do stuff } else { System.out.println("Hard Ore block, " + this.getUnlocalizedName() + " has no flower data. This is a bug!"); System.out.println("Listing all mapped blocks:"); Map<BlockWrapper,OreFlowerData> map = HardLibAPI.recipeManager.getOreList(); for(BlockWrapper b : map.keySet()) { System.out.println(" " + b.block.getUnlocalizedName() + ":" + b.meta + " " + bw.equals(b)); } } Here's the wrapper class: public class BlockWrapper { public Block block; public int meta; private int fHashCode; /** * the block and metadata to match, -1 matches all **/ public BlockWrapper(Block block, int meta) { this.block = block; this.meta = meta; } @Override public int hashCode() { if (fHashCode == 0) { int result = HashUtils.SEED; result = HashUtils.hash(result, Block.getIdFromBlock(block)); fHashCode = result; } return fHashCode; } @Override public boolean equals(Object aThat) { if(aThat instanceof BlockWrapper) { BlockWrapper other = (BlockWrapper)aThat; return other.block == this.block && (other.meta == -1 || this.meta == -1 || other.meta == this.meta); } return false; } } I don't get what could possibly be going wrong to cause map.get(key) to be returning null here.

Or you could call the fire info in your main mod class....

Guis are client side only. In order to make changes to slots and items, you need to do or on the server.

they need to sync the data back from the server to the client again. Look for the methods getdescription packet and on description packet.