Some item/node groups I would like to see made more standard

[Piezo_]

I feel that there are some item-groups that are missing.

group:mushroom could be useful, just because there are mods such as nsspf and mushrooms_redo that add mushrooms, and a universal reference ought to be available. For more detail, mushroom=3 could possibly be used for plantlike mushroom flora, mushroom=2 being for mushroom tree saplings/leaves, and 1 being mushroom tree trunks.

group:immovable would be a useful way to indicate that a node's behavior might break if it were suddenly moved from its position, because some internal mod Lua is relying on it being there. immovable=1 would indicate that moving it could also be a risk to server security (i.e. breaking someone's protected area by moving the node they placed to claim it with a piston after they shared the area with you), whereas 2 simply means that the node's functionality would break.
Mods like mesecons_mvps and meshnode should add all nodes with group:immovable to their blacklist. Soon-to-be-released updates to meseportals and wardzones/wardnodes (WIP) will support this.

group:sword, group:shovel, group:axe, group:pick, group:hoe.
These groups would just make it easier to refer to all tools of that type in crafting recipes, and/or without having to check the definition's tool_capabilities.groupcaps.(cracky/choppy/etc). instant_ores and wield_redo support these already.

[SpaghettiToastBook]

The tool type groups are especially needed. Although they could probably just be group:pick, group:shovel, and so on.

[Wuzzy]

I'm all for standardizing group names more. This should actually have been done years ago.

I also think the tool type group names should be shorter, the “tooltype_” seems unnecessary. Then I will happily adopt them. Just make it “sword”, “shovel”, “hoe”, “axe” and “pickaxe”. I would also add “shears” to the list.

It's very important that all groups are well-defined. There must be no ambiguity on whether a thing should belong in a group or not. Also, don't forget to define the group rating!

mushroom=1 seems very obvious, I'm assume it's only for the fruiting body, and that big mushroom blocks are excluded as well? Fun fact: I already used it in MCL2 to add it to brown mushroom and red mushroom.

The “fragile” group sounds useful, but the name is terribly misleading. Note that in mesecons_mvps, there is a function mesecons.register_mvps_stopper to register nodes that cannot be pushed or pulled by piston, but it sounds more useful to have a more generic group for that as well.
I don't understand fragile=1. Why would moving a block ever be a risk to server security? :D Such a thing should not be possible in the first place. As for the name: Maybe call it “immovable”?

In the Help modpack I use one group that could be considered “universal” as well.
fake_liquid=1: Used for nodes that are technically a liquid (liquiddef~="none"), but gameplay-wise should not be considered a liquid. Cobwebs usually fall in this category, they are often implemented as liquids that do not flow to get the slowdown effect.

When there is significant support for any group, we should go advertise it to games and mods (including Minetest Game!). And when there is actual usage, an entry on this page should be made:
https://dev.minetest.net/Groups/Shared_groups

We could use this thread to brainstorm for more groups that seem universally usefull across game boundaries. Or to post groups that are already used often, but underdocumented.

[Wuzzy]

Another concept that screams for standardization: food.

In MCL2, I use the group “food” like this:

Code: Select all

 * `food`: Group for an item that is a comestible item which can be consumed (as in “eat”/“drink”) (healthy or unhealthy)
     * `food=2`: Item is food / “primarily eatable”. Examples: apple, bread, raspberry
     * `food=3`: Item is a drink / “primarily drinkable” (this includes soups). Examples: bottle of water, tea, coffee, mushroom stew
     * `food=1`: Item is some other comestible or you're unsure


This is useful for a hunger mod to play the correct sound and/or particle effects without actually knowing the item.

I think this concept is universal enough to be adopted as “standard”. Who agrees? Who will put it in their mods/games?

[Skulls]

There are only two hard problems in CS: cache invalidation, naming things, and off-by-one errors.

Its a good idea but a very difficult one. You might try to just get a list together first and decide if you want a hierarchy or something more attribute based. There will be overlap between the terms. There is always overlap.

[Hume2]

I think too that group:fragile should be called group:immovable.

I think, there should be also group:smoothstone, group:cobble, group:stonebrick, group:stoneblock etc., so crafting recipes those need cobble but not a smooth stone or stone brick can work with both cobble stone and desert cobble. I already use these groups in my underch mod.

There should be also group:unbreakable for all nodes those shouldn't be breakable in survival at all. Excluding the block from all groups works somehow but technic lasers and digtrons (and possibly other mod items) can still break these blocks. Well, this can be also considered as a bug in the mods technic and digtron.

[Piezo_]

I'll have to go through my server and all of my mods to rename the groups, probably later this week, but I've edited the original post with the suggestions taken into account.

[Wuzzy]

The “unbreakable” group might be unneccessary:
https://dev.minetest.net/Mod_interopera ... ible_nodes
(which is why I have refused to use it for indestructible bedrock)

Please let's call the pickaxe group “pickaxe”, not just “pick”. The word “pick”, when it stands alone, it too ambigious.

I think, there should be also group:smoothstone, group:cobble, group:stonebrick, group:stoneblock etc., so crafting recipes those need cobble but not a smooth stone or stone brick can work with both cobble stone and desert cobble. I already use these groups in my underch mod.

Those names aren't all exactly obvious, however.
I already use stonebrick in MCL2. cobble group also seems useful. smoothstone and stoneblock sound more arbitrary and are not obvious what they mean.

I think some of the group suggestions could be suggested directly to MTG.

[Hume2]

Thank you for the tip for unbreakable blocks, that will be useful.

I agree that smoothstone and stoneblock aren't much obvious but I can't think any better name.

[Wuzzy]

I just added the following groups for tool items in MineClone 2 and Hades Revisited (dev version only, for now):

• pickaxe=1: Pickaxe
• axe=1: Axe
• sword=1: Sword
• shovel=1: Shovel
• hoe=1: Hoe
• shears=1: Shears

Note I insist on “pickaxe” rather than “pick” because it is less ambigious.

EDIT: I posted an issue for MTG: https://github.com/minetest/minetest_game/issues/2323

[Wuzzy]

Oh, I just saw that:

For more detail, mushroom=3 could possibly be used for plantlike mushroom flora, mushroom=2 being for mushroom tree saplings/leaves, and 1 being mushroom tree trunks.

Seems a little overkill, doesn't it? I would just use mushroom=1 for MTG-style mushrooms, excluding stuff like mushroom blocks. For mushroom blocks, better to use a different group name. But it seems not so important.

[Hume2]

It's a shame that crafting recipes can't distinguish group items by their group rating. You can use group:mushroom but you can't make anything like group:mushroom=2 which would apply only to items with group rating equal to 2. Something like group:mushroom>2 or group:mushroom<2 could be also useful.

[ShadMOrdre]

In terms of the bigger picture, standardizing group names is a great idea.

This helps to build an ontology that can be further utilized not just by modders, but by AI mods, that can more easily be directed and programmed using an easy to understand and simple language.

I've begun using group defs to better define various items from both lib_materials and lib_ecology, sticking to the most common usages of group names. I use various groups to define things such as fruit (any item that grows naturally), trunks, leaves, stone, dirt, sand, liquids, tools, and any other context where an ontology can be easily created and used.

IIRC, "food" as a group is already part of one of the farming mods. plant = 1, tree = 1, leaves = 1, if not already considered, should be.

Groups can be added to help further define various "properties" that are referenced by modders, and help to generally make things easier, more cohesive, and better integrated.

[Astrobe]

I think the greater-greater picture is to have an override_item() that's a bit more subtle and merge the group definitions instead of replacing the old groups table. That's what you actually want to do 99% of the times. Or create a separate override_groups() function.

I browse MTG's default and I see "puts_out_fire" groups that shouldn't be there because default doesn't (and cannot) declare a dependency on the fire mod. It's no big deal, but it is still bad hygiene. The fire mod is responsible for what it is doing, so it should override the items/nodes that it wants to burn or spare.

I browse the tables&chairs mod and also the stairs mod. I see they define their things without copying the groups of the building material (they require you to state which groups they belong to), which is often how you want it to be. It makes it error prone to create new tables, chairs, stairs or slabs.

Creating "standard" groups ahead of time is continuing to do that kind of wrong thing. And who decides what should be standard and what doesn't have to, anyway? I don't condemn in advance a design committee here; I just say it won't work very well with dozens of mod authors doing their own thing in their own corner of MT.

What you really want is to make it less of a PITA to add or remove groups from items after their definition. It's not hard to do, but there are no standard functions that do that kind of thing.

[Wuzzy]

I don't like your negativity. Just because there are many mods should not mean we should not start trying to standardize some groups.
There are some groups that are so universal, so uniquely useful for basically everyone, that they just ought to be standard. For example, the group “not_in_creative_inventory=1” is so universally accepted standard, you might think it's a special group. Yet you don't complain.
The reason to standardize such group names is to have unified names. Groups would be useless if modders would just recklessly use, like, 3 different group names for exacly the same thing (like, “not_in_creative_inventory”, “notincreativeinventory”, “non_creative”, etc.). It's really that simple.

By no means I am saying we should standardize everything. This would be madness and too chaotic anyway. Clearly, groups that are mod-specific should normally not be standard. But these cases are very obvious anyway.

Your example “puts_out_fire” is specific to a very specific gameplay mechanic and you are right in that that one particular group should not be considered “standard”, but more MTG-specific. But that's not a reason to reject any attempt of standardization whatsoever.
I disagree completely with your idea to force the fire mod to overwrite all flammable items. That's insanity, it would have to depend on ALL mods that would introduce flammable items, which is impossible. Plus, overwriting item forces you to add a dependency on the item.
Also, you seem to fail to understand the point of groups: The point of groups is exactly to AVOID hard dependencies on specific mods. Groups are meant to be a lightwight feature to put items into buckets fast. They are very useful for concepts that are shared over many many mods. Especially “crafting recipe groups” like “wood”, “wool”, etc. For concepts that are shared over many many mods, the dependency system won't help you. It will crash down on you in flames.
Imagine we had no “not_in_creative_inventory”, but instead would have to depend on a specific creative mod to call a mod-specific function. For each different Creative Inventory mod we would have to add new boilerplate code then, for a single node that we want to hide. Welcome to the deepest layers of Dependency Hell.

overwrite_groups is unnecessary, you can already do this stuff with overwrite_item + table.copy on the groups table you find in minetest.registered_items. So it would be a convenience function AT BEST.

I browse the tables&chairs mod and also the stairs mod. I see they define their things without copying the groups of the building material (they require you to state which groups they belong to), which is often how you want it to be. It makes it error prone to create new tables, chairs, stairs or slabs.

Off topic, isn't it?

Creating "standard" groups ahead of time is continuing to do that kind of wrong thing.

That's missing the point. Most suggestions so far here are all real world use cases that are ALREADY being actively used. This is not about some theoretical groups that might be used eventually.
Plus, adding groups in the code is a trivial thing to do. Reverting such a step, too. I really don't understand why you make a such big deal out of it. It's cheap to experiment around.

And who decides what should be standard and what doesn't have to, anyway?

Kinda by everyone. There will be no committee. There can't be, and there shouldn't be. It will always depend on what will finally end up in the real mod code. So it's the job of the “group inventor” to convince fellow modders to adopt that shiny new group. Hence this thread. I don't think it has to be rock-solid decisions. But groups only get you so far when modders can kind of agree what they mean.

But what is more important IMO is not standardization, but documentation. If you invent groups, take your time to write down what it freaking means. I've seen so many games that just completely ignore it.



Long story short, here is I guess a few best practices I propose for groups.
If you have an idea for a group …:
- First of all, look around in the Wiki and maybe other games/mods: Is an identical group to what you need already used, just with a different name? Then use that one instead of inventing a new group.
- If the group didn't exist, invent a new group
- … and write down what it means in an easily accessible document

So with that out of the way, can we please go back to discuss specific groups? Let's talk about the real topic here.

Like, who else (but me) will adopt the tool groups suggested above (pickaxe, axe, shovel, ...)? Did you already adopt it? Are you against it?

Do you know other universal concepts that are useful as group? Etc. etc.

[v-rob]

I'm all in for tool groups. Mushroom seems pretty good. I also like the idea for immovable because some mods could potentially crash the game if pushed by a piston, and nodes could lose their metadata, etc.

So, how about a group:misc_tool which would denote a tool that doesn't fit into one of the other categories, but is still a tool that would fit in?

I also think a group:weapon would be good, because swords aren't the only weapons. What about spears, bows, guns, etc?

[Festus1965]

so I go in also: group
* eatable
* drinkable
* skinspead, for woman need skincare
* breathable, sure we also include biochemical weapons also, mean also
* skinbreakable
* spreadable, like virus in air or on things touch, door ...
* air should get added smog depending on technic machines, smokers, cars
did I joke now, or just looking 5 years ahead ... (my daughter Celine need to wear Breathmask in School in reality)

[Astrobe]

I don't like your negativity.

I was not, but now I am.

[Wuzzy]

sandstone=1 for sandstone (full cubes only).
Added in MCL2.

[runs]

IMO:
1) 'Groups' is an undefined concept = Troubles everywhere.
2) They should be defined officially, in the api.txt, or in the MTG in a separated file. A list as a guide! The basic ones at least.
3) The food group should be defined.

[Piezo_]

Why would moving a block ever be a risk to server security? :D Such a thing should not be possible in the first place.

Locked chests, protection nodes, shops/vendor nodes from a variety of mods, steel doors, locked signs, etc...

[JTE]

Mesecons defaulting to "everything is pushable, even diggable = false nodes" and demanding special mod dependency treatment to do otherwise has been the bane of my every technical block. A simple immovable group to tell every mod (TNT included) basically "don't touch this unless I give you special handling instructions" would be an incredible boon in simplifying certain kinds of node definitions.

[Wuzzy]

I now agree, suggest that to the Mesecons authors.

[Piezo_]

I now agree, suggest that to the Mesecons authors.

I've already implemented this into the version of mesecons_mvps that I use on my server, if anyone wants to use that in the meantime.