Talk:minetest.register node

Splitting between "Engine" and "Default game" callbacks

This doesnt make sense at all, because the builtin Lua code is part of the engine. It is not a mod. And also the default minetest_game doesnt call any of these callbacks. --PilzAdam (talk) 13:58, 3 March 2013 (MSK)

There is a huge difference between the two, but perhaps you can help me figure out how to phrase it better if the existing titles and description aren't sufficient. The "engine callbacks" are called directly from the C++, and each one will always be called on the node if it is defined. They can be used to completely override all behavior that normally occurs as a result of the interactive event. If you set a node's "on_place" callback to do nothing, no block will appear in the environment when you try to place it from inventory, nothing will be removed from inventory, no "after_place_node" callback will be made, etc. The "default game callbacks" have no behavior by default and are called by the "engine callbacks", so they really do form a whole second layer of callbacks and if the applicable "engire callback" is overridden you cannot expect the "default game callback(s)" to be called at all. They can be used to add to the existing behavior, but not really to override/modify it. If you set a node's "after_place_node" callback to do nothing, all default behavior will continue as usual. In some cases the info passed to the second layer of callbacks is different as well. For example, "after_place_node" isn't passed the pointed_thing and "after_dig_node" is passed copies of the old node and metadata after the node is actually replaced using minetest.env. --Prestidigitator (talk) 13:40, 5 March 2013 (MSK)

Ah, now I get what you wanted to say by that. The problem in calling it "engine callback" and "default game callback" is that all these callbacks are called by the engine. The difference between them is just that the latter ones are nil by default. I will fix it in the article --PilzAdam (talk) 18:52, 5 March 2013 (MSK)