Jump to content

PlayerInteractEvent issue


Sikhstar97

Recommended Posts

I have a custom bucket and in the Item*** for the custom bucket, I have code set that allows the bucket to become full when I right click water or lava.

However, we I try to do it for air, I obvisouly have to instead use the PlayerInteractEvent in my EventHandler like this:

public void playerInteract(PlayerInteractEvent event)
{
	EntityPlayer player = event.entityPlayer;
	if(player.inventory.getCurrentItem() != null && player.inventory.getCurrentItem().itemID == Base.customBucketEmpty.itemID)
	{
		if(event.action.equals(Action.RIGHT_CLICK_AIR))
		{
			player.inventory.addItemStackToInventory(new ItemStack(Base.customBucketAir, 1));
			if(player.capabilities.isCreativeMode == false)
			{
				--player.inventory.getCurrentItem().stackSize;
			}
		}
	}

 

However, this means that when I right click block, the water block disappears, but the air bucket returns instead of water. How can I fix this?

Link to comment
Share on other sites

Hi

 

So how does your custom bucket differ from a normal bucket?  So far it sounds exactly like a normal bucket.  If so, why aren't the two existing ItemBucket methods suitable?

 

-TGG

 

Ok so I took this on board and ditches the handler and used the method within the ItemBucket class (obviosuly in my custom class) I took the following the code and tweaked like so

if (par2World.getBlockMaterial(i, j, k) == Material.air && par2World.getBlockMetadata(i, j, k) == 0)
                    {
                        //par2World.setBlockToAir(i, j, k);

                        if (par3EntityPlayer.capabilities.isCreativeMode)
                        {
                            return par1ItemStack;
                        }

                        if (--par1ItemStack.stackSize <= 0)
                        {
                            return new ItemStack(Base.customTankAir);
                        }

                        if (!par3EntityPlayer.inventory.addItemStackToInventory(new ItemStack(Base.customTankAir)))
                        {
                            par3EntityPlayer.dropPlayerItem(new ItemStack(Base.customTankAir.itemID, 1, 0));
                        }

                        return par1ItemStack;
                    }

I replaced Material.air with water and then lava, and the returned item to something else.

With water and lava, it works fine.

HOWEVER, when I right click mid-air, nothing happens. It's probably because this material has isSolid set to false. Anyway around this?

Link to comment
Share on other sites

Hi

 

So when you right-click in mid air with an empty bucket, you want the bucket to stay empty, and in addition a second custom item ("compressed air" or "captured butterfly" or similar) to appear in the player's inventory?

 

-TGG

Well the stack of empty buckets will decrease by 1. But I'm not bothered about that because I know how to do it,

What happens is that when I right click mid-air, all is fine, but when I right-click water, it's like the game runs the method when right-clicking water AND air (because you're right-clicking water "through" air in a sense). I just need help working around this.

Link to comment
Share on other sites

Hi

 

The reason this is happening is because of the way the code tells whether you've clicked on a block or not.

 

 

In Minecraft.clickMouse(1) is where it's all happening:

 

            if (this.objectMouseOver == null)
            {
                if (button == 0 && this.playerController.isNotCreative())
                {
                    this.leftClickCounter = 10;
                }
            }
            else if (this.objectMouseOver.typeOfHit == EnumMovingObjectType.ENTITY)
            {
//snip
            }
            else if (this.objectMouseOver.typeOfHit == EnumMovingObjectType.TILE)
            {
                int j = this.objectMouseOver.blockX;
                int k = this.objectMouseOver.blockY;
                int l = this.objectMouseOver.blockZ;
                int i1 = this.objectMouseOver.sideHit;

                if (button == 0)
                {
                    this.playerController.clickBlock(j, k, l, this.objectMouseOver.sideHit);
                }
                else
                {
                    int j1 = itemstack != null ? itemstack.stackSize : 0;

                    boolean result = !ForgeEventFactory.onPlayerInteract(thePlayer, Action.RIGHT_CLICK_BLOCK, j, k, l, i1).isCanceled();
                    if (result && this.playerController.onPlayerRightClick(this.thePlayer, this.theWorld, itemstack, j, k, l, i1, this.objectMouseOver.hitVec))
                    {
                        rightClickNoEffect = false;
                        this.thePlayer.swingItem();
                    }

//snip

               }
            }

            if (rightClickNoEffect && button == 1)
            {
                ItemStack itemstack1 = this.thePlayer.inventory.getCurrentItem();

                boolean result = !ForgeEventFactory.onPlayerInteract(thePlayer, Action.RIGHT_CLICK_AIR, 0, 0, 0, -1).isCanceled();
                if (result && itemstack1 != null && this.playerController.sendUseItem(this.thePlayer, this.theWorld, itemstack1))
                {
                    this.entityRenderer.itemRenderer.resetEquippedProgress2();
                }
            }

 

.objectMouseOver contains the first object that your line of sight intersects within a certain distance (6 blocks from memory).  It contains the location and the type:

NULL = hit nothing (or fluids)

TILE = hit a block

ENTITY = hit an entity

 

I think the problem is that this .objectMouseOver ignores liquids.  So if you right-click when pointing at a liquid, it falls through to the RIGHT_CLICK_AIR, then keeps going to .sendUseItem which makes its way to your onItemRightClick method as well.

 

You could fix this by putting your onItemRightClick code into the RIGHT_CLICK_AIR handler.

The first statement in this code performs the line-of-sight ray tracing again, but with the "collide with liquids" flag set to true, so it will stop when it hits a liquid rather than keeping on going.

        MovingObjectPosition movingobjectposition = this.getMovingObjectPositionFromPlayer(par2World, par3EntityPlayer, true);

        if (movingobjectposition == null) // didn't hit any blocks or liquid
        {

        }

You also need to handle the case where your line of sight passes through a liquid then hits a block, because in .clickMouse it will get EnumMovingObjectType.TILE.

 

Perhaps the easiest way is to use the RIGHT_CLICK_BLOCK handler the same as your RIGHT_CLICK_AIR, i.e. perform the ray-trace again and verify that the block you hit is a fluid.

 

Disclaimer: I've never tried this myself.  However it looks like it should work.

 

-TGG

 

Link to comment
Share on other sites

Hi

 

The reason this is happening is because of the way the code tells whether you've clicked on a block or not.

 

 

In Minecraft.clickMouse(1) is where it's all happening:

 

            if (this.objectMouseOver == null)
            {
                if (button == 0 && this.playerController.isNotCreative())
                {
                    this.leftClickCounter = 10;
                }
            }
            else if (this.objectMouseOver.typeOfHit == EnumMovingObjectType.ENTITY)
            {
//snip
            }
            else if (this.objectMouseOver.typeOfHit == EnumMovingObjectType.TILE)
            {
                int j = this.objectMouseOver.blockX;
                int k = this.objectMouseOver.blockY;
                int l = this.objectMouseOver.blockZ;
                int i1 = this.objectMouseOver.sideHit;

                if (button == 0)
                {
                    this.playerController.clickBlock(j, k, l, this.objectMouseOver.sideHit);
                }
                else
                {
                    int j1 = itemstack != null ? itemstack.stackSize : 0;

                    boolean result = !ForgeEventFactory.onPlayerInteract(thePlayer, Action.RIGHT_CLICK_BLOCK, j, k, l, i1).isCanceled();
                    if (result && this.playerController.onPlayerRightClick(this.thePlayer, this.theWorld, itemstack, j, k, l, i1, this.objectMouseOver.hitVec))
                    {
                        rightClickNoEffect = false;
                        this.thePlayer.swingItem();
                    }

//snip

               }
            }

            if (rightClickNoEffect && button == 1)
            {
                ItemStack itemstack1 = this.thePlayer.inventory.getCurrentItem();

                boolean result = !ForgeEventFactory.onPlayerInteract(thePlayer, Action.RIGHT_CLICK_AIR, 0, 0, 0, -1).isCanceled();
                if (result && itemstack1 != null && this.playerController.sendUseItem(this.thePlayer, this.theWorld, itemstack1))
                {
                    this.entityRenderer.itemRenderer.resetEquippedProgress2();
                }
            }

 

.objectMouseOver contains the first object that your line of sight intersects within a certain distance (6 blocks from memory).  It contains the location and the type:

NULL = hit nothing (or fluids)

TILE = hit a block

ENTITY = hit an entity

 

I think the problem is that this .objectMouseOver ignores liquids.  So if you right-click when pointing at a liquid, it falls through to the RIGHT_CLICK_AIR, then keeps going to .sendUseItem which makes its way to your onItemRightClick method as well.

 

You could fix this by putting your onItemRightClick code into the RIGHT_CLICK_AIR handler.

The first statement in this code performs the line-of-sight ray tracing again, but with the "collide with liquids" flag set to true, so it will stop when it hits a liquid rather than keeping on going.

        MovingObjectPosition movingobjectposition = this.getMovingObjectPositionFromPlayer(par2World, par3EntityPlayer, true);

        if (movingobjectposition == null) // didn't hit any blocks or liquid
        {

        }

You also need to handle the case where your line of sight passes through a liquid then hits a block, because in .clickMouse it will get EnumMovingObjectType.TILE.

 

Perhaps the easiest way is to use the RIGHT_CLICK_BLOCK handler the same as your RIGHT_CLICK_AIR, i.e. perform the ray-trace again and verify that the block you hit is a fluid.

 

Disclaimer: I've never tried this myself.  However it looks like it should work.

 

-TGG

 

This looks both complex but also very useful. Someone else helped with a different method, so I'll try both, decide which is the best and then get back to both you and the other helper about which i think works best (so you could use the best method, in my opinion, if you ever need to use it).

 

So I've decided to ditch the "fluid" tanks (they had no use in my mod). So when I right click mid air with an empty tank, an air tank should return (just 1). However, another problem has risen. This topic can be locked now but the following link takes you to my next issue. If you wouldn't mind checking it out, I would be very grateful and thank you 1 gigabyte times.

http://www.minecraftforge.net/forum/index.php/topic,13075.msg67737.html

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I am not using hardcoded recipes, I'm using Vanilla's already existing code for leather armor dying. (via extending and implementing DyeableArmorItem / DyeableLeatherItem respectively) I have actually figured out that it's something to do with registering item colors to the ItemColors instance, but I'm trying to figure out where exactly in my mod's code I would be placing a call to the required event handler. Unfortunately the tutorial is criminally undescriptive. The most I've found is that it has to be done during client initialization. I'm currently trying to do the necessary setup via hijacking the item registry since trying to modify the item classes directly (via using SubscribeEvent in the item's constructor didn't work. Class so far: // mrrp mrow - mcmod item painter v1.0 - catzrule ch package catzadvitems.init; import net.minecraft.client.color.item.ItemColors; import net.minecraft.world.item.Item; import net.minecraftforge.registries.ObjectHolder; import net.minecraftforge.fml.event.lifecycle.FMLClientSetupEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.client.event.ColorHandlerEvent; import catzadvitems.item.DyeableWoolArmorItem; @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public class Painter { @ObjectHolder("cai:dyeable_wool_chestplate") public static final Item W_CHEST = null; @ObjectHolder("cai:dyeable_wool_leggings") public static final Item W_LEGS = null; @ObjectHolder("cai:dyeable_wool_boots") public static final Item W_SOCKS = null; public Painter() { // left blank, idk if forge throws a fit if constructors are missing, not taking the chance of it happening. } @SubscribeEvent public static void init(FMLClientSetupEvent event) { new Painter(); } @Mod.EventBusSubscriber private static class ForgeBusEvents { @SubscribeEvent public static void registerItemColors(ColorHandlerEvent.Item event) { ItemColors col = event.getItemColors(); col.register(DyeableUnderArmorItem::getItemDyedColor, W_CHEST, W_LEGS, W_SOCKS); //placeholder for other dye-able items here later.. } } } (for those wondering, i couldn't think of a creative wool helmet name)
    • nvm found out it was because i had create h and not f
    • Maybe there's something happening in the 'leather armor + dye' recipe itself that would be updating the held item texture?
    • @SubscribeEvent public static void onRenderPlayer(RenderPlayerEvent.Pre e) { e.setCanceled(true); model.renderToBuffer(e.getPoseStack(), pBuffer, e.getPackedLight(), 0f, 0f, 0f, 0f, 0f); //ToaPlayerRenderer.render(); } Since getting the render method from a separate class is proving to be bit of a brick wall for me (but seems to be the solution in older versions of minecraft/forge) I've decided to try and pursue using the renderToBuffer method directly from the model itself. I've tried this route before but can't figure out what variables to feed it for the vertexConsumer and still can't seem to figure it out; if this is even a path to pursue.  The vanilla model files do not include any form of render methods, and seem to be fully constructed from their layer definitions? Their renderer files seem to take their layers which are used by the render method in the vanilla MobRenderer class. But for modded entities we @Override this function and don't have to feed the method variables because of that? I assume that the render method in the extended renderer takes the layer definitions from the renderer classes which take those from the model files. Or maybe instead of trying to use a render method I should be calling the super from the renderer like   new ToaPlayerRenderer(context, false); Except I'm not sure what I would provide for context? There's a context method in the vanilla EntityRendererProvider class which doesn't look especially helpful. I've been trying something like <e.getEntity(), model<e.getEntity()>> since that generally seems to be what is provided to the renderers for context, but I don't know if it's THE context I'm looking for? Especially since the method being called doesn't want to take this or variations of this.   In short; I feel like I'm super super close but I have to be missing something obvious? Maybe this insane inane ramble post will provide some insight into this puzzle?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.