Alright, so I know I am screwing something up. I just don't know how or what to do to fix it. The idea is really simple. One class which handles this particular type of my items, and uses metadata to store the different variants of that item. Other classes that handles the effects of using those items. Each item is meant to act like a bow, you can "charge" it. Then, upon onPlayerStoppedUsing whatever that item is supposed to do gets executed. So I have my code, and everything runs and compiles fine. However my items are not "acting" like a bow.

 

Here is the main item class code:

http://pastebin.com/BjyvcakQ

 

What that code does is registers the items for me, gives them their models, etc. etc. As you can see at the top I am storing the class that are to be called in an array and upon using the item it will cycle through the array and is supposed to call the proper class based on the items metadata.

 

So now here is the class for array position 0 or O_card_Fire

http://pastebin.com/Kf9aYHBr

 

I did something very similar to this in 1.7.10 with my Celestial Keys and each key called out to a class that spawned an entity. The concept is the same except it is called out to an itemclass instead of an entityclass.

 

Granted, I know I can probably do this by creating a specific item class for each card and attach it specifically to its respective item class as opposed to using Metadata like I am currently doing, but that isn't what I am going for. If there is no other option and I don't have a choice well I will do it, but my objective here is to better myself with java and 1.9.4 by trying to do things differently. So for anyone that may ask "Why are you doing it this way" it is simply because I am trying to learn and want to better myself.

 

So what am I doing wrong with the new 1.9 style? Is it my main card class? Is it my O_Fire_Card class? Or is it just totally wrong and needs to be completly rewritten? Any help and guidance with some example is greatly appreciated.

 

EDIT: Yes I know that adding the information and what not should probably be done in the main item class since I am really only making those other separate classed for and I plan to change that. I am more concerned with the actual functionality of the item.

Alright, so I know I am screwing something up. I just don't know how or what to do to fix it. The idea is really simple. One class which handles this particular type of my items, and uses metadata to store the different variants of that item. Other classes that handles the effects of using those items. Each item is meant to act like a bow, you can "charge" it. Then, upon onPlayerStoppedUsing whatever that item is supposed to do gets executed. So I have my code, and everything runs and compiles fine. However my items are not "acting" like a bow.

 

Here is the main item class code:

http://pastebin.com/BjyvcakQ

 

What that code does is registers the items for me, gives them their models, etc. etc. As you can see at the top I am storing the class that are to be called in an array and upon using the item it will cycle through the array and is supposed to call the proper class based on the items metadata.

 

So now here is the class for array position 0 or O_card_Fire

http://pastebin.com/Kf9aYHBr

 

I did something very similar to this in 1.7.10 with my Celestial Keys and each key called out to a class that spawned an entity. The concept is the same except it is called out to an itemclass instead of an entityclass.

 

Granted, I know I can probably do this by creating a specific item class for each card and attach it specifically to its respective item class as opposed to using Metadata like I am currently doing, but that isn't what I am going for. If there is no other option and I don't have a choice well I will do it, but my objective here is to better myself with java and 1.9.4 by trying to do things differently. So for anyone that may ask "Why are you doing it this way" it is simply because I am trying to learn and want to better myself.

 

So what am I doing wrong with the new 1.9 style? Is it my main card class? Is it my O_Fire_Card class? Or is it just totally wrong and needs to be completly rewritten? Any help and guidance with some example is greatly appreciated.

 

EDIT: Yes I know that adding the information and what not should probably be done in the main item class since I am really only making those other separate classed for and I plan to change that. I am more concerned with the actual functionality of the item.

Bumping This Please. I fixed up the code a bit:

 

Here is the main card class:

http://pastebin.com/yXAWD09R

 

Here is the specific class I am trying to call out to

http://pastebin.com/g3LLPJTG

 

Ideally I need the onStoppedUsing Item method to be called. Like I said above, I know i can probably do this all in separate item classes registering the cards as separate items but that is not what I am looking to do unless I have no other choice.

Bumping This Please. I fixed up the code a bit:

 

Here is the main card class:

http://pastebin.com/yXAWD09R

 

Here is the specific class I am trying to call out to

http://pastebin.com/g3LLPJTG

 

Ideally I need the onStoppedUsing Item method to be called. Like I said above, I know i can probably do this all in separate item classes registering the cards as separate items but that is not what I am looking to do unless I have no other choice.

eAngelusCards#onItemUse

(called when the item is right clicked on a block) tries to instantiate one of the card

Item

s using a constructor that takes a

World

argument, but

O_card_Fire 

doesn't have this constructor. It also never calls a method on this new instance.

 

eAngelusCards

doesn't override

Item#onPlayerStoppedUsing

, so it does nothing when the player stops using it. It also has several override methods without

@Override

, you should always use this annotation so the compiler ensures that the methods actually override a super method.

 

That said, your design is a mess. You shouldn't be creating

Item

s on the fly or using

Item

s that haven't been registered.

 

What you should do is create a

Card

class with all the necessary methods and then have each card type extend this and override the appropriate methods to implement their functionality. You should then have a single card

Item

that stores an instance of each card type and overrides various

Item

methods to call the corresponding

Card

method.

 

If you wanted to make this system more extendable, you could create a registry for

Card

s using Forge's registry system (

IForgeRegistry

/

IForgeRegistryEntry

) and store the card type in either the NBT (as its registry name) or in a Capability of the

ItemStack

.

 

Edit: Fixed the formatting.

eAngelusCards#onItemUse

(called when the item is right clicked on a block) tries to instantiate one of the card

Item

s using a constructor that takes a

World

argument, but

O_card_Fire 

doesn't have this constructor. It also never calls a method on this new instance.

 

eAngelusCards

doesn't override

Item#onPlayerStoppedUsing

, so it does nothing when the player stops using it. It also has several override methods without

@Override

, you should always use this annotation so the compiler ensures that the methods actually override a super method.

 

That said, your design is a mess. You shouldn't be creating

Item

s on the fly or using

Item

s that haven't been registered.

 

What you should do is create a

Card

class with all the necessary methods and then have each card type extend this and override the appropriate methods to implement their functionality. You should then have a single card

Item

that stores an instance of each card type and overrides various

Item

methods to call the corresponding

Card

method.

 

If you wanted to make this system more extendable, you could create a registry for

Card

s using Forge's registry system (

IForgeRegistry

/

IForgeRegistryEntry

) and store the card type in either the NBT (as its registry name) or in a Capability of the

ItemStack

.

 

Edit: Fixed the formatting.

What he said, plus it looks as if your using reflection to try to implement your own runtime polymorphism. You don't need to do that; Java already does this for you when you use inheritance correctly.

 

Find a Java tutorial online and read about runtime polymorphism.

What he said, plus it looks as if your using reflection to try to implement your own runtime polymorphism. You don't need to do that; Java already does this for you when you use inheritance correctly.

 

Find a Java tutorial online and read about runtime polymorphism.