MineMaarten

Oh wow, how strange: It appears that the codechicken/lib version gets generated when Minecraft runs, and is placed in mcp/jars/mods/1.6.2. Anyway, I've put in this generated folder (dev version, that also gets generated) in my workspace and it works brilliantly now!

Hey, Thanks for your reply, putting the normal versions of the mods in the mcp/jars/mods folder definately helped: I now have NEI running in my dev environment. Whilst downloading the normal versions of the mod I realised that was the place where also the dev versions could be downloaded (which is probably prefered above downloading them from BitBucket). So I did that, and pasted both the dev versions of the mods (CodeChickenCore & NEI) in the mcp/src/minecraft folder. The result in Eclipse is unfortunately the following: And this is where one of the errors is located: All the errors are caused by the missing codechicken/lib package, which isn't included in the dev package.... Which strangely enough, also doesn't exist in the normal versions of CodeChickenCore ?? (I checked with winRar). Only putting the API files in my Eclipse isn't an option I think, as there are errors due to the missing codechicken/lib in the API folder as well...

Hey, I want to create a NEI plugin for one of my mods, and therefore I need NEI to be installed in my workspace obviously. And that's with what I've problems with. ChickenBones himself gave the following brief description: I downloaded the dev zips from his BitBucket, and put them in /jars/mods. What does he mean with "link it in Eclipse"? If he means 'project->Build Path->link source...', what I thought he meant, I linked the source (a copy of it, located not in the /jars/mods folder) without being in the .zip. This doesn't work too well. I've also tried just adding in a new project with it being CodeChickenCore and NEI, but this gives some import errors like (when I only add CodeChickenCore) : In class ClassDiscover: import org.objectweb.asm.tree.ClassNode; import codechicken.lib.asm.ASMHelper; Does CCC need some special libraries? And why is the lib package of CCC missing? When I search for these problems, I only get methods for versions before MC1.6, which is handled differently as far as I can tell from ChickenBones saying "Developing with my mods is now even easier". One solution could be just putting the source to run in the MCP/jars/mods folder and keep the source not being used to develop with. However when I put mods in the MCP/jars/mods folder these don't get picked up by Forge somehow.. I love Eclipse, but as you can tell from this probably I'm not an Eclipse expert . Many thanks in advance, I hope I'll be pushed in the right direction.

And if you 'just missed' the unused methods for some reason (although I think GotoLink is right), you can use Call Hierarchy in Eclipse to track where in your program the said method is being called. <3 Eclipse

Normally I would say, go look it up, it's a basic Java question. However, as this example is such a good example to explain typecasting I'll explain it to you right now: When you refer to an element of Block.blockList[], you'll get a Block, as blockList[] is an array of Blocks. And when you want to execute methods that are defined in the Block class this is fine. For example, if you want to mimic the right click on a door, you can just use Block.blockList[block.doorWood.blockID].onBlockActivated(world, x, y, z, player, side, f1, f2, f3); That is because the onBlockActivated() IS defined in the Block class (it is overriden though, to give it its opening door properties). When you wanted to use the onPoweredBlockChange() defined in the BlockDoor class, you'd tried this: Block.blockList[block.doorIron.blockID].onPoweredBlockChange(params) which gave you the following error: And this is true, there's no method in the Block class that is called onPoweredBlockChange(). And Java searches this method in the Block class, because blockList[] was like I said an array of Blocks. So Java thinks you're just dealing with a Block. We are sure that blockList[block.doorIron.blockID] is an instance of a BlockDoor. When you have this situation, you can use a typecast to tell Java that you're not just dealing with a Block. BlockDoor door = (BlockDoor)Block.blockList[block.doorIron.blockID]; I recommend that you learn more Java. When you do, you know what tools you can use to solve a problem and you understand what's going on .

spawnEntityInWorld() works for sure! In Mobspawners this is also used, although I must say the Mobspawner code got more complicated after they added custom entity spawning. On line 140 of the MobspawnerBaseLogic class the obfuscated func_98265_a() gets a call. In there the entity gets spawned at line 217 with getSpawnerWorld().spawnEntityInWorld(par1Entity). Can you show your code which proved to you it didn't work?

That's why GotoLink said Block.blockList[id], not Block.blockList[]. Small but important difference. When you do Block.blockList[block.doorIron.blockID] you'll get the instance of the Iron Door block. Java thinks however that you're just dealing with a Block, so you'll need a typecast: ((BlockDoor)Block.blockList[block.doorIron.blockID]).onPoweredBlockChange(params)

Two things: timer--; worldObj.spawnEntityInWorld(ent);

When using BlockGlass the block will have glass-like properties you may don't want to have, like the loss of the block when you break it in survival. What's the problem with creating a class?

One of another problem you could encounter is that I don't think the data which says which chunks are slime chunks is available client sided...

I see no problem, I would do it in the way you'd described I think .

In the current build of my mod PneumaticCraft there are 14 different plants each with a different way of propagating themselves. A few of these plants do that in the way you've described. You also have to plant the plants by throwing them on the ground with Q instead of right-clicking the ground. Wiki page about the behaviours.

You're registering renderers server sided? This is not correct. Register it only client sided instead. Also why are you registering the renderer for all Entities (by calling the register with Entity.class)? Use your own entity instead.

Congrats man! And visually astonishing!

You should send packets at places where client/server can desync. This mainly is the case when parts of code are only executed by either the server (updates of electricity) or client (button press in a GUI). You then should send packets at these locations. If you're updating the electricity flow (which is in the TileEntity) and the client should know about it, send a packet there to the client (with PacketDispatcher.sendPacketToAllPlayers(Packet)). If the player presses a button in a GUI, send a packet to inform the server with a packet (with PacketDispatcher.sendPacketToServer(Packet)).

The metadata you're seeing on the covers are item damages (which can be higher than 0-15). Probably what's going on is that when you place down a cover it makes the TileEntity, with data dependant on the item damage of the item used to place down the cover. So it doesn't have NBT on the item. Predefined NBT can be done though, this can be specified in getSubItems(int par1, CreativeTabs par2CreativeTabs, List par3List) from the item class, to make NBT items appear in the Creative window. Also NBT can be given to ItemStacks in the crafting handler, to output items with NBT out of crafting recipes.

Sorry, but this sounds like another 'learn Java before you're going to mod' case. Or at least learn the basics (so you can advance whilst modding). And knowing (and recognizing) the difference between object and static references is essential to this basics.

And instead of using the LivingDeathEvent you could better override setDead() with the line diesieben07 posted to stop the sound.

I suspect a name/return/parameter change in one of the methods in Block, which you are therefore are not overriding anymore? Make sure every method you should be overriding shows up with a green arrow on the left, if you're using Eclipse. I now add '@Override' at each method (code formatting FTW) I'm overriding after having experienced weird bugs related to Block as well. This will give me an error when methods change.

Once you have the knowledge after completing Mazetar's guide: You can fake an item is an Armor item, or you can put the item in the armor slot from a different (custom) inventory (which doesn't check if the item is an armor piece). All your other questions are rendering related. I therefore recommend that (after you've completed Mazetar's guide) you dive into OpenGL. An (in-depth) guide I found really nice can be found here.

You're making a new instance of EntityCreeper, instead of retrieving an existing one in the world. Use World.getEntitiesWithinAABB() to retrieve entitities of a certain type from a certain bounding box. Look at MobSpawnerBaseLogic to see it in action. There it's used to determine if there are too many entities of the spawned entity for the mob spawner to not spawn anymore. When you'll use the right AABB, you can also throw away the distance check (unless you want a spherical range).

As far as I know, you'll need a TileEntity. It can be very simple though (an empty class will do). When you have this TileEntity, you can register it along with your render class with ClientRegistry.bindTileEntitySpecialRenderer(Class<? extends TileEntity> tileEntityClass, TileEntitySpecialRenderer specialRenderer) provided that your render class is an instance of TileEntitySpecialRenderer.

You're never making an instance of Description, so it will never call the constructor like the others said.

Possible: Yes. Allowed: Not really. The problem is other mod compatibility (which is a very high priority thing of Forge modding). Say you've changed some code from the Cow so it can breed with Dirt. What would happen when there is another mod which adds a way for Cows to breed with cobblestone? When the changed code of both of these mods are inserted in someone's minecraft, these will collide. The solution to this is the abilities Forge gives you. Forge has many so-called events, which are basically methods that are fired when certain things happened (or going to happen). One of these events is the OnEntityInteract event, which will trigger when a player right clicks an entity (like a Cow). You can add code in there to allow Cows to do their thing with dirt...

The problem you're having is that the update intervals of rendering and the player movement are different. The player position is changed each 1/20s, but your line rendering is updated every render frame (which is usually much faster than the 1/20s). Say you're doing a render at the half of a tick time passed. What you have to basically do is starting with the current position of the player at the current tick, and subtract the old position of the player from the previous (server) tick. if you then multiply this by how much you're 'in' the current tick (0.5 in this case) you have the average of the two. Take a look at this code snippet to see what I mean: double playerX = player.prevPosX + (player.posX - player.prevPosX) * event.partialTicks; double playerY = player.prevPosY + (player.posY - player.prevPosY) * event.partialTicks; double playerZ = player.prevPosZ + (player.posZ - player.prevPosZ) * event.partialTicks; Like you can see, the variable holding the value telling you how far you are in the current tick is called a 'partial tick', and can be retrieved from the RenderWorldLast event.