Yagoki

ok if it's not showing try scrapping the if(world.isRemote) completely. See what that does, I'm to too familiar with entities, it's been a while since I've done stuff with them and i don't have the files anymore still don't know about the other one

Dang that's a lot of values! Here's how I do it: Main File Config class Adding Blocks Base Block Class (all my blocks extend this) Adding Items Base Item Class (all my items extend this) this frees up a lot of space (both in terms of your coding and the memory it occupies as each variable takes space) and is a lot easier to work with as you don't have to make sure you've use the correct variable name ext... [EDIT] The important bit in my code is the Config.getItem or Config.getBlock methods getting called in the constructor of the item/block. You must however make sure that the blocks are added in the @PreInit method AFTER the config file is loaded and BEFORE it is saved (also make sure it is sent to the config class).

I said about this already! the config file will change your IDs to avoid conflicts between things. Therefore the reason it is giving you different numbers is because you ether have an ID conflict somewhere between your item and vanilla OR some other reason it would decide to shift them (maybe moving away from some hard-coded values which it thinks are too low and may be used too frequently, not sure) If you really want to sort it try increasing your coded values by some value (say 1000) and try again.

just override registerIcons and leave it blank.

I need to add a field to my GUI a bit (a lot) like the frequency list in Wireless Redstone. Not too sure on how to do this, I've got my Basic GUI working but I need this for the GUI to function properly.

for the first bit of code, try this: @Override public ItemStack onItemRightClick(ItemStack par1ItemStack, World par2World, EntityPlayer par3EntityPlayer) { if (TuxWeaponsCore.harpoonEntity != null) { int i = TuxWeaponsCore.harpoonEntity.recall(); par1ItemStack.damageItem(i, par3EntityPlayer); par3EntityPlayer.swingItem(); } else { par2World.playSoundAtEntity(par3EntityPlayer, "random.bow", 0.5F, 0.4F / (itemRand.nextFloat() * 0.4F + 0.8F)); if(par2World.isRemote) par2World.spawnEntityInWorld(new EntityHarpoon(par2World, par3EntityPlayer, 0.7F, 5)); par3EntityPlayer.swingItem(); } return par1ItemStack; } that may fix it, not too sure if that will work but give it a shot (don't have anything like this anymore for reference) if not, play around with it just remember you only want to spawn the entity when world.isRemote = false (i.e. you're on the server), as this will send the relevant stuff to the client, also damage is only done on the server hence it wasn't doing damage as you only had it on the client. not too sure about the other problem though...

from memory I think it's these methods, Kinda set it up so my code does most of this automatically now, so i could be missing something. @Override public boolean renderAsNormalBlock() { return false; } @Override public boolean isOpaqueCube() { return false; } to drop items I think something like this: public ArrayList<ItemStack> getBlockDropped(World world, int x, int y, int z, int metadata, int fortune) { ArrayList<ItemStack> ret = new ArrayList<ItemStack>(); int count = quantityDropped(metadata, fortune, world.rand); for(int i = 0; i < count; i++) { int id = idDropped(metadata, world.rand, fortune); if (id > 0) { ret.add(new ItemStack(id, 1, damageDropped(metadata))); } } ret.add(new ItemStack(Item.stick)); return ret; }

yes. They should be if you extended it. The properties of the leaves however you will need to set using .setHardness and various other methods. Look here if you're not sure how to set the properties, it's a touch out of date, but all that's really changed is textures and you don't need to do anything about that.

haha, ok. Look through the wiki a bit and see what you can figure out, Try to do as much as you can without help as it's a better way of learning and you'll start to figure out how to solve these things in the future. If you get completely stuck post it or feel free DM me with the problem and i'll do my best to get back to you, and point you in the right direction. There is also quite a lot of good stuff on youtube if you do a quick search.

i'm confused is that good or bad? also... why the dancing stick men?

buut then they don't match and OCD rage

I think this is a bug with eclipse, it's done this to me a few times and i can't remember there ever being much of a reason. To sound cliched "have you tried turning it off and on again?"

the config won't change by itself. My code doesn't change the ID's passed to the config, only the ones read form it. If you want it to change then delete the cofig file and have it regenerated, but what i said won't change anything in the config file, only make it the same in the game. Except that other mods might not do that, leading to players going "WTF!!! ITS CRASHING BUT THE IDS ARE DIFFERENT! *RAGE*" yes, but that's the fault of the modder for not taking it into account. Normally forge puts quite a gap between the IDs anyway, so unless a modder has been extremely unconservative with their IDs then there shouldn't be many problems although yes possible rage

for the ghost entity you should be able to get away with an if(!world.isRemote) before spawning it. as for the other bug, can we see your code rather than doing this blind?

argh!! not like that! you will get a problem with if (blocksList[par1] != null) { throw new IllegalArgumentException("Slot " + par1 + " is already occupied by " + blocksList[par1] + " when adding " + this); } in the block constructor. Hence i did it how i posted. then the constructor for your block will put it into the array.

And...might cause conflicts with other mods. NO. This will cause the id shown in config to be the same as it is in game, which is also what forge shuffles the ids based on (i think...) , ergo no conflict if the other author has also taken this into account.

quite simply when you do myItem = new MyItemClass(myItemIDFromConfig); change it to myItem = new MyItemClass(myItemIDFromConfig-256); This should make it so that the IDs in the config file are the same as what it says they are in the world. (assuming you're doing everything else right). P.S. your English is very good don't worry

Vmy guess is that you've probably forgotten to de-increment them by 256 before sending them to your items. vanilla adds 256 to each of its itemIDs/shiftedIndex thingies when they get registered to avoid conflicts with its blockIDs. It also does the same thing to your items, and as the config is mostly for the mod user forge shows them the IDs in the config how they will see them in game meaning you need to remove 256 from each id as you pass it to your item. Your IDs are probably higher than you were expecting as forge does some things to try to prevent id conflicts between mods, normally by making them high (note this is only done between config files created in the same launch).

how are you adding the recipe (code plz)

shouldn't cause too much incompatibility. Most mods which reference leaves will be doing it by Block.leaves.blockID, which is the same as our blockID, or by if(block instanceof BlockLeaves) which is true for our block also as it extends BlockLeaves. A problem may occur if they do if(block.class == BlockLeaves.Class) but this wouldn't be anything critical, and i think should be fairly uncommon.

you create a class which extends BlockLeaves, this class has all the properties of BlockLeaves. Then be removing the vanilla block form the array and replacing it with your block you cause your block to be generated whenever the vanilla leaves would have been. You can then override the drops so that it drops sticks as well as saplings. P.S you will need to override the drops as follows so that the probability of saplings does not change: @Override public ArrayList<ItemStack> getBlockDropped(World world, int x, int y, int z, int metadata, int fortune) { ArrayList<ItemStack> ret = super.getBlockDropped(world, x, y, z, metadata, fortune); ret.add(new ItemStack(Item.stick.itemID, 1)); return ret; }

there are forge events (like this), but as far as i can tell there isn't one which is called when the block is broken (see full list). Someone correct me if i'm wrong, but after a few Google searches all I've found are people asking why there isn't one. that probably wouldn't work. Your class wouldn't be called when the block was broken unless you overwrote some vanilla code, which is something i guess you already know you don't want to do. You could, possibly, try doing something like the following where you register your blocks: Block.blocksList[block.leaves.blockID] = null; myLeaves = new BlockMyLeaves(Block.leaves.blockID); //BlockMyLeaves being your extension of BlockLeaves and myLeaves being the block name not sure how well that will work, but it could be worth a shot. good luck

it's even simpler than that, in my code i just do this: @Override public void onDataPacket(INetworkManager net, Packet132TileEntityData pkt) { NBTTagCompound tag = pkt.customParam1; this.readFromNBT(tag); } @Override public Packet getDescriptionPacket() { NBTTagCompound tag = new NBTTagCompound(); this.writeToNBT(tag); return new Packet132TileEntityData(xCoord, yCoord, zCoord, 0, tag); } just put that into your TileEntity class, this gets called every time the block is marked for an update and automatically passes it from the server to the client.

if you could let me know when you get back to it, that would be useful. For now i think I've found a way of doing it in my TileEntity class, but it requires at least one to be loaded for the information about the network to be remembered so it's not perfect (if one is created whilst all the others are in chunks which haven't been loaded then the information won't exist), also the method will be called in each tile entity when write/readFromNBT is called so it's not optimal. [EDIT] after a bit more googling with some stricter search terms i found this http://www.minecraftforge.net/forum/index.php?topic=8264.0 so going to have a go with it and see if it works

If you want to know why that worked it's because, previously, you were spawning the entity on both the client and server side. The "!world.isRemote" makes sure that the code is only executed on the server, which then sends the update to the client. In summary the client was being told to show a new entity twice (once by your code on the client thread and once by the server) so it showed two new entities.