registered_crafts table

[SkyBuilder1717]

You cannot check registered crafts to find your one from mod, so we need to create a registered_crafts table for that, I sure this will solve manu amount of problems about crafts.
If we add this table system in mods code, (like, init.lua) it will not identify many amount of crafts, as needed.

[rollerozxa]

This would be a useful feature, as it would make things glcraft's "zzzz" load-first-of-all bootstrap mod not really necessary anymore: https://gitlab.com/Kimapr/glcraft/-/blob/master/zzzz_glcraft_crafthook/init.lua?ref_type=heads

While there are already core functions for retrieving crafting results based on recipe input, there is no way to get a full table of all of them, short of hijacking the register_craft function as such. It would also be more consistent with other registries that also provide such a table with the registered entries.

[rollerozxa]

Also add documentation about it in lua_api.md

[appgurueu]

I see multiple problems with this (besides what roller already said):

• The registered_crafts are not indexed by anything useful. It's just a flat list, tricking users into writing unnecessarily slow code. This is in contrast to many other registration functions and corresponding registered_* tables, where we have names (e.g. node names).
• No recipe definition table normalization is done; for example a user of this table would have to handle both itemstrings and itemstacks. This is a mistake other registered_* tables have made too but which I would like to avoid for new API additions.
• The deprecations are absolutely unacceptable. You are deprecating useful functions which can leverage engine-internal indexes and instead forcing people to replace them with inefficient boilerplate iteration of a list of registered crafts, creating completely unnecessary and counterproductive work for them. Undo that now.
• Furthermore, there is a glaring bug in your implementation: clear_craft does not update the list. (And fixing this would make the PR a good bit nastier: You now need a way to match recipes, going back to my normalization point, or for the C++ side recipes to know the indices in registered_crafts.)

While there are already core functions for retrieving crafting results based on recipe input, there is no way to get a full table of all of them, short of hijacking the register_craft function as such.

How so? What's the problem with iterating over registered items and finding all recipes that have any item as an output using core.get_all_craft_recipes(item)? Sure, it's a few more lines of code and unnecessarily using an index, but it should be possible. What am I missing?

It would also be more consistent with other registries that also provide such a table with the registered entries.

I disagree, the big difference being that other registries typically have obvious useful indices (names), or you need to iterate effectively all of them anyways (e.g. lists of callbacks), neither of which is the case here; and the indexing by output item (for which the keys are just the registered items, which you can already iterate) is already provided.

So far this PR is between low priority and possible close in my opinion; I do not support it. Maybe @Kimapr can convince me otherwise.

[appgurueu]

just no

[SkyBuilder1717]

In other way this will give false

[appgurueu]

you would need a recursive lua table compare (or have to manually implement recipe def compare) here. your normalization is also incomplete.

but i don't think this is the right approach to begin with.

[appgurueu]

this table isn't even a list anymore after this

[appgurueu]

still deprecating things you shouldn't be deprecating