GetZoneAtCoords Native provides "cached/wrong" results if queried too quickly

FiveM Discussion Bug reports
1

FiveM version: Canary

Client side GetZoneAtCoords native is behaving like it’s caching the results of the Native.

What I expect to happen:
GetZoneAtCoords providing unique/correct results when called.

What happens instead:

Code example:

RegisterCommand('zoneTest', function()
    print(1, GetZoneAtCoords(-2956.87, 483.47, 14.73)) -- Should return 494 (correct)
    print(1, GetZoneAtCoords(-2956.57, 481.7, 14.75)) -- Should return 494 (correct)
    print(1, GetZoneAtCoords(-2960.176, 479.0105, 15.97156)) -- Should return 494 (correct)
    print(1, GetZoneAtCoords(-2964.697, 476.386, 16.01)) -- Should return 82 (actually returns 494)
end)

If you add Wait between function calls you will receive correct information:

RegisterCommand('zoneTest', function()
    print(1, GetZoneAtCoords(-2956.87, 483.47, 14.73)) -- Returns 494
    Wait(500)
    print(1, GetZoneAtCoords(-2956.57, 481.7, 14.75)) -- Returns 494
    Wait(500)
    print(1, GetZoneAtCoords(-2960.176, 479.0105, 15.97156)) -- Returns 494
    Wait(500)
    print(1, GetZoneAtCoords(-2964.697, 476.386, 16.01)) -- Returns 82
end)
```

Also, additionally - it looks like the result is "cached" globally, and rewrites all returns from that native, so if you run this while there is other script running in parallel - the other script will also be "affected"
2

And your findings are consistent with what is happening in game code:

// Check provided coordinates against a cache. Returning early if coordinates hit.
...
// Look through popzone atArray
...
v24 = byte_14247F63A;
...
// Internally cache popzone details at offset byte_14247F63A
...
byte_14247F63A = (unsigned __int8)(v24 + 1) < 4u ? v24 + 1 : 0;
3

Oh that’s very annoying. I guess to way to change that logic?
Maybe a native that doesn’t use the cache or something like that?
I’m doing some zone-dependent logic and this example in rare places breaks :frowning: