[sw1ss]

I'd like to know what those values are too.

In spite of initial apparent affect, upon further anolysis, adjusting those values has yielded nothing consistent. I apologize for mentioning it.

Thanks.

[Chloe Mayo]

bummer, and yeah don't mind my impatience. I was very eager to go be navmesh bug genny(?) pig and test this out.

I guess, I'll be like the others now. There is absolutely nothing outside of Beth's own hand that can be done to fix this ourselves. As it is, it is on them.

[k a t e]

I think it is time to take the fight to Twitter. From what I read and saw about this bug, its a real killer to the Skyrim modding community. So if everyone bothered this bug starts to voice/tweet their discontent about it still not being fixed, we might get it to their attention in such a way that they can't ignore us.

I even made a Twitter account just for that.

[Rik Douglas]

If they cannot fix it for a while, do you guys think that a good consolation prize would be if bethesda developed an official tessnip that also generates ONAM lists? At least that way, we could use the .esm workaround while having confidence that the esm won't screw up people's games

- Hypno

[Solina971]

I agree with creating more visibility of the issue by lobbying... that's what I was saying a couple threads ago. I still think that it should be tactfully and politely done; and alternative methods offered as interim solutions for the educated adventurous. Since we haven't heard anything of note from Ma Beth since the v1.5.24 patch fiasco (and its subsequent fix)... maybe more people are getting fed up with it by now that it could make a difference in the sense of urgency. I assume a LOT of people are abandoning the game in general because of this hold-up... I mean it's been out for over 6months now, people move on without new content to keep 'em interested (and/or the ability to MAKE it).


I've done more experimenting; prompted by Amethyst's issue with a totally destroyed mod. I won't go over that specifically, as there's a thread for it already. But I found more relating specifically to navMesh while messing with it. As with the NAVM record decoded, manually changing an NVMI subrecord has no real use but it CAN be done. I wish I knew this preCK... I could have made the only navMeshed mod back then!

But the primary reason I'm showing you this is because these findings back up my theories and elucidates navMeshery in general.

- First, that NVMIs are seemingly the cause for the NavMesh Bug - though NOT the data itself... but how it's handled during specific system events (eg: onCellLoad). All the data works properly on 'FirstArrival', but is broken on fast-trav-return. NAVMs are NOT affected whatsoever, as navMesh is still intact and present - proven by forcing an actor back into the Bugged area.

*** My next looking-into of this will be to test for OTHER data in the NVMI after FTR. I plan to have an actor patrolling two points, but have preferred navMesh take the path 'out of the way'. Theoretically, the actor will travel horseshoe instead of straight; and will continue to do so after FTR, if that data is properly processed and that ONLY the cell-borders are Bugged. If not, the actor will travel straight; and we will know more is damaged/ignored/whatever than just regular borders... presumably the entire NVMI.

- Second, I found that if there are duplicate NVMIs contained in the NAVI record (ie: pointing to the same NAVM), the one LOWER in the tree is the one that's used. The first/higher one is disgarded. What the implications of this are, regarding multiple mods navMeshing the same ref/area... I dunno yet...

- Third, the standard NavMesh Bug (NB1) can be intentionally induced in isolated actors by having certain data structure in an NVMI... specifically, if a cell-border merger is not 'recorded'. As you'll see below, there are specific data blocks which store various aspects of navMesh; one such is for linked doors, another for cell-merges, and yet another for cell-merges which has preferred status. If a specific cell-merge (or door for that matter) is omitted or damaged, the NavMesh Bug occurs; BUT only for actors crossing the missing cell-merger (ALL others work fine, even after FTR). One may manually delete this data block to induce this effect, or add it for correction.

- Fourth, that performing certain operations during a given CK session will cause corruption of data. Regarding navMesh, this means that cell-borders may become damaged or destroyed, water/preferred status may become corrupted, or worst of ALL - the entire cell's navMesh completely exploded into dozens of tiny little islands. Certain cells are more prone to this buggy behavior than others, as noted in earlier posts.

*** There appears to be little one can do to predict the occurances of this and what specifically causes it; keeping navMesh sessions to a bare minimum and saving/backing up frequently seem to help prevent it... if User starts with a fresh CK session, then saves & exits immediately after making essential edits. Each time the plugin is re-saved, re-finalized, or ANYTHING in the SAME CK session - you hold your mod's stability atop your own mouse-pad.

- Fifth, creating CUSTOM Forms of navMesh (non 00- FormIDs) is flawed; and the chances of having Bugged navMesh because of it are greatly increased. While I need to test this more, it appears that 01- navMesh (02- for ESPs with ESM dependency, 0x-whatever) sometimes causes the NVMI record to adopt the data-structure of an "Island" navMesh. The NAVM is NOT 'flagged' as an Island in the CK though... which makes it yet-more-suspicious. I haven't yet discerned any pattern of when this happens or what exactly causes it... it's best to simply avoid doing it in Vanilla areas (as stated in previous threads).

*** Having 'Island data-structure' means that arbitrary points are defined by the CK (almost ALWAYS different from the actual navMesh's vertices), which seem to re-create the actual navMesh. Since the navMesh's geometry is already defined in the NAVM record, why does NEW and ARBITRARY geometry get placed in the NVMI? Does this conflict with the NAVM's geometry? Is it legacy data? Does it cause some form of the NavMesh Bug? How does the game-engine use this data, and does it cause excessive strain since two sets of navMesh are now presumed to be in play (NAVM, and the new NVMI data)?

- Sixth, that TESvSnip does NOT necessarily destroy or corrupt data. Snipping navMesh across plugins had no effect whatsoever; saving the new plugin caused file bloat (decompressed some records), but NOTHING was damaged and everything was still intact in-game and when re-loaded in the CK. This was tested using SEVERAL ESPs, doing several different functions (cut/paste, data editing, etc).

*** I must include here that certain things MAY cause damage, but I haven't found any yet. I should also include that sometimes records seem to disappear when viewing a plugin in Snip... as in all the subGRUPs are empty and it appears that the entire mod's contents has been gutted. This is merely the way Snip displays the records; exiting the app, then restarting it has the records still in place and everything as it should be. I don't know why this happens specifically, but it may confuse some people into thinking their mods have been destroyed.

- Seventh, placing ANY Vanilla record in an ESM causes drama. In the case of Vanilla navMesh in an ESM, it RELIABLY induces a form of the NavMesh Bug (NB2)... where actors whose AI crosses the cell-border mergers are broken, BUT additionally they completely disappear (as in, nowhere to be found whatsoever). The 'normal' NavMesh Bug (NB1) induces 'wandering' actors, but they may always be found in adjacent cells or elsewhere in the Bugged cell. When a plugin works perfectly as an ESP; if simply converted to an ESM it causes it NOT to work.

*** Here I want to reinterate my unwavering stance that anything Vanilla MUST go into an ESP (unless you know how to effectively employ ONAM subrecords). I corrected the above NB2 behavior by simply Snipping over the entire NAVI grup and the entire Tamriel WRLD grup (to an ESP). All else remained in the ESM. This did NOT change anything else Vanilla; so if you change a Vanilla actor for instance, you'd have to Snip over that actor to the ESP as well. This also uses Snip to change the ESM flag. The resulting plugin combos were all tested BEFORE AND AFTER re-loading and re-saving the files in the CK (which CORRECTS the data compression and version #, as well as the number of records)... all worked the same before and after.



NVMI subrecord's DATA STRUCTURE mostly demystified:

Spoiler

(* Indicates data that may not be present in all NVMIs; depending on the presence of merged cell-borders and linked doors. These data blocks are inserted and make the subrecord larger.)

- FormID of assigned NAVM
- unknown flag, always 00, 20, or 40; followed by '00 00 00'
- XYZ coords of assigned NAVM
- preferred-border flag ('00 00 00 00' if none)
- # of NAVMs merged with, listed immediately following
*- FormIDs of the NAVMs in the adjacent cells, with which this one has merged cell-borders (4bytes are inserted for each NAVM merged to)
- # of merged NAVMs which contain preferred tri's
*- FormIDs of NAVMs with preferred mergers (4bytes inserted for each NAVM)
- # indicating how many linked doors are present (00=none, 01-1, etc)
*- 2-2byte shorts (always 'F3 73 8B E4') then the FormID of the linked door (8bytes are inserted for each door)
- 00 flag, unless the navMesh is an Island then it's 01
- Islands list 'bounding' points near actual NAVM vertices
- these coordinates are data blocks which are inserted, after the 01 flag
(if the flag is 01, the following data is inserted)
*= 2-4byte floats are inserted; XYZ coords of the Island's bounding box
*= varying sized string inserted; seems to indicate # of tri's, then the arbitrary points they consist of (defined next)
*= 3-4byte floats are inserted; XYZ coords of arbitrary points which define the Island
- FormID of the worldSpace containing the NAVM assigned to this NVMI; if an interiorCell is all 00s
- cell coordinates if a worldSpace; listed Y,X (eg: 5 -5 is actually -5x,5y)
- FormID if an interiorCell

Here's a bunch of examples to illustrate how this applied...

NVMIs of a simple, custom navMesh in a custom worldSpace (which spans two cells)

Spoiler

(NVMI with unmerged cell borders)
6D 18 00 01 00 00 00 00 DB 34 2C 45 A7 9F F9 44 8E FF 9F 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3C A0 E9 A5 2F 18 00 01 00 00 00 00

(NVMI after merged/finalized)
6D 18 00 01 00 00 00 00 DB 34 2C 45 A7 9F F9 44 8E FF 9F 40 00 00 00 00 01 00 00 00 6E 18 00 01 00 00 00 00 00 00 00 00 00 3C A0 E9 A5 2F 18 00 01 00 00 00 00

= Breakdown of the above 'merged' NVMI

6D 18 00 01
- FormID of NAVM is 0100186D (custom navMesh)

00 00 00 00
- unknown flag & buffer
- same for all NVMIs (except the first byte)
- first byte is always 00, 20, or 40

DB 34 2C 45
A7 9F F9 44
8E FF 9F 40
- coordinates of the NAVM
- approx center (not the exact center from end to end, it considers all angles and tri's)
- 3-4byte floats
- above values are 2755.303x (DB 34 2C 45), 1996.989y (A7 9F F9 44), 4.999946z (8E FF 9F 40)

00 00 00 00
- preferred cell-border flag (off)

01 00 00 00
- 01 was 00 before merging; always present in all NVMIs
- # of NAVMs this subrecord's NAVM is merged to

6E 18 00 01
- FormID of NAVM (0100186E) this subrecord's NAVM is merged with
- This data block is INSERTED during the merge; beforehand the subrecord is smaller

00 00 00 00
- # of preferred merged NAVMs

00 00 00 00
- # of linked doors
- would precede the INSERTED FormIDs of the linked doors (in this case there aren't any)

00
- precedes the inserted XYZ coords if the NAVM is an Island (or has been 'damaged')
- changed to 01 if 'Island' data structure (sometimes doesn't have Island status in the CK)

3C A0 E9 A5
?- appear to be coordinates to nothing, a max/min, or flags (but don't match anything)
- always the same for ALL NVMIs
- 2-2byte shorts; -24516 (3C A0) and -23063 (E9 A5)
- is also contained in NAVM records, near the beginning of of the data

2F 18 00 01
- FormID (0100182F) for the custom worldSpace which this NVMI's NAVM is linked to
- would be 3C 00 00 00 is it were in Tamriel worldSpace
- would be all 00s if an interior Cell

00 00 00 00
- cell coords (0,0)
- would be a FormID if an interior Cell

NVMI for a custom interiorCell's NAVM, has door linked to Vanilla-Tamriel

Spoiler

63 0D 00 01 00 00 00 00 00 80 09 45 46 17 04 45 7D 97 82 44 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 F3 73 8B E4 C7 12 00 01 00 3C A0 E9 A5 00 00 00 00 62 0D 00 01

= Breakdown

63 0D 00 01
- FormID of NAVM is 01000D63

00 00 00 00
- same for all NVMIs (first byte is either 00, 20, or 40)

00 80 09 45 46 17 04 45 7D 97 82 44
- coordinates of the NAVM inside the cell
- 3-4byte floats
- 2200.0x (00 80 09 45), 2113.455y (46 17 04 45), 1044.734z (7D 97 82 44)

00 00 00 00
- preferred flag

00 00 00 00
- # of merged NAVMs

00 00 00 00
- # of preferred merged NAVMs

01 00 00 00
- # of linked doors

F3 73 8B E4
- door flag (on)
- same for ALL NVMIs which have doors
- 2-2byte shorts; 29683 (F3 73) and -7029 (8B E4) (but doesn't match anything)
- block was INSERTED

C7 12 00 01
- FormID of the door in the cell/NAVM, which is linked to Vanilla
- 010012C7
- block was INSERTED

00
- flag before inserted XYZ coords if NAVM is an Island

3C A0 E9 A5
- always the same for all NVMIs

00 00 00 00
- always 0s if NAVM is in an interior cell
- exteriors would have the FormID of the WRLD

62 0D 00 01
- FormID (01000D62) of the CELL record containing this subrecord's NAVM (interiors only)
- exteriors would have coordinates of the cell

NVMI of Riften's center cell (42,-24); an Island
- NOTICE all the extra data that is ADDED to the subrecord; seemingly arbitrarily

Spoiler

(this is using an ESP I used during my 'Riften Experiments', inside the city's walls in Tamriel worldSpace)
- points to the NAVM of a custom balcony
- not linked or connected/merged to anything
- 2tri Island

73 0D 00 01 20 00 00 00 E2 94 2A 48 82 99 BB C7 DA 73 32 46 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 79 6E 2A 48 E3 02 BC C7 DA 73 32 46 20 BC 2A 48 19 28 BB C7 DB 73 32 46 02 00 00 00 00 00 01 00 02 00 00 00 02 00 03 00 04 00 00 00 09 A2 2A 48 E3 02 BC C7 DA 73 32 46 20 BC 2A 48 02 E6 BB C7 DA 73 32 46 64 86 2A 48 19 28 BB C7 DA 73 32 46 79 6E 2A 48 9B 55 BB C7 DA 73 32 46 3C A0 E9 A5 3C 00 00 00 E8 FF 2A 00

= Breakdown

73 0D 00 01
- NAVM FormID 01000D73

20 00 00 00
?- unknown flag (either 00, 20, or 40)

E2 94 2A 48 82 99 BB C7 DA 73 32 46
- 3-4byte floats
- coordinates of the above NAVM
- 174675.5x, -96051.02y, 11420.96z

00 00 00 00
- preferred flag

00 00 00 00
- # of merged NAVMs

00 00 00 00
- # of preferred merged NAVMs

00 00 00 00
- # of linked doors

01
- flag indicating the NAVM is an Island
- is 00 if not an Island
- precedes the inserted XYZ coords of Island points

79 6E 2A 48 E3 02 BC C7 DA 73 32 46
- first of two sets of 3-4byte floats
- coordinates of bounding box
- 174521.9x, -96261.77y, 11420.96z
- x is same as vertPoint3 , y is vertPoint4
- INSERTED data block

20 BC 2A 48 19 28 BB C7 DB 73 32 46
- 174832.5x, -95824.2y, 11420.96z
- x is same as vertPoint1, y is vertPoint2
(** 'DB 73 32 46' is the same as above/below 'DA 73 32 46', int/short values are diff, but float is same)
- INSERTED data block

02 00 00 00 00 00 01 00 02 00 00 00 02 00 03 00
?- connected points which form the Island
- almost never the vertices of the NAVM, but very close
- INSERTED data block

04 00 00 00
- # of points defined in the next data blocks
- INSERTED data block

09 A2 2A 48 E3 02 BC C7 DA 73 32 46
- 174728.1x, -96261.77y, 11420.96z
- vertex; tri2, vert4, point0
- INSERTED data block

20 BC 2A 48 02 E6 BB C7 DA 73 32 46
- 174832.5x, -96204.02y, 11420.96z
- almost a vertex (point1) except -.52y
- INSERTED data block

64 86 2A 48 19 28 BB C7 DA 73 32 46
- 174617.6x, -95824.2y, 11420.96z
- almost a vertex (point2) except +1.2x (y/z work)
- INSERTED data block

79 6E 2A 48 9B 55 BB C7 DA 73 32 46
- 174521.9x, -95915.21y, 11420.96z
- almost a vertex (point3) except -0.61y (x/z work)
- INSERTED data block

3C A0 E9 A5
- always the same for all NVMIs

3C 00 00 00
- FormID for Tamriel WRLD record
- indicates what worldSpace the following coords are located in
- is all 00s for an interior

E8 FF 2A 00
- -24,42 Tamriel cell coords
- is a FormID for an interior

NVMI of Riften's center cell (42,-24); non-Island
- notice that it is a custom NAVM Form yet does NOT have 'Island' data-structure

Spoiler

- the main navMesh (where Player would walk)
- shares two different cell-borders, merged/finalized to those adjacent cells
- has several tri's

71 0D 00 01 20 00 00 00 72 9F 2A 48 20 31 BC C7 43 FE 2D 46 00 00 00 00 02 00 00 00 74 0D 00 01 72 0D 00 01 00 00 00 00 00 00 00 00 00 3C A0 E9 A5 3C 00 00 00 E8 FF 2A 00

= Breakdown

71 0D 00 01
- FormID of NAVM

20 00 00 00
- unknown 00-20-40 flag

72 9F 2A 48 20 31 BC C7 43 FE 2D 46
- XYZ coords of NAVM

00 00 00 00
- preferred flag (off)

02 00 00 00
- # of NAVMs merged with, listed next

74 0D 00 01
72 0D 00 01
- 2 FormIDs, the NAVMs in the adjacent cells with which this one has merged cell-borders
- 01000D74 and 01000D72
- INSERTED data block

00 00 00 00
- # of preferred merged NAVMs

00 00 00 00
- # of linked doors

00
- flag for Island navMesh (off)

3C A0 E9 A5
- same for every NVMI

3C 00 00 00
E8 FF 2A 00
- 1 FormID and 2-2byte shorts
- Tamriel -24 (E8 FF), 42 (2A 00) (cell containing this NVMI's NAVM)

NVMI of WhiterunExterior17 (in front of Pelagia's Farm; I used this area to test Amethyst's issue)
- shows how a linked door is added (to a custom worldSpace)
- cell has preferred and regular cell-borders, as well as a door to a custom interiorCell

Spoiler

(NVMI before adding a second door to the cell)
BF 9B 07 00 00 00 00 00 4D 93 AE 46 77 FE 5C C6 B5 49 8C C5 39 D3 61 3D 05 00 00 00 D2 9B 07 00 FC 16 0E 00 4B 34 0A 00 81 A0 0E 00 E2 16 0E 00 02 00 00 00 C2 9B 07 00 35 83 0B 00 01 00 00 00 F3 73 8B E4 C8 12 00 01 00 3C A0 E9 A5 3C 00 00 00 FC FF 05 00

(NVMI after adding a second door; 1st door goes to interiorCell)
BF 9B 07 00 00 00 00 00 4D 93 AE 46 77 FE 5C C6 B5 49 8C C5 39 D3 61 3D 05 00 00 00 D2 9B 07 00 FC 16 0E 00 4B 34 0A 00 81 A0 0E 00 E2 16 0E 00 02 00 00 00 C2 9B 07 00 35 83 0B 00 02 00 00 00 F3 73 8B E4 C8 12 00 01 F3 73 8B E4 97 23 00 02 00 3C A0 E9 A5 3C 00 00 00 FC FF 05 00

= Breakdown

BF 9B 07 00
- FormID of NAVM

00 00 00 00
- unknown flag

4D 93 AE 46
77 FE 5C C6
B5 49 8C C5
- coords of NAVM's origin

39 D3 61 3D
- preferred cell-border flag
- 2-2byte shorts; -11463 and 15713

05 00 00 00
- # of merged NAVMs

D2 9B 07 00
FC 16 0E 00
4B 34 0A 00
81 A0 0E 00
E2 16 0E 00
- FormIDs of merged NAVMs
- 00079BD2 Wilderness (6,-4)
- 000E16FC WhiterunAttackStart03 (5,-5)
- 000A344B WhiterunExterior16 (4,-4)
- 000EA081 WhiterunExterior02 (5,-3)
- 000E16E2 WhiterunAttackStart03 (5,-5)
- all INSERTED data blocks

02 00 00 00
- # of preferred merged NAVMs

C2 9B 07 00
35 83 0B 00
- FormIDs of merged NAVMs
- 00079BC2 is in (6,-4)
- 000B8335 is in (4,-4 WhiterunExterior16)
- both NAVMs contain preferred tri's (this is the only perceivable diff)
- INSERTED data block

02 00 00 00
- changed from 01
- indicates # of doors linking to other NAVMs

F3 73 8B E4
C8 12 00 01
- always the same 4byte block for all NVMIs with doors
- FormID of the door (010012C8)
- first door, originally INSERTED

F3 73 8B E4
97 23 00 02
- newly INSERTED block of data, added after the above door
- FormID is 02002397

00
- flag for Island navMesh (off)

3C A0 E9 A5
- same 4bytes for ALL NVMIs (regardless of finalized, links, merges, anything)

3C 00 00 00
FC FF 05 00
- Tamriel FormID (0000003C)
- cell coords (-4,5)

NVMI of custom worldSpace after door to Vanilla was added

Spoiler

- already merged to adjacent cell in the worldSpace

(before adding the second door)
6D 18 00 01 00 00 00 00 DB 34 2C 45 A7 9F F9 44 8E FF 9F 40 00 00 00 00 01 00 00 00 6E 18 00 01 00 00 00 00 00 00 00 00 00 3C A0 E9 A5 2F 18 00 01 00 00 00 00

(after)
6D 18 00 01 00 00 00 00 DB 34 2C 45 A7 9F F9 44 8E FF 9F 40 00 00 00 00 01 00 00 00 6E 18 00 01 00 00 00 00 01 00 00 00 F3 73 8B E4 96 23 00 02 00 3C A0 E9 A5 2F 18 00 01 00 00 00 00

= Breakdown

6D 18 00 01
00 00 00 00
DB 34 2C 45
A7 9F F9 44
8E FF 9F 40
- normal

00 00 00 00
- preferred border flag (off)

01 00 00 00
6E 18 00 01
- cell-border merger

00 00 00 00
- # of preferred merged NAVMs

01 00 00 00
- changed from 00
- # of linked doors

F3 73 8B E4
96 23 00 02
- newly inserted data block
- shows the linked door

00
3C A0 E9 A5
2F 18 00 01
00 00 00 00
- same before and after

(after changing the border to preferred; no new data is inserted, only existing changed)
- only the two tri's on the border were toggled preferred
6D 18 00 01 00 00 00 00 DB 34 2C 45 A7 9F F9 44 8E FF 9F 40 25 49 12 3E 00 00 00 00 01 00 00 00 6E 18 00 01 01 00 00 00 F3 73 8B E4 96 23 00 02 00 3C A0 E9 A5 2F 18 00 01 00 00 00 00

6D 18 00 01
00 00 00 00
DB 34 2C 45
A7 9F F9 44
8E FF 9F 40
- normal

25 49 12 3E
- only when preferred tri's are present (normally is '00 00 00 00')
- this block is moved up from after the FormIDs of merged NAVMs
- 2-2byte shorts;

00 00 00 00
?- seems to be the # of preferred cell-merges, but left blank and moved above the regular mered NAVMs
- seems to occur if the preferred tri's are not connected to any other preferred tri's (within that cell)

01 00 00 00
6E 18 00 01
- merged NAVM

01 00 00 00
F3 73 8B E4
96 23 00 02
- linked door

00
3C A0 E9 A5
2F 18 00 01
00 00 00 00
- normal

NVMI of the adjacent cell
- shows how cell-borders containing 'preferred' status tri's are treated separately from normal ones

Spoiler

- has preferred, merged cell-border

(before preferred)
6E 18 00 01 00 00 00 00 26 35 89 45 BB 8F FB 44 00 00 A0 40 00 00 00 00 01 00 00 00 6D 18 00 01 00 00 00 00 00 00 00 00 00 3C A0 E9 A5 2F 18 00 01 00 00 01 00

6E 18 00 01
00 00 00 00
26 35 89 45
BB 8F FB 44
00 00 A0 40

00 00 00 00

01 00 00 00
6D 18 00 01
00 00 00 00

00 00 00 00

00
3C A0 E9 A5
2F 18 00 01
00 00 01 00

(after preferred)
6E 18 00 01 00 00 00 00 26 35 89 45 BB 8F FB 44 00 00 A0 40 00 00 00 3F 00 00 00 00 01 00 00 00 6D 18 00 01 00 00 00 00 00 3C A0 E9 A5 2F 18 00 01 00 00 01 00

6E 18 00 01
00 00 00 00

26 35 89 45
BB 8F FB 44
00 00 A0 40

00 00 00 3F
- preferred flag (no readily apparent pattern)
- 3F when used as a 1byte short is 63

00 00 00 00
01 00 00 00
6D 18 00 01

00 00 00 00

00

3C A0 E9 A5
2F 18 00 01
00 00 01 00

(after water is toggled with the preferred tri's)
6E 18 00 01 00 00 00 00 26 35 89 45 BB 8F FB 44 00 00 A0 40 00 00 00 3F 00 00 00 00 01 00 00 00 6D 18 00 01 00 00 00 00 00 3C A0 E9 A5 2F 18 00 01 00 00 01 00
- no difference

(preferred removed, water left)
6E 18 00 01 00 00 00 00 26 35 89 45 BB 8F FB 44 00 00 A0 40 00 00 00 00 01 00 00 00 6D 18 00 01 00 00 00 00 00 00 00 00 00 3C A0 E9 A5 2F 18 00 01 00 00 01 00
- 3F flag is changed back to 00
- the '00 00 00 00' block is moved back after the FormID of the linked NAVM

(adjacent cell, which has the door back to Vanilla)
6D 18 00 01 00 00 00 00 DB 34 2C 45 A7 9F F9 44 8E FF 9F 40 25 49 12 3E 00 00 00 00 01 00 00 00 6E 18 00 01 01 00 00 00 F3 73 8B E4 96 23 00 02 00 3C A0 E9 A5 2F 18 00 01 00 00 00 00
- the preferred-flag block (4bytes) is different
- this cell is '25 49 12 3E' and the other cell is '00 00 00 3F'

NVMI of 000A344B (Vanilla NAVM; WhiterunExterior16, upper-right corner of cell)
- notice that this has 'Island' data-structure, yet in the CK is NOT indicated as being "Island"
(maybe because this is NOT the main navMesh of the cell; but then why is it not flagged as an Island?)

Spoiler

- has two cell-border merges
- does NOT have Island status in the CK, yet has the data structure of one

4B 34 0A 00 20 00 00 00 A5 C4 9D 46 78 AF 41 C6 0F BE 8F C5 00 00 00 00 02 00 00 00 88 96 06 00 BF 9B 07 00 00 00 00 00 00 00 00 00 01 B7 3A 9B 46 2C CC 44 C6 73 5C 91 C5 00 00 A0 46 00 00 40 C6 FC 14 8E C5 02 00 00 00 01 00 02 00 00 00 00 00 01 00 02 00 03 00 00 00 00 00 A0 46 2C CC 44 C6 9A 31 90 C5 00 00 A0 46 00 00 40 C6 F5 34 90 C5 B7 3A 9B 46 00 00 40 C6 58 18 8E C5 3C A0 E9 A5 3C 00 00 00 FC FF 04 00


4B 34 0A 00
20 00 00 00
A5 C4 9D 46
78 AF 41 C6
0F BE 8F C5
- normal

00 00 00 00
- preferred flag (off)

02 00 00 00
88 96 06 00
BF 9B 07 00
- # of merged NAVMs
- their FormIDs

00 00 00 00
00 00 00 00
- # of linked doors (none)

01
- Island flag (00 if not an Island)

B7 3A 9B 46
2C CC 44 C6
73 5C 91 C5
00 00 A0 46
00 00 40 C6
FC 14 8E C5
- two sets of XYZ coords, indicating a bounding box

02 00 00 00 01 00 02 00 00 00 00 00 01 00 02 00 03 00 00 00
?- arbitrary points and how they connect to form tri's

00 00 A0 46
2C CC 44 C6
9A 31 90 C5

00 00 A0 46
00 00 40 C6
F5 34 90 C5

B7 3A 9B 46
00 00 40 C6
58 18 8E C5
- three arbitrary points defining the Island

3C A0 E9 A5
3C 00 00 00
FC FF 04 00
- normal

[Leilene Nessel]

I think it is time to take the fight to Twitter. From what I read and saw about this bug, its a real killer to the Skyrim modding community. So if everyone bothered this bug starts to voice/tweet their discontent about it still not being fixed, we might get it to their attention in such a way that they can't ignore us.

I even made a Twitter account just for that.

#NavMeshBug is now live!

[Sophie Miller]

#NavMeshBug is now live!

Done my part.

[Lou]

Maybe it is an idea to spread the word about the Twitter movement on other TES related modding sites and ask people to join us.

I have already done so on Lovers Lab

[Liv Staff]

This is it https://twitter.com/#!/search/realtime/%23navmeshbug

Add your voice, get modding back.

[Philip Lyon]

http://www.gamesas.com/topic/1376246-skyrim-patch-16-beta-now-out/page__view__findpost__p__20824114 If you're using the 1.6 beta that is. Just don't try to fire up the CK, it'll be beyond broken.

[Eduardo Rosas]

If i don't select update .esm then ck should be fine though , right?

[Robert Garcia]

No guarantees there. A new subrecord in the TES4 main record was introduced. There's no way of knowing what purpose it serves. The navmesh fix is only in the game executable at this point, so it should be a simple matter of checking your mods that have them to see if they've been fixed or not.

[Jay Baby]

My own limited testing also indicates that the navmesh bug is finally dead!

[Rebecca Clare Smith]

Seems to have fixed the ft/return problem and the 2 cell return problem. Did have one slight problem in that when I exited my interior cell into Whiterun, the NPCs arrived at the piece of navmesh above the navmesh that the exit sits on. (The entrance/exit is underground). This could have something to do with the fact I have to use a teleport script to get back to Whiterun, otherwise CTD.

I noticed that they included some sort of memory optimisation fix as well. Just wondering if this fixes the need to actually have the teleport script in place, to avoid the CTD. I'll do some testing tomorrow.

[Edit] Shold have added, the CK still works OK, but there are a few more errors reported, mainly referring to Kinekt (something or other) ? Isn't that something to do with the Xbox 360 ?

[Marquis T]

Well there's hundreds of errors like this one:

CELLS: Dummy object ref does not have a leveled list. This ref will never be visible in game.MASTERFILE: Errors were encountered during InitItem for reference:Base: 'BirdEgg01' (0007E8C8)Ref: '' (0008AB1E)Cell: 'FortGreymoor02' (000352C7)See Warnings file for more information.

I don't know what that implies, but it doesn't look good.

The Kinect errors:

MASTERFILE: GameSetting 'sKinectNotCalibrated' in file 'Update.esm' is not recognized by the current EXE.MASTERFILE: GameSetting 'sKinectCantInit' in file 'Update.esm' is not recognized by the current EXE.MASTERFILE: GameSetting 'sKinectAllyTooFarToTrade' in file 'Update.esm' is not recognized by the current EXE.

Missing GMST's (game setting records) are usually not a big deal. It's all these other Base/Ref errors that bother me.

[Evaa]

Well there's hundreds of errors like this one:

CELLS: Dummy object ref does not have a leveled list. This ref will never be visible in game.MASTERFILE: Errors were encountered during InitItem for reference:Base: 'BirdEgg01' (0007E8C8)Ref: '' (0008AB1E)Cell: 'FortGreymoor02' (000352C7)See Warnings file for more information.

I don't know what that implies, but it doesn't look good.

The Kinect errors:

MASTERFILE: GameSetting 'sKinectNotCalibrated' in file 'Update.esm' is not recognized by the current EXE.MASTERFILE: GameSetting 'sKinectCantInit' in file 'Update.esm' is not recognized by the current EXE.MASTERFILE: GameSetting 'sKinectAllyTooFarToTrade' in file 'Update.esm' is not recognized by the current EXE.

Missing GMST's (game setting records) are usually not a big deal. It's all these other Base/Ref errors that bother me.

Crap. I've done it again and worked for a while on my mod with the beta installed...

I don't use Update.esm as a master, so is it safe to assume that I may continue working without high risk of corruption or any issues?

[Patrick Gordon]

Couldn't tell you. All I know is that whatever those errors are, they didn't exist prior to 1.6.

The main one to be unsure of is the INCC subrecord in the TES4 header included with Update.esm. It could well be that the missing 4 bytes has thrown everything off in the CK and the errors are all false. There's no way to know that though.

If you're getting the errors even without Update.esm being present, it doesn't seem like it would be safe to continue at the moment except with some test stuff to see what all happens.

[Sierra Ritsuka]

Edit strike that. I closed it down and then started it up again and I have all the errors now. Wierd.

[kyle pinchen]

Since I came on to this bug only a month ago, and then read all 4 threads on this problem (very long!), thought I'd comment here that I tested 1.6.87.0.6 Beta and it does fix the navmesh bug with my mod, ScenicCarriages, which edits/fixes the vanilla road navmeshes.

[Katey Meyer]

So what's the general conclusion; is the dreaded NavMesh bug fixed for good with 1.6? Finally, after so many years since Fallout 3?

If so, a party is in order. :B

(Wish they'd fix it for F3 and F: NV but that sounds bloody unlikely...)

Now, about the X-axis world collision bug...

[Richus Dude]

^If the cause of the bug is similar to Skyrim's, it's possible, but that's if their willing to apply that fix to an old game like Fallout3/NV.

[Jamie Lee]

I have the following problem , I have scene taking place in Cell A , with several actors , but the scene starts when talked to Actor , now if I talk to actor in Cell B , he starts talking , the talking take place even when no other actor is around and the actore doesn't go move to the cell A to perform the scene .... is that a navmesh bug?

[megan gleeson]

Now, about the X-axis world collision bug...

I don't expect an official fix for that, ever. There's however an http://www.gamesas.com/topic/1352988-fixing-the-64x64-cell-havok-bug-for-when-you-just-want-a-bigger-world/page__st__60__p__20419923#entry20419923.

[Casey]

.... is that a navmesh bug?

No, I've seen vanilla scenes do stuff like that too. I'm not sure why, but it's been hit n miss ever since launch.

[Nicola]

ok I have pseudosolved by forcing the NPC to reach first the scene location befoure any talking begins , but not always works ...