GotoLink

Gui are client-side only, which means you can't reference it from a server file. Now check the tutorials, please.

With final ClassLoader loader = WikiLink.class.getClassLoader(); You get net.minecraft.launchwrapper.LaunchClassLoader, thus reading Minecraft.jar. You might want cpw.mods.fml.common.Loader instead.

Check the Gui, and Packets, tutorials.

Use lower case for your package. Check the @SidedProxy parameters.

this.setOwner(par1EntityPlayer.getCommandSenderName()); This works. You did something wrong elsewhere.

This method only affects the default world type array of biomes.

I'd recommend reading the tutorials in the wiki. The basic ones give a way to separate the rendering with proxies.

I meant ChunkDataEvent, which give you the chunk NBTTagCompound, thus you can read/write some values to it.

I don't understand what you are trying to achieve with this... Anyway, both packet handlers have the same name, in the same package, but are different implementations. Sounds like trouble to me.

Do option A. There are easy ways to do this. Use WorldSavedData and ChunkEvent, you wouldn't need your hashmap. Coremod would only bring world data corruption for no obvious advantages.

Man, i see wrong code everywhere... :'( Let's begin with public RenderEnt(ModelEnt model, float f) { super(new ModelEnt(), 0.5F); model = (ModelEnt)mainModel; } that is one stupid constructor. Fix needed. then ((ModelQuadruped)this.mainModel).head.postRender(0.0625F); i am pretty sure your model isn't a ModelQuadruped, but who knows ? finally EntityRegistry.registerModEntity(EntityCreeperHeart.class, "CreeperHeart", 1, this, 80, 3, true); LanguageRegistry.instance().addStringLocalization("entity.CreeperHeart.name", "CreeperHeart"); RenderingRegistry.registerEntityRenderingHandler(EntityCreeperHeart.class, new RenderCreeperHeart(TutorialMod.CreeperHeart)); EntityRegistry.registerModEntity(EntityEnt.class, "Ent", 1, this, 40, 1, true); both entities have same id, and the rendering should only be registered on client side.

player.inventory.addItemStackToInventory(new ItemStack(Base.tankAir)); if (!player.inventory.addItemStackToInventory(new ItemStack(Base.tankAir))) ... You are giving it twice here. I'd recommend removing the first line.

You can use pendingTickListEntriesTreeSet field in WorldServer to get the blocks that will update next. Why do you need onNeighborBlockChange() ? This is mostly a redstone thing...

Write some code in. protected void drawSlot(int par1, int par2, int par3, int par4, Tessellator par5Tessellator) protected void drawBackground()

Do the logs in mcp/logs give anything else ?

It is not null because world#clip(blockVec,entityVec) will give you the block#collisionRayTrace(World,int,int,int,Vec3,Vec3) You are going to need to define some orientation into your block, probably a view distance too, and make your own vectors calculation.

I am sure that having a non-void TileEntity can help

Oh right, Mojang changed that with the "boat update". Then use moveStrafing

To account for strafing, you could use moveForward /moveStrafing in EntityLivingBase...or the motionX.Z fields in Entity.

@diesieben07: I think you are confused. The OreRegisterEvent only concern the ore dictionary. This can't change other mods generation. I suggested this as a way to easily tell which ore is registered and make your own ore generation sensitive to other ores (like, lower chance if an "equivalent" ore is registered, etc.). I didn't mean to cancel anything with it.

Well actually, you can subscribe to the OreRegisterEvent and react to any registered ore however you want.

Change if(par1World.isRemote) to if(!par1World.isRemote)

What "effect" of sneaking ?

In Item class, there is a method with IconRegister as argument. You can use it to #registerIcons(String).

Set the game directory in a profile...