[1.9.4] dissabled the swicth animation from mi items or at leats workaroundit

[perromercenary00]

well

i know i eventually hit again this same stone, coz i have trouble whith it in 1.7, 1.8 and now 1.9

its what i call switch animation is the little animation tha hapens when you change the item you are holding in your hands in the game so the item moves down and then up,

the trouble is that also happen when you writte or change an nbt tag to the item

 

a more graphical description of the trouble

 

in this case i have two of mi guns,

and i program them to:

on right click shoot the mainhand gun,

on left click it shots the off hand gun,

 

in this video i shoot first ten times whith only the rightclick|mainhand, and latter i shoot eleven times whith only leftclick|offhand

 

To animate the shoot in the main i manage to writte nbt only in the end part of the process so this one is tolerable

but to shoot the offhand gun i must first write five nbt tags to the items tos causing the annoying switch animation ruining the graphical feeling of the dual handing guns experience

 

for why not i just use

  @Override 
  public boolean shouldCauseReequipAnimation(ItemStack oldStack, ItemStack newStack, boolean slotChanged) 
  {
  int oldStackSN = util.getInttag(oldStack, "numerodeserie"); 
  int newStackSN = util.getInttag(newStack, "numerodeserie");
  
  if (oldStackSN == newStackSN) 
  { 
	  return false; 
  }
  
  return true; 
  }

this disabled completely the switch animation but also disable completely the animation from mi guns so it becomes worst at thi end

 

########

soo i need a way to disable that annoying motion of the item going down and up again every time i writte or update an nbt value

 

i was thinking if its posible to write values to the item as properties and later use them to control the animations and actions

some idea hot to fix this??

 

thank for reading

 

 

 

[/code]

[Guest]

I would suggest you to use a capability interface to handle the gun behaviour. That way the NBT data is only saved when the world is saved.

[Ernio]

I would suggest you to use a capability interface to handle the gun behaviour. That way the NBT data is only saved when the world is saved.

 

This is actually only correct approach (any other is shameful display).

 

http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/

 

https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java

[perromercenary00]

good days

today i take tiime for this to solve

 

but is a little complicated im trying to ensamble the parts but things i dont get like

where is stored the data ? i think is stored on the players nbt but not soo sure

 

and how i make the client to get the data ?

 

how i implement this to store mi kind of data in the itemstack?

 

this is the nbt tags i use to make the guns works

// ############################################################################################3
@Override
public void inicializar(ItemStack stack) {

	util.setBooleantag(stack, "inicializado", true);
	util.setBooleantag(stack, "ejecutar", false);

	int meta = stack.getMetadata();
	int mm = 16;

	switch (meta) {
	default:
		;
		break;
	case 2:
		mm = 32;
		break;
	case 3:
		mm = 64;
		break;
	}

	util.setBytetag(stack, "tipo", this.tipo);
	util.setInttag(stack, "serial", util.getSerialAlHazar());

	util.setBytetag(stack, "tipodisparo", 1);
	util.setBytetag(stack, "tipodisparomax", 1);

	util.setBytetag(stack, "cargadorr", meta);

	util.setBytetag(stack, "municion", 0);
	util.setBytetag(stack, "tipomunicion", 1);
	util.setBytetag(stack, "tipomunicionmax", 3);
	util.setBytetag(stack, "municionmax", mm);
	util.setInttag(stack, "municiondisp", 0);

	util.setBytetag(stack, "municionb", 0);
	util.setBytetag(stack, "tipomunicionb", 1);
	util.setBytetag(stack, "tipomunicionmaxb", 3);
	util.setBytetag(stack, "municionmaxb", mm);
	util.setInttag(stack, "municiondispb", 0);

	util.setFloattag(stack, "tj", -1.0F);
	util.setBytetag(stack, "accion", 0);
	util.setInttag(stack, "ticksmax", 0);
	util.setInttag(stack, "tiempo", 0);

	util.setLongtag(stack, "currenttime", 0); // llevar las animaciones en
												// el mundo local
	util.setLongtag(stack, "currenttimed", 0); // dexbloquear si se atasca
												// en el servidor

}

// ############################################################################################3

 

 

now come to mi mind the word datawacher but now well i tink i could'n use the entityplayers datawacher as in 1.8

 

 

thanks for reading

 

[Ernio]

Just like @Capability assigned to e.g Entity (which works kinda like old IEEP), a capability assigned to ItemStack will simply be a sided object (instance of your capability interface) assigned to it.

 

Whenever ItemStack is created (object instance), it will call attach caps event. You can use that to attach capability to stack which will then receive load NBT (once) - you can load capability from ItemStack's NBT, and then will be saved into itemStack's NBT whenever there is a need - so, e.g when game saves (on server obviously).

 

Now the syncing is kinda tricky. NBT of ItemStack are auto-synced (unless you fuck up internals). Capabilities of ItemStack on the other hand are NOT.

 

As fun as it is - whenever ItemStack goes to client it is always being recreated from current NBT, so basically - example:

1. Server loads ItemStack with NBT with integer "count" = 10.

2. You assign capability which will hold int count.

3. Your capability assigns count = nbt.get("count");

4. Server sends -> Client receives stack packet.

5. Client creates ItemStack instance following same process as in 1->2->3.

 

Now let's that on server say you change capability's count (field) to 20.

Client will not have that change

Server:

NBT count = 10

count = 20

Client:

NBT count = 10

count = 10

 

Server's stack's NBT will change when capability will be serialized back (savetoNBT).

 

Seriosuly - it is really fun to play with and FINALLY allows to NOT send all data about stack to clients. You can hold data server only.

 

P.S:

 

You util class is kinda bad. You should be getting stack's NBT once - then opeare on it, not re-get it every call.

 

And yeah - with capabilities and right design you can have literally NONE nbt-calls shit. (I mean you will have them once to load/save).

[perromercenary00]

well

i spend the last two days reading random things and think i'm grasping the concept but not yet the process to get it working

 

is the syncing between server side and local side waths botther me, i set the animations serverside and this get execute client side, when i wass playing whith packages in 1.8 the average package takes about tree ticks to reach client side and could take up to fithteen, mi single shoot animation takes tree ticks to execute this could cause a visible unsync between the shoot and the the actual animation of the shoot, trouble is not so big whith actual nbt system

 

// ############################################################################################3
public pistolaMercenaria(String name, int tipo) {
	super(name, tipo);

	// TexturaJason
	this.addPropertyOverride(new ResourceLocation("tj"), new IItemPropertyGetter() {
		@SideOnly(Side.CLIENT)
		public float apply(ItemStack stack, World worldIn, EntityLivingBase entityIn) {

			return getTJ(stack, worldIn, entityIn);

		}
	});

}// fin de contructor
	// ############################################################################################3

@SideOnly(Side.CLIENT)
public float getTJ(ItemStack stack, World worldIn, EntityLivingBase entity) {

	// tipodeCargador estadoR { 0 estatico, 1 disparo , xxx rutina de sacar
	// o meter cargador, estadoL { 0 estatico, 1 disparo , xxx rutina de
	// sacar o meter cargador }

	// accion
	// 0 estatica
	// 1 disparo
	// 2 unload
	// 3 reload
	// 4 unload reload
	// util.setBytetag(stack , "cargadorr" , meta);

	boolean ejecutar = util.getBooleantag(stack, "ejecutar");

	if ((!ejecutar) && (entity != null) && (entity.isHandActive()) && (entity.getActiveItemStack() == stack)) {

		byte accion = util.getBytetag(stack, "accion");

		int count = entity.getItemInUseCount();

		int conteo = 10000 - count; // actuall ticks

		if ((conteo > 3) && (accion < 2)) {

//cos the single shoot is done on tick 4
//on ticks 4 and 5 display the json whith texture of the gun shooting 
//on tick 6 go back to base json whith texture of static gun 
			if (conteo == 4 || conteo == 5) {
				byte tipodisparo = util.getBytetag(stack, "tipodisparo");
				if (tipodisparo < 4) {
					byte municion = util.getBytetag(stack, "municion");
					if (municion > 0) {
						return (stack.getMetadata() * 100) + 10.0F;
					}

				}
			}

and thats its way i thing capabilities wont'n gonna work for mi case

 

whith the vainilla NBT tag system works pretty well the trouble is that Anoying ReequipAnimation in the client side i could'n get ride of

 

################################################

 

yerterday nigth i sit to read old post's

 

soo i find the relationship betwin ItemRenderer.class and the troublesome  item#shouldCauseReequipAnimation(); method

 

in this expecific post

http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/modification-development/2350120-can-i-disable-the-animation-of-item-at-right-click

 

this lapizSea manage to change the behaveour of the itemRender class using some kind of ASM whichery,  asm is still out of mi reach and this one is for an old minecrafts version.

 

well either way doing this or the capabilities

is like the gift

################################################

 

 

this morning test i decide to go back to original aproach

i discover than if i do

 

// ############################################################################################3	
@Override
public boolean shouldCauseReequipAnimation(ItemStack oldStack, ItemStack newStack, boolean slotChanged) {
	long tiempo =( System.currentTimeMillis() % 2000 );// = every two seconds
System.out.println("tiempo="+tiempo);		

	if ( tiempo > 1000 && tiempo < 1100)
	{
		return true;
	}
return false;
}
// ############################################################################################3

 

this method is executed like 19 times per second or i must say every tick 

and its causes reequip once every two seconds

 

on what i understand after reading the net.minecraft.client.renderer.ItemRenderer.class  exactly 

if i just set this thing to retun allways false the ReequipAnimation should never happend but this is not the case

the item just gets stuck there  and never really change the old for the itemstack

 

 

// ############################################################################################3	
@Override
public boolean shouldCauseReequipAnimation(ItemStack oldStack, ItemStack newStack, boolean slotChanged) {
return false;
}
// ############################################################################################3

 

soo i think this is a bug and to workarrounded i dont have other option but learn wtf is reflecction and how to use to set the values from

net.minecraft.client.renderer.ItemRenderer.class

exactly this values from here

    private float equippedProgressMainHand;

    private float prevEquippedProgressMainHand;

    private float equippedProgressOffHand;

    private float prevEquippedProgressOffHand;