Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ObservationFromGrid is centered on an odd point #370

Closed
TGlas opened this issue Sep 24, 2016 · 3 comments
Closed

ObservationFromGrid is centered on an odd point #370

TGlas opened this issue Sep 24, 2016 · 3 comments
Milestone

Comments

@TGlas
Copy link

TGlas commented Sep 24, 2016

Let (x,y,z) denote the position of the character as reported by the XPos, YPos, and ZPos observations. These are floating point numbers, not integer-valued block coordinates. I assume that the numbers refer to the character's feet; at least the y coordinate is an integer while standing on a solid block.

Apparently (I have collected quite some data), the grid of blocks returned by ObservationFromGrid is centered on the block with the following coordinates:

           (floor(x), round(y), floor(z))

In other words, truncation is applied in horizontal directions, while rounding to the closest integer is applied in the vertical direction. This odd combination resulted in some very subtle bugs in my code (trying to perform temporal integration).

I cannot be 100% sure that rounding is what's actually going on here. It may also be that the grid is centered on a point located rougly half a block above the feet. However, it doesn't seem to be the eye's, which would be the other logical point, since that should be about 1.5 blocks above the feet. That's why I presume a rounding issue.

I would be very much surprised if the current behavior was by design, so I assume it is a bug. I'd like to strongly suggest to apply the floor operation relative to the XPos, YPos, and ZPos observations in all three coordiantes. This seems to be the most natural behavior, probably expected by most users.

@DaveyBiggers
Copy link
Member

That does indeed sound like a bug. I'll take a look.

@DaveyBiggers DaveyBiggers added this to the Fallow Deer milestone Sep 26, 2016
@DaveyBiggers
Copy link
Member

Yes, for some reason 0.5 gets added to the y value before the floor takes place.
I've fixed this - ca9f416 - hopefully no one is relying on the wrong behaviour...

@TGlas
Copy link
Author

TGlas commented Sep 26, 2016

Thanks a lot, works perfectly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants