Kwibble

^^^ See? I said you didn't need id's... I apologize for not explaining fully though.

Your using item id's... Why? I don't mean to be rude, but have you read any tutorials on fire modding? Sure doesn't look like it.

Spoiler tags...

What's still not working? Also, use onItemUse, not onItemRightClick.

Are you still getting a null pointer? What is your ItemKirinBuff line 19?

Interesting idea to say the least I am now wondering if its possible to have two different projects, and have the exact same file in the exact same package etc. And be able to reference either of them as one.

Would you be able to show us what you have done and all the problems associated with it? (screenshots will work). That always helps

What he said. And like I was saying, having that one interface will then fix all your casting issues that would occur from multiple 'identical' classes.

An API is just code that grants access to the actual functionality (my definition). I believe, most API's provide interfaces to access their code. you could essentially make a separate "mod" that is just an interface for your world storage. Then in every mod you want access that same storage, you create a class that implements your interface. That will then allow for casting. You may or may not want to put actual implementation in the "mod" as well. It depends I guess.

@The_SlayerMC No, I don't have any code yet. @TGG Hmm, thanks! [EDIT] Oh yeah... I should probably add that it's a tileentity? I already have the rendering of the tileentity block wise sorted, its the inventory that's the problem... I guess I could do a simple hack involving an item that acts like a block in terms of onItemUse and placing the block... Hmm...

Now I know there will have been multiple of these, I just can't seem to find them Am I going to need an IItemRenderer or something to that effect?

I'm sorry, but... * facepalms * GO ACTUALLY LOOK UP WHAT A STATIC VARIABLE IS IN GOOGLE!!!! >.>

Yeah. I don't mean to point and yell at people. But that is still the moral of the story... Name things appropriately. I, for one, use the decomp workspace too.

Moral of the story: Always name things appropriately... And make sure it is actually useful.

That would make a lot of sense actually. Seeing as every item is actually a copy of an original, and I believe the creative inventory contains those originals (don't quote me on that). So when you click to grab the item, it just copies it... But that doesn't explain the crafting... which is the same... Hmm...

Yes, it is quite annoying. But then again... At any rate, it could be implemented a bit better, that is for sure.

Question 1: I believe that when you use the @ForgeSubscribe annotation (if that is still in use), there is a parameter that you can add that is an enum involving priority. The higher the priority set on your event, the quicker it will be called when the event occurs. So if your mod has a higher priority than another mod, and you cancel the event, it *should* cancel it for the other mod as well seeing it is further down the chain. Question 2: Good question... I am not too sure on that one.

Have you tried item.greenPickaxe.name=Green Pickaxe (without the space before the equals).

Yes, that is another possibility. And yes, that does seem easier. Give it a try and tell me what happens

Interesting this popped up actually. It will come in handy for my current project. Thank you for this.

Didn't you say the entity wasn't being saved in the world if it was riding the player anyway? If that's the case, problem solved

You do realize that you are setting it to null to start with... Right?

Sort of. If the entity is riding the player - save via extended properties. If the entity is in the world - save it in the world. Does that make sense? Don't stop researching because you have this way to do it. There is most definitely a better way.

That seems to be the question doesn't it. Not being near my testing environment, I can't try much. But it seems you may have to store all the entities data that you need into the extended properties and then when the player constructs, add a new entity with all the stored data... Probably an easier way, but try that to start with?

So yes, you do want to have an IExtendedEntityProperties. In this, have a variable equal to the entity that is riding the player. That way, when the player is initialized you can add the entity back on again. I think. So.ething along those lines anyway... 'tis an interesting problem