saxon564

Basing off what Ernio said, the only way you may be able to do this is to make your own lightmap and have your block emit your light. This way you can create a shaded "overlay" that would be projected onto the blocks. When I say this I am referencing how the lighting system works in vanilla Minecraft which has a slight yellow hue to it. I cannot say however that this IS possible, but it may be worth looking into if it is.

it was only just the other day that I saw Draco introduce it.

I have a feeling this is going to become a staple on these forums now!

your file name does not appear to be correct with the unlocalized name of your item. This is the name I am seeing on dropbox for your item: item.druidicstavecore.png. It should not have that extra period after the word 'item'.

Was to tired last night, didn't think of adding "VillageBuildings.registerVillagePieces()" to my main class, which fixed it. Sorry for wasting your time!

I know the issue is with the registering of the village, but I am not sure how to fix it as everything seems to be right to me. Crash Report: Main class here and World package here Does anybody know how I need to be registering this to get it working?

What type of entity are you using, a LivingEntity, a ItemEntity, or some other kind of entity?

Everything you have there is only happening on the client that did the action. the server does not update the block. EDIT: You also need to check for pos to be null, because if you hit an entity, pos is null and it will crash.

no you have to do new ItemStack(item, qty, meta) I will let you fill in the specifics. How to implement it should be self-explanatory.

try float xpToDrop = new ItemStack(block, 1, blockMeta).getItem().getSmeltingExperience(new ItemStack(block, 1, blockMeta));

I meant to send the packet, which with the wording I used would still technically be correct, but its all on interpretation there. EDIT: I have gotten everything working right with the mouse. You can see the final code here for the event handler and here for the packet management EDIT2: I have determined, the only way this would work all around would be using the PlayerInteractEvent, but I would have to translate it to a client event and send it as a packet to the client to cancel it. Just some final thoughts about it. Im probably just going to stick with what I already have for now.

try taking the ItemStack and adding .getItem().getSmeltingExperience(Your ItemStack) ane see what that returns, in the method you are calling it is using that to get the experience to return, but it doesnt seem like it is getting the right values. So try it that way and see what you get.

Could you show everything related to your call, like where you get your block and metadata?

I do have it setup to run when the key is pressed and not released. EDIT: I set it up so that if someone is using a keyboard press to try to get rid of the block it will say "Please contact saxon564 if you are trying to put out a fire using a key on your keyboard as your attack key." This will help show me how many people actually use their keyboard. Now I just need to get the packet sending all figured out and get the mouse input to run on the server.

I will admit, I have never looked into reflection before and have no idea how to do it. So far what I have found about it, shows, but doesnt really explain really well.

You would have to use ItemStacks to specify metadata.

here you go Okay, I just wanted to clarify that you weren't still attacking with mouse and that attack meant more than just extinguishing the fire. I think the problem is that the setKeyBindState() method is the wrong method to use, you should use unpressKey() -- If you look at both methods, the key bind state doesn't affect the timer that is checked when you call isPressed(). there is no unpressKey(), there is an unpressAllKeys().

I havent quite figured that out yet, I know the fizz sound plays when using the PlayerInteractEvent, so I'm thinking it has to be played on the server.

I know what it SHOULD do, and i know it is not doing it. "attack" is the key binding mc.gameSettings.keyBindAttack.getKeyCode() which most people have set to left click. For testing sake I have been setting it to 'm' now the issue that is happening, is that the code does not stop the attack, and breaks the block the fire is on, when it is not supposed to do that.

I'm aware of this, the point of it was to show that if someone binds Attack top a key, setting the key press to false does NOT stop it like you would expect. The idea is to stop the attack command from breaking the block the fire is on by canceling it, but you cannot cancel the KeyInputEvent, which is why you have to set the key press to false. Those were just a couple things I did to test if it would cancel the attack command.

Well heres the thing with the KeyInputEvent that is really confusing me. This stops all key inputs EXCEPT attacking from happening. @SubscribeEvent public void onInputEvent(KeyInputEvent event) { int key = Keyboard.getEventKey(); Minecraft mc = Minecraft.getMinecraft(); EntityPlayer player = mc.thePlayer; World world = mc.theWorld; int bind = mc.gameSettings.keyBindAttack.getKeyCode(); BlockPos pos = mc.objectMouseOver.getBlockPos(); EnumFacing face = mc.objectMouseOver.sideHit; KeyBinding.setKeyBindState(key, false); if (key == bind) { MoChickens.logger.info("Key Input Event"); if (world.getBlockState(pos).getBlock() != null) { this.extinguishFire(player, pos, face, world, event/*, key*/); } } } This stops no key inputs at all. @SubscribeEvent public void onInputEvent(KeyInputEvent event) { int key = Keyboard.getEventKey(); Minecraft mc = Minecraft.getMinecraft(); EntityPlayer player = mc.thePlayer; World world = mc.theWorld; int bind = mc.gameSettings.keyBindAttack.getKeyCode(); BlockPos pos = mc.objectMouseOver.getBlockPos(); EnumFacing face = mc.objectMouseOver.sideHit; if (key == bind) { MoChickens.logger.info("Key Input Event"); if (world.getBlockState(pos).getBlock() != null) { KeyBinding.setKeyBindState(key, false); this.extinguishFire(player, pos, face, world, event/*, key*/); } } } At one point it was canceling everything, but I can't remember where I had it before.

He's gone over this before: it does not work because PlayerInteractEvent is not called on the client when left-clicking a block, so on the client it still looks like the block breaks for a split second and then reappears after the server re-updates the client saying 'hey, that didn't actually break.' Jabelar's solution may work, provided that the BreakEvent is fired on the client as well (I haven't checked) and BEFORE the block disappears from the world. Otherwise, the only way to stop the visual glitchiness is to intercept the actual attack key press on the client. @OP The KeyInputEvent will work, as I said, but if the attack key bind is set to the mouse, you have to intercept it from MouseEvent first and cancel that if your conditions are met, because as you found out unsetting the key pressed value is not fast enough to stop the mouse from clicking through. Thank you for explauning that to him, its getting tiring having to explain that to everyone who comments. Haha As for KeyInputEvent, from the testing I've done, it does not fire with mouse input. And it is very fikle with how it works, I am on my phone right now, so when I have a computer and time, I will show you what I mean.

If you are going to stick to 1.7 because 1.8 is "hard" to update to, then you will be stuck at 1.7 forever because it's not going to get any easier to update as time goes on.

My bad, didn't realize it was final. It looks like you can use your own version of it, the BiomeGenOcean class has public void genTerrainBlocks(World p_150573_1_, Random p_150573_2_, Block[] p_150573_3_, byte[] p_150573_4_, int p_150573_5_, int p_150573_6_, double p_150573_7_) { super.genTerrainBlocks(p_150573_1_, p_150573_2_, p_150573_3_, p_150573_4_, p_150573_5_, p_150573_6_, p_150573_7_); } You may be able to use that and make your own genBiomeTerrain method. How it is working in the BiomeGenOcean class it it is sending the variables to genTerrainBlocks in the BiomeGenBase class, which is then sending the variables to genBiomeTerrain. I cannot say for sure if that would work, but it's worth a shot.

I know that would work, but it causes a block 'blip' meaning the client still breaks the block, then puts it back when the server tells the client it is still there. Would you know how to fix that?