MineMaarten

The MCP recompiler doesn't know that you're using a .jar. Everything that has to be recompiled should be in the mcp/src folder. So I think the solution would be to download the dev version from the Buildcraft Github, and add it to the mcp/src folder. Yes, this will output the Buildcraft mod as well in the mcp/reobf folder, but you can just leave it there.

f1 is the rotation angle, of all following angles: f2 is how much of the angle given at f1 will be rotated on the X-axis (so if f1 is 90 degrees, a value of 0.5 in f2 wil result in a 45 degree rotation on the X-axis). f3 and f4 are the same for the Y- and Z-axis.

As NEI changes a baseclass (GuiContainer), and relies on CodeChickenCore to work, I don't think there is an other way to make NEI work in your workspace than putting them both in your Minecraft project from Eclipse (I'm also using 'the Pahimar setup'). But I would very much like to be corrected on that, as I also would like to have separate projects in Eclipse for CCC and NEI.

I've recently done it. Where you can find the most information about how to do it is in the NEI code itself, and especially codechicken.nei.recipe.TemplateRecipeHandler.java. You probably want to extend this class to fill it in your way. If you want an example, take a look at LP's NEI plugin: https://github.com/RS485/LogisticsPipes/tree/MC-1.5/common/logisticspipes/nei What you can see there is for your plugin to be activated by NEI, you need a class that has the name NEIxxxxConfig.java and implements IConfigureNEI. When you do, this will be picked up by NEI (when it's installed), and it will invoke loadConfig().

And if your TileEntity is implementing IInventory (it probably will be), make sure that you're preventing automation (like Hoppers) to insert invalid items by properly implementing isItemValidForSlot().

If you take a look at the GuiTextField class, you can see there are three methods in there that'll help you out. These are setEnableBackgroundDrawing(boolean), setTextColor(int) and setDisabledTextColor(int).

That packet is used to sync the data (text) of the sign between client and server. When you (on the client) just wrote the text you want to put on the sign and confirm it for example. When this packet is read by the receiving side it checks if the TileEntity located at the location the packet sent is a TileEntitySign. You could try to use this packet instead of trying to change it / implement your own, by making your TileEntity class a subclass of TileEntitySign. If you have more data you want to send along with this predefined packet (and you want to use getDescriptionPacket() for something else) you could use the Packet132TileEntityData packet. And if you don't understand what I'm saying: There are many tutorials about packet handling

I was thinking 'that can't work, Lava Buckets are container items and are used up too'. Tested it, and they didn't. I didn't know that. When did Mojang add that . It has been some while that I've used a Lava Bucket as fuel source. Anyway, cool feature, and GotoLink's solution will work .

i cannot import @NetworkMod or @Mod Both these annotations still exist, so the problem lies somewhere else (is your (Eclipse ?) workspace properly configured?)

Or you can use EnumChatFormatting: LanguageRegistry.addName(exname, EnumChatFormatting.GOLD + "DumbExample"); It saves you the time looking it up.

You've almost got it right. Now you're setting up a AABB for only a part of the radius. This can be solved by doing this: List<EntityMob> e = player.worldObj.getEntitiesWithinAABB(EntityMob.class, AxisAlignedBB.getBoundingBox(player.posX - 5, player.posY - 5, player.posZ - 5, player.posX + 5, player.posY + 5, player.posZ + 5)); Checking for e.size() > 0 is unnecessary, as the test of the for loop will be false at the start (0 <= 0 - 1) = false. But this is a small side note. This code should work at the server side as well.... By the way, if you want to have a real max of 5 blocks, you can use Pythagoras' theorem to filter out entities that are outside your radius (you're now checking in a box around the player).

A wooden pickaxe in a Furnace gets used up straight away, it doesn't get damaged...

Learn java first . (just kidding )

private void generateSurface(World world, Random random, int i, int j) { if(random.nextInt(4) == 0){ int firstBlockXCoord = i + random.nextInt(16); // int firstBlockYCoord = random.nextInt(256); int firstBlockZCoord = j + random.nextInt(16); new AirTempleStructure().generate(world, random, firstBlockXCoord, world.getTopSolidOrLiquidBlock(firstBlockXCoord, firstBlockZCoord) - 1, firstBlockZCoord); } } In this case this means that every chunk has a 1/4 chance to spawn your structure. This ratio easily can be changed to your taste of course.

Hmm you guys are right! I'm learning everyday on this forum, thanks

And where are you sending your packet (PacketDispatcher.sendPacketToAllPlayers(getDescriptionPacket())) ? I would put that just after you set the progress to 13. Or you can move the checking for progressticks being 0 to only be executed by the server as well, and send the packet when you change the power.

I still find this a very strange behaviour. In my UV Lightbox TileEntity (from my PneumaticCraft mod), I've done something similar. The only thing I've done is overriding getLightValue() : @Override public int getLightValue(IBlockAccess world, int x, int y, int z){ Block block = blocksList[world.getBlockId(x, y, z)]; if(block != null && block != this) { //checks that are also done in the super method. return block.getLightValue(world, x, y, z); } TileEntity te = world.getBlockTileEntity(x, y, z); if(te != null && te instanceof TileEntityUVLightBox) { return ((TileEntityUVLightBox)te).areLightsOn ? 15 : 0; } else { return 0; } } The areLightsOn boolean variable in TileEntityUVLightBox is managed server side, and is updated in the client via packets.

Don't use the blockMetadata in the TileEntity, and don't save it in NBT (Minecraft will do that for you). Use getBlockMetadata() instead. You can see in getBlockMetadata() why: /** * Returns block data at the location of this entity (client-only). */ public int getBlockMetadata() { if (this.blockMetadata == -1) { this.blockMetadata = this.worldObj.getBlockMetadata(this.xCoord, this.yCoord, this.zCoord); } return this.blockMetadata; } blockMetadata is just a variable in the TileEntity which holds the metadata, and gets updated when you call getBlockMetadata(). It says in the MCP (?) description that it's client only, but as far as I can see it isn't (and I've used it on server side successfully as well). If you want to set the metadata from your TileEntity use the good old worldObj.setBlockMetadataWithNotify(xCoord, yCoord, zCoord, metadata, updateflags).

No, on both the client and server is the same game running. Most of the things should be executed on both client and server. There are things that are side specific yes. GUI's and rendering are examples of things that only should run on the client. Some things only should be executed by the server, and most of the times these are things that if they were executed by both client and server, desyncs will happen (they both execute in a different way). This is the case for example when random numbers are being used. And that is for instance with explosions, as the blocks removed in the world by an explosion is determined by a random number generator. Therefore explosions only should be executed on the server (with a !worldObj.isRemote). About your problem: Even if the server would update the information on the client, the client will still execute the same piece of code to calculate the lighting, which means also the client will get its light value of the getIsLit() method in the (client sided) TileEntity. Solution: Remove the check of !worldObj.isRemote.

The getIsLit() method in your tileEntity, and the field that returns the value: Is that set on both client and server side?

How are you getting your TileEntity if you have no access to a World object? You aren't, and are using static methods/fields? Don't. You can use one of Forge's added methods to the World class: public int getLightValue(IBlockAccess iBlockAccess, int x, int y, int z) IBlockAccess is all you need, as that type has the method getBlockTileEntity(x,y,z) (IBlockAccess is implemented by World).

As a side note, you're not supposed to put your src in the assets folder (previously the mods folder), only resources as textures. @SidedProxy(clientSide = "assets.jordsta95.ClientProxy", serverSide = "assets.jordsta95.CommonProxy") public static assests.jordsta95.CommonProxy CommonProxy; assets or assests ? your Client and Common proxy are located in assests.

This is entirely dependant on what you want to do with the random tick. In the example you gave it does some plant-like behaviours. But you want to spawn an item in, and that doesn't need the code you've just posted, GotoLink's code is what you need.

public static int minecoinBalanceWallet = 0; public static int minecoinBalanceBank = 0; The balances are defined static, which (if this on its own doesn't ring any bells) means that they can't be instantiated, and are the same in every world.

I don't think this has something to do with the drawRect() method. Can you show how you're doing your texture binding? Whoops, no texture off course! Can you show how you're doing your other rendering? Could it be that this render is done first, and another thing is rendering above this box?