get_zone_and_area can trip assertion

[pikdum]

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:

1202bb7f85094460bff4f52602ef6b1fcf6c9234e343ecd58f7b8354ebc982c1  Azeroth.map
905ae5d844312ed8dc44b361222888d83de94fe247bdb39749c991830e6b5210  Nav/Azeroth/32_48.nav

With the Python bindings, trying to get the zone here is returning None.

nav_data = "/path/to/maps"
azeroth = pathfind.Map(nav_data, "Azeroth")
x = -8664.2421875
y = -123.19469451904297
z = 91.81388092041016
adt_x, adt_y = azeroth.load_adt_at(x, y)
print(adt_x, adt_y)
# 32 48
result = azeroth.get_zone_and_area(x, y, z)
# None

When doing the same through an Elixir NIF that wraps namigator-rs, I'm getting more details about an assertion failure:

Map.cpp:937: bool pathfind::Map::ZoneAndArea(const math::Vertex&, unsigned int&, unsigned int&) const: Assertion `rayResult || adtResult' failed.

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.

[namreeb]

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.

[namreeb]

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.

[namreeb]

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.

[JohnPCarvalho]

@namreeb, can I take this issue to investigate it/fix it?

[namreeb]

@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.