Loose and variable use of ore definitions and is_ground_content

[pamodeo]

While looking at the code of different mods to increase their compatibility and interoperability, I noticed two issues that can substantially complicate this work:

1) "ores" are intended in different ways by different developers: from stricter (e.g. blocks giving a product when digged, like in "stone with coal"), to broader (like the former, plus any block specifically used in crafting recipes, like "marble" or "granite" in Technic mod), up to the most general interpretations (substantially any "non-living" block);

2) the "is_ground_content" variable in node initialization is at best partial or scrambled/missing in many mods. In many mods, its initialization receives some attention in ores and derived blocks, but very often it is totally neglected in tools, machineries, plants and derived/processed blocks. Unfortunately, is_ground_content has a default value ("true") that is handy for map generation tools/mods, but, if neglected, can be problematic for most blocks in mods more oriented to technical, plant/farming and "dynamical" contents. Probably a wiser choice would have been to mandatorily require its explicit initialization in all blocks.

These two issues, alone and, even more, in combination, make any attempt to ensuring consistency and getting a fine control of the effects of tools/processes intended to operate differently on artefacts and "natural" blocks (like selective/intelligent drilling, mining, explosion, only assumed to mine/destroy the latters preserving the formers) a pain in the neck, often requiring a different ad hoc solution for each mod.

In this view, a discussion on possible new guidelines or changes in material/block initialization procedures could help the development and interoperability of mods.

[Linuxdirk]

As far as I understand is this value only relevant when the terrain is being generated the first time.

So having craftable nodes with explicit or implicit is_ground_content = true is irrelevant for the intended purpose of is_ground_content.

If a game or mod uses this value for anything else than “marking” nodes for the terrain generation for caves to be carved through them it’s the mod’s/game’s “fault”.

[pamodeo]

What I intended is that if a mod uses is_ground_content value to check (and not to mark) if the block "is ground content", a wrong initialization determines a wrong evaluation. Since the value is reported in node register and there aren't, as far as I know, best (simple) ways to find if a block is an artefact, it could be useful/opportune to initialize it correctly.
An alternative strategy, that could also fix the "ore" issue, is based on a well-codified and enforced use of (some) groups to characterize different classes of blocks.
Since I just started to work on this subject, I still don't know how "loose" or "broken" is the consistency of groups among different mods/games, but I will explore it as soon as possible.

[Blockhead]

You're right that a lot of mods are too loose with marking stuff with is_ground_content. It was noted since it affects jumpdrive, see this GitHub issue. It should help mod authors a lot of you could (a) Make some clear advice and publicise it (b) spot oversights in other mods and submit patches to them. Thanks and welcome to the forums :)

[pamodeo]

Thank you, Blockhead!

As for your suggestion:

(a) because of my present limited expertise in Lua and Luanti, I need some more time and help from expert developers to formulate a "clear advice"... any help is welcome!

(b) I am already studying how some mods are affected by these issues (ores and/or is_ground_content) and the different criteria they apply (presently, I'm working on everness, ethereal, moreores, too_many_stones). As soon as my ideas about the optimal configuration for the related variables becomes more clear, I will submit patch proposals to the involved mods.

In the case of a mod that is affected by the different ways other mods adopt to define the parameters (techage), I have also started to submit comments and possible patches/strategies to circumvent/approach this problem. It is in the context of this collaboration that I realized that a standardization of ores (what exactly is an ore?) and a correct initialization of is_ground_content could substantially contribute to a more consistent development experience and better interoperability among mods.