Method for In-game node texture changes

[Extex101]

So first of all, get the fact into mind about how Minetest does animated textures on nodes.
How it works is it moves the image to create the animation.
My idea is to use the same method to dynamically change a nodes texture in-game

Setting the offset of the image via a number

        tiles = {
		{
			name = "texture.png",
			data = {
				type = "vertical",
				aspect_w = 16,
				aspect_h = 16,--basically the same as animated
                                start_at_frame = 1,
                        },
		}
        }

And you can set the offset via lua

Could possibly close the oldest open issue #36
Other issues (duplicates of 36) #323 #2887 #7848

[benrob0329]

So, being able to store the animation frame in meta?

[Extex101]

Yeah, but optional and it doesn't increase
So you can set it at will opening up the ability to change a nodes texture in-game

Also maybe being able to choose which texture uses what meta value so you can have multiple textures that can be altered in different ways

[paramat]

Related #2746

Storing in meta is problematic (which is the problem that has halted 'meta-set-nodedef') as meta is per-node so is very intensive, you would not be able to use this for many nodes. -1 for using meta.
So the chosen tile would probably be specified by param2, you would not be able to use rotation or hardware colouring as well.

This doesn't close #36 as that is for many properties.

[SmallJoker]

From #36:

But to change property such as texture you need to remove node from the world and place another node with desired property on the same place.

This request is already covered in that old issue.

[paramat]

I don't think this is a duplicate, as this also contains a suggestion for a different implementation.

[Extex101]

Okay maybe not meta but something else could be implemented

[style-nine]

Am I right in assuming that the most notable use case would be the furnace, so that you could animate the front of the node as well as the image in the formspec without needing several nodes and liberal use of swap_node()? If so, this could have a huge impact on mods like Technic.

[tacotexmex]

the chosen tile would probably be specified by param2, you would not be able to use rotation or hardware colouring

I’m just wondering what the upper limit of this param cramming looks like? When is it regarded no longer useful to add more features to?

More features added means even harder choices between node param2 features. When is it time for, say, param3? Or do we stop adding features when param2 is completely crammed? I don’t mean to come off too strong, sorry. I’m genuinely curious!

[paramat]

There is no harm in adding new uses for param2, if they are justified. Modders just have to work within the limitations and make the choice of what to use param2 for, instead of having unreasonable expectations and wanting to use everything at once.

[sfan5]

see also #6663

[tacotexmex]

"should I use hardware coloring or meshoptions for grass?"

To expect availability of hardware coloring and meshoptions at the same time is not unreasonable though. I’m sure there are several more reasonable examples. It’s too bad, because it stifles the uses to small, individual cases instead of being able to using it on a systematic scale. Now I’ve said my piece, sorry for the offtopicness.

[Extex101]

Coming back to this idea, I thought maybe it could be done as a paramtype2, similar to the way the color paramtype works