Multiple textures for 1 node

[pud_V12.8]

Is there anyway to have multiple textures for 1 node type and have each node of that type display one of those on random?
I'm trying to decrease that "tiled" feel where every node has the same exact texture.

[rubenwardy]

The only way to do this currently is to either rotate the node, or to register a node for each texture

[pud_V12.8]

Will that ever be added in the future?

[SegFault22]

It would be nice if textures for nodes and items were controlled by metadata fields, but that would necessitate some radical changes, such as itemstacks having a metadata key-value store rather than just a single string.

If this were implemented, you could change the metadata table entry for the texture and "update" the node somehow, and its texture would be different. You could also make backpacks that can be colored, since the itemstack metadata would have to be expanded to a table in order to hold its texture metadata and whatever other metadata may be stored in itemstacks (other mods may already make use of item metadata, so it would be a bother to use that metadata string for the texture and it remain the only metadata field for itemstacks). This might break existing mods that use item metadata, but it won't break node metadata since a simple key/value entry is all that is needed for the texture (something like key "texture" and value "default_stone.png"). There may also be a way to maintain backwards-compatibility for mods which use the single item metadata field, for example by making ItemStack:get_metadata always fetch the same key/value pair in the key/value store, and a new method like ItemStack:get_metatable (or something like that) to get the whole table instead of the single string returned by the "old" method.

I would go learn C++ so I can change the engine code and submit a pull request which implements this fully, but I am busy with a complicated mod so it may be some time before I can do that.

[Christian9]

Different nodes and abms is has close has you can get

[SegFault22]

If I want to make a mod with a special machine that processes materials into a liquid form, mixes said materials in any arbitrary ratio, and produces items or nodes that retain that same ratio of materials, they would all have to have the same texture and dig groups. If I wanted each possible ratio to have its own distinct coloration based on the materials used to make it, I would have to register thousands or possibly millions of items and nodes, each entry for every possible mixture in the form of nuggets, ingots, dust-piles, rods, wires, plates, screws, all 5 tool heads, full-blocks, and dust-blocks. With some kind of meta-item/meta-node system, we would only need 14 registry entries, each entry being used for every possible combination of materials.

This wouldn't be easy to implement, but it would definitely be worthwhile. For this to be complete, all properties of meta-items/nodes/tools would be stored in metadata fields, which are loaded when they are needed by the client and server and not unless it is necessary. The simplest example would be the textures, set by a metadata value and loaded when the client needs to render whatever has the texture. With existing technology it would be relatively simple to generate textures with arbitrary coloration, instead of requiring the client to fetch millions of different textures from the server, (currently you cannot use such generated textures after the world is loaded/started, because you would have to register new items/nodes) but to make any use of it in such a meta-item/node system, the textures would need to be loaded in a dynamic fashion - when a meta-item is rendered for the first time, its texture would have to be processed and loaded into memory, and then it could be used for any item/node with the matching texture metadata value without having to process it again.

From the mod-side, a few base textures would be supplied, each having the proper shape/form and assigned to the right meta-item/meta-node registry entry, without any coloration and with balanced brightness and contrast. On the internal side, these base-textures would be processed with additional texture metadata to provide the "actual" texture to be rendered, which would then be loaded into memory and used.

The same principle of dynamic loading could also be applied to other properties, such as dig group level times, so that tools made of arbitrary mixtures of materials have properties determined by the materials "in the mix". We don't have to worry about material properties being combined wrong, (for example, copper-aluminium alloy is considerably strong, beyond a simple average of the strength of copper and aluminium by the mix ratio, due to the metal crystalline system) because all of the relevant properties would be set in metadata when the itemstack/node is created, which is handled by the mod as part of whatever process is used to create the items/nodes (like a tinkers' construct smeltery, except far more advanced, and not using "your stinkin' lava" for heating metals like tungsten to their melting point).

It would also be preferable that items with the same metadata be stackable up to their stack_max, but not stackable with items that have different metadata, but I am not sure if this feature already exists, because there is already a simple metadata field for itemstacks - it would seem wrong to either combine two stacks with different metadata into one with the metadata of one of those stacks, or simply disallow itemstacks with metadata to be stacked by more than one even if their stack_max is anything greater than one.

I do not know specifically how this would be implemented in code, and it may prove to be very difficult; but if I come back in 4 years and nobody has bothered to try, I will commit to make this, because it is very important. Minecraft could do something somewhat like this with the help of Forge, but it is not nearly as powerful as the aforementioned system. Minecraft is written in an object-oriented language, which simplifies the process of making new items/nodes/tools and referencing already existing definitions for relevant properties, but it still suffers from the problem of having to register millions of different items in order to allow arbitrary combinations of constituent materials without completely overhauling every part of the meta-item/meta-node/meta-tool system. Unlike Minecraft, the system I propose is far beyond the concept of object-oriented programming, and doesn't really have a good name-phrase yet - you are not referencing or extending existing code from an object to make a new object, but using existing code for a "base" object to make any possible variation at any time without having to write said variation into existence directly. It would probably be difficult to try to imagine what different uses there would be for an infinite quantity of possible material mixtures, just as it would be difficult to try to imagine the uses for fire for if you didn't know how to control it.

If Minetest will truly become better than Minecraft, it is likely that something like this (or anything which brings potential considerable to or greater than that which would be brought by this) will be part of such a transition, because a successful implementation of this system or something like it would create vast fields of "ecological niches" to be filled by new mods, and enable the creation of an uncountable quantity of new mods which are currently not imagined or even dreamed due to the limitations of the system as it is now - akin to how humans never imagined building steam engines to power industrial processes such as textile manufacture, before the first epochal event when humans learned to make stone tools and control fire to make use of it. This proposed system specifically, would allow new items/nodes/tools to be "created" while the game-world is running, but without using the same methods as are used now to create said items/nodes/tools, and their properties being determined by their metadata which can be set to anything. You would basically be able to create an infinite number of new ingots of metal, or even ingots of metal which are unique to a specific player or one or a few who know a good recipe, and the same with nodes and tools of all kinds. All that would have to be set statically is each "template" or "base" item/node/tool off of which all others are created.