before I start to create pull requests for different projects I need to ask if I am on the right way.
In short:
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
diff --git a/mods/stairs/init.lua b/mods/stairs/init.lua
index 191c78d..2781ce2 100644
--- a/mods/stairs/init.lua
+++ b/mods/stairs/init.lua
@@ -33,6 +33,8 @@ function stairs.register_stair(subname, recipeitem, groups, images, description,
is_ground_content = false,
groups = groups,
sounds = sounds,
+ base_material = recipeitem,
+ shape_type = "stair",
selection_box = {
type = "fixed",
fixed = {
@@ -143,6 +145,8 @@ function stairs.register_slab(subname, recipeitem, groups, images, description,
is_ground_content = false,
groups = groups,
sounds = sounds,
+ base_material = recipeitem,
+ shape_type = "slab",
node_box = {
type = "fixed",
fixed = {-0.5, -0.5, -0.5, 0.5, 0, 0.5},
The longer description: I like to introduce the "base_material" and "shape_type" attributes on "shaped" items (mostly nodes).
Why? There are some mods that just creates nodes definitions for each combination of existing textures (base_material) and some (new or existing) shapes. I am about ts_doors, moreblocks, stairsplus, carpets, lib_node_shapes...
Sometimes I look to buildings of MC players, they have very limited count of blocks available but this people mostly build more pretty things, andI asked me "why"? The answer is: trough nearly unlimited blocks available in MT, the player (me and my childs) loose the overview and use mostly just the first-known blocks like cobblestone and sand. I see this issue is not new, the mod developer of mods above try to solve it by
1: limit textures usage to limit the outcome nodes
2: set "not_in_creative_inventory" group and take a second way to get the blocks, like circular saw or doors-workshop
The Solution 1 is sad.
My proposal about "base_material" and "shape_type" is about generalization of solution 2.
I started the smart_inventory with the goal to be able to manage as much item definitions as possible. The whole gloss of diversity in Minetest should be available to the player in an intuitive way. Coincided with lib_node_shapes I seen the differentiation need. If I enable all generated shapes, the shapes takes over the inventory because of 90% all items are from this one mod. But the game focus should not be moved to this one mod. The solution is to differentiate the "natural items" and "shaped items". Natural items are individual, each of them earned a place of honor in inventory. The "shaped items" are just combinations of a base-material and a shape.
If the both attributes "base_material" and "shape_type" are available on item definition, the information is usable for some things more like
- generalized "shaping tool" possible for circular saw, doors worshop, carpet maker
- Encourages to take more shaped combinations in more mods
- shaping-mods can check for "if base_material exists, do not use them for new shape", to avoid carpets for each variation of wood chapes.
In smart_inventory a simple handling of shaped material outcome is impelemted. In creative there is a top-level group "material outcome" that distinguish the ~ 4.000 shaped items from ~ 300 natural items in other groups. See second screenshot in https://forum.minetest.net/viewtopic.php?f=9&t=16740#p253365
lib_node_shapes did included the "base_material+shape_type" patch already so you can play with them. Note, smart_inventory ignores the "not_in_creative_inventory" group if "base_material" is set. So the lib_node_shapes does not spam the creative inventory if an other inventory mod is used.
Now the question: Will the patch been accepted in minetest_game and the proposed attributes able to be "official"?
PS: sorry for my bad English.