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