[1.10.2] How to change ItemStack item?

[yooksi]

Until now I've been using ItemStack#setItem to get this job done, but now that it's been recently deprecated, I don't know what to use. What is the best way of accomplishing this task in 1.10.2?

[Draco18s]

That depends.  Where are you wanting to do this and why?

[yooksi]

That depends.  Where are you wanting to do this and why?

I would like to change the item of an ItemStack passed as an argument in the ItemBlock#onUpdate method with another custom item instance. Why? Because I want to replace an item the player is holding in his main hand.

[Draco18s]

You can just replace the itemstack in the player's inventory.

[tripl3dogdare]

That would indeed probably be the simplest way, although if you have any custom NBT attached to it you'll need to copy it over.

[yooksi]

You can just replace the itemstack in the player's inventory.

 

That would indeed probably be the simplest way, although if you have any custom NBT attached to it you'll need to copy it over.

 

That's exactly what I wanted to avoid, but guess in the end it's really no biggie. If that's the proper way of doing it, then that's the way I'll do it. Thanks for the info you two.

[yooksi]

Okay, two more additional problem:

 

First: after checking the code, I see I don't actually have direct access to a EntityPlayer instance in the method that is handling the ItemStack in question, although I can remedy this by adding an additional argument to the method.

 

Second: I don't know of an elegant way of finding the ItemStack instance in player's inventory. How would I go about solving the second problem in a most elegant fashion permissible by the newest version of Forge?

[Draco18s]

If you're replacing an item in the hotbar (the currently active item) you should be able to figure out which slot is currently active.

Even if not you can loop over the hotbar and compare item stack instances directly (one will return true for

stack == otherStack

)

[yooksi]

If you're replacing an item in the hotbar (the currently active item) you should be able to figure out which slot is currently active.

Even if not you can loop over the hotbar and compare item stack instances directly (one will return true for

stack == otherStack

)

 

Yes I know, and I can do pretty much the same for HeldEquippment, but is there a specialized method for doing that? Something like InventoryPlayer#hasItemStack which tries to see if an ItemStack instance exits in player's inventory, except returning a boolean it would return an inventory slot position.

[Animefan8888]

If you're replacing an item in the hotbar (the currently active item) you should be able to figure out which slot is currently active.

Even if not you can loop over the hotbar and compare item stack instances directly (one will return true for

stack == otherStack

)

 

Yes I know, and I can do pretty much the same for HeldEquippment, but is there a specialized method for doing that? Something like InventoryPlayer#hasItemStack which tries to see if an ItemStack instance exits in player's inventory, except returning a boolean it would return an inventory slot position.

No you will have to create that method yourself.

[yooksi]

Yes I know, and I can do pretty much the same for HeldEquippment, but is there a specialized method for doing that? Something like InventoryPlayer#hasItemStack which tries to see if an ItemStack instance exits in player's inventory, except returning a boolean it would return an inventory slot position.

No you will have to create that method yourself.

 

Alright, good to know. Thanks.

[Choonster]

The

onUpdate

method has a parameter for the slot in the player's inventory. No need to search anything.

 

The difficulty is that

Item#onUpdate

will be called for items in any of the player's three inventory sections (main, armour and off hand), so you need to check which section it's in before trying to interact with that section.

 

You can do this by checking if the

ItemStack

in the provided slot of the inventory section is the same as the provided

ItemStack

.

 

I do this here. This doesn't handle the item being in the player's off hand.

[Draco18s]

Wow... that is a horrible design on Mojang's part.

 

Hash-tag: no one is surprised.

[Choonster]

This thread inspired me to fix the item I linked earlier to properly handle the off hand. You can see the new implementation here and here.

 

I now use the latter method for all inventory handling in my

Item#onUpdate

implementations.

[yooksi]

The

onUpdate

method has a parameter for the slot in the player's inventory. No need to search anything.

 

The difficulty is that

Item#onUpdate

will be called for items in any of the player's three inventory sections (main, armour and off hand), so you need to check which section it's in before trying to interact with that section.

 

You can do this by checking if the

ItemStack

in the provided slot of the inventory section is the same as the provided

ItemStack

.

 

I do this here. This doesn't handle the item being in the player's off hand.

 

I see you use IItemHandler to interact with player inventory. What are the advantages of manipulating the inventory that way over using PlayerInventory?

[Choonster]

The

onUpdate

method has a parameter for the slot in the player's inventory. No need to search anything.

 

The difficulty is that

Item#onUpdate

will be called for items in any of the player's three inventory sections (main, armour and off hand), so you need to check which section it's in before trying to interact with that section.

 

You can do this by checking if the

ItemStack

in the provided slot of the inventory section is the same as the provided

ItemStack

.

 

I do this here. This doesn't handle the item being in the player's off hand.

 

I see you use IItemHandler to interact with player inventory. What are the advantages of manipulating the inventory that way over using PlayerInventory?

 

It allows you to simulate inventory changes and treat it the same as any other inventory, e.g. use it in a wrapper like

CombinedInvWrapper

or

RangedWrapper

.

[yooksi]

 

It allows you to simulate inventory changes and treat it the same as any other inventory, e.g. use it in a wrapper like

CombinedInvWrapper

or

RangedWrapper

.

 

I don't know what

CombinedInvWrapper

and

RangedWrapper

are, can you give me a simpler explanation? I am not a really experienced modder.

[Choonster]

It allows you to simulate inventory changes and treat it the same as any other inventory, e.g. use it in a wrapper like

CombinedInvWrapper

or

RangedWrapper

.

 

I don't know what

CombinedInvWrapper

and

RangedWrapper

are, can you give me a simpler explanation? I am not a really experienced modder.

 

CombinedInvWrapper

combines multiple

IItemHandler

inventories into one.

RangedWrapper

exposes a range of slots from an

IItemHandler

inventory.

[yooksi]

This is how my method code looks after I've tried to work around ItemStack#setItem: NewItemTorch.java.

 

Notice that I am forced to call ItemStack#areItemStacksEqual quite often, and from what I've seen in the code belonging to the methods called, this might get really expensive after continued use. Especially since I have to scan the whole player inventory, and if the player is carrying a lot of items... you see my point.

 

I am very sensitive about code optimization and even though I try not to fall into the pit of premature optimization, I'm still often worried about my code performance. Do you think I am overreacting in this case?

[yooksi]

It allows you to simulate inventory changes and treat it the same as any other inventory, e.g. use it in a wrapper like

CombinedInvWrapper

or

RangedWrapper

.

 

I don't know what

CombinedInvWrapper

and

RangedWrapper

are, can you give me a simpler explanation? I am not a really experienced modder.

 

CombinedInvWrapper

combines multiple

IItemHandler

inventories into one.

RangedWrapper

exposes a range of slots from an

IItemHandler

inventory.

 

Aha, so for example, it merges all player inventories into one?

[Choonster]

This is how my method code looks after I've tried to work around ItemStack#setItem: NewItemTorch.java.

 

Notice that I am forced to call ItemStack#areItemStacksEqual quite often, and from what I've seen in the code belonging to the methods called, this might get really expensive after continued use. Especially since I have to scan the whole player inventory, and if the player is carrying a lot of items... you see my point.

 

I am very sensitive about code optimization and even though I try not to fall into the pit of premature optimization, I'm still often worried about my code performance. Do you think I am overreacting in this case?

 

You don't need to know whether the stacks are equal to each other (i.e. same

Item

, metadata, NBT and capabilities), you need to know whether they're the same object (i.e. use

==

).

 

You already know which slot the item is in, so you shouldn't need to scan every inventory slot; just check that slot of each section.

 

Aha, so for example, it merges all player inventories into one?

You can do that (and

PlayerInvWrapper

does), but I'm not using that myself because I need to access each section separately.

[yooksi]

 

You don't need to know whether the stacks are equal to each other (i.e. same

Item

, metadata, NBT and capabilities), you need to know whether they're the same object (i.e. use

==

).

 

 

You're right, that's a better idea, I was overthinking it.

 

 

You already know which slot the item is in, so you shouldn't need to scan every inventory slot; just check that slot of each section.

 

 

I don't know this in every situation, the itemSlot method argument will sometimes be passed as -1.

[Choonster]

You already know which slot the item is in, so you shouldn't need to scan every inventory slot; just check that slot of each section.

 

I don't know this in every situation, the itemSlot method argument will sometimes be passed as -1.

 

Vanilla never calls

Item#onUpdate

with a negative slot number. Is the method being called from another mod?

[yooksi]

Vanilla never calls

Item#onUpdate

with a negative slot number. Is the method being called from another mod?

 

It's called by other methods beside

Item#onUpdate

. I still believe we should have a method that edits the item of an ItemStack, all this effort seems like hacking to me. We also have to allocate new objects all the time when all we want to do is replace the Item and leave other ItemStack properties the same.

[trollworkout]

I found out that deprecated does not mean do not use. Deprecated rather means more like "i'd rather you not use it but if you have to go then go ahead."

 

In my code I have a block which has multi textures and FACING so orientation matters. One of the functions there      getStateFromMeta(int meta) is marked as deprecated.

 

@Deprecated

    public IBlockState getStateFromMeta(int meta)

    {

        return this.getDefaultState();

    }

 

Now if you don't use this function the block resets position every time you reload the game so in this case is deprecated but YOU HAVE TO USE IT. So what do I do? I use it. There's no other way

 

Point is if it says deprecated is because original MC team are trying to move away from this function so expect it to go away in the future but doesn't mean you can't use it now.