1: Your API requires your Mod. So its not a API anymore... That makes support not really possible.

2: (More a Suggestion) instead of making an API which allows only Set Exchange Value for this Item/Block and nothing else is what you can support (thaumcraft like) add a Recipe Manager.
What does the RecipeManager do? Simply it provides a Interface with 2 Functions which will support quite a lot of stuff (since this is a popular mod the support would be way more and way better then the current one)
The interface contains these to 2 functions:
-public boolean canSupportRecipe(IRecipe par1)
-public List getRecipeItems(IRecipe par1)
(that a registry is required is not need to say but here you have it)
that allows you to access more Crafting Recipes then only the Forge/MC recipes and you do not have to do so much work (if you have a lot of fans/support)...
And also its way easier to support. If you do these 2 things i would enjoy to support this mod with IC2 Classic :3

1. The mod is a compile time dependency if you are making a mod. If the mod is not detected when someone loads up their instance, the API will not attempt calls to things that don't exist. Read up on the API annotation.

2. Implemented literally months ago - https://github.com/pahimar/Equivalent-Exchange-3/blob/master/src/main/java/com/pahimar/ee3/api/exchange/RecipeRegistryProxy.java

An example of an implementation of the EE3 API

https://github.com/MineMaarten/PneumaticCraft/blob/bbebb9cdfe33221ccd80bfdec1d1f030339690be/src/pneumaticCraft/common/thirdparty/ee3/EE3.java

Well thats the reason of an API making something that starts working if something is loaded..
My plugin System also loads only if a mod is installed but i am not interested in implementing a Full mod when i do not need internal classes for something which the API can not provide... Also you could do a
public EquilantExchange3()
{
API.instance = this;
}
would have the same effect and requires not every call a to check if the mod is there...
By the way:
I can not do that while i register Crafting Recipes normally. For machines its fine to have that system but if i make CraftingManager....add(new CustomRecipe()) for something that is harder to implement because i need to loop through the Entire Recipe List to find something... While you do that anyway... So wasted resources which i do not need to waste

So no support. Good to know.

I don't think you understand how the RecipeRegistry works in EE3. Yes it iterates over the vanilla crafting manager, but the RecipeRegistryProxy exists for you to let EE3 know of your custom crafting mechanics, whether that be machines, IRecipe's that are not registered in the CraftingManager, or magical "recipes" that produce output. You only waste cycles if you add something the vanilla way as well as through the RecipeRegistryProxy.

There are several mods happily (and easily) using the EE3 API. So far in the 6ish months it's existed, you are the only one to have found difficulty with it.

If you have improvements feel free to PR something. It's your choice to add extra EE3 support to your mod or not, and the API is there to support you in that. If you choose not to add extra support, I'm fine with that also. However the passive aggression because I answered your two points, and provided you with an example implementation, are entirely unproductive and frankly just are a shitty thing to do.

I repeate myself.
No support.

No, it's not the support you are expecting me to make for you to fit your specific case. You appear to refuse to use the API as structured today for nothing more than an ideological difference. You do not appear to understand that one of the things you asked for is implemented, and the second is just in how you want to access the API.

I pointed out re: access to API that there exists the FML API annotation and that you should read up on it to learn about it's use and how awesome it is (Link for you in case you haven't seen this awesome tutorial by @Minalien: https://github.com/Minalien/BlogArchive/blob/master/ForgeTutorials/Spotlight__API_Annotation.md)

Once again, if you decide not to add EE3 support to your mod that's fine. It's your mod (presumably) and I'm not forcing you to do anything for you. Other people could presumably add EE3 support to your mod with their own mods as well, but that's up to them as well. If you can come back with concrete reasons (and hopefully code) then I will review it but at this time you have failed to show you are even aware of the features of the API.

I repeat, no support because you won't support.

There are (painstaking) ways to construct an API so that it is entirely separate from the rest of the mod, and it works hand-in-hand with the FML API stripping annotation. For Forestry, there is a separate API jar which can be compiled against without needing the whole Forestry dev jar.

Generally I have one entry point, BlahManager which has public static fields to some interfaces. See BeeManager.java. From there, almost everything is just an interface and there are no implementation details exposed, so the API doesn't depend on the rest of Forestry at compile time. When Forestry is present, it sets the managers' public static fields in preinit so that they're available.

This gives me more freedom to change stuff internally without making people update their mod with each change (except when I break the API...). It's better for the people using the API as well because they don't need to have the mod running in their dev environment all the time, just when they want it. I'd go crazy if I needed Minecraft to load 20 mods while bug testing.

@mezz has summed it up well. requiring a mod as a compile time dependency for using an API is cumbersome. Though I disagree that it's "painstaking" to do so :P

Isnt the whole point of an api to make addons or compatibility for the mod
that the api belongs to?

I cant think of an instance where you make a mod using the api and ee3 is
not in the collection of mods.

And wouldnt it be better to test your mod/addon that you used the api to
make if you have the ee3 mod installed?
On Oct 19, 2015 8:01 PM, "tterrag" [email protected] wrote:

@mezz https://github.com/mezz has summed it up well. requiring a mod as
a compile time dependency for using an API is cumbersome. Though I disagree
that it's "painstaking" to do so :P

—
Reply to this email directly or view it on GitHub
#1013 (comment)
.

@reapersremorse I have compatibility with 15 mods, most are large like IC2, EnderIO, Railcraft, and Buildcraft. I certainly do not want to be running them all the time, it would take forever to start the game to do testing. For EE3 I would like to add the compatibility stuff, get it working and tested, and then remove EE3 from my environment and forget about it until someone reports a bug.

I didnt realize that you ment ee3 had to compile with your mod...
On Oct 19, 2015 8:36 PM, "James Mitchell" [email protected] wrote:

@reapersremorse https://github.com/reapersremorse I have compatibility
with 15 mods, most are large like IC2, EnderIO, Railcraft, and Buildcraft.
I certainly do not want to be running them all the time, it would take
forever to start the game to do testing. For EE3 I would add the
compatibility stuff, get it working and tested, and then remove EE3 from my
environment and forget about it until someone reports a bug.

—
Reply to this email directly or view it on GitHub
#1013 (comment)
.

I do agree that APIs should not reference internal classes. It only serves to complicate usage of the API. I should be able to use the API as an independent source.

I accept PRs :-p

thanks...

Is it not obvious that this entire package is meant to be repackaged in your own mod(s)? Genuine question because if it's not apparent I need to add documentation here.

Well it can stay where it is because you can delete everything else except for the api but that would cause a lot of problems....

I am only referring to the com.pahimar.ee3.api package. Is it not obvious you are to repackage this specific package and its classes into your mod for shipping, and to use EE3 as a compile time dependency, as per FML API?

Yeah... I hope @pahimar that you change at least that so you do not require thaumcraft to load it. (API requirement is something differend that can be handled with Reflection real easy)

...Reflection? If you need reflection to use an API you're doing it wrong.

For my API I like building the mod on top of the API, as opposed to the other way round. so the mod doesn't initialize the API, the mod just reads from the API. It works better for me.

@tterrag1098 i am using Reflection to load the Plugins from IC2 Classic (if the classes are not there it simply throws a runtime execption which i catch) and that allows me to have all the plugins inside without adding the APIs to IC2 Classic. It loads only things which are aviable.
Thats why i do not mind API requirement/Mod Rewquired (if needed because API does not provide enough stuff)

@Speiger EE3 does not and never has required Thaumcraft, and never will

@mezz Set the dependency to 'provided'. It will be present at compile time but not runtime.

I do not know how to program yet, but if your able to setup your mod where
the the api is only needed when ee3 is in the game, then why would it
matter that the mod has to be in the mod testing invironment when you
recompile?
On Oct 20, 2015 9:09 AM, "Adly Templeton" [email protected] wrote:

@mezz https://github.com/mezz Set the dependency to 'provided'. It will
be present at compile time but not runtime.

—
Reply to this email directly or view it on GitHub
#1013 (comment)
.

@pahimar i did mistype something. I meant EE3... Sry

@reapersremorse and @pixlepix there is in the dev-invioment a requirement. And i do not want to load like 30 mods just to test my plugins. It is for me better to use reflection to load my plugins because i can merge all my plugins (or most of them) into a complete new workspace and they still got loaded (if IC2 Classic is as dev mod installed). So i have 1 workspace for IC2 Classic (without plugins or 2 plugins depends) and then i have a workspace only for IC2 Plugins and it works fine xD The Power of Java Reflection xDD It simply allows me to have a cleaner workspace and less mods to load. Even if it is complicated to update the jar if something changes in it... But that is less work then normal