FANDOM


 
Line 3: Line 3:
 
Just about the development of the plugin: As you've already seen, I'm not very active at adding more recipe handlers etc., but as new mod updates come, more recipe handlers have to be implemented (occasionally). But as I work on other projects that have more priority for me than this addon, and there are people that are interested and able to add new recipe handlers, but merging and checking PR's and releasing new versions for every change seems a bit unneccesary, so I came to the following solution:
 
Just about the development of the plugin: As you've already seen, I'm not very active at adding more recipe handlers etc., but as new mod updates come, more recipe handlers have to be implemented (occasionally). But as I work on other projects that have more priority for me than this addon, and there are people that are interested and able to add new recipe handlers, but merging and checking PR's and releasing new versions for every change seems a bit unneccesary, so I came to the following solution:
   
How about if I design the addon in a way, that it only provides core functionalities for implementing recipe handlers, a recipe handler API, and the actual recipe handlers are submodules (separate Jars/classes), that are loaded and managed by the core module? So I can provide a set of default recipe handlers that are currently supported by the addon, and another set of "unofficial" recipe handlers that can just be dropped in the mods folder and that will be loaded by the addon. So I wouldn't have to test and check foreign recipe handlers, and the community would have a more flexible way to have NEI support, even if I don't have the time to implement a new recipe handler. So, TheCrafter4000, you could implement every recipe handler you want, and I don't have to merge, check and test it and release a new version every time you'll create one, but only if I have the time to work on this.
+
How about if I design the addon in a way, that it only provides core functionalities for implementing recipe handlers, a recipe handler API, and the actual recipe handlers are submodules (separate Jars/classes), that are loaded and managed by the core module? So I can provide a set of default recipe handlers that are currently supported by the addon, and another set of "unofficial" recipe handlers that can just be dropped in the mods folder and that will be loaded by the addon. So I wouldn't have to test and check foreign recipe handlers, and the community would have a more flexible way to have NEI support, even if I don't have the time to implement a new recipe handler. So, TheCrafter4000, you could implement every recipe handler you want, and I don't have to merge, check and test it and release a new version every time you'll create one, but only if I have the time to work on this. In between I'll only have to provide a link on the MC Forum page or on this wiki to the third party submodule, so the people that want this handler can simply drop it in their mod folder.

Latest revision as of 14:49, November 12, 2017

I got your PR, I'll look at it later.

Just about the development of the plugin: As you've already seen, I'm not very active at adding more recipe handlers etc., but as new mod updates come, more recipe handlers have to be implemented (occasionally). But as I work on other projects that have more priority for me than this addon, and there are people that are interested and able to add new recipe handlers, but merging and checking PR's and releasing new versions for every change seems a bit unneccesary, so I came to the following solution:

How about if I design the addon in a way, that it only provides core functionalities for implementing recipe handlers, a recipe handler API, and the actual recipe handlers are submodules (separate Jars/classes), that are loaded and managed by the core module? So I can provide a set of default recipe handlers that are currently supported by the addon, and another set of "unofficial" recipe handlers that can just be dropped in the mods folder and that will be loaded by the addon. So I wouldn't have to test and check foreign recipe handlers, and the community would have a more flexible way to have NEI support, even if I don't have the time to implement a new recipe handler. So, TheCrafter4000, you could implement every recipe handler you want, and I don't have to merge, check and test it and release a new version every time you'll create one, but only if I have the time to work on this. In between I'll only have to provide a link on the MC Forum page or on this wiki to the third party submodule, so the people that want this handler can simply drop it in their mod folder.

Community content is available under CC-BY-SA unless otherwise noted.