Does anyone know where the camera angle and location is?

[Zen]

The code I've written so far get's close, but at time it can be as much as a thirty second of a block off from the true edge.

Here's a starting image.



Then I rotate one pixel over and I get cobble even though I'm in the sand block.



Also, if I move over laterally, I get sand where I ought to get cobble.



P. S. I've put the code in a zip file attachment.

[Krock]

I don't get why you use vector.normalize() on player:get_look_dir().
From what I've seen in the codes, it looks like a precision error.

[Zen]

I don't get why you use vector.normalize() on player:get_look_dir().

Well, I thought it would fix the problem by improving accuracy.
Removing it, other the hand, didn't change anything.

From what I've seen in the codes, it looks like a precision error.

I thought that at first, but I've noticed something odd.

When you move sideways there's a regular skew downwards and then a jerk upwards
and the greater the skew the greater the error in the aiming system. But when
it jerks upward, the accuracy improves dramatically.

I just did a test with the camera fixed, after the last jog, at 270 degrees, and
none of the camera angles x, y, or z changed with sideways motion. That means
the height of the camera is changing and messing up the targeting system.

Hm. I don't see a way of fixing that since I cannot predict the changes in height.

[Zeno]

https://github.com/minetest/minetest/bl ... e.cpp#L294

Edit ^^ have fun (?) with that, heh

I haven't really looked at your code but have you taken the distance of the player into account (i.e. raycast in the direction the player is looking and seeing what/where it intersects)?

[Zen]

Edit ^^ have fun (?) with that, heh

It'll take a bit of time to translate C++ because I don't know of that language.
But I notice that it has the advantage of camera_position that I cannot get.

I haven't really looked at your code but have you taken the distance of the player into account (i.e. raycast in the direction the player is looking and seeing what/where it intersects)?

Yes, it's like a ray. Starts from the player and goes outward, stepping from node to
node until it hits a blocking node or exceeds a distance of 5 units. But it doesn't deal
properly with small objects like torches, slabs, or steps.

[prestidigitator]

Like many things in Minetest, it appears you can set the value (via Player:set_eye_offset()), but not get it. When working on a wands mod, I just added {x=0,y=1.5,z=0} to the player's current position, which seemed to work pretty well (but could obviously be wrecked by any other mod that modifies the position). I was using it for reasonably long ranges, though, where minor imprecision in the camera position is not that important (unlike direction, which is very important).

EDIT: After testing, I've added the following description to Player:set_eye_offset() on the wiki: Offsets are relative to the default camera position for the given view, not relative to the player's position as returned by getpos() and not relative to previous calls (so using {x=0,y=0,z=0} resets to the default position for the view). Offset vectors are in a left-handed coordinate system where x is toward the player's right, y is up, and z is toward the player's front.

EDIT: By the way, my LuaCmd mod works pretty well for testing this sort of thing. For example, you can just issue the command "/lua me:set_eye_offset({x=1,y=0,z=0}, {x=0,y=0,z=0})" and see what happens. Remember you can use up and down arrows in the message console to go through history.

[Hybrid Dog]

If you don't regard bobbing, the player's camera position is 1.625 above the position you get with player:getpos().
You can get the exact pointed position of a node.
https://github.com/HybridDog/technic_ex ... it.lua#L34