Player_api: Give laying players a low selection/collisionbox

[paramat]

^ Killing player

^ Dead

^ Boxes are sized to diagonally laying player to not be excessively large, quite a nice fit

^ Dead player respawns, boxes reset

Attends to https://github.com/minetest/minetest/issues/7510

[paramat]

Updated.

[paramat]

Added documentation @SmallJoker

[SmallJoker]

Regarding different collision boxes. There could be more appearing, depending on the "mode" of the player. For that reason I think it would make more sense to change the format of the collisionbox parameter so that it's like animations. Each "mode" is then indexed by a string key - allowing a new public API function like player_api.set_mode(player, "lay").
EDIT: Or even keep the "animation" name and "collisionbox" name synced. Fall back to the "stand" collisionbox if none is specified for the current animation.

[paramat]

Good point, making it expandable for more box types, will try that.

[paramat]

Updated to improve 'reset_box' API.

Now i need to consider your other suggestion.

[SmallJoker]

Looks quite good already, although a structure like this would allow to assign a collisionbox to all available animations values, including custom ones:

player:set_properties({
	collisionbox = model.collisionbox[player_anim[name]] or model_collisionbox_default
})
-- Using a model definition like this:
{
	-- ... animations ...
	collisionbox = {
		lay = {-0.6, 0.0, -0.6, 0.6, 0.3, 0.6},
		sit = { ?? },
		-- whatever; custom animations?
	}
}

This would allow integrating it dynamically into set_animation and set_model. However, the old collisionbox definition would have to be converted to the new format (~3 lines in register_model)
Maybe I'm alone with this idea; feedback please.

[paramat]

It's quite a good idea but needs consideration.

[paramat]

I've ground to a halt on this due to the consideration the suggested improvements need, which i don't feel like attending to.
The suggestions are good and i feel this PR is therefore a little messy.

[paramat]

My approach here was entirely wrong, and SmallJoker's suggestion is going in the right direction.
I am interested in this again, and have transferred the MT issue to MTG #2742