Ideal API Design

[sinkillerj]

• A real API, not this wonky IMC business.
• Mods that attempt to modify EMC values in any way, adding, removing, etc, are automatically added to a config file where the user can deny that mods permission to do so. Ideally two config options per mod, allow modify self, and allow modify other mod id's.

Below are current suggestions please feel free to add to this list by commenting.

• Allow mods to add their own EMC mappers, this would also allow for NEIAddons style mods.
• Access to player knowledge, mostly read, but I could see write being useful for some addons.

[Brycey92]

Would it be possible to have an API function to add your mod's custom recipe handler to the ProjectE graph mapper?

[sinkillerj]

@Brycey92 This is certainly something that we would like to do in the future, this would allow not only mods adding their own mappers, but could open the door to NEIAddons type mods.

[Brycey92]

Oh, speaking of NEIAddons type things, would it be feasible and/or useful for ProjectE to have an NEI addon type thing to show how an item's EMC was calculated?

e.g: Initial items: a - aEMC, b - bEMC Crafting to c: a+b = cEMC Smelting to d: c+smeltingEMC = dEMC

If you think this is a good idea, I'll open a separate issue for it, don't mean to clutter issues with unrelated things. :P

[sinkillerj]

Would @Brycey92 's suggestion be feasible @MaPePeR ? I'm guess no but you know better than me on that one.

[MaPePeR]

That is a idea I'm playing around in my head with myself , but I would not do that ingame, but add an option to generate a HTML file for that. Showing all the information ingame is to much of trouble.

[MaPePeR]

The PR, I opened yesterday implements exactly your point 2 #588

[Vexatos]

Mods that attempt to modify EMC values in any way, adding, removing, etc, are automatically added to a config file where the user can deny that mods permission to do so.

It might be that a mod has to blacklist its items having EMC values because it would make the mod unplayable otherwise (e.g. if you can get to the end game of the mod skipping the rest). I'd say such a config option should be optional, i.e. have the methods that change EMC values have a boolean parameter and the mod will only generate a config option if that is set to true.

Other request: Allow blacklisting items, itemstacks or item-metadata pairs from being picked up by the Black Hole ring. Ideally all three things would be there.

[sinkillerj]

@Vexatos The config would be true by default, the mod changing the values would only be blocked if the user explicitly told ProjectE to.

[Vexatos]

@sinkillerj Some mod authors might still want to enforce the behaviour as it could be possible that the mod's end game breaks other mods as well, some people just don't want that under any circumstances.

Also, what about my other request?

[MaPePeR]

Do we really need to have that exact same discussion at 2 different places in the Repo?

A mod author of mod X is not aware of every Situation/ModPack/Whatever that mod X is used in. The one who is configuring the pack is aware of all the mods in the pack and knows which kind of balance is wanted in the pack => the one configuring the pack should have the last word.

But probably it is a good idea to split blacklist and custom emc values, so one can allow a mod to blacklist values and disallow it to add values. or the other way around.

[sinkillerj]

At the end of the day the user/pack author has the final say, I understand that some mod authors may not like how ProjectE interacts with their mods but using the mod is a choice. I'm simply attempting to protect the user from Gregtech situations, forced changes to other mods that the user may not want.

As for your other request its being kept in mind, it goes a lil beyond the API itself.

[MaPePeR]

Personally i think we should use a similar approach as AE2 for the API: Have the full API be in an Interface, that can be included and use a 'getter' to get the actual instance implementation.

Adding handlers for custom IRecipe Implementations and even IEMCMapper-Implementation should definitefly be in the API, but i think this needs a little bit more preparation beforehand.

The IEMCMappers need to be prioritized in their order of execution. The same actually applies to the custom-emc values from mods as well, so we might need to add a priority list to that configuration.

[Vexatos]

Gregtech situations, forced changes to other mods that the user may not want.

Everything in GregTech is configurable, literally everything. Also, GregTech only affects Vanilla MC and IC2, any other mod adds integration to GregTech, not the other way around. I just wanted to clarify as it's a common misconception.

Also, I second adding some priority list.

[TomeWyrm]

Vexatos: Forestry. Unless he's changed it FINALLY, he still screws with Bronze crafting.

His Ore Dictionary Unifier also caused a lot of mod bugs. I could go on. Greg isn't as blameless as some people make him out to be either. Yes the vast majority of the "greg" changes are done by the other mod authors, but they only activate with GregTech installed which adds to the issue of misattribution, and a lot of them seem to enable be default, which REALLY doesn't help, but he also has broken MANY MANY things over the years, and even if the particulars can be nitpicked on technicalities, the core of the idea remains the same. "forced changes to mods that the user may not want". Who is at fault in the topic of GregTech is mostly immaterial to the point being made. When GregTech was installed, mods changed without user notification. Mods that had little to nothing to do with the IC2 ecosystem. Sinkiller does not like that behavior, and does not wish to implement things making it easier to do in his own mod; because ultimately that is why people add Equivalent Exchange and Project E to their instances and modpacks: EMC. The ability to turn matter into "energy" and then back again. The original idea that spawned this chain of mods was x3n0ph0b3 having rooms dedicated to storing cobble from his mining trips and wishing he could do something useful with them. Taking something the USER decides is useless or worth less to them than something else, and allowing them to obtain that other thing. The USER. Not the mod author. The only way people learn is by making mistakes or watching other people make mistakes. Trying to protect against stupid only wastes everyone's time once you get to a certain point. We've well and truly hit that point with PE.

If you want people to use your mod reasonably with PE? Research how the EMC system works so you don't lock up people's computers for MORE THAN A HALF HOUR blacklisting hundreds of thousands of individual items (Yes I'm talking about Reika here. It's been fixed since, but doing that shows a lack of understanding on how PE derives EMC values for items), and give those items fair prices because the only way to get an item with Project E is either by enabling the "cheat sheet" in the config and then spending a CRAPTON of EMC on it, cheating it (the item or the Alchemical Tome) in, or by obtaining the item legitimately.

If you think RoC Tungsten should be more expensive than the raw materials (Which if tungsten ore's value from RP2 days is kept means it's worth significantly more than a diamond with all the ingredients that go into making it)? Then register it as such. But ultimately it's the user's machine, the user's pack, and the user gets to decide what they want.

Thank you for sticking up for the end user SinkillerJ

[sinkillerj]

For continued discussion see #807.