Loading content...
Grid
2D spatial partitioning of the map for O(1) proximity lookups — the engine behind zones and points.
2D spatial partitioning of the map for O(1) proximity lookups — the engine behind zones and points.
lib.grid splits the GTA5 map into a fixed cell grid so you can find nearby entries cheaply.
It's the foundation of lib.zones and lib.points — most scripts use those instead.
Reach for the grid directly when you index your own objects (shops, props…) for proximity.
lib.grid.addEntry(entry) — index an entry; it needs coords (vector3) and either radius or width/length.lib.grid.removeEntry(entry) — remove an entry (matched by identity — the same table instance).lib.grid.getNearbyEntries(point, filter?) → table[] — entries in the cells around point, deduped; optional predicate filter.lib.grid.getCell(point) → table[]? — raw contents of the single cell containing point.lib.grid.getCellPosition(point) → number, number — the cellX, cellY indices for a world point (clamped to the map).local entry = { coords = vector3(215.0, -810.0, 30.0), radius = 5.0, id = 'shop_1' }
lib.grid.addEntry(entry)
local coords = GetEntityCoords(cache.ped)
for _, candidate in ipairs(lib.grid.getNearbyEntries(coords)) do
if #(coords - candidate.coords) <= candidate.radius then
print('inside', candidate.id)
end
end
lib.grid.removeEntry(entry)A predicate keeps the scan tight:
local zonesOnly = lib.grid.getNearbyEntries(coords, function(entry)
return entry.type == 'zone'
end)Entries are matched by identity — recreating an equivalent table won't remove it. If you change an entry's coords / radius, remove and re-add it (the index doesn't update in place). Off-map coords are clamped, not rejected. Pass a stable filter reference — a fresh inline closure every frame defeats the internal cache.