Is there a good way to go apon doing this? I was at first using damage value of the item, but this just seems very inefficient. And is there a alternative to animationapi for 1.9 at least, or maybe an example somewhere of animating a player to do a custom animation.

http://pastebin.com/VfS8v9Ta

Is there a good way to go apon doing this? I was at first using damage value of the item, but this just seems very inefficient. And is there a alternative to animationapi for 1.9 at least, or maybe an example somewhere of animating a player to do a custom animation.

http://pastebin.com/VfS8v9Ta

In both cases below you can use: http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

 

If cd should be per-entity (player):

Assign integer to player, use it to define if player has cd on item. Note: You must take care of syncing if you want client to see value in ANY way.

 

If cd should be per-itemstack - use either item's:

1. Only NBT (basically save cd in NBT, nothing else)

2. NBT + Capability

- assign caps to ItemStack - once ItemStack is loaded (read NBT) it will create data-object which can hold integer cooldown. Then if item would be unloaded - that object can be serialized back to NBT.

Second option is as efficient as it gets in per-item cases.

Only difference between 1 and 2 is that you don't have to read NBT per-tick (which is kinda bad if you want to read A LOT of data, if you only read integer, it is not that bad).

 

Note: ItemStack's NBT is auto-synced (you don't need syncing like in per-entity basis).

In both cases below you can use: http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

 

If cd should be per-entity (player):

Assign integer to player, use it to define if player has cd on item. Note: You must take care of syncing if you want client to see value in ANY way.

 

If cd should be per-itemstack - use either item's:

1. Only NBT (basically save cd in NBT, nothing else)

2. NBT + Capability

- assign caps to ItemStack - once ItemStack is loaded (read NBT) it will create data-object which can hold integer cooldown. Then if item would be unloaded - that object can be serialized back to NBT.

Second option is as efficient as it gets in per-item cases.

Only difference between 1 and 2 is that you don't have to read NBT per-tick (which is kinda bad if you want to read A LOT of data, if you only read integer, it is not that bad).

 

Note: ItemStack's NBT is auto-synced (you don't need syncing like in per-entity basis).

In both cases below you can use: http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

 

If cd should be per-entity (player):

Assign integer to player, use it to define if player has cd on item. Note: You must take care of syncing if you want client to see value in ANY way.

 

If cd should be per-itemstack - use either item's:

1. Only NBT (basically save cd in NBT, nothing else)

2. NBT + Capability

- assign caps to ItemStack - once ItemStack is loaded (read NBT) it will create data-object which can hold integer cooldown. Then if item would be unloaded - that object can be serialized back to NBT.

Second option is as efficient as it gets in per-item cases.

Only difference between 1 and 2 is that you don't have to read NBT per-tick (which is kinda bad if you want to read A LOT of data, if you only read integer, it is not that bad).

 

Note: ItemStack's NBT is auto-synced (you don't need syncing like in per-entity basis).

I was thinking of making a something where i could just put in the item class, because i'm planning on making tons of items with cast times etc.

this.setCasttime(int cast time, something to execute,bool interruptable); Would the best way to do this would be with capabilities ?

In both cases below you can use: http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

 

If cd should be per-entity (player):

Assign integer to player, use it to define if player has cd on item. Note: You must take care of syncing if you want client to see value in ANY way.

 

If cd should be per-itemstack - use either item's:

1. Only NBT (basically save cd in NBT, nothing else)

2. NBT + Capability

- assign caps to ItemStack - once ItemStack is loaded (read NBT) it will create data-object which can hold integer cooldown. Then if item would be unloaded - that object can be serialized back to NBT.

Second option is as efficient as it gets in per-item cases.

Only difference between 1 and 2 is that you don't have to read NBT per-tick (which is kinda bad if you want to read A LOT of data, if you only read integer, it is not that bad).

 

Note: ItemStack's NBT is auto-synced (you don't need syncing like in per-entity basis).

I was thinking of making a something where i could just put in the item class, because i'm planning on making tons of items with cast times etc.

this.setCasttime(int cast time, something to execute,bool interruptable); Would the best way to do this would be with capabilities ?

1. Item != ItemStack

- Item is a SINGLETON describing what you are holding.

- ItemStack is the thing that you are actually holding (it knows what Item it is, how many, and other data such as NBT).

- Logically - you can't hold ANY data in Item, Only static or fields shared between all Items.

- If you want item with data - you hold it in ItemStack's NBT.

 

2. Data held in NBT can be read directly (but like I mentioned - if you would use it per-tick and there is a lot to read, it is not very efficient).

The other option is to read data once, deserialize it into @Capability and then operate on normal-java fields. Then when itemStack is saved back - you can serialize @Capability back to ItemStack's NBT.

 

3. If you would go after design you mentioned, you would need such (or similar) method:

public boolean cast(EntityPlayer caster, ItemStack itemStack, Skill skillToCast);

Now - to use a skill you would do: MyItemSingleton#cast(player, player#heldItemStack, letsSayFireball extending Skill).

Skill would be a class having some methods such as execute(Entity, ItemStack), getCooldown(), isInterruptable().

 

What cast(...) would then do is grab @Capability of ItemStack assigned to passed ItemStack and set "currentlyCast" field to passed Skill, which would be only possible if it was null or currentlyCast.getCooldown() would be 0 or currentlyCast.isInterruptable() would be true (in which case you replace old cast).

 

Now - since @Capability is serialized to ItemStack NBT - you would also need toNBT and fromNBT in your Skill class.

 

This is not how I'd do it (since I have a LOT more extended casting on my own), but its a example.

 

Hope it helped.

1. Item != ItemStack

- Item is a SINGLETON describing what you are holding.

- ItemStack is the thing that you are actually holding (it knows what Item it is, how many, and other data such as NBT).

- Logically - you can't hold ANY data in Item, Only static or fields shared between all Items.

- If you want item with data - you hold it in ItemStack's NBT.

 

2. Data held in NBT can be read directly (but like I mentioned - if you would use it per-tick and there is a lot to read, it is not very efficient).

The other option is to read data once, deserialize it into @Capability and then operate on normal-java fields. Then when itemStack is saved back - you can serialize @Capability back to ItemStack's NBT.

 

3. If you would go after design you mentioned, you would need such (or similar) method:

public boolean cast(EntityPlayer caster, ItemStack itemStack, Skill skillToCast);

Now - to use a skill you would do: MyItemSingleton#cast(player, player#heldItemStack, letsSayFireball extending Skill).

Skill would be a class having some methods such as execute(Entity, ItemStack), getCooldown(), isInterruptable().

 

What cast(...) would then do is grab @Capability of ItemStack assigned to passed ItemStack and set "currentlyCast" field to passed Skill, which would be only possible if it was null or currentlyCast.getCooldown() would be 0 or currentlyCast.isInterruptable() would be true (in which case you replace old cast).

 

Now - since @Capability is serialized to ItemStack NBT - you would also need toNBT and fromNBT in your Skill class.

 

This is not how I'd do it (since I have a LOT more extended casting on my own), but its a example.

 

Hope it helped.

Yeah that helped thanks!

Yeah that helped thanks!