GotoLink

Well, if IDs are gone, they should be replaced by "unlocalized names". Considering you can already prefix those with your modid, it is guaranteed to not conflict anymore...thus you no longer need to put them into a configuration file. @thebombzen Metadata support in configuration files is entirely on the modder's hands as of now. If IDs are gone and replaced by unique names, metadata would be useless, due to "infinite" possibilities of different blocks. That doesn't mean it will be removed, since it can help organize things like planks, logs, leaves...but no modder would need to use them to reduce the block ids used.

renderTileEntityAt tries to load a TileEntity that doesn't exist. The TileEntity doesn't exist normally outside of the world (in the inventory). You can't use it directly for the IItemRenderer.

Chunk#getHeightValue(int x, int z) will give you the highest block height. The World#getTopSolidOrLiquidBlock isn't reliable for this process. (gives air block or liquid block ) What event are you talking about anyway ?

You shouldn't load the chunk. If the chunk isn't loaded, save the changes somewhere, and send them to the tile entity when the chunk is loaded, using ChunkEvent.Load.

There is nothing linking log blocks in a tree. There are just log blocks. You'll have to make educated guess for what should be considered a "tree", and what shouldn't. I have some tree algorithm, here.

Guys... Item#renderHelmetOverlay(ItemStack stack, EntityPlayer player, ScaledResolution resolution, float partialTicks, boolean hasScreen, int mouseX, int mouseY)

Let's actually reduce this list to its main points, shall we ? [*]Crafting [*]Item [*]Armor [*]Potion effects [*]Inventory [*]Dyeable item [*]Throwing weapon [*]Teleporter [*]Fishing line [*]Explosion [*]Waypoint on Block [*]Find nearest hostile [*]Smoke FX [*]Moving Entities Now you can find the classes of interest in Minecraft. Considering you have "little to no experience coding", i'd suggest learning the basics of coding, then basics of Java, completing each step before the next.

It is simple. You shouldn't use findGlobalUniqueEntityId() nor global id altogether. You just found the reason why.

You are checking for an instance of EntityLiving. Note that the player is only an instance of EntityLivingBase.

Well, first, there is a line limit per class file in Java. 3000, if i remember correctly. Second, your structure looks really symmetrical and repetitive, so it would be best to generate smaller parts individually. You can separate the lower part and the "towers", for example. Then the lower part seems to contain, a lot of round rooms.

Kinda like the End generation ?

You put searge names in your class that are already used in other classes. This confuses the obfuscator/deobfuscator. Those: int[][] field_73219_j = new int[32][32]; public void func_104112_b() { } Should be changed.

Block#onBlockExploded(World, int, int, int, Explosion)

isImmuneToFire = true;

You can search the forums for two input furnace. That would give you everything you might need.

Use LivingDeathEvent and spawn the thing yourself, or use the LivingDropsEvent to add it to the list of possible drops.

I thought you needed a code example for spawn with conditions, that is all Look into performWorldGenSpawning About your example : In BiomeGenDesert, this.spawnableCreatureList.clear(); With an empty creature list, no passive mob spawn

Yes, the client-side world name is always MpServer. You'll have to get the server side world name.

addRandomArmor() isn't called by Minecraft for every mob. You'll have to call it yourself. You might as well do just this.setCurrentItemOrArmor(0, new ItemStack(SeroeMod.redLightsaber)); when spawning or creating the mob.

Huh...SpawnerAnimals class ?

It could be a reobfuscation issue. You might want to try reobfuscating with a more recent version of mcp/forge. Also, that codechicken.nei bit could be ruining it.

...Handle the IOException. [spoiler=Hint] try/catch

Instant kill: Block#removeBlockByPlayer(World world, EntityPlayer player, int x, int y, int z) A mining operation: World#destroyBlockInWorldPartially(int...)

Locate the forge hook in the method you want to change. Search the corresponding event class. Register to the event bus and use the event class to perform changes. If there isn't a forge hook, use ITickHandler.

We need to clarify things, i think. The main difference between entityId and UUID is that the UUID is kept with the world data, while the entityId will change with each loading of the world. In either case, they are not meant to be changed at will. You can easily set whatever new flag you need in the entity NBT data. You don't need to change any of the vanilla ones. If you want your own UUIDs, go for it. But you can only set them inside your own mobs classes, and only once, or it wouldn't make sense. By the way, the LivingSpawnEvent may help you do what you want.