Add ability to update node/craft/tool/entity properties during runtime about minetest HOT 18 CLOSED

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

Yes, no problem, this is preferable to a complex and problematic alternative.

Such feature required for implementation of animated furnace like objects, and objects with some kind of progress indication on their sides.

Textures can be changed by replacing with other nodes. Its not a high priority need.

👎

from minetest.

We can change facedir of node by changing it's param2. How about to add to node defenition 'node_states' field as some table with alternative drawtypes and tiles for node and select needed by using param2?
Something like:

    node_states = {
        {
              drawtype = "mesh",
              mesh = "node_mesh.obj",
              tiles = { ... }
        },
        {
              -- here will be used default tiles
              drawtype = "nodebox",
              nodebox = { ... }
        },
        {
              -- default drawtype with another tiles
              tiles = { ... }
        }
    }

from minetest.

This issue should be closed.

The use cases that were stated are:

• animation: Obsolete. We already have animated textures
• Allowing to change node textures without changing the node itself: This is reasonable, but I don't think node definitions need to be overwritten all the time for this.

In fact, I have posted a different idea to make node textures changable, namely, by adding a new paramtype2: #9193

I summarize:
This suggestion is ancient, OP hasn't replied for >8 years, the suggestion is partially technically obsolete, the suggestion has enormous design implications that would cause huge disruption, the only valid stated use case is for changable node textures, and for this use case there's already a more lightweight alternative suggestion on the table.

Therefore, I recommend to close this isse.

from minetest.

If you could update the node definition, then every node of that kind would change. This is kind of a limitation of the design. If everything would be made changeable by an overloading mechanism, that would probably be too heavy. And selecting just a single feature (like the texture) is silly, because why would exactly that feature be the one that should be updateable? Anyway, this is a valid deficiency; just not trivially improvable.

from minetest.

Related to #1118

from minetest.

@Novatux can you rebase and finish this PR ? :)

from minetest.

👍 I would love to see this. A big limitation for me at the moment is not being able to dynamically set the tooltip description on items.

I have been working on a locked door and key mod and would like to be able to have the description text change from "Key" to "Key to nameofdoor".

from minetest.

@falsechicken That's separate from meta nodedef. It should be easier to implement though.

from minetest.

Can we close this due to its age and because #2887 is similar?

from minetest.

@paramat: Since this is the older issue the new one should probably be closed instead.

from minetest.

Fine by me.

from minetest.

I am thinking of implementing tool capability overrides. What do people think of having a "toolcaps" key with a value that is a JSON-serialized toolcaps table?

@sfan5 suggested a different approach in IRC:

+sfan5 ╡ wouldn't it be nicer to be able to define several toolcaps ahead of time and have "toolcaps" just be an int
╡ would be less flexible but nicer imo

Which I think removes too much flexibility.

from minetest.

@rubenwardy I want to add stuff to serialized item metadata, but it looks like if I add anything after the meta key/value pairs it will append garbage to the end of the last pair, from the point of view of older clients.

from minetest.

Though I suppose I could just put the serialized stuff in a special-use meta field.

from minetest.

PR for tool capability overrides: #5612

from minetest.

#5612 merged.

from minetest.

@paramat: "Supported by core dev" lol why? Was this label added by mistake?

from minetest.

I'm going to go out on a limb and say that the label is a mistake. If it isn't, it can be added again. However, this feature is essentially infeasible at the present time with Minetest's current capabilities (metadata is bad for the job; it might be possible with SSCSM, but that's not a feature yet, so irrelevant to this issue), so closing.

from minetest.