FOSS gamedev and creative worlds

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.

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.

Krock wrote: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.

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)?

Zeno wrote: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.

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.

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