[1.7.2] perworld storage between mods

[delpi]

What I want to do is to create a perworld storage but access it from different mods.

 

Based upon this post and what I looked up in the vanilla classes, I think I know how to do it.

 

http://www.minecraftforge.net/forum/index.php?topic=8520.0

 

What, I'm unsure about is how to access it from the other mods.  The methods involve casting the WorldSavedData it returns into your extended version of it with the actual functionality.

 

This is where I'm stuck.  If I basically have the same exact class in both mods, I don't think it is really the same class, is it?  The casting won't work in both, will it?

 

I had trouble finding the answer to this on a java search, but probably because I couldn't figure out the right way to ask the question.

 

Any advice?

 

[sequituri]

The classes are simply determined by package in any game environment. If you create an API package, make your save class there. import it in any class, and you have your perWorldSave class.

[delpi]

Could you point me at some tutorials/discussions on API's.  I've had a challenge searching for the right way to do this in the past.  The searches always seem to bring up topics on Forge's API.

[Kwibble]

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.

[delpi]

I know this is something most Java experts can talk about backwards and forwards but it escapes me.

 

So, I build an API for accessing the storage and then use it in my mods.  I know how to do all that.

 

What is different from that versus just having the class in each of my mods?

[sequituri]

Duplicate class collision is all. Interfaces work best for APIs.

[Kwibble]

Duplicate class collision is all. Interfaces work best for APIs.

 

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.

[delpi]

Thanks guys. I get it now.

 

I did this in Eclipse.  Each of my mods are their own project, so for two of the mods, i included this 'API' mod in the buildpath.  Programming wise it looks fine and something like this worked back when i did bukkit.

 

However, for forge it isn't working when i try to run the server in dev mode.  Its not including the separate mod from the build path.  Looking at it (assuming i'm not still missing the point), it looks that I need to tell gradle to include it, but i'm struggling with the right syntax.  I posted something in the gradle help section.

[delpi]

After thinking about this, I'm probably messing up that last statement.

 

I probably have to tell eclipse to use in in the run scenario.  However, how do I make sure gradle includes it?  do i have to pack it as a jar and put it in the libs folders before running gradle each time?

[delpi]

Well scratch that, putting it in the libs folder does nothing.  Will have to describe to Gradle to include it.  I see how to do that with external jars, but would rather know how to tell it to just include the project straight from the eclipse setup.

[Kwibble]

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

 

That always helps

[jabelar]

Back to your original problem (saving data to be shared across mods).  While I think the idea of an API mod as the intermediary is an interesting way to do that, it is slightly problematic in that it kinda complicates the installation (in addition to the complicating the implementation of each of your mods).  For example even if you just want to run one of the mods, you'll have to have this API mod as well.

 

No big deal I guess, but I think an alternative is just to share a configuration file between them.  Or actually any file between them.  We're working in Java after all, so you have access to regular file methods.  And the Configuration class in Forge allows you to use file locations other than the default.

 

Anyway, when I think of storing data my first instinct is a file, not a whole 'nother mod.

[Kwibble]

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.

[delpi]

It's funny that you mention just saving it to a file.  It's what I've been doing for my mods for some time now.  Works fine. 

 

I was interested in trying to do it inside minecraft to be simpler, but I think I achieved the opposite.

 

Now I'm really just exploring options and learning. 

 

I think links in eclipse will be the trick for shared code.  I think it will be the same as a common library.  Will try later today and post some stuff if it works.

 

Still can't get my mind 100% around how to make an API in the forge/grade/minecraft environment

[delpi]

For anyone interested, it works.

 

In Eclipse, set your project up as recommended for multiple projects.  Basically each mod is a new project.

 

Put all of your common code in one.  In the other mods, right click on their project, choose build path, configure build path.  Under the projects tab, add this common code project.  You can then use its methods in your mods. 

 

The problem will now be that gradle won't compile it.  To fix this, go to your build.gradle file for that project and add something like this to the bottom after the 'minecraft.version' line:

 

 

 

 

dependencies {

        compile files (

                "../CD_Utilities/java"

        )

}

 

 

 

 

Basically, you are telling it to go up a folder, down into your specified project and file path.

 

Works like a charm.