ACBob
commented
3 years ago A few issues I can see arising from this action though, is timing issues.\ We want the dirt block, so we depend on the Bobcraft API and request the dirt block. But we don't depend on the Bobcraft base blocks, and the dirt block hasn't been registered yet.
...Or two mods that register the same block. \ ...Or a mod that overrides a block, but can't override it because it hasn't been created yet.
I wonder if sub-modpacks are ran first before the rest of them, and if we could have a directory structure like so that would be clean and still work;
bobcraft/
mods/
bobcraft_api/
init.lua
base/
stuff-that-bobcraft-has-by-default
Bobcraft is great, being developed by one person.\ But I feel that mods will end up being developed for Bobcraft in one way or the other, and I fully support this practice.\ ...But the code doesn't.
I propose that the code gets consolidated somewhere, node registration, item registration, etc. into one API that Bobcraft mods can depend on, and then call & use.\ This would also add consistency to areas of Bobcraft, such as translation (#20), block breaking (which would fix our awful situation of recalculating them every block adding mod), etc. as it would ALL be handled by one or two base functions when push comes to shove.
Are we just re-inventing the wheel by replacing Minetest's API with ours? Yes. World generation already does it, replacing Minetest's biome API, and adding a new dimensions API. - And it works for them.
Another thing that's ought to be worth looking at, is merging some mods that are split for no real reason - such as
blocksandblocks_xtra, they can easily be the same mod(pack)! But this may be a task for another time, another issue.There should be a clear separation between the API and Bobcraft, with the API being defined first and doing nothing on its' own, and Bobcraft itself using the API to make its' blocks, items, and what-have-you.
..This would also let us completely drop the Minetest engine much easier, if we ever decide to do so!