[Solved] Access to other mods (requirements?) (1.12.1)

[Pixtar]

Hi dev community,

 

I'm currently try to access the functions / variables of another mod. I know there are still threads about it, but they didn't helped me at all.

 

Let us imagine a mod called "FooBar"

It's modid is "foo_bar"

It has a class declared as:

static class FooAPI

with a function declared as:

public static boolean getBar(){ return true; }

 

Now I have the jar and the source of the mod.

 

I've modified the build.gradle of my mod like this:

dependencies { provided fileTree(dir: 'libs', includes: ['*.jar']) }

 

The folder "libs" is placed at the root of gradlew and contains "FooBar.jar"

 

Now I'm importing all classes with:

import FooBar.*;

I'm checking for the existence of the mod and calling the needed function:

boolean x = false;
if( Loader.isModLoaded("foo_bar") )
  x = FooAPI.getBar()

 

Gradle is saying:

error: cannot find symbol: FooAPI

 

I appreciate any help to get the above example working. Maybe I'm missing something simple or maybe MC / Forge are not designed to work as the above example. I would even use other methods to get the above example to work,

 

Kiind regards,

Pixtar

 

EDIT: I'm currently using forge-1.12.1-14.22.0.2467-mdk

Edited September 5, 2017 by Pixtar

[Draco18s]

Well, for one, you have to wrap your API getter in a separate class. If FooAPI isn't available at runtime, Minecraft will crash when it instanciates your main class because FooAPI can't be found.

 

That said, you need to do this in the dependencies section of your build.gradle file:

    compile files('lib/FooBar.jar')

[Pixtar]

Thanks for the reply Draco18s. I want to have the mod "included" as optional mod.

I'm also used:

compile files('lib/FooBar.jar') 

It didn't changed anything.

Edited September 4, 2017 by Pixtar

[Draco18s]

30 minutes ago, Pixtar said:

Thanks for the reply Draco18s. I want to have the mod "included" as optional mod.

You still need to put any access to FooAPI into another class. The JVM doesn't know at the time that it reads your main mod file from disk that FooAPI will never be accessed, so it goes to check to see if it knows where FooAPI is, won't find it, and will crash.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/FarmingBase.java#L196-L198

 

I don't know why you're getting the error you are when compiling, though.

Did you add FooAPI to your build path in Eclipse?

Edited September 4, 2017 by Draco18s

[Pixtar]

Hi Dracos18s,

 

I know about the fact, that if I want to use another mod that this one needs to be loaded before the access.

But I thought that this would be handled by the useage of the following line in build.gradle or am I wrong?

dependencies { compile files('lib/FooBar.jar') }

 

Currently I'm only using Eclipse as editor not as compiler interface or something like that.

You've mentioned the "build path"; I think this can also be handled via build.gradle but how?!

 

Kind regards,

Pixtar

[Draco18s]

Right click anywhere in the Package Explorer window. Build Path -> Configure Build Path. Libraries tab. Add External Jars.

[Pixtar]

Hi Draco18s,

 

I've found the option and I've added the JAR but executing "gradlew build" via cmd still bitches, that it cannot find symbol FooApi.

 

Anyway I'm asking myself, what the external JAR is good for in Eclipse, when I'm calling gradlew not via Eclipse?!

 

Pixtar

[Draco18s]

1 minute ago, Pixtar said:

Anyway I'm asking myself, what the external JAR is good for in Eclipse

Oh, probably for doing things like code hinting, error checking, and development/debug builds. Nothing special.

 

As for gradle, that's what the dependencies { ... } block is for. If it's bitching, show the error.

[Pixtar]

22 minutes ago, Draco18s said:

Oh, probably for doing things like code hinting, error checking, and development/debug builds. Nothing special.

I've heard that sarcasm. ;-P

 

.. and now I put myself in a corner to feel ashamed of myself. *facepalm*

 

I've found my mistake - because of your hint. Now eclipse was moaning that it knows that the FooApi is comming from FooBar.jar, but if I want to use it I should include the defined path to the interface/function/whatever.

 

So I changed

import FooBar.*;

to

import FooBar.FooApi;

and gradlew is compiling without any errors.

 

.. but I stumbled right in the failure you've described above .. the mod is maybe loaded after mine, because

if( Loader.isModLoaded("foo_bar") )

is false.

 

Pixtar

Edited September 5, 2017 by Pixtar

[Draco18s]

@Mod annotation. Add dependencies="after:foo_bar"

[Pixtar]

Hi Draco18s,

okay, I've added the property to my @Mod annotation which now looks like the following:

@Mod( modid = ExampleMod.MODID, version = ExampleMod.VERSION, useMetadata = true,
	  serverSideOnly = true, acceptableRemoteVersions="*", dependencies="after:foo_bar" )
public class ExampleMod
{
    public static final String MODID = "examplemod";
    public static final String VERSION = "1.0";
	....

and I've also edited mcmod.info from the resources and added:

  "dependencies": ["foo_bar"],
  "useDependencyInformation": true

.. and .. *drum roll* .. oh miracle .. it's working .. fabulous!

 

Thanks you very much Draco18s for your help and your patience. Hopefully other users may have a little walkthrough/manual by reading this thread.

 

Have a nice day,

Pixtar

[Draco18s]

For reference, the mcmod.info files has no bearing on whether or not it works. It's just a easy-to-read text format of the details of your mod so that services like Curse can display that information without having to decompile the entire jar.

 

Good practice to change it, but doesn't actually do anything.

[Pixtar]

Hi Draco18s,

ah good to know that it's only text doing nothing than being parsed by Curse to collect meta-data. :-)

Pixtar