Important Mineclonia modding PSA

[repetitivestrain]

PSA: the next release of Mineclonia will feature a new deterministic structure generator and biome abstraction layer, which supersede mcl_structures, the engine's decoration system, and the engine's "core.get_biome_*" functions and "core.registered_biomes" table. Please update your mods accordingly; failure to do so will result in structures ceasing to generate or invalid or erroneous biome data being returned when the singlenode-based custom map generator is enabled. These new facilities are documented at:

https://codeberg.org/mineclonia/mineclo ... en/API.txt
https://codeberg.org/mineclonia/mineclo ... ch/API.txt

though it may be prudent to retain support for the existing structure systems, as they will continue to be enabled and utilized on Luanti releases earlier than 5.14, unless the new custom map generator is also enabled.

Furthermore, new function blocks are available by the names of jigsaw and structure blocks to facilitate recording player constructions for future generation and assembling templates so recorded into procedurally generated structures, and function nearly identically to their Minecraft counterparts. It is now exceedingly trivial to create large and complex generated structures with a combination of structure, structure data, and jigsaw blocks; this process is also documented in mcl_levelgen's API.txt. Here is an example of jigsaw generation in action:

https://codeberg.org/mineclonia/mineclo ... d_city.lua

Mods which depend upon the default behavior of the "singlenode" mapgen must place a file named "mcl_levelgen.conf" in their base directories with the following line:

disable_mcl_levelgen = true

to inhibit the new map generator.

[isaiah658]

So I'm sort of struggling on how to keep my mod compatible. How do you register basic mapgen decorations, like plants? Because my mod is meant to work on any game, I would normally just use core.register_decoration and avoid any game specific mapgen features. Also, is there a way to determine which mapgen is being used, the old one or the new one? My mod will have to support both for very long time.

[repetitivestrain]

So I'm sort of struggling on how to keep my mod compatible. How do you register basic mapgen decorations, like plants? Because my mod is meant to work on any game, I would normally just use core.register_decoration and avoid any game specific mapgen features. Also, is there a way to determine which mapgen is being used, the old one or the new one? My mod will have to support both for very long time.

core.register_decoration is not supported, but you can detect whether the custom map generator is enabled by reading the variable "mcl_levelgen.is_levelgen_enabled".

To register a feature, you must register a level generator script (as documented in API.txt), and within the script, define a feature:

Code: Select all

mcl_levelgen.register_feature ("mymod:my_feature", {
  place = function (self, x, y, z, cfg, rng)
  end,
})

where the "place" function invokes mcl_levelgen's own map accessor functions, mcl_levelgen.get_block, and mcl_levelgen.set_block, and derives all random values from the provided RNG. These functions are likewise documented in API.txt.

Define a configured feature:

Code: Select all

mcl_levelgen.register_configured_feature ("mymod:my_feature_cfg", {
  feature = "mymod:my_feature",
})

which associates the name "mymod:my_feature_cfg" with the second table and the feature identified in the same, which is provided as the "cfg" parameter to the "place" function in the feature defined above.

And finally a placed feature:

Code: Select all

mcl_levelgen.register_placed_feature ("mymod:my_feature_placed", {
  configured_feature = "mymod:my_feature",
  placement_modifiers = {
    mcl_levelgen.build_count (function (rng) ... end),
    -- Et cetera.
  }
})

which associates the configured feature that was defined with a list of placement modifiers that take a position at the northwest corner of a chunk, produce a random number of instances of the configured feature, and arrange to generate each such instance at a position defined by programmer-specified criteria specific to each modifier. (Also see the section on placement modifiers in API.txt.)

This placed feature must be registered to generate in one or more biomes, by invoking mcl_levelgen.generate_features with a list of biomes, the name of a generation stage, and the name of an existing feature in each biome that generates during the provided stage before which to generate it, e.g:

https://github.com/LunaSquee/elepower/b ... er.lua#L40

Here's API.txt:
https://codeberg.org/mineclonia/mineclo ... en/API.txt

If your decoration is larger than 32x32 blocks horizontally or 64x64 blocks vertically, it must be defined as a structure, which is substantially more involved but also documented in API.lua:

https://codeberg.org/mineclonia/mineclo ... .txt#L1315

Be advised that neither structures nor features will generate in an environment where engine-provided APIs such as core.{get,set}_node, or core.place_schematic, are available. You must only manipulate the map through functions provided by Mineclonia, mcl_levelgen.{get,set}_block, mcl_levelgen.place_schematic, mcl_levelgen.make_schematic_piece, and so forth, and read random values through levelgen-provided rngs, which are incompatible with the engine's Pcg or PseudoRandom objects and operate on 64 or 128-bit quantities represented as Lua tables, rather than 52-bit integers, as they do.

[ArceusI]

That's why MineClonia DX is being conceptualized, to avoid this situation where mods become unsupported. MineTest would never break compatibility with mods like this.

[repetitivestrain]

That's why MineClonia DX is being conceptualized, to avoid this situation where mods become unsupported. MineTest would never break compatibility with mods like this.

Retaining compatibility with old structures or decorations in the new level generator is simply impossible, and insisting on it would force the game to remain in the past and increasingly irrelevant as against Minecraft. The new level generator is so overwhelmingly superior in every respect that it would be plainly absurd to abandon it to accommodate existing mods, which will continue to function under the existing generators for as long as they are supported, and will gradually be ported anyway.

In general the engine should provide fewer underspecified and organically developed subsystems, such as the built-in decoration system, and devolve implementing these facilities on games and mods. But that's just my (considerably informed by experience) opinion.

[ArceusI]

MineClonia DX has a unique solution: Incorporation. By including the mods directly into the game, they can update alongside MineClonia DX, it won't be easy though, as mods would have to be rebuilt explicitly for MineClonia DX and it's updates. But at least it would keep compatibility to a degree, plus, there could be "Legacy Compatibility" modules that could try to maintain legacy compatibility, and outside mods would have to detect this to continue functioning.

[rstcxk]

could be "Legacy Compatibility" modules that could try to maintain legacy compatibility, and outside mods would have to detect this to continue functioning.

That is by definition not backwards compatible

[ArceusI]

could be "Legacy Compatibility" modules that could try to maintain legacy compatibility, and outside mods would have to detect this to continue functioning.

That is by definition not backwards compatible

Yes, but I see that some mods have a Legacy partition, meant for old versions converting to newer versions, but at least mods won't have to update after that, but maybe there's another way...