[1.8] [90% SOLVED] Cannot Interact With CustomFire E.G. Hit to Extinguish

[saxon564]

Its really simple.

 

First of all. Rule number 1 all non gui code must happen on server.

Currently you are running code simultanouslyserverside and clientside.

Anything that has to do witch changing blockstates has to be serverside.

 

Now in your example im going to presume your fire will always be on another block.

 

This where you use the PlayerInteractEvent to detect if your fireblock is a possible target

 

Some pseudocode(im on mobile)

@Eventhandler
Public void userclick(PlayerInteractEvent event) {
If(!event.world.isRemote) {
If(event.action == Action.LEFT_CLICK) {
if(event.world.getBlockState(event.pos.offset(event.face)).getBlock() == MyCustomChickenFire) {
Event.world.setBlockToAir(event.world.getBlockState(event.pos.offset(event.face)) );
//playsound hiss
//spawn smoke fx via networkpacket to client to tell it to spawn the fx
}
}
}
}

That still will not fix it, im am testing in creative because thats where this is the biggest problem, the client will assume you still broke the block until the server says the block is still there. So it doesnt matter how I set up the PlayerInteractEvent, the client will always break the block until it hears back from the server saying not to break yhe block. That is why the check has to be done on the client because the client does all the actions, then sends the information to the server.

[coolAlias]

You cannot cancel KeyInputEvent, but you CAN set the key state to not pressed. Whether that will happen before the MouseEvent / mouse input is processed, I can't tell you for certain, but you can certainly try it.

int kb = Keyboard.getEventKey();
if (kb == mc.gameSettings.keyBindAttack.getKeyCode()) {
// Set attack key to not pressed
KeyBinding.setKeyBindState(kb, false);
}

Then, if that doesn't unset the key press in time, you can still listen for the MouseEvent and cancel it if the mouse button pressed is the same as keyBindAttack and your other conditions are met. More economically, make callKeyInputFunctionThatChecksYourConditions() that you can use both in the KeyInputEvent and to setCanceled(resultOfThatMethod) from MouseEvent when clicking the attack key.

[TmzOS]

Idea: Just put a simple flat bounding box on the base of the block, when the player clicks... whoop...

[saxon564]

You cannot cancel KeyInputEvent, but you CAN set the key state to not pressed. Whether that will happen before the MouseEvent / mouse input is processed, I can't tell you for certain, but you can certainly try it.

int kb = Keyboard.getEventKey();
if (kb == mc.gameSettings.keyBindAttack.getKeyCode()) {
// Set attack key to not pressed
KeyBinding.setKeyBindState(kb, false);
}

Then, if that doesn't unset the key press in time, you can still listen for the MouseEvent and cancel it if the mouse button pressed is the same as keyBindAttack and your other conditions are met. More economically, make callKeyInputFunctionThatChecksYourConditions() that you can use both in the KeyInputEvent and to setCanceled(resultOfThatMethod) from MouseEvent when clicking the attack key.

Ok, I will have to try this later when I get home.

[saxon564]

Idea: Just put a simple flat bounding box on the base of the block, when the player clicks... whoop...

That may work, but I think I have to make my own block model for it? Im not sure though.

[TmzOS]

Just setup the bounding box inside the block.

 

Collision BB is when you literally touch the block and trigger contact functions... Selected is the BB that you see with a black border when point the crosshair to the block.

 

See this part of BlockCactus:

public AxisAlignedBB getCollisionBoundingBox(World worldIn, BlockPos pos, IBlockState state)
    {
        float f = 0.0625F;
        return new AxisAlignedBB((double)((float)pos.getX() + f), (double)pos.getY(), (double)((float)pos.getZ() + f), (double)((float)(pos.getX() + 1) - f), (double)((float)(pos.getY() + 1) - f), (double)((float)(pos.getZ() + 1) - f));
    }

    @SideOnly(Side.CLIENT)
    public AxisAlignedBB getSelectedBoundingBox(World worldIn, BlockPos pos)
    {
        float f = 0.0625F;
        return new AxisAlignedBB((double)((float)pos.getX() + f), (double)pos.getY(), (double)((float)pos.getZ() + f), (double)((float)(pos.getX() + 1) - f), (double)(pos.getY() + 1), (double)((float)(pos.getZ() + 1) - f));
    }

[saxon564]

You cannot cancel KeyInputEvent, but you CAN set the key state to not pressed. Whether that will happen before the MouseEvent / mouse input is processed, I can't tell you for certain, but you can certainly try it.

int kb = Keyboard.getEventKey();
if (kb == mc.gameSettings.keyBindAttack.getKeyCode()) {
// Set attack key to not pressed
KeyBinding.setKeyBindState(kb, false);
}

Then, if that doesn't unset the key press in time, you can still listen for the MouseEvent and cancel it if the mouse button pressed is the same as keyBindAttack and your other conditions are met. More economically, make callKeyInputFunctionThatChecksYourConditions() that you can use both in the KeyInputEvent and to setCanceled(resultOfThatMethod) from MouseEvent when clicking the attack key.

Unfortunately, it does not unpress the key in enough time so it still breaks the block. There doesn't seem to be an ideal way to deal with keyboard inputs. It seems it will unpress any other key except the key to break the block.

 

Just setup the bounding box inside the block.

 

Collision BB is when you literally touch the block and trigger contact functions... Selected is the BB that you see with a black border when point the crosshair to the block.

 

See this part of BlockCactus:

public AxisAlignedBB getCollisionBoundingBox(World worldIn, BlockPos pos, IBlockState state)
    {
        float f = 0.0625F;
        return new AxisAlignedBB((double)((float)pos.getX() + f), (double)pos.getY(), (double)((float)pos.getZ() + f), (double)((float)(pos.getX() + 1) - f), (double)((float)(pos.getY() + 1) - f), (double)((float)(pos.getZ() + 1) - f));
    }

    @SideOnly(Side.CLIENT)
    public AxisAlignedBB getSelectedBoundingBox(World worldIn, BlockPos pos)
    {
        float f = 0.0625F;
        return new AxisAlignedBB((double)((float)pos.getX() + f), (double)pos.getY(), (double)((float)pos.getZ() + f), (double)((float)(pos.getX() + 1) - f), (double)(pos.getY() + 1), (double)((float)(pos.getZ() + 1) - f));
    }

The more I thought about it, the more I realized that doing that still wont accomplish what I am trying to do. I am trying to make my fire work just like the vanilla fire and you can click on the side of a surrounding block the fire is on to put the fire out. doing it the way you are suggesting means you can only hit the bottom to put out the fire.

[Abastro]

It seems that fire is treated specially. It is checked before any block method gets called.

So in order to make custome fire extinguishes, you should subscribe to PlayerInteractEvent and check if it is clicking fire.

[saxon564]

It seems that fire is treated specially. It is checked before any block method gets called.

So in order to make custome fire extinguishes, you should subscribe to PlayerInteractEvent and check if it is clicking fire.

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?

[jabelar]

What happens if you handle the BreakEvent instead? I think it fires on both sides. You can check if whatever block that is breaking has a fire on top, in which case you extinguish the fire and cancel the breaking of the block.

[Abastro]

It seems that fire is treated specially. It is checked before any block method gets called.

So in order to make custome fire extinguishes, you should subscribe to PlayerInteractEvent and check if it is clicking fire.

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?

PlayerInteractEvent is called before client clicks and breaks the block. So you can just cancel the event when you extinguishes the fire.

[coolAlias]

PlayerInteractEvent is called before client clicks and breaks the block. So you can just cancel the event when you extinguishes the fire.

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.

[jabelar]

Jabelar's solution may work, provided that the BreakEvent is fired on the client as well (I haven't checked)

 

Nope, I checked and it is server side only. So nevermind.

[saxon564]

PlayerInteractEvent is called before client clicks and breaks the block. So you can just cancel the event when you extinguishes the fire.

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.

[coolAlias]

Oh yeah, you're right - KeyInputEvent does NOT fire for mouse keys, but there was a PR I saw that was going to change that.

 

Anyway, you need to listen for both KeyInputEvent AND MouseEvent, whichever one receives the keyBindAttack will need to handle preventing the interaction; MouseEvent you can cancel directly and that will 100% for sure work, but I'm not sure how unpressing the key from KeyInputEvent will work in the event that someone is using a non-mouse key to attack.

[saxon564]

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.

[jabelar]

In your first code sample, you need to remember this event will fire for every key pressed. But you set the key bind state to false in all cases, so of course it is going to prevent all key presses. The keybinding still works because you continue with code to handle it.

 

What you should be doing is only setting the key state to false inside the if statement.

[saxon564]

In your first code sample, you need to remember this event will fire for every key pressed. But you set the key bind state to false in all cases, so of course it is going to prevent all key presses. The keybinding still works because you continue with code to handle it.

 

What you should be doing is only setting the key state to false inside the if statement.

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.

[jabelar]

What exactly do you mean by "attack"? Your code should still extinguish the fire, but no other attack should happen and all other keys should be stopped.

 

And what key are you binding to the attack?

[saxon564]

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.

[NovaViper]

Hey I got a question, how come the fizz sound isn't playing when I try out the code on my custom blocks?

 

 

[saxon564]

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.

[NovaViper]

Ok. Let me see what you have so far so I can test it

[jabelar]

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.

 

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().

[saxon564]

Ok. Let me see what you have so far so I can test it

here you go

 

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.

 

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().