[SOLVED] Preventing 1st-person item change animation?

[coolAlias]

EDIT: Closed. Thanks Lex!

 

I've tracked this down to ItemRenderer#renderItemInFirstPerson which is the only place that actually uses the equippedProgress and prevEquippedProgress to affect how the item is rendered.

 

I've got an item that I don't want to have this 'animation' - I want it to appear in place just as it does in 3rd person, right when the player switches to it (it's actually to accommodate changing NBT [and no, I can't store it elsewhere in this case]).

 

Has anyone ever come up with a solution for this?

 

If not, how about the following solution:

 

 

It seems with all the other useful Item hooks available, there should be something like 'Item#shouldRefresh(ItemStack, ItemStack)' called from ItemRenderer#updateEquippedItem:

if (!this.itemToRender.getIsItemStackEqual(itemstack))
{
    flag = this.itemToRender.shouldRefresh(this.itemToRender, itemstack);
}

The default Item implementation would of course simply return 'true'. Would that not be useful? I know I'm not the first to encounter this limitation; the usual workaround for NBT at least is to store the data elsewhere, e.g. IEEP, but the above would, in my opinion, be a much simpler solution.

 

Can anyone think of any drawbacks to it? Is there another way already available for those cases in which it is not possible to use IEEP or other storage devices? What about if the item should simply not have any animation, regardless of NBT?

 

EDIT: Actually, it would make more sense to call the method for the second itemstack, since that would be the one that should be current, but it won't become current unless the flag is true... damn. See second solution below.

 

 

EDIT: The following solution is much better than the one in the spoiler above:

Another possible solution would be to have something like Item#getFirstEquippedProgress(ItemStack current, ItemStack previous, float equippedProgress) at this point:

if (this.equippedProgress < 0.1F)
{
  this.equippedProgress = itemstack.getItem().getFirstEquippedProgress(itemstack, this.itemToRender, this.equippedProgress);
  this.itemToRender = itemstack;
  this.equippedItemSlot = entityplayersp.inventory.currentItem;
}

I added in the current equippedProgress so the default Item implementation has an easy return value, and note that returning 1.0F will prevent any unwanted equip animation - heck, it could even just be a boolean return value, really, but the float gives more control.

 

Thanks for reading,

coolAlias

[Himself12794]

I'm curious if this will also remove the bobbing animation that happens when you modify the NBT tags of an item stack that is in use. I had that problem awhile back, but decided the information I needed stored was better tied to the entity instead of the stack. Still, I must test this.

[larsgerrits]

I'm curious if this will also remove the bobbing animation that happens when you modify the NBT tags of an item stack that is in use.

That is the animation and problem he is talking about.

[coolAlias]

There is Item#getShareTag() which could be used to prevent the itemstack NBT from being sent to the client, which would presumably stop the animation change for that particular case, but then you couldn't use the NBT data at all for rendering.

 

So, it seems that currently there is no possible way (i.e. without ASM) to do what I am attempting.

 

In that light, does anyone have any comments on my proposed solution? Can you think of any situations it would not handle well? Is there a better way?

 

I ask because I don't want to go to the trouble of learning how to submit a proper PR to Forge (I tried once before but I had just edited the files directly, which is apparently a big no-no) and putting one together only to have it rejected for something stupid I didn't consider.

[EverythingGames]

Hi

There was a topic on this very same problem a while back (solved), I've even had to switch to IEEP because of this. I have found a close solution - reflection. Setting the equipped progress to 1.0F when setting / changing the NBT of an item. However, checking every tick if the tag is being changed and setting the value to 1.0F causes major rendering problems when trying to switch to another item (It continues to render the same item regardless of what item is actually equipped).

[coolAlias]

@EverythingGames That is exactly the kind of hacky solution that I am trying to avoid with my proposal.

[perromercenary00]

 

long ago i try something like but not soo deep like the yours

 

http://www.minecraftforge.net/forum/index.php/topic,27461.msg140547.html#msg140547

 

an i have ideas but i could not disable the thing i call "switchAnimation"

then i think the trouble is the nbttag system trigering it so if i dont use it it would'n be trouble

then research and learn how to to write data to a json file creating  a custom storing class whith the variables i need to use 

in this storing class i asign a serial number for every gun create whith mi mod to keep values from mixing betwin each other

every five minutes a server ticks class check if the vaules in the storing class has change if its so it writes the values to the json file it is not then it leave it alono for another five minutes

in teory works but then i realize the tragedy.

when you set an item in use it triggers again the swtching animation so you could not avoid the animation

 

what i do, just learn to live whith it making the code store al the nbttags from the shooting at same time to reduce the times the items switchs to only two per shoot

http://www.curse.com/mc-mods/minecraft/228033-mercenarymod

 

 

i not in your level whith  the minecraft code

 

this

equippedProgress thing is an event caugth or where are you doing this

 

 

 

 

 

 

 

[coolAlias]

It's not something I have done, it's something I am proposing we add to Forge so that we can avoid crazy workarounds like the one you implemented.

 

The fact that some modders go to such great lengths to prevent this stupid forced animation is, in my opinion, a strong indicator that my proposal is at least in the right direction, and I think it would solve these issues pretty elegantly with minimal code.

 

Again, if anyone can think of a better way to do it, or has suggestions of how to improve mine, I'm all ears, but something needs to be done.

 

If Lex Manos or anyone else on the Forge team happens to read this, would there be any reasons you can think of that my suggestion would be rejected as a PR?

[EverythingGames]

I myself just don't see why an animation has to play when the item is refreshed / updated. All the fields are private, and yes, reflection is hacky considering all the work-arounds that you must do to try and get it to work. I did but it was not efficient and extremely hacky. Hope that the Forge Devs work this out as it has caused a lot of trouble with my mods causing me to fall back on IEEP and packets.

[coolAlias]

This issue is now closed! Thanks Lex!

[coolAlias]

Actually, there is still an issue with it. The way it has been implemented prevents any changes in NBT from affecting the rendering of the item if you don't allow the re-equip animation to play. This would be resolved using my implementation, but I don't want to keep pestering Lex with issues (I opened one and immediately after saw his commit in the change log... doh).

 

This issue is now closed. Many thanks to Lex for implementing this!