Open pikdum opened 2 months ago
Thanks for the report. The issue is that that Z value is slightly under the world where there is a hole in the ADT for the cave. For that (x, y) the minimum Z is 91.8140564
, at least according to the Z query. So strictly speaking the failure is "correct". But this function should probably be more forgiving than that. I'm not quite sure what the right answer is. My guess is that if this happens we should send a raycast in the upward direction and return the zone/area we hit first, but I'm not 100% sure that is blizzlike.
Correction, this was easy to test. With the 1.12.1 client, even if I go far under the cave, it works. Same for going high above.
So I solved one problem, but revealed another. The query now "works" but the data returned is still wrong. In 1.12.1, the zone and area should be 12 and 34, respectively. Currently it is returning 0 and 0.
@namreeb, can I take this issue to investigate it/fix it?
@namreeb, can I take this issue to investigate it/fix it?
I'd be happy to review a merge request. But I actually have fixed this issue. I haven't pushed the fix because as I mentioned before there is a deeper issue. I guess what I should do is push this fix and open a different issue for the zone and area query.
Hello,
I think I found some spots where
get_zone_and_area
trips an assertion. This is one up by the mine in the human starting area:-8664.2421875, -123.19469451904297, 91.81388092041016
I've found a few others around and inside that mine, but this is the only one I logged.This is with the latest code and a 1.12 client. Relevant sha256 hashes:
With the Python bindings, trying to get the zone here is returning
None
.When doing the same through an Elixir NIF that wraps namigator-rs, I'm getting more details about an assertion failure:
Also, thanks for the project! I've been eyeing it for a while now and only recently got it integrated with Thistle Tea, starting with random mob wandering.