YNV 导航网格查看器

What a .ynv actually is

Peds walk on a navmesh. The game keeps it in .ynv files, one per 150 metre square of the map, and the file name is the square: navmesh[X][Y].ynv counts in 50 metre units, so the numbers are the cell index times three, and the corner of cell (0, 0) is at -6000, -6000. The area id a file carries iscellX + cellY * 100. This build ships 4,440 map cells plus 37 more named after a vehicle, which carry the navmesh for walking around on a moving deck.

Inside, a file is a header of pointers and counts, four chunked lists (vertices, indices, edges, polygons), a quadtree of sectors, a portal array and a portal link array. A vertex is six bytes, three unsigned shorts read as a fraction of the file's own bounding box, so the grid a vertex can sit on is about 2.3 mm across in a typical cell. A polygon is 48 bytes: three flag words, a run of indices into the shared vertex list, an area id, a part id, a portal link range and a six short box.

Colour by flag, because that is what the file says

A polygon does not store "this is a road". It stores bits, and three words of them. The key on the right is a fixed order, so a polygon that is both water and a footpath is drawn as water and counted once. Open the inspector and you get the whole set, every bit that is on, with CodeWalker's own names where it has one and the bit number where it does not. Nothing here is invented: PolyFlags2 bits 0 to 15 are set on plenty of real polygons and nobody has named them, so they are listed as unknown.

The stored box is a hint, not a bound

Every polygon carries six signed shorts in 0.25 metre units, which look like its bounding box. They are not. Across all6,559,005 polygons in this build, 6,556,248 carry a box that does not contain the polygon's own vertices. The inspector prints it beside the ring's real extent and labels it for what it is: a loose broadphase hint the game's own code is happy with.

An edit to a navmesh is an edit to five files

This is the fact that decides everything, and the Neighbours tab counts it for whatever file you open. An edge in a.ynv names the polygon on the other side by an area id and a polygon index. Where that area is a different cell, the index is a position in the neighbouring file's polygon list.

Across the whole stock build that is 1,398,536 of 50,869,898 edge parts, 2.75%, roughly 350 per file. So adding or removing a single polygon renumbers everything after it and silently repoints the edges of up to four neighbouring files, which are files you would have to open, renumber and ship too. Nothing in the format warns you and nothing in the game complains: the edges simply point at the wrong polygon.

Why this page reads and does not write

Three reasons, in order of how much they matter.

• The five file problem above. A tool that edits one .ynv at a time is a tool that writes a quietly broken map.
• Fields with no known derivation. A new polygon needs values for PolyFlags2 bits 0 to 15, which are set on a large share of real polygons and which nobody has named. An edge carries an 11 bit field that takes 48 distinct values up to 62 in this build and means nothing anyone has established. Portal and cover point placement follow rules that are not written down anywhere.
• There is no byte exact proof standard available. The YND editor could claim one: read all 274 stock files, write them back, and have CodeWalker read every number back identically. For .ynv that check does not pass even for CodeWalker itself. Its own writer rebuilds the sector tree and recomputes every polygon box, and0 of 30 round tripped files came back byte identical. Shipping a writer without that proof would be shipping a guess.

What the reader itself is checked against: all 4,477 stock files were read with this page's own code and compared field by field against CodeWalker.Core's read of the same files. 4,477 of 4,477 agree on the area id, the content flags, the bounding box, the vertex, index, edge, polygon, portal and point counts, the adjacent area table and the whole shape of the sector tree. The cell to world rule agrees on all 4,440 map files.

Streaming a .ynv, and the one trap in it

A .ynv in stream/ needs no data_file line, no files entry and no script. The client looks the extension up as a streaming module and the file name without the extension as a slot, and swaps the handle.

A stock name is the clean case. The old handle is kept on a stack, so stopping the resource puts the game's own file back and restarting works. A new name is not. It creates a slot, and navmesh slots are deliberately never removed, with a comment in FiveM's own source saying re-registration crashes. The slot leaks for the rest of the session. On top of that, the game asks for navmesh by region through the navmesh[x][y] naming, so nothing is going to request a slot you invented a name for. Treat a new name as unproven, not as a feature.

Before you make a file, check you need one

The Runtime tab is there because the answer is often no file at all. Seventeen natives carry NAVMESH or NAV_MESH in the name and every write among them is subtractive: a blocking box, an area switch, a streaming request. Nothing creates, moves, retags or adds a polygon. If you wanted peds to stop walking through your new building, that isADD_NAVMESH_BLOCKING_OBJECT and a few lines, and the tab writes them with your file's own box filled in.

The one thing the runtime cannot do for you is the one people ask for most: with no navmesh under a custom map,TASK_FOLLOW_NAV_MESH_TO_COORD has nothing to path on and the documented behaviour is that the ped simply stands still. There is a flag, ENAV_GO_FAR_AS_POSSIBLE_IF_TARGET_NAVMESH_NOT_LOADED, and even it needs navmesh where the ped is standing.

No game files are shipped here

You open your own .ynv out of your own install. What this page does ship is a catalogue of facts about the 4,477 stock files: which cell each one covers, how many polygons it holds, how big it is and which archive folder to find it in. Type a position into the box at the top and it names the file and the path. The navmesh itself is Rockstar's and stays in your game.

What this page does not do

• It does not write a .ynv. See above. That is a decision, not a missing feature.
• It does not draw more than one file at a time. The Neighbours tab names the files next door and marks their squares on the map, but you open them one by one.
• It does not claim to know what the unknown fields mean. Where the game files carry no table, the raw number is printed and said to be a raw number.

Credits

The format comes from CodeWalker by dexyfex (GameFiles/Resources/Nav.cs and GameFiles/FileTypes/YnvFile.cs), which is also what every number on this page was checked against. The flag names are CodeWalker's; where it marks one as unknown, so does this page. The runtime facts come from the Cfx.re native documentation and from citizenfx/fivem's own source.