[IDEA] Mod-opt-in via API/Registering materials & receiving item classes etc from AOBD

[kotoroshinoto]

@ganymedes01 perhaps isntead of seeking to do this intrusively, via editing the recipes FOR the mods, providing an API for mods to register the materials themselves and use AOBD's items instead of their own when creating/adding their recipes on launch would be a more elegant approach.

[kotoroshinoto]

It could allow for the ores/nuggets/fluids/ingots/blocks depending on the request being a minable resource or a produced alloy.

[kotoroshinoto]

as well as working for the current dusts/clumps/etc

[kotoroshinoto]

You could maintain the current editing behavior by moving the explicit recipe/mod support functionality into a second mod jar (until/unless those mods embrace the API idea).

I'd be willing to provide whatever help I was capable of to implement such a thing if you were to choose to do it.

[kotoroshinoto]

I envision it having methods like these available for mods to tell AOBD to set things up for them. boolean RequestMetal (String Metal, String color); boolean RequestMetal (String Metal, byte R, byte G, byte B);

return false if it already exists, perhaps use object so you can return null in case of failure (though I can't think of a reason that it would fail), or perhaps signal that some other way.

boolean MetalRegistered (String Metal);

Item RequestItem(String Metal,String itemtype), Block RequestBlock(String Metal,String itemtype),

where itemtype would be fluid, nugget, ingot, dust, tinydust, cluster, crystal etc.

perhaps at the last step of loading it could then spit out the metal configs that were requested from it, so the server admins could override the values. Default behavior if the config already exists could be to append items and values not already represented in it, and use the values in the config preferentially over the ones requested by mods. (for things like color, or if you decide to allow for oregen, then things like max/min height and rarity values)

perhaps could even provide this: void RequestOreGen(String Metal, .... otherparameters);//would automatically add the ore for the metal if it didn't exist yet

however the other mods could probably handle their own oregen using your item/block objects just fine.

[buttilda]

The idea of an API for materials would only work if it was implemented natively into forge (good luck convincing anyone there of implementing anything lol And even if you're lucky, they'd never do it for 1.7.10)

Requesting items from other mods is already possible. GameRegistry.findItem(modid, itemname):

There are also several mods that allow you to unify all items that are registered under the same name. Simples blocks that allow you to pump a bunch of different copper ingots in one side and extract only of type on the other.

[buttilda]

What I would be willing to do is allow for a user control of which items AOBD uses as outputs. As it is it uses the first item it finds in the ore dictionary (so when adding a dust -> ingot smelting recipe, the ingot outputed will be the first found, the plan is to allow the user to choose which ingot it would be). Anything other than that I'd be going over the line in what AOBD is meant to be doing.

[kotoroshinoto]

Is there a reason beyond propriety that makes you think something like that should be part of the forge API? In principle I agree with you, but I also think AOBD's codebase is already halfway to being able to do just that, and perhaps SHOULD be the basis for such a system.

I mean, would there be anything to prevent it from working in principle?

[kotoroshinoto]

Given what it is already capable of doing, if you allow mods to forward request the items, they could ask AOBD for them during their own loading process if its available and then use them in their own code while registering recipes. It could take quite a bit of the dependencies out of AOBD, and make it work seamlessly with any mod that might want to use it.

[buttilda]

Yes, I could easily implement it into AOBD, but no one will want to use it because no one wants to depend on AOBD (and I don't want them to). If it was natively implemented into forge (instead of the mess that is the Ore Dictionary) then mods would actually use it.

[kotoroshinoto]

It could be a soft dependency rather than a hard one, but still its your mod, seems to me you've got about 60% of a better materials API for forge here already. It seems a shame not to put into a form that could potentially gain that purpose.

[kotoroshinoto]

(I.E. if and only if AOBD is available they use your materials, otherwise use their own, etc.)

[buttilda]

Out of the few mods supported by AOBD, I don't see half of them using the system I'd put in place IC2, factorisation, railcraft, Applied Energistics, Thaumcraft... none of those (and probably more) would bother with it

[kotoroshinoto]

perhaps if you forked it and toyed with such a system, just for funsies, you could show it to LexManos and perhaps replace the blighted oredict system as far as ores/fluids/metals are concerned.

it just seems SO close to being able to do exactly what minecraft needs even in its curent form lol.

[kotoroshinoto]

Mind you I wouldn't be pushing the idea so hard if I didn't think minecraft modding could benefit so greatly from it and the mod is wonderfully implemented already. I hope you take this as the compliment and confidence in your work that I intend this to be rather than an annoyance.

[buttilda]

I believe that a system like this would be great, but every attempt I've seen of tweak the way the OreDictionary works was rejected immediately (or ignored forever). I've tried many times to send commits to forge in several different occasions and they all get ignored or rejected with absolutely no explanation. I have no intentions of sending them anything anymore.

When they stop being knuckleheads and re-implement the item rendering classes that modders NEED in order to port to 1.8, then maybe I'll change my mind. Until then, to me, committing to forge is an exercise in futility.

[buttilda]

Make an issue on forge's repo and discuss it there. If Lex likes the idea or it gets people's attention then I'll more then happily do it.

[kotoroshinoto]

well given the system you have in place here, if i'm understanding it correctly. Looking at the barebones resource images you have, the only thing lacking is ingots. If you forgo the idea of worldgen, and simply stick to providing items for recipes, adding in the potential to have AOBD create & color ingot objects and forward request these things and move the specific mod support into a dependent compat-mod set to loadlast it could probably be done with absolutely minimal change to what you're already doing. That would be minimally invasive, and if it did happen to acquire massive utilization, would it really matter if it was or wasn't built directly into forge?

[kotoroshinoto]

Would you mind If I linked this issue to that issue or would you prefer they not see your statement about having things rejected?

[buttilda]

Yeah a mod like that could probably easily be done. See how things go with forge, if they reject it I'll make the mod :3

[buttilda]

Probably not a good idea, they'll see me moaning and get annoyed, which would probably decrease the chances of it being heard (remember NOVA api outcry). But it's up to you :3

[kotoroshinoto]

I did post an issue, it has number 1753.

[kotoroshinoto]

You can elaborate or add to the issue if you feel like it, i'm not sure if I explained myself all that well.

[kotoroshinoto]

It probably wouldn't hurt to have you say that I wasn't making it up on your behalf and that you did actually say that you'd be willing to do it.

[kotoroshinoto]

I don't hold out much hope tho, it seems their dev team is somewhat resistant to change, especially when it doesn't originate from within.

[buttilda]

I'll post on the issue. I also doubt we'll even get a response. But who knows, maybe we catch their dev team in a good mood today XD

I'll close this for now. And open an issue myself with the details of how the future system will work.

[kotoroshinoto]

Man they are coming up with pretty lame excuses. Modder community disagreeability should have no bearing on what features make sense to provide. If the modders want to be whiny cockbags, I don't see how that makes the feature a bad idea XD.