I've got InterModComms set up with my mod for other mods to add recipes (for a machine) to my mod. But the only stuff it looks like you can send between mods is Strings, NBT, and Itemstacks. Is there a way to send an Object value? the value field in a message is an Object but that is private and isn't accessible. How would I do this?

 

What I have set up now is a mod sends three separate messages, (Itemstack, String, String), and I put that into a new instance of a class called an entry, but if a mod could send it in an Object array maybe that would be less redundant and more efficient, if that's possible.

the only stuff it looks like you can send between mods is Strings, NBT, and Itemstacks.

The author himself is stating that those are only things you can send.

 

An object is nothing else but a 'wrapper' for other values and references. So no, you can't "send" Object. You need to encode (split into parts) it and decode it (put toghether from parts).

 

There are ways to do it, but that will not be anythig close to efficient and will not have anything to do with InterModComms.

 

Personal opinion:

Don't use InterModComms, you may aswell setup optional dependency or make API (idk what exacly you are planning).

There is no point in encoding and decoding data when you are in the same JVM process.

 

Btw. - if you are just sending this (what you told), you are probably doing it once - during recipe registration? If something is NOT used very extensively (per tick, per entity, etc) then you don't optimize it, no point.

 

Disclaimer - I don't use IMC, so above is not opinion of professional IMC user, but a modder.

Wait, did you say an optional dependency? Like if a mod is installed, make it a dependency, if it isn't don't? Is that what that means?

Yeah, why not?

You can (anyone can) check if some mod is running and add stuff accordingly.

 

Do tell - what exacly are you doing? Are you:

- making it possible for other people to add recipes to your mod?

- making dependency that if some other mod is running, then add some recipes that will use other mod's e.g items?

- making dependency that if other mod is running, then your mod will add recipes to other mod's "machine"?

Well, I'm making a machine (sort of) where you put an item in and it breaks up into essentia (elemental magic, essentially) and the resulting "essentia" is stored elsewhere in another tile entity. The recipes, what type of essentia is made from an item and how much, are stored in a HashMap as EssentiaEntry instances. Each key in the hashmap is a modid of a mod, so other mods can add recipes for their own items (I have a helper class for this, btw). The problem I'm having is the communication required for another mod to say, "Hey add this item, k?". I need to provide a means for another mod to access my helper class for adding entries. If this is confusing, I can explain it better.

Could I perhaps have an api that the user drops into their source folder and use reflefection in the api to call methods in my mod? Or would that work?

You can use an api for that indeed. I would recommend placing the (static)Hasmap inside the api along with the helper classes. this way a registery of items/recipdles will stay inside the api(wich doesnt require complicated intermod communication). But it can still be accessed through the same api, by every mod which has implemented the api(like your mod of course!)

You can use an api for that indeed. I would recommend placing the (static)Hasmap inside the api along with the helper classes. this way a registery of items/recipdles will stay inside the api(wich doesnt require complicated intermod communication). But it can still be accessed through the same api, by every mod which has implemented the api(like your mod of course!)

Won't it have to sync some how? If someone drops my api in their source folder and adds a recipe my mod won't be able to access it because it will be as if it's their code right? My mod will only be able to access the api in my directory. It doesn't make sense to me.

Nope, if you would try it out, youll see that in call hiearchy that all static methods(and fields) are linked together. that way its automatically synced. (Usually thats the purpose of an api, to save the time of syncing etc.)

I don't think you (OP) know what an API is and how it should be made.

 

Best way would be: Make your mod's API and build your mod onto it (well, that's basically what you should do).

Place all data-holders inside API's classes, make everything private, create getters and setters ("adders").

 

Export your API as ready to use (one for developers (not obf), one for use - obfuscated).

Import .jar of dev API into your libs.

 

Inside your mod you can now use that .jar's methods for getting and adding new recipes.

Your MainMod will need to be dependent to this API and when looking for "recipes" - ask the API about them.

Developers (other) will simply get API and add their stuff.

 

And wtf with that reflection? Whole point of APIs is to not have one.

 

Note: Yes, we are talking about 2 mods, and yes - you can export them in one JAR.

Actualy, I dont know for sure if you need an obfuscated version as wel. (if all refference are oke, why is an obf lib. needed?)

Anyway, if you need an example, just take a look at any API. You'll see what setup is mentioned by Ernio

What you guys are saying is have my api be a separate mod, right? I was going to do that once I released my mod, once the api is a little more developed. But I could do that now...

It should be seperatly downloadable indeed.

Any the code that uses @Mod needs to be distributed separately, but if it doesn't you can use @API so other debs can just add your API to there project and include it in their JAR and Forge will handle making sure there' only one instance of the API at runtime, even if multiple copies of the code are included in various different mods.

Oh, that's useful, I will use @API then, or at least until I know I'm done developing the api.