Baked postal numbers or a nearest-postal script?

#The two things postals actually do

Postals get treated as one feature, and they are two. A dispatcher taking a call needs to convert a number into a place on the map and send units there. A player who has just crashed a car needs to convert a place into a number they can say on the radio. Those are opposite operations and they are served by different things.

• Number to place. Only a baked grid or a /postal waypoint command can do this. The dispatcher has to find 8040 on the map.
• Place to number. Only a HUD element does this well while moving. Reading a three-digit label off a radar at speed does not work.

Once the question is split that way, most of the argument disappears. A server that does serious police and EMS roleplay usually wants both. A drift or racing server usually wants neither. A small casual server is often better off with one, whichever it is, than with two that contradict each other.

#What a baked grid is

The numbers are pixels in the minimap texture, rendered at the same resolution as the roads and the coastline. There is nothing to start, nothing to configure and nothing that can fail. The map has the grid on it the same way it has street names on it, and it is there the instant the texture streams in.

• No resource, no loop, no events. It cannot be the cause of a hitch warning.
• It works before any script has loaded, including during the first few seconds after spawn.
• It shows the whole grid at once, which is what a dispatcher needs.
• It survives a resource restart, a script error and a framework migration, because it is not code.

The trade-off is scale. The numbers are drawn at map scale, so they shrink with it. On the pause map they are perfectly legible; on the radar at driving zoom they are small enough that most players will not read them without stopping. That single fact is the entire reason the two approaches coexist.

The other trade-off is permanence. Baked pixels cannot be renumbered. Changing the grid means re-rendering the map, and removing the numbers means repainting whatever was underneath them. This is why maps are usually sold in a postal build and a no-postal build rather than one build with a toggle.

#What a nearest-postal script is

A postal script is a list of points and a distance check. Each entry is a code and an X/Y coordinate; the client works out which point is closest to the player, and draws that code near the minimap. The best-known open-source implementation, DevBlocky’s nearest-postal, is MIT licensed and set the pattern most others follow: a JSON data file chosen in the manifest, a refresh rate, a HUD element and a /postal command that draws a route to any code and clears itself within 100 metres of the destination.

[
  { "x": 2325.4345703125, "y": 5147.21484375, "code": "2000" },
  { "x": 2151.2138671875, "y": 5166.0888671875, "code": "2001" },
  { "x": 2059.6528320313, "y": 5105.8408203125, "code": "2002" }
]

• One large number, always legible, wherever you put it on the HUD.
• Renumbering is a text file edit rather than a re-render.
• It can expose the current postal to other resources through an export, so dispatch and MDT agree with the HUD.
• It can route the player to a code, which a baked map cannot.

The costs are real but small. It is one more resource to keep working. It only ever tells the player where they are, never where anything else is. And it introduces the possibility of disagreement, which is where nearly every postal complaint on a FiveM server comes from. Implementation detail, including the performance mistake almost everyone makes, is in nearest-postal scripts.

#When each one wins

• Police, EMS and a dispatcher: both. The dispatcher reads the map, the units read the HUD.
• Casual roleplay, no dispatch: baked only. Fewer moving parts, and nothing to break.
• Custom numbering, a fictional city or a renamed grid: script only, on a no-postal map. Let the code own the numbers.
• Drift, racing, PvP: neither. Take a clean map and give the screen back to the player.
• You inherited the server and something is already drawing postals: script only, until you know what it is reading.

#The standard San Andreas postal grid

There is no official grid, and this is the single most misunderstood thing about FiveM postals. What exists is a handful of community sets that have been copied between servers for years. They are not variations of one another. They use different numbers, different densities and different ranges, and a player who learns one set cannot read another.

The three that turn up most often are the three shipped with nearest-postal, and they are a useful reference point because anyone can read the files.

The density difference is not cosmetic. With 1,687 points, the nearest postal to you is almost always within a block. With 459, it can be a few hundred metres away, which means two people standing on opposite sides of a junction can call in the same number and a third can be a long walk from the one they called.

The clearest way to see how incompatible they are is to stand in the same three places in each one.

#Working out which grid your map prints

If you already have a postal map and do not know where its numbers came from, you can identify the set in about two minutes without asking anybody.

1. Open the pause map and zoom into Pillbox Hill in central Los Santos.
2. Read the number printed over the hospital block.
3. Four digits starting with 8 suggests the new-and-improved set. Four digits starting with 3 suggests the original set. Two or three digits suggests OCRP or a server-specific grid.
4. Confirm with a second landmark a long way away. Paleto Bay is the useful one, because the three sets are furthest apart up there.
5. If neither matches, your map carries a custom grid and you will need the postal file from whoever produced it.

Some packs solve this for you. oulsen_satmap, for example, ships an oulsen_satmap_postals.json alongside the art precisely so a nearest-postal script can be pointed at the same numbers the map prints. That is the behaviour to look for when choosing a postal map, and it is rarer than it should be.

#Running both, correctly

Running a baked grid and a HUD element together is the standard setup on a serious roleplay server, and it is only a problem when the two disagree. The rule is that one of them owns the numbers and the other follows.

1. Decide who owns the grid. If the map is baked, the map owns it, because pixels are harder to change than a JSON file. Everything else is configured to match.
2. Point the script at the matching data file. In nearest-postal that is the postalFile value in the manifest. Do not assume the default is the one your map uses.
3. Spot-check three landmarks. Pillbox, the airport and Paleto. Stand on each, read the number off the map, compare it to the HUD. Three matches out of three is enough.
4. Make the HUD element small. It is a confirmation, not a feature. One number near the radar, in the HUD’s own typeface.
5. Expose it once. Add an export such as exports.my_postal:getPostal() and have dispatch, 911 and the MDT call it instead of loading their own copies of the data.
6. Set a sane refresh rate. About one second. Recomputing every frame is 1,687 distance checks sixty times a second for a number that changes twice a minute.

#What a mismatch looks like from the player side

Postal mismatches rarely get reported as postal mismatches. They get reported as everything else, which is what makes them expensive.

• "Dispatch never finds me." The HUD and the map are on different grids, so the number the player reads out does not exist where they are.
• "The /postal command sends me to the wrong place." The command is reading a different file from the one the HUD displays.
• "Police are always slow." Units are routing to a coordinate several hundred metres from the call.
• "The map is wrong." The map is fine. The script is on a different set.
• "Nobody uses postals any more." Players stopped trusting the system and reverted to describing streets.

The diagnostic is the landmark test above. If the map says one number and the HUD says another while you are standing still, you have found it, and the fix is a one-line configuration change rather than anything structural.

#Changing grid on a live server

Switching sets is the sort of change that looks trivial and annoys everybody, because a postal grid is a shared vocabulary. Your police department has memorised it. If you are going to change it, change everything at once.

1. Swap the map and the postal data file in the same restart, never in separate ones.
2. Update dispatch, 911, MDT and any job scripts that store postal numbers against locations.
3. Check your database for stored postals in call logs and reports. They will be wrong afterwards and nothing will tell you.
4. Announce it before, not after. A department that has memorised 3224 for the hospital will call it in for weeks.
5. Keep the old data file somewhere. You may need it to read old reports.

The stronger advice is not to. Renumbering to a custom grid costs your players a shared language with every other server they play on, and the benefit is almost always aesthetic. The situation where it is genuinely right is a custom or fictional map, where no existing grid describes the world.

#The short answer

Take a baked postal map if you want the least that can break and you have a dispatcher who reads the pause map. Take a clean map and a script if you already run postals, have custom numbering, or want the grid off the artwork. Take both if you run police and EMS properly, and make the map the owner of the numbers.

Every theme in the catalogue is built both ways for exactly this reason: a postal build with the grid baked in, and a no-postal build with the ground underneath rebuilt rather than covered. Both are at all 36 minimaps, and the underlying mechanics are in postal codes explained.