In my mod, lib_node_shapes, I use a variety of IF tests, pulling node info straight from minetest.registered_nodes. I test against names, definition items, and use groups mostly to weed out things, as opposed to using groups to include. Groups are too inconsistently defined, at the moment, to be useful for getting this info. Groups really only exist within a node definition, none of which follow any convention, and not all materials are appropriately labeled.
You are about the checks if an item is relevant for your formation "sub-items"? In this case you are right, the groups are not consistent enough for this. I had the same issue with the carpets. See the filter function
https://github.com/bell07/minetest-carpets/blob/master/init.lua#L11But I am about the result. The "generated items" should at least contains the information about the source material and target type (=formation). I added both to the carpet mod and test it currently on moreblocks. The smart_inventory can use this informations for grouping now, so please test it with your mod too.
Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.
- Code: Select all
def.material = recipeitem
def.formation = "carpet"
What if you were to trim your inventory lists by mod, or by drawtype, or whether it is a registered node, item, craftitem, or entity. You can still include groups, but rather than try to find all the groups by trolling the installed mods, you could simply build a list of groups from data trolled from the various minetest.registered_ functions.
Currently implemented are the next filters:
group: (item.groups.group)
ingredient: (item in recipe)
type: (item, node, craftitem..)
mod: (mod_origin)
filter: there is a register_filter() implemented. Currently they are "Translucent blocks", "Vessel", drawtype, material and formation (from discussion above) as filter implemented
What I'm thinking is that the first selection list in your formspec would allow a user to define whether to search by mod, drawtype, item_type (node, craft_item, entity), group, and some other params to be determined. The second list would then present all the mods, drawtypes, item_types.... The third list would then show each value. This would greatly empower your inventory, in what info it can provide to users and modders.
Basically that is the idea on creative page with 3x group lists. But without any settings or decisions by user, the dynamic grouping decides depending on data which groups should be displayed.
1. Can we have a trash can on the craft grid page?
That's low-prio for me since the key Q exists. There is risk of confusion with the "Lookup field" till the page is graphically polished.
2. Instead of using the 3x3 grid icon for the creative inventory, use the front face of the treasure chest, leaving the 3x3 grid icon for craft grid.
Done
EDIT: "exclusive" handling commented out because it does not work as expected and create lag. Will try it again the next days
EDIT2: Tried an other way: no generic "exclusive" groups because of performance impact. Just in creative page only special handling for "filter:material" group. Resolve the groups as before without the items in this group. In addition add a additional group ">>> Material outcome" on top level with items only containing the material attribute. For modified moreblocks+carpets it look like:
EDIT3: Renamed the new attributes to more understandable "base_material" and "shape_type". Previous it was "material" and "formation"