New paramtype2 variants

[MatyasP]

Hello

for a long time, I've been thinking that the current paramtype2 variants don't fully cover the needs. In many cases, we require more unique nodes (which also fills the node limit). To address this issue, I have prepared a proposal for new variants (below). A few days ago, I mentioned this in a package of my drafts - viewtopic.php?t=31363.

1. For different textures of a single node type (e.g., a wall with either a brick or stone texture).
   New paramtypes:
   texture4dir
   texturefacedir
   texturewallmounted
   texturedegrotate
   Each of these works similarly to the existing "color..." types, such as "colorwallmounted."
   How does it work?
   For every variation of "color...", we use texture replacement for the same bits and define the feature using texture_prefix="nicewall","png". This can apply either to the entire node or to each side individually. Each texture variation of param2 will have its own texture named <texture_prefix><decimal_number>. For example, the texture name could be nicewall7.png or, for a specific side, nicewall_leftside_7.png (where `texture_prefix` for the left side is `"nicewall_leftside_","png"`).
2. At least one group of nodes should have a dedicated paramtype2 variant for structural configurations—nodes that have 0 to 4 "backs" and (4 - backs) "fronts," similar to fences but with specific properties (e.g., not interacting with adjacent nodes or having different nodeboxes for each variation). Each side requires its own 0/1 paramtype2 state. For this, I propose the following variants, under the name "intstate" (which I find better than the working name "eachside"):
   intstate
   colorintstate
   textureintstate - only after variant 1 is completed
   Textures and nodeboxes must be defined using a state-based system called "statevar," such as:
   statevar="alone"{nodebox, tiles ...}
   statevar="front"{nodebox, tiles ...}
   statevar="corner"{nodebox, tiles ...}
   statevar="sides"{nodebox, tiles ...}
   statevar="3sides"{nodebox, tiles ...}
   statevar="cross"{nodebox, tiles ...}
3. For even more specialized nodes, a unique paramtype2 variant could be introduced:
   userdefined - where everything is defined by the user.

[MatyasP]

Not to forget - thanks to BlockHead for his comments! I have need it for make this plan as completed as is.

[Blockhead]

I was skeptical at first, though I do like the idea of using a sequence of texture names. Although I didn't respond at first, your post came to mind today. I was actually thinking that, like I have said for texture options before, why not have meshes? I actually found the original pull request from jwmhjwmh again - #12928. After prior fruitless searches, I remembered the author so I went through his history (may he rest in peace, the world is poorer without him) to find it.

Anyway, the thought occurred to me today while looking through the Advtrains track models for problems, that it would be good to have mesh options as well. While I took care to carefully arrange the sleepers when I did the diamond crossings, Y-turnouts and 3-way turnouts, I had to compromise between making the node make sense on its own (not a huge priority) and in combination with where it is supposed to be used (the main priority, though it still has to be compromised because of the overlap in models).

I thought: Well, these nodes only use 4 rotations, that's only 2 bits. Why not let me choose a different model with different sleeper placement under the rails by using some more of those bits? The placement code for tracks already checks for orientation so you that placed track nodes will connect to other nearby track nodes, it would just need to be extended for sleeper options.

Of course, it's possible already to make custom track mods that would register more nodes with different models and even override advtrains.trackplacer. It would still be nice to use the same nodes, especially given just how many track nodes a set already needs: I count 80 models.

[MatyasP]

I was skeptical at first, though I do like the idea of using a sequence of texture names. Although I didn't respond at first, your post came to mind today. I was actually thinking that, like I have said for texture options before, why not have meshes? I actually found the original pull request from jwmhjwmh again - #12928. After prior fruitless searches, I remembered the author so I went through his history (may he rest in peace, the world is poorer without him) to find it.

Anyway, the thought occurred to me today while looking through the Advtrains track models for problems, that it would be good to have mesh options as well. While I took care to carefully arrange the sleepers when I did the diamond crossings, Y-turnouts and 3-way turnouts, I had to compromise between making the node make sense on its own (not a huge priority) and in combination with where it is supposed to be used (the main priority, though it still has to be compromised because of the overlap in models).

I thought: Well, these nodes only use 4 rotations, that's only 2 bits. Why not let me choose a different model with different sleeper placement under the rails by using some more of those bits? The placement code for tracks already checks for orientation so you that placed track nodes will connect to other nearby track nodes, it would just need to be extended for sleeper options.

Of course, it's possible already to make custom track mods that would register more nodes with different models and even override advtrains.trackplacer. It would still be nice to use the same nodes, especially given just how many track nodes a set already needs: I count 80 models.

Great!
Some years ago, I tested concrete ties but it was... not functional.
For your response, I see more variants to do it (after needed parts of this proposal will be added):

1. Simpliest - only texture variants of ties (up to 64 textures) with paramtype2="texture4dir",
2. More parts with texture variants (for example - 2 bits for tie textures - new wooden, concrete, old wooden, steel; 2 bits for bed texture - grey gravel, orange gravel*, snow, dirt_with_grass; 2 bits for rail texture - new, used, rusty, very rusty) by paramtype2="userdefined"
3. As point 2), but if it will be possible - with paramtype2="texture4dir" (I think that this variant is for Luanti development the most difficult)

* = orange gravel have we in modernised railway station Beroun (County of Beroun, Middle-Bohemian region, Czech Republic) - as in photo: https://zdopravy.cz/wp-content/uploads/ ... 140348.jpg

[MatyasP]

I thinked about it... and for slopes could be used "userdefined" for straight slopes too with mod More slopes. Now, are 5 nodes for straight slopes (+30 nodes with More slopes) + 2 nodes for diagonal slopes + placer (and when you use too tieless track, all are 2-times). But, with paramtype2="userdefined", you could you use only 1 node for straight slopes, 1 node for diagonal slopes, and placer.

[Blockhead]

I thinked about it... and for slopes could be used "userdefined" for straight slopes too with mod More slopes.

I'm skeptical of a blank cheque like "userdefined". It would add a big split (conditional) right into the code, or more likely many different little conditionals peppered everywhere.

Now, are 5 nodes for straight slopes (+30 nodes with More slopes) + 2 nodes for diagonal slopes + placer (and when you use too tieless track, all are 2-times). But, with paramtype2="userdefined", you could you use only 1 node for straight slopes, 1 node for diagonal slopes, and placer.

This works okay in theory, where param2 would be the height out of maximum that the slope node represents. Again, not sure that's something to fit into "userdefined", but rather something like using param2 for snow layers*. Advtrains does use param2 for rotation a bit like 4dir, but also with _30 _45 and _60 "degree"^ nodes as well.

It uses a "conns" system where track pieces find the next track piece according to their rotation which is one of 16 directions, as well as a shape like a basic straight track, a turnout with 3 connections (straight in, straight out and diverging) or a diamond crossing where one input goes to one and only one other output. You already made the param2 budget add up to 8 bits with 4 rotation directions + 3 2-bit texture options, so now we have to choose one of them to throw away for the slope nodes.

I would actually prefer not to use param2 for so many uses, since if I wanted to add tracks with rusty rails for instance, then I would probably want them to have other properties that Advtrains doesn't yet model for tracktypes, like a slower speed restriction. Anyway, that's enough of the hypotheticals for now.


*Tangent: I checked and neither Minetest Game nor Mineclonia have snow layers. That's a bit weird given it's a feature in Minecraft and node levels are a feature. The only reference I found in my whole .minetest was in Farlands Reloaded actually.

^The degree figures are an approximation. The real values are atan(1/2), atan(1) and atan(2). The system predates the degrotate node type, but is still not replaceable with that due to needing different models for different rotations.

[MatyasP]

I'm skeptical of a blank cheque like "userdefined". It would add a big split (conditional) right into the code, or more likely many different little conditionals peppered everywhere.

I think that are some specific situations where will be needed paramtype2="userdefined" but I don't know that this is the right use.
For example, combination of "color4dir" and "texture4dir" will need to use it (when we don't to want use more than needed number of textures). We have 2 bits for rotation, so for color you could use from 1 to 5 bits and for texture (6-color_bits) bits.
Or for other specifical use, for example - upgrading of table or wall, gate that could be opened (every punch=one part of opening), or for ropes between sticks with anchor, or for phases of egg opening... or for fulfillment rate of wood pile[/quote]

This works okay in theory, where param2 would be the height out of maximum that the slope node represents. Again, not sure that's something to fit into "userdefined", but rather something like using param2 for snow layers*. Advtrains does use param2 for rotation a bit like 4dir, but also with _30 _45 and _60 "degree"^ nodes as well.

It uses a "conns" system where track pieces find the next track piece according to their rotation which is one of 16 directions, as well as a shape like a basic straight track, a turnout with 3 connections (straight in, straight out and diverging) or a diamond crossing where one input goes to one and only one other output. You already made the param2 budget add up to 8 bits with 4 rotation directions + 3 2-bit texture options, so now we have to choose one of them to throw away for the slope nodes.

I would actually prefer not to use param2 for so many uses, since if I wanted to add tracks with rusty rails for instance, then I would probably want them to have other properties that Advtrains doesn't yet model for tracktypes, like a slower speed restriction. Anyway, that's enough of the hypotheticals for now.

*Tangent: I checked and neither Minetest Game nor Mineclonia have snow layers. That's a bit weird given it's a feature in Minecraft and node levels are a feature. The only reference I found in my whole .minetest was in Farlands Reloaded actually.

I understand. For bits of userdefined of trucks - I think that question "how we will use 6 remaining bits for railway tracks" is for very long and great discussion.
Using layers is very good remark. Although we have paramtype2 = "leveled", it could be too used in "userdefined" or as more new variants of paramtype2. For example:
colorleveled - 16 levels, 8 colors
leveled4dir - 32 levels, 4 directions
textureleveled - 16 levels, 8 textures

When we would to have "userdefined", we will not to need more new paramtypes 2.

[MatyasP]

World with me is so complicated :D
I have more new ideas for paramtype2 and I think that this isn't my last idea for new paramtypes2
doors
colordoors
texturedoors

Bits:
0, 1 = 4 directions,
2 = left (0) / right (1)
3 = closed (0) / opened (1)
4 - 7 = 16 colors / textures

[MatyasP]

hordegrotate - some as degrotate but around one of horizontal axes (perpendicular of player),
colorhordegrotate - the same but too with color

texturehordegrotate - the same but too with texture (after will be added support for texture in paramtype2)

[Wuzzy]

I only have one idea for a new paramtype2 right now and it is "columnlike".

This is for nodes that are like stone columns or pillars. But also tree trunks or (straight) pipes, and the like. In general, this is for nodes that are oriented towards an axis, but more rotation doesn’t matter or can even be harmful as it would create ugly texture inconsistencies. For example, when you place a tree trunk with param2=0 on top of a tree trunk with param=20. (if I remember correctly)

A columnlike node can be rotated in 3 possible directions, one for each axis: X, Y and Z. It uses 4 bits with numbers 0-3, with number 3 being unused. For consistency, the number 0 should be used for the Y axis and be identical for paramtype2s facedir, 4dir, none. Number 1 should be for X, and number 2 for Z, or vice-versa (whichever seems more useful; must be decided by implementation).

Also, obviously there also should be a "colorcolumnlike" which is the same but with color support. This has the advantage that has access to many colors.

Rationale: When developing games, I have noticed that column-like nodes come up quite frequently. Especially tree trunks come to mind. Traditionally, games have been using facedir for such nodes but if you have an issue with bad texture seams due to rotation mismatch, a columnlike paramtype2 can greatly simplify the code and make it easier to enforce artistic consistency.

[MatyasP]

I only have one idea for a new paramtype2 right now and it is "columnlike".

This is for nodes that are like stone columns or pillars. But also tree trunks or (straight) pipes, and the like. In general, this is for nodes that are oriented towards an axis, but more rotation doesn’t matter or can even be harmful as it would create ugly texture inconsistencies. For example, when you place a tree trunk with param2=0 on top of a tree trunk with param=20. (if I remember correctly)

A columnlike node can be rotated in 3 possible directions, one for each axis: X, Y and Z. It uses 4 bits with numbers 0-3, with number 3 being unused. For consistency, the number 0 should be used for the Y axis and be identical for paramtype2s facedir, 4dir, none. Number 1 should be for X, and number 2 for Z, or vice-versa (whichever seems more useful; must be decided by implementation).

Also, obviously there also should be a "colorcolumnlike" which is the same but with color support. This has the advantage that has access to many colors.

Rationale: When developing games, I have noticed that column-like nodes come up quite frequently. Especially tree trunks come to mind. Traditionally, games have been using facedir for such nodes but if you have an issue with bad texture seams due to rotation mismatch, a columnlike paramtype2 can greatly simplify the code and make it easier to enforce artistic consistency.

It is good idea. But I think that existing facedir and colorfacedir are still usable although has longer bit length then needed for (color)columnlike. But I think that it is so simplier for add to Luanti engine then paramtype2 "texture...".

[MatyasP]

Bit definition for userdefined - for example:

Code: Select all

drawtype = "mesh"
paramtype2 = "userdefined",
bit_definition = {"model_texture","model_texture","model_texture2","direction","direction","direction","facing","facing"}
bit_def_properties{
facing="facing",
direction="direction",
model_texture="example_wood_"..number,
model_texture2="example_stone_"..number,
}

Bit definitions:
- direction: 6 variants (from "wallmounted" or bits 4,3,2 in "facedir")
- facing: 4 variants (from "4dir" or bits 1,0 in "facedir")
- texture: from texturepalette (as in proposed "texture4dir" and similar)
- texture2, texture3 ... if needed, similar as "texture" but with own definition (for overlaying textures)
- color: from colorpalette
- model_texture, model_texture2...8: similar as "texture" but defined for parts of meshes
- model_color, model_color2...8: similar as "color" but defined for parts of meshes
- pos_x, pos_y, pos_z: for movable meshes or nodeboxes in node (for example, more positions of candle in one node)
- degrotate
- objecthigh: for snow and similar
- objectsize_center, objectsize_corner, objectsize_wallcenter, objectsize_edgecenter (bigger size of object or nodebox by defined values)

[MatyasP]

colored_flowingliquid (16 colors palette) - but this need rules for color using
colormixed_flowingliquid (4 colors palette) - colors could be mixed (every from 4 palette colors "is there" or "isn't there")
colorflowing_flowingliquid (2 colors palette) - more variants between colors (100% color 1 ... 100% color 2), very good for combination of river water and sea water

[Linuxdirk]

param2 must die! This should all be meta data instead of being crammed into a tiny integer.

[LMD]

This should all be meta data instead of being crammed into a tiny integer.

I don't think a proper solution is as simple, metadata still has much larger overhead than a single byte.

But I do agree with the general notion. I think we will need a good API for "dense" metadata storage (essentially typed arrays) for use cases that require efficiency; and then a good SSCSM API so this data can influence meshgen on the client (but that's still far off).

In the meantime we will probably be adding some param2 types that generalize well (such as selecting matrix transforms), but we do not want to excessively specialize param2 as suggested here.

[MatyasP]

param2 must die! This should all be meta data instead of being crammed into a tiny integer.

param2 is great for simple using. But I think that more meta data solves some of said features better. And for advanced variants of the same nodes are necessary.

[Linuxdirk]

But I do agree with the general notion. I think we will need a good API for "dense" metadata storage (essentially typed arrays) for use cases that require efficiency;

Absolutely, yes. Modders should not care about how the engine stores the data they add via the API.

Especially when it comes to coloring and rotation. Something like THIS is an absolute mess:

Code: Select all

* `paramtype2 = "colorwallmounted"` for nodes which use the first
  five bits (most significant) of `param2` for palette indexing.
  The remaining three bits are describing rotation, as in `wallmounted`
  paramtype2. Division by 8 yields the palette index

Why isn’t there a simple meta:get_palette_index()/meta:set_palette_index()? Why do modders manually calculate values from bits?

[MatyasP]

But I do agree with the general notion. I think we will need a good API for "dense" metadata storage (essentially typed arrays) for use cases that require efficiency;

Absolutely, yes. Modders should not care about how the engine stores the data they add via the API.

Especially when it comes to coloring and rotation. Something like THIS is an absolute mess:

Code: Select all

* `paramtype2 = "colorwallmounted"` for nodes which use the first
  five bits (most significant) of `param2` for palette indexing.
  The remaining three bits are describing rotation, as in `wallmounted`
  paramtype2. Division by 8 yields the palette index

Why isn’t there a simple meta:get_palette_index()/meta:set_palette_index()? Why do modders manually calculate values from bits?

But I think that after will be added "node meta", we need the paramtype2 to save for compatibility with older mods.

What meta data types / options we could to use (every primary from 0 up to 255)?

1. color - from palette
2. rotation - from actual facedir
3. rotation_x
4. rotation_y
5. rotation_z - for 15° mesh rotations
6. texture - as texture from "texture4dir" and similar in my proposal in main post of this topic,
7. texture_front
8. texture_back
9. texture_top
10. texture_bottom
11. texture_left
12. texture_right - for texture only of each side if main "texture" will not useful as much as needed
13. nodebox_var - after it will be defined nodebox_vars (for example, different stairs types, created by nodeboxex)
14. model_var - the same but for models; I propose - if it will be possible - use it too for combination of models (thismod_01.obj & thismod_02.obj)
15. model_texture_# - for textures on parts of model (it could be for materials) from 1 to 9
16. nodebox_size - for size multiplier of nodebox, needs definition of place (nodebox_size= center / wallcenter (wall) / edgecenter (edge) / corner (corner) / defined_point) and main_size_value
17. model_size - as nodebox_size but for meshes
18. liquid_state - for liquids
19. light_emitation - for different light emitations of lamps
20. transparency - value of transparency
21. light_color - for different color of light emitation
22. size_x
23. size_y
24. size_z - for "cube" of snow and similar; for value from 0 to 127 is start in -0.5, for values from 128 to 255 is start in 0.5
25. api_defined_1
26. api_defined_2 - for special variants

[MatyasP]

This should all be meta data instead of being crammed into a tiny integer.

I don't think a proper solution is as simple, metadata still has much larger overhead than a single byte.

But I do agree with the general notion. I think we will need a good API for "dense" metadata storage (essentially typed arrays) for use cases that require efficiency; and then a good SSCSM API so this data can influence meshgen on the client (but that's still far off).

In the meantime we will probably be adding some param2 types that generalize well (such as selecting matrix transforms), but we do not want to excessively specialize param2 as suggested here.

Okay... this is good plan. Could I ask you, how much difficult is creating paramtype2 texture4dir? Could be it added to paramtypes2 before adds meta data for nodes?

[MatyasP]

But I do agree with the general notion. I think we will need a good API for "dense" metadata storage (essentially typed arrays) for use cases that require efficiency;

Absolutely, yes. Modders should not care about how the engine stores the data they add via the API.

Especially when it comes to coloring and rotation. Something like THIS is an absolute mess:

Code: Select all

* `paramtype2 = "colorwallmounted"` for nodes which use the first
  five bits (most significant) of `param2` for palette indexing.
  The remaining three bits are describing rotation, as in `wallmounted`
  paramtype2. Division by 8 yields the palette index

Why isn’t there a simple meta:get_palette_index()/meta:set_palette_index()? Why do modders manually calculate values from bits?

But I think that after will be added "node meta", we need the paramtype2 to save for compatibility with older mods.

What meta data types / options we could to use (every primary from 0 up to 255)?

1. color - from palette
2. rotation - from actual facedir
3. rotation_x
4. rotation_y
5. rotation_z - for 15° mesh rotations
6. texture - as texture from "texture4dir" and similar in my proposal in main post of this topic,
7. texture_front
8. texture_back
9. texture_top
10. texture_bottom
11. texture_left
12. texture_right - for texture only of each side if main "texture" will not useful as much as needed
13. nodebox_var - after it will be defined nodebox_vars (for example, different stairs types, created by nodeboxex)
14. model_var - the same but for models; I propose - if it will be possible - use it too for combination of models (thismod_01.obj & thismod_02.obj)
15. model_texture_# - for textures on parts of model (it could be for materials) from 1 to 9
16. nodebox_size - for size multiplier of nodebox, needs definition of place (nodebox_size= center / wallcenter (wall) / edgecenter (edge) / corner (corner) / defined_point) and main_size_value
17. model_size - as nodebox_size but for meshes
18. liquid_state - for liquids
19. light_emitation - for different light emitations of lamps
20. transparency - value of transparency
21. light_color - for different color of light emitation
22. size_x
23. size_y
24. size_z - for "cube" of snow and similar; for value from 0 to 127 is start in -0.5, for values from 128 to 255 is start in 0.5
25. api_defined_1
26. api_defined_2 - for special variants

It needs too:
- positions X, Y, Z,
- texture_swap
- texture_rotation (for example, 45° texture rotation on nodebox...)
- changable_text

Predefined numbers? No, better will be when meta data has "property_name" for each property and "property_type" (types of properties are above)!

Sorry, my brain has kitchen of meaning yestarday again :D

[MatyasP]

- actions - different actions (on_rightclick, on_punch, on_walk ... all too with limitation for some specific tool) - some as different tones / songs
- tone / tune - different tones or songs after punch or rightclick
- text_size - different text size of signs