Currently, we're including the EB source and the Highlands source in src/api to compensate for the lack of an API (EB) or the lack of a robust API (Highlands). This is obviously great because it allows the content from these awesome mods to generate in RTG worlds. However, the drawback as we know is that when testing locally, EB (and probably Highlands now too) interferes with the world and acts as if it was actually installed.

It occurred to me that we can get around this by gutting the preInit(), init() and postInit() events to prevent them from actually 'doing' anything. I haven't looked into the specifics yet, but I just thought I'd create this issue as a reminder to look into it further. But it should just be a case of gutting those events, resolving a few compile errors, and bob's your uncle.

Libraries, dude! In my own installation I have the EB and Highlands mods as libraries and no source code from either except for the EB API, and it works just fine, running with or without either in my mods directory.

Nope, I threw out that folder. All I have for EB is enhancedbiomes/api/EBAPI. I don't have any HL API code at all. Jars can refer to external code, no problem.

you can refference them in many other ways than the api folder. if you put a jar in /libs it will include that too, and in 1.9 we are including it via maven

But you still have them in src/api, right? I didn't think you could build a JAR without having the relevant external code in src/api.

Well, I'm using NetBeans, so I don't know how it works for you. I have EB, etc., as libraries in my dev environment (I pick with a file selector - I don't have to use a libs folder and I don't). I test by compiling and copying into my MC mods folder (with a script). Everything works fine - I can refer to methods in the dev environment but they only show up in play if the mod is in my mods folder. If I refer to a mod method I get an error, of course, but I catch those.

Also, I don't have to use a deobfed jar except for occasional mods which are doing funky stuff with the loader. The jar that goes into the mods folder is already deobfed.

Nope, I threw out that folder. All I have for EB is enhancedbiomes/api/EBAPI. I don't have any HL API code at all. Jars can refer to external code, no problem.

So how did you add EB and Highlands as a library? I've just added a deobf EB jar to my libs folder, which allows me to compile a build jar for RTG, but when testing locally, EB appears as being a loaded mod, which I'd like to prevent if possible.

I'm just trying to find a way to include the EB/Highlands source files to the project so that we can reference their stuff and compile a build JAR for RTG and also not have them appear as being loaded mods when testing locally.

Am I missing something glaringly obvious here?

if you are, i am as well, and i might be

Takes me 13 seconds, YMMV. Debugging, sure.

@Zeno410 How does building the jar take a few seconds? You don't use gradlew build?

Ah, ok, I see how you're doing it. In that case, I think I'll try out the method in the OP to see if it works - that way everyone can keep testing the same way they are currently, with the added benefit (if it works) that those testing locally via src/api won't have EB/HL 'installed' but will still be able to access the EB/HL code.

I build from the compiled classes, not the source code

Ok, I've gutted the EB and Highlands bootstraps in 931522b, so basically everything works exactly as it did before, except now when testing locally via your IDE of choice, it won't try to load up EB or Highlands and show them as being 'installed'.

oh - the thing is, we would like to not have to build a jar and copy it into a minecraft instance - using eclipse/idea's run configs is way faster. Also it allows us to do debugging without having to do voodoo

@Zeno410 were gonna need a guide for that

And how do you actually edit the code then? Where would the source files that you can edit be in and how do the changes get included when compiling?

I do all the editing in my development folders - same place I have all my 20+ projects, MC or no

Well, what I had been doing long ago was copying my source files into the source file directory for the gradle build, and then running gradle. But it turns out you can just copy the compiled classes into the appropriate section, not copy the source files, and gradle is perfectly happy. I started because of some library issue which was messing up the gradle compilation but which NetBeans could deal with, but once I found it made building take a couple of seconds rather than 2-3 minutes I always did it that way.