Digging group capabilities of a custom hand item are not used if the built-in hand has a cap for the same group

[Sneglium]

Luanti version

Luanti 5.10.0 (Linux)
Using LuaJIT 2.1.1703358377
Built by GCC 13.2
Running on Linux/6.8.0 x86_64
BUILD_TYPE=Release
RUN_IN_PLACE=0
USE_CURL=1
USE_GETTEXT=1
USE_SOUND=1
STATIC_SHAREDIR="/usr/share/luanti"
STATIC_LOCALEDIR="/usr/share/locale"

Operating system and version

Kubuntu 24.04

Summary

If the player's hand is changed (i.e. their hand inventory list has a different item at index 1 than '') and the new hand item has entries in groupcaps which are also present in the groupcaps of the builtin hand, the new item's properties for that digging group will be ignored in favour of the builtin hand's capabilities.

If the same item if wielded (held in a hotbar slot and selected), this will not be the case, and the new item's groups will correctly take precedence.

Probably related: #5200, which has been closed as completed so this might be a regression.

Steps to reproduce

Create a mod called hand with the following init.lua, and load it into a Development Test world:

core.register_item("hand:hand", {
	type = "none",
	tool_capabilities = {
		groupcaps = {
			crumbly = {times={[1] = 0.1, [2] = 0.1, [3] = 0.1}, uses = 0, maxlevel = 1},
			cracky = {times={[1] = 0.1, [2] = 0.1, [3] = 0.1}, uses = 0, maxlevel = 1},
		}
	}
})

core.register_chatcommand('hand', {
	func = function(name, param)
		local player = core.get_player_by_name(name)
		
		local handitem
		if param == 'reset' then
			handitem = ''
		else
			handitem = 'hand:hand'
		end
		
		local inv = player: get_inventory()
		inv: set_size('hand', 1)
		inv: set_stack('hand', 1, ItemStack(handitem))
	end
})

Dig some dirt with the unchanged builtin hand, and also note that you can't dig stone. Next run the /hand command, and try both again. Stone will dig in the expected 0.1 seconds, but the digging speed for dirt will be unchanged.

Now run /hand reset, and then /giveme hand:hand and try again while holding the hand item. It will behave as it should and dig the dirt quickly.

[Sneglium]

Actually it seems like a lot of other properties are not applied correctly/applied inconsistently, like the new item's range seems to only apply when wielding another item but not with an empty hotbar slot, and on_use/on_place/etc callbacks of the new hand aren't called the way they would be if set on the builtin hand. I might have to change the issue to be more general

[cx384]

By replacing crumbly with crumbly2 (in the item and node definition) or adding

core.override_item("", {tool_capabilities = {}})

the problem disappears.

[Sneglium]

My workaround for now is to have the builtin hand only contain the callbacks and not the capabilities, and use a second custom hand item as the 'default' which has the basic digging capabilities that survival players are meant to have.