Inconsistent rounding with position at negative y levels (y < 0)

[fnetX]

Luanti version

(Flatpak release)
Luanti 5.14.0 (Linux)
Using LuaJIT 2.1.1756211046 (OpenResty)
Built by GCC 15.2
Running on Linux/6.12.57 x86_64
BUILD_TYPE=Release
RUN_IN_PLACE=0
USE_CURL=1
USE_GETTEXT=1
USE_SOUND=1
STATIC_SHAREDIR="/app/share/luanti"
STATIC_LOCALEDIR="/app/share/locale"

Operating system and version

Linux Mint Debian Edition 7 (based on Debian 13)

CPU model

Intel Core i7-5650U

GPU model

No response

Active renderer

No response

Summary

Naive calculations based on player position seem to suffer from rounding errors. I'd expect the following code to provide the node below the player:

pos = player:get_pos()
pos.y = pos.y - 1
n =  core.get_node(pos)

However, it does not work reliably when y < 0. While this can probably be worked around, it seems that several mods suffer from this problem and the behaviour is confusing, to say the least. I am not sure if it can be fixed in the engine, but I think there should be a canonical way to do such calculations, and I found nothing related to this in the docs.

Background and use case

I was investigating that several mods don't work properly on my server. TNT run and sumo minigames sometimes don't kill players or let TNT fall.

Upon investigation, I also found that other mods like worldedit are not consistent: The behaviour of which node is selected differs based on the y value. I recorded a demonstration in which I additionally demonstrate that the selected node is not even deterministic based on the node I stand on. If I fly, go down slightly, and disable fly, I can trigger that I'm apparently on a different level. See demonstration video:

we-node-glitch.webm

Steps to reproduce

I created a demonstration world and a simple mod that demonstrates the behaviour.

init.lua:

core.register_on_joinplayer(function(player, last_login) checkfn(player) end)

function checkfn(player)
	pos = player:get_pos()
	pos_get = pos
	pos_get.y = pos_get.y - 1
	node_name = core.get_node(pos_get).name
	core.chat_send_all("y: " .. tostring(pos.y) .. ", below is: " .. node_name)
	core.after(1, function() checkfn(player) end)
end

mod and world are attached. I recorded another video (with audio comments):

posglitch.webm

Likely related

#6818
#1154
#14757

[appgurueu]

I'd expect the following code to provide the node below the player [...]

I would not. player:get_pos() returns the "bottom center" ("foot") position of a player (though at a glance this does not appear to be documented?). Thus, it is pretty much precisely on the edge between the node you're standing on and the node above it. If you subtract exactly 1, you end up on the edge between the node you're standing on and the node below it.

It is possible that the engine does something funky for this edge case. If it is doing a naive rounding, it depends on whether 0.5 and -0.5 are rounded to 1, 0 or 1, -1. In the latter case, you would probably be seeing the inconsistency you report.
This edge case is fixable, and probably should be fixed despite a small risk of breaking mods relying on it. It should also be documented precisely: Is a cube taken to be half-open towards larger or smaller coordinates?

That said, this is a pretty brittle way to try to find the node below the player to begin with; it suffers greatly from rounding errors and such. It also only works for nodes that are at least 1m high to begin with: If you stand on a 0.5m slab, the node below the slab will incorrectly be reported.

The following logic would be more robust, at least for nodes that are fully contained within the 1m³ standard cube (and at least 1e-3 m high)

pos = player:get_pos()
pos.y = pos.y - 1e-3
n =  core.get_node(pos)

You just subtract a very tiny number (1e-3) to enter the node right below the feet ever so slightly.
(This is however still not perfect when it comes to nodes higher than one node, e.g. doors.)

So in summary, I think there are two things for us to do:

1. Document that player:get_pos() is a "feet position".
2. Check how get_node rounds, potentially fix it, and document it.

Meanwhile, mods should ideally try to avoid the edge case of querying nodes at positions that lie perfectly between two different nodes.

[appgurueu]

Alright, the logic is effectively this:

static_cast<s16>(coordinate + (coordinate > 0 ? 0.5 : -0.5))

The cast is a truncation to zero. So: If the coordinate is above 0, it will be rounded up; if it is <= 0, it will be rounded down. So it rounds towards +- infinity. In the earlier example, 0.5 -> 1, -0.5 -> -1. Judging by the code, this seems to be intended.

Personally I find it odd, because it means that the "canonical cubes" are very inconsistent: A cube at the origin, from -0.5 to +0.5, is open in both directions: It is effectively the cartesian product (-0.5, 0.5)³. Whereas a cube at (1, 1, 1) +- 0.5 instead is the half-open cube [0.5, 1.5)³. But at a cube at (-1, -1, -1) +- 0.5 is the other way around, (-1.5, 0.5]³...

#6818 is a red herring, I think. I see how you could arrive there via a blame, but this rounding logic (see e.g. floatToInt) is older. That PR just concerned itself with float vs double. #14757 deals with a similar topic, but math.round is not used in the C++ get_node_raw implementation.

Edit: This dates all the way back to the initial commit, 4e249fb#r173911731, 15 years ago 👀

I'm gonna say there's at least a documentation bug here, the edge case and the player position ought to be documented properly.

Whether changing the rounding is a good idea still needs to be discussed. I would advocate for rounding towards +infinity, so -0.5 -> 0, 0.5 -> 1, which gives cubes that are consistently open on the high side, so (x, y, z) + [-0.5, +0.5)³.

The question is just what the impact is. But if mods tend to be inconsistent as you say already, then there's a good chance we'd be fixing more end user bugs than we introduce by fixing the underlying engine behavior.

[sfan5]

Upon investigation, I also found that other mods like worldedit are not consistent: The behaviour of which node is selected differs based on the y value.

FWIW WorldEdit just uses vector.round, which defers to math.round:

luanti/builtin/common/math.lua

Lines 32 to 41 in 42906db

	function math.round(x)
	if x < 0 then
	local int = math.ceil(x)
	local frac = x - int
	return int - ((frac <= -0.5) and 1 or 0)
	end
	local int = math.floor(x)
	local frac = x - int
	return int + ((frac >= 0.5) and 1 or 0)
	end

...which I'm not sure what exactly that does but it was changed intentionally in #14757 and also some stuff was discussed when it was added in #10803.

In any case we should also make sure the engine and math.round are consistent.

[appgurueu]

By the unit tests I can tell that math.round is consistent with this - it rounds away from 0, towards +- infinity (which is also documented):

assert.equal(11, math.round(10.5))
assert.equal(-11, math.round(-10.5))

The implementation is just a bit more complex because care must be taken to avoid deferring to some unspecified FPU rounding resulting from arithmetic.

So indeed, if the rounding were to be changed, math.round would probably also need to be changed, good point.

That might make it nasty enough that it's not worth doing, and we should just document how it is instead then.

We could also consider an alternative math.roundup / vector.roundup or something that rounds towards positive infinity to alleviate the issue?

[fnetX]

I'd expect the following code to provide the node below the player [...]
I would not.

I don't have any experience in game engine design or with how Luanti works. However, I do have experience in user research and UX. The data I have confirms that at least 4 independent people (3 mod developers and me) seem to have made false assumptions about how a player position is returned. And especially that standing on the same block can return different y levels seem to be unexpected.

returns the "bottom center" ("foot") position of a player

Still, I would sugest that feeding this position into get_node always returns the block the player is standing in. Because the player is standing "On top" of a node. As far as I understand your explanation, the current behaviour can sometimes return "the player stands inside the floor" due to the rounding behaviour, which seems really odd.

From the mod's perspective, I suggest to provide a simple and reliable way to determine the node the player is standing on (e.g. for checking if it needs to be removed, if it should kill the player, trigger some action etc) and the node the player is standing in. You can choose to not change the behaviour of the current code if you introduce other convenient helpers that provide this information and document it.

I am not sure about the best behaviour for slabs and other half-height blocks. My intuitive assumption would be that both return the same node basically, but I don't have a strong opinion on that.

The question is just what the impact is. But if mods tend to be inconsistent as you say already, then there's a good chance we'd be fixing more end user bugs than we introduce by fixing the underlying engine behavior.

I agree to this. Any code that is currently affected by this is either broken (the examples I demonstrated), or it depends on flaky behaviour and can already deal with both values. As far as I can see, the only thing you could break is if someone already applied explicit fixes for this or if you used this to create a pseudo random number generator :)

[yl-whosit]

This rounding also affects client physics: place 3x3 platform of groups = {disable_jump=1} node under a single climbable = true node in the middle. Depends on how you arrive on top of the platform, sometimes disable_jump nodes can prevent you from climbing.
I tried investigating this by checking my position with core.chat_send_player('whosit', string.format("Your Y: %s", core.get_player_by_name('whosit'):get_pos().y)) (you must use .y instead of dump(), because dumping seems to round the numbers...)

I don't have more exact reproduction, but the way you "arrive" on top of the node changes your exact y when standing on top of it:
When I jump and land on a block, my Y gets set to -y.499 - client considers player being inside a climbable node and allows climbing.
If I walk up the stairs from below, my Y is exactly -y.5 - client considers player standing on a disable_jump node and it's impossible to climb a climbable node directly above.

So this rounding affects client logic/gameplay too.

(this inconsistency was reported by players having a rope in a mineshaft with some "mushroom pores" (full-node blocks preventing fall damage) at the bottom - sometimes they could not climb the rope, other times they could just fine)

[sfan5]

Please open a separate bug report for that, it's not directly related to this (different code).

[yl-whosit]

Please open a separate bug report for that, it's not directly related to this (different code).

done: #16813

I see that my issue is caused by different code, but also it's a similar problem of determining if player is in/on top of a node...