Add 'multiface' paramtype2 to turn on/off faces of node (e.g. signlike, nodebox)

[Wuzzy2]

This is a feature request.
I suggest to add a new paramtype2 (NOT a drawtype!) in which the param2 determines which of the 6 sides of a node are rendered, and which aren't. There are 64 possible combinations, so this param2 needs values from 0-63, with the status each of the six sides being represented by a bit.

I suggest support for signlike and nodebox drawtypes.

For signlike, there will be multiple "signs" rendered on the 6 sides of the node instead of only one. One great use case for this is vines and other "sideways-growing" plants, so you can have multiple vines in the same node. This is about eye-candy more than anything else. Same goes for ladders. Here's an example for vines: https://satoshiupload.com/images/gNGZYUU3bo.png

For nodebox, it's the same thing, expect you enable/disable boxes per-side. This could be useful to have some kind of catwalk node in which you want to use param2 which sides have railings and which don't.

Emulating this with current nodeboxes or meshes is possible, but a huge pain, as you would have to register 64 (!) nodes for each possible on/off combination (2^6).

Use cases

• Have multiple vines, ladders or other flat wall deorations at different angles in the same node. Great for decoration
• Powerful catwalk nodes in which you can turn the railings on/off with param2
• Complex window corner node systems
• Possibly simplify some of your complex 3D nodebox collections down to a single node

Implementation

This feature request is currently fully implemented in #11383. All it needs is some approvals. Thanks for reading.

[v-rob]

Hmm, what if #9193 were implemented to work for nodeboxes (and selection boxes, collision boxes, models, etc) as well as textures? I think that, while 64 elements would have to be added to the alternates list (which could be done with a for loop easily enough), it could match all the abilities of this and more without the need for another specific drawtype. Thoughts?

[Wuzzy2]

Arrrrghhhhh... I meant to say "paramtype2", not "drawtype". I propose to add a new paramtype2, NOT drawtype. >_>
I will fix that in a minute.

I don't think you understand at all what this issue is about. This is !!!NOT!!! about textures at all. This issue and #9193 are completely different things.

So the basic idea of this issue is this: Normally, when you have a vines node, you would want to use a signlike drawtype. However, this drawtype currently limits you to put the vines only at one of 6 possible sides, e.g. left, right, front, back. If you want more sides, e.g. having vines at both the left AND right side of a node, you're currently out of luck. A workaround is possible, but it requires you to add a large amount of nodes for every possible combination.

Multiface to the rescue! Now you can put the vines at any of the 6 sides of the node and only need to change param2. Oh, and the same could be done for nodeboxes as well, but I explained that already.

Soo, what has this to do with #9193? Well, nothing, really. If you meant to combine the two somehow, remember that multiface already takes 6 out of 8 available bits, so ...

[v-rob]

No, I understand this issue, and I mean something else. I understand #9193 is about textures. So, let's say #9193 does this:

minetest.register_node("bla:bla", {
    paramtype2 = "tiles",
    tiles = {"bla.png"},
    alternate_tiles = {
        {"bla2.png"},
        {"bla3.png"},
        -- ...
    }
}

Now, what if it could be extended to do more than just textures, like nodeboxes (and a select few others) as well?

minetest.register_node("bla:bla", {
    paramtype2 = "alternates",
    nodebox = {...},
    alternate_nodeboxes = {
        {...},
        {...},
        -- ...
    }
}

That way, one new paramtype2 can kill two (or more) birds with one stone, because 64 nodeboxes can be added to the table with a simple for loop to implement all that this issue and associated PR can do and more. That's my idea.

[Wuzzy2]

One ability this specific paramtype2 could have in future is placement prediction (e.g. pre-enabling the face depeonding on which side you placed the node). My PR doesn't have that but it could be added, if wanted. It would be a reasonable extension.

Also, how would your solution work with signlike? I can't think of something.

Finally, my paramtype2 is limited from 0-63, meaning we still have 2 free bits. A "texture alternatives" paramtype2 will likely use the full value range 0-255 tho.

So, there are differences, it's not entirely equivalent.

[v-rob]

Well, "signlike" can be made using a nodebox. Really, "signlike" doesn't even deserve its own drawtype because something that works exactly the same can be done with a nodebox trivially. It would just be {-0.5, -0.4375, -0.5, 0.5, -0.4375, 0.5}, I believe.

As for placement prediction, that doesn't even require engine changes to do. Just do a connects_to = {"air"} and add a bunch of disconnected nodeboxes.

Finally, as for having two free bits, I'd assume that there would be an "alternates" paramtype2 for #9193, but also combinations, like "alternatesfacedir" and "alternateswallmounted". Assuming #11431 is merged, then there would be a "alternates4dir", which has 64 alternates and two bits used for direction, which is probably the main way that those two extra bits might be used for "multiface" anyway.

Anyhow, I'm not trying to say that your idea isn't good or anything (I like the usecase of vines, it makes a lot of sense), but I prefer more versatile solutions that can work for a lot of different things when possible over specific solutions.

[Wuzzy2]

As for placement prediction, that doesn't even require engine changes to do. Just do a connects_to = {"air"} and add a bunch of disconnected nodeboxes.

This is incredibly hacky and an abuse of connected nodeboxes. Also, don't assume that the world is usually filled with air. Some games might intentionally have a different kind of air-like node. Don't assume that air is the default for "empty node" (from a game perspective).

[v-rob]

I would not call it an abuse, it's a perfectly reasonable usage of the engine feature, although connecting to air could be improved. Anyhow, I don't see how multiface could connect to non-air any better than connects_to could. I guess it could connect to anything that is not "airlike", but that feels hacky as well and non-extensible.

[Wuzzy2]

Note that multiface is NOT intended to automatically connect to anything. The game should be free to choose the active faces freely, regardless of neighborhood.

[Wuzzy2]

Another benefit of this is that multiface could be nicely extended to other drawtypes, like firelike (which I did do).