* Provide tool and digger to get_node_drops
This gives games/mods the ability to modify node drops depending on item
and/or player metadata without overriding node_dig or other workarounds.
* Copy wielded item to prevent modification in get_node_drops
* Also pass node pos to get_node_drops
Allowing properties of the node and its surroundings to affect node drops.
* Copy pos to prevent modification in get_node_drops
Co-authored-by: Lars Müller <34514239+appgurueu@users.noreply.github.com>
* Don't pass empty item stack to get_node_drops if wielded is nil
---------
Co-authored-by: sfan5 <sfan5@live.de>
Co-authored-by: Lars Müller <34514239+appgurueu@users.noreply.github.com>
behavior change: newly generated blocks are no longer momentarily activated.
this shouldn't matter for anyone and did not consistently apply to all blocks anyway
addresses issue from #15902 for new maps(!)
The currently established convention uses `NS` for "translation no-ops", i.e., it will be collected by a string-collecting utility but not be translated by Luanti at this place.
We don't want to mislead modders with this example into using `NS` for plural forms instead, breaking with the established convention and making use of automated tools harder.
See also: https://github.com/minetest/modtools/pull/11
We are being lax here, but the glTF specification just requires that "when the weights are stored using float component type, their linear sum SHOULD be as close as reasonably possible to 1.0 for a given vertex"
In particular weights > 1 and weight sums well below or above 1 can be observed in models exported by Blender if they aren't manually normalized.
These fail the glTF validator but Irrlicht normalizes weights itself so we can support them just fine.
The docs have been updated to recommend normalizing weights (as well as documenting the status of interpolation support).
Weights < 0, most of them close to 0, also occur. Consistent with Irrlicht, we ignore them, but we also raise a warning.
