[Question] Player Height and Slab thickness and Sneaking? [Answered]

[sirrobzeroone]

So I have been playing around with:

Code: Select all

player:set_properties({collisionbox = {-0.3, 0.0, -0.3, 0.3, 1.7, 0.3}})

I think I've come across an oddity or maybe a gap in my understanding. So Slabs have a collisionbox which is half a node high:

Code: Select all

		node_box = {
			type = "fixed",
			fixed = {-0.5, -0.5, -0.5, 0.5, 0, 0.5},
		},

So I set player height to 1.49 and would expect that I can now walk under a space were its 1 empty node and then a slab in the top half of the next node up, I can get in under the first slab then gets stuck on the 2nd slab ina row... (think low tunnel the player can walk through or hobbit house)

Okay noticing the above was for nodebox I tried adding specific collision:

Code: Select all

		node_box = {
			type = "fixed",
			fixed = {-0.5, -0.5, -0.5, 0.5, 0, 0.5},
		},
		collision_box = {
			type = "fixed",
			fixed = {-0.5, -0.5, -0.5, 0.5, 0, 0.5},
		},

Same test still a fail. Then I tried incrementally setting the player height down until it worked which occured at a height of 1. Event ried 1.01 still failed :)

Question do node_box's automatically fill the whole node for the purposes of collision? If they don't want am I doing wrong here? :)

Thanks again for the help.

[Skamiz Kazzarch]

So I added your first line of code to an items on_use and changed the height to the mentioned 1.49, then tried walking though this:

Result: Could pass through with no issue.
Wroth mentioning: This is a custom game where I didn't otherwise touch the player properties at all, so my guess is that some other code from MTG (if that's what you are using) is interfering. (on version 5.3.0 btw)

As for nodebox colision, that usually bahaves as expected exept for two conditions:
1) When the box gets too big. (when the side is more than 1 node away from it's original node) collision starts to jitter/fail.
2) When sneaking, the snaping which prevents you from going over the edge uses a simplified nodebox. But that's only relevant to more complex shapes.
Neither of these should be an issue with a simple slab though.

Hope that helps at least a little.

[sirrobzeroone]

Thanks Skamiz Kazzarch really appreciate the effort you took to test.

I dropped back to devtest and all worked as expected, so stepped back up to base MTG and ran some more testing and finally worked it out.

I'm using crouch (shift) to set the players height property just a hair lower so they can fit through that space when crouching down. What my guess is as to what is causing the issue is the edge detection in the crouching is detecting the slab above the players head as an "edge" and naturally prevents them from moving forward when crouching. If I hard set hieght to 1.5 works as expected as soon as use the crouch 1.5 no go.

I'm hoping that crouch detection is controlled by lua somewhere so I'll go see if I can find it and confirm if thats definitly what is causing the issue.

Thanks again for the help.

Edit: No dont think its that either strange behaviour, press crouch down and enter the low tunnel it stops/jams at end of first low slab. If I then let go of crouch while pressing forward it sort of jumps over the "spot" and then re-crouch I can then walk all the way through as expected which is a long low tunnel - Ill keep testing

[sirrobzeroone]

I think I've isolated this is something odd in the crouch behaviour and the way it ineracts with slabs.

I stripped my mod right out of the equation and basically just added this to the player_api>>api.lua code were crouch is defined about line 118

Code: Select all

			-- Determine if the player is sneaking, and reduce animation speed if so
			if controls.sneak then
				animation_speed_mod = animation_speed_mod / 2
				player:set_properties({collisionbox = {-0.3, 0.0, -0.3, 0.3, 1.45, 0.3}})
				player:set_properties({eye_height = 1.37})
			end

adding just that then pressing and holding sneak key down and trying to walk under slabs results in jamming halfway along the first slab. The above code acts like a permenant switch so if you let go of shift back out and then run through without holding shift down it works as expected. Make sure you have your slabs brackets on both sides by pillars of solid nodes otherwise you can slip along the open edge and everything appears okay.

However can also toss these lines in down walk/stand lines 131 to 140:

Code: Select all

				if controls.LMB or controls.RMB then
					player_set_animation(player, "walk_mine", animation_speed_mod)
				
				else
					player_set_animation(player, "walk", animation_speed_mod)
					player:set_properties({collisionbox = {-0.3, 0.0, -0.3, 0.3, 1.7, 0.3}})
					player:set_properties({eye_height = 1.47})
				end
			elseif controls.LMB or controls.RMB then
				player_set_animation(player, "mine", animation_speed_mod)
			else
				player_set_animation(player, "stand", animation_speed_mod)
				player:set_properties({collisionbox = {-0.3, 0.0, -0.3, 0.3, 1.7, 0.3}})
				player:set_properties({eye_height = 1.47})

With the above code all in you can then test the second scenario which is hold shift down walk forward until jammed then let shift go while still walking forward you'll stutter over something then you can hold shift down again and you can then walk all the way along.

At the moment Im leaning towards some form of engine bug? since sneak seems to built into the engine core not in the minetest game itself....unless I missed something? very possible :).

I'll poke around a little more but Im not finding a lot of lua code that adds the crouch/sneak functionality. If I find nothing else I'll raise an issue and see if a dev or someone can look at it.

Edit: Should have added I coded a workaround for my purposes, hopefully I've made it tight enough it cant be exploited but its a workaround.

[Skamiz Kazzarch]

Played around some more and I think I have figured it out. Basically it's this:

If any node in the positions where the fences are has a collision box then the node at the bricks position is considered collision-less for the purpose of sneak snapping (not for the purpose of colliding though, obviouslly). Which means that sneaking won't prevent you from going right off the birick block.
It also means that in any of these three scenarious:

the brick is treated as if it wasn't there, so sneaking is preventing you from falling in that 'gap'.
The only way this behaviour releates to collision boxes is that if your height is <=1 then the check which prevents a node from having sneak collision goes only one node high instead of two, so you can sneak under the slab and trapdoor, but not through the door which has collision in the node directly above the brick.

This whole thing is a result of the fact that for the purpose of determining if you can sneak snapp to a node it is assumed that all nodes with collision are a full 1*1*1 cube.
And this simplification itself is probably for optimization purposes. Since with complex nodebox shapes and all the possible rotations it would get costly to determine for all the possible snapping positions.

disclaimer: This is all conjuncture, I don't actuall know any engine code.

[sirrobzeroone]

Played around some more and I think I have figured it out.

Thanks Skamiz Kazzarch again for taking the time to test and investigate. I always get nervous it's something dodgy I'm doing :).

I think I might raise this as an issue now given we are both seeing the same behaviour (Unless you would like too? I think you have done the heavy lifting with testing.). I think your hypothesis is correct or very very close. Not sure I can expect a fix given it could cause performance issues and the workaround fix I have in Lua isn't that untidy, might be a little irritating for the player but I think i can refine it more and smooth it out so players wouldn't notice.

Basically my workaround at the moment is I only allow the collision box to be set to 1 high when (probably excessive checking):

• the players velocity has dropped to <0.5 kph (I always get some slight speed rounding error seems to be tied to some slight Y jitter)

• The player is pressing up (forward - W)

• the node in front and up one is in the group "slab"

• player is pressing holding down the crouch button

All that is true then there collision box momentarily (for 0.05 sec) gets sets to 1 high, I have these checks occurring via globalstep as I'm using it for player animation setting.
I probably need to add a check that the block directly in front is also drawtype == "airlike" or some smarty could block themselves in and jam themselves in a 1 high collision box loop and make themselves harder to hit....I think i'd be impressed with the dedication that would take :).

I can probably fairly easily work out from the data metrics I'm already gathering from the player if it would be allowable for them to be say be looking forward but be moving sideways and the sideways node is a slab and they are currently likewise jammed. The above fix makes a very slight visual pause hardly noticeable when walking through a low tunnel and crouched (due to near 0 velocity needed to trigger it, I could probably up velocity limit a little which would smooth it out even more). I do find it odd it only occurs for the first slab not any slabs after that?

Currently the fix I have is wrapped up in the next version of my fly_swim mod (which will now have crouch and climb animations as well) but I'll excise the code and make it standalone and post it back here. It's not perfect but someone else may hit this problem in the future and it will give them a start to work from.

[Skamiz Kazzarch]

I think I might raise this as an issue now given we are both seeing the same behaviour (Unless you would like too? I think you have done the heavy lifting with testing.).

You are welcome to do it yourself, since it doesn't really bother me. I actually find it interesting, since it means that in a jump'n run map I can selectively disable the playes ability to snapp to certain nodes, making the jumps significantly harder.

I do find it odd it only occurs for the first slab not any slabs after that?

Since at the first slab you go from a node which has snapping collision to one which doesn't, sneaking prevents you from 'falling' in. But after that, as far as sneak snapping is concerned, you are basically floating, since you go from one node without collision to another node without collision. The game doesn't see any nodes it could snapp you to, so it lets you go forward.

[sirrobzeroone]

I do find it odd it only occurs for the first slab not any slabs after that?

Since at the first slab you go from a node which has snapping collision to one which doesn't, sneaking prevents you from 'falling' in. But after that, as far as sneak snapping is concerned, you are basically floating, since you go from one node without collision to another node without collision. The game doesn't see any nodes it could snapp you to, so it lets you go forward.

Thanks again, I should have remembered or connected that, Krock pointed that out to me when i was messing with using mesh nodes to generate a map. I lost the node optimization the engine does with normal nodes so they become essentially one big long node rather than individual nodes which when using mesh nodes is what happens. Needless to say performance went way down using mesh nodes for map generation - ditched that idea quick smart.

So essentially we sneak-snap to the edge of the long node/mesh but once over that barrier the snapping see's no more edges as they don't exist as the engine has optimized the many nodes into one big long node.

Thanks for the explanation that has put all the pieces together in my head and it makes perfect sense now :)

[sirrobzeroone]

Lodged an issue but noted it maybe better to simply document the behaviour in the API as it can add interesting game behaviour.

https://github.com/minetest/minetest/issues/10706

[Linuxdirk]

Lodged an issue ...

And despite all the proof and testing done here the only label is "unconfirmed bug". Classic.

[sirrobzeroone]

Bit disappointed didnt find an unknown bug or at least theres already a very close relative :(

https://github.com/minetest/minetest/issues/1229

[Skamiz Kazzarch]

If you apply a change to the players collision box size when they press sneak and set the collision box to say 1.5 blocks high the player still won't be able to walk under a space that is 1.5 nodes of empty space. ie the player will "catch" on the slab above.

You still misunderstand the issue. It has nothing to do with changing the collision box or being stuck under things. You aren't bumping against the slab at all. As far as collision goes, everything is working perfectly.

What is actually happening is that if the node at your head position has any collision, regardless of wheter you touch it at all, then the node under your feet is treated as if it weren't there. Notice that in my previous screenshot I included a door as something you can't sneak through, even though there is nothing above you, but since the door has collision (which doesn't obstruct you from moving through), it treats the brick as if thery didn't have collision, which prevents you from sneaking through.
Here's another example:

Even though there isn't anything preventing you from walking through you can't sneak through, since sneaking prevents you from falling in the 'hole' that is percieved there.

The "duplicate" is actually a completely unrelated issue which allows you to clipp up into nodes due to the automatic step up and has nothing to do with sneaking..

[sirrobzeroone]

So its more like we collide with an upper collision box which then programmatically removes the node on the ground infront of the player and because we are sneaking and sneaking stops us from falling in holes we are effectively on an edge and stop. I know thats what you wrote just rewriting it to make sure Ive understood.

So two pieces of code doing exactly what they are meant to just combing in a way that is not really what you would expect.

Thanks again, I'll update the issue to clarify if I have got that correct now.

[Skamiz Kazzarch]

So its more like we collide with an upper collision box which then programmatically removes the node on the ground infront of the player ...

Exactlly. Here yet another example:


It's clear that you can't stand on the bricks becaue there is the metal block in the way. Since sneak snapping can teleport you a little bit, it could move you to the position anyway. To prevent that from being possible the game say that for the purpose of sneaking the bricks have no colision at all.

Which works just fine in this example, since all involved nodes are full cubes, but starts being inaccurate once you add nodeboxes to the equation, since the algorythm just asumes that every node with collision is a full cube.
(Again this all is just conjuncture on my part.)