How do we deal with the navmesh bug?

[jet4571]

You were testing AI behavior with TCL? thats a new one. TDETECT for non followers and just play for followers is a good rule of thumb. Ive been watching this thread because my latest mod changes navmesh and many many items were deleted in about 6 cells in Tamriel. Only major bug I have is some buildings I added they wont exit. Otherwise they cross the bridges, swim in water, avoid buildings and rocks.. all that no problem.

 

The idea of converting my mod to .esm is not one I care to think about.

[Mundoid]

You were testing AI behavior with TCL? thats a new one. TDETECT for non followers and just play for followers is a good rule of thumb. Ive been watching this thread because my latest mod changes navmesh and many many items were deleted in about 6 cells in Tamriel. Only major bug I have is some buildings I added they wont exit. Otherwise they cross the bridges, swim in water, avoid buildings and rocks.. all that no problem.

 

The idea of converting my mod to .esm is not one I care to think about.

 

Yeah it's because the NPC's with the patrols I wanted to observe were deep in ze dungeon, so i was just flying through to the spot where I thought there was a problem. Never mind. Sorry for the off topic. I won't fluff that one again... huzzah for steep learning curves. :dance:

[expired6978]

Did you manually make your navmesh or did you auto generate it? I've manually made all of my navmeshes, optimized and finalized and I don't have this issue.

[SLuckyD]

I thought I'd weigh in here... as I just happened to be skimming through these forums for something like what I'm about to release and saw this. All this stuff (ESMs) is from Obliv and FO3 modding, and there's a TON of info on it if you go to sites with that info, and I'd actually classify this as an "intermediate level of moddery theory." NavMesh there is less info on, and I only learned it just before Skyrim was released (I KNEW they were going to be used in Skyrim, so I pre-familiarized). But as for how it all applies to Skyrim: here's my opinions on getting it all working together... it took a little while for me to get the big picture (back when I modded for Obliv), but now that I believe I near-fully understand it, the payoff is well worth studying up on (and users of the finished products appreciate not having to move their homes for each update!).

 

ESMs:

1 - ESMs cannot alter anything in another ESM, this includes your mod's ESM altering or adding to anything in Skyrim.esm (technically they can, but they aren't supposed to, and can cause unpredictable results... SUCH AS your disappearing items or NPCs not 'walkin their beat.')

2 - I use ESMs to create a base for the mod to be built off - but NONE of it CHANGES OR ADDS to Vanilla; it may REFERENCE Vanilla stuff (such as placing a new wooden plate in your worldSpace), but not CHANGE it (such as moving THE wooden plate on SUCHnSUCH table in whoever's house in Vanilla)

3 - I create ESMs by saving my mod as ESP in the CK; then opening it with TESvSnip, d-clicking the TES header and setting the "ESM flag" then saving the mod as ESM

4 - MULTIPLE ESMs... if your mod references more than one ESM, CK won't load it; so the workaround I use is to REMOVE the "master dependency" from your mod's ESP while editing in the CK (any custom objects you created in the ESM should be 'Snipped' over to your ESP so the CK knows what data to reference)

5 - the contents of your ESM AS-IS should NOT be accessible from vanilla - it should be loaded into the CK and an ESP created for the purpose of linking it, and making any changes or impermanent additions (they will be wiped out with a newer version ESP)

6 - technically, you can put about ANYTHING in your ESM (that doesn't alter SkyNilla), and for some things this is VERY desirable... such as custom containers (to retain your Player's storage when switching to a newer version ESP or using an 'addon'). Also, custom NIFs with custom textures take up a LOT of space, so should be created in the ESM - so previous users upgrading won't have to download the SAME resources multiple times) I've found it best to leave things which you KNOW are going to change in the future for the ESP

[example: the actual placement of a custom NPC... NPC created in the ESM, custom wrld/cell placement in the ESM, vanilla placement in the ESP, changes/moving NPC in the addon/upgrade ESP. This allows for any scripted interaction the Player had with the NPC in an early version to be 'remembered' even after later changes or addons... since the BASE NPC is ALWAYS stored in the ESM, yet changes and tweaks to that character (adding more dialog for instance) made in the ESP will be reflected seemlessly. Same concept for containers... those BASE FormIds/references need to be made in the ESM to "echo" into later versions of the mod.]

7 - editing ESMs in the CK - I simply retain a copy of the ESP I 'converted' to ESM, and load IT into the CK... then re-convert it after I make my changes. Once there is a final version, the ESM should NEVER change (as that defeats most of the reason for HAVING an ESM). I have had some success with manipulating SMALL changes in an ESM and not having in-game drama (like lost items in storage, etc).. but it's spurious and unreliable, so I think it best to get a FINAL BASE version ESM... then make changes in your ESP. Do it right from the beginning and spare EVERYONE some drama.

8 - the main thing (in my opinion) is that there are unique FormIDs for any custom storage; then there should be actual references (placement) of those storage objects in worldSpace/cell somewhere... this ensures 100% upward compatibility, even when your ESP moves that reference (because it exists 'perpetually' in the ESM, the game engine doesn't think you have 'new' storage for each ESP update you make, yet your changes are reflected)

9 - one final comment on using ESMs regarding ESP changes.... if (in the ESP) you MOVE a storage container (chest/etc) or mannequin (created in the ESM), it's contents won't change; but if you move a DISPLAY CASE/RACK/PLAQUE, or BOOKCASES, their contents will be puked out onto the floor (but not LOST). If you created ANY of this stuff in an ESP, then change the ESP (update), anything changed/moved will lose it contents forever (or need to be "moved")... so now I hope you see the main value and reason for using ESMs... at least how it's seen through MY perspective!

 

NavMeshes:

1 - EVERY time I've tried to auto-generate a navMesh in Vanilla worldSpace or interiors, it ends in disaster... there are too many things which were obvious edited by hand AFTER an auto-generate, so the odds of you breaking the HELL outta the game by wiping all that out is like 105%... so don't do it. EVER.

2 - vanilla navMeshes must be edited by hand - vertex by vertex is the way I do it, adding some if need be... but touch ONLY the stuff you need to for getting your mod to work

3 - if you have a custom worldSpace or interiorCell, you must generate your navMesh in your ESP... since your custom area is linked to vanilla, by auto-generating your navMesh it alters the vanilla ones it links to as well... this should NOT be done in your ESM

4 - 'finalizing' your navMesh may be where your problems arise as well, because if you have multiple cells in your area then you have to ensure the navMesh vertices on those cell borders line up to each other so they 'merge' during finalization. If this is successful, you should see a thick green line on the cell border (press "b" to toggle the grid).. if not then your NPCs will patrol only the cell they are placed in, or it may break their packages altogether (making them just stand there presumably).

5 - I have had EXCELLENT success with auto-generating my cells' navMeshes, then dragging vanilla vertices over to my custom door (usually placed outside the vanilla navMesh) then finalizing that vanilla cell. BUT ANY NAVMESHING AT ALL should be done in your ESP... NOT your ESM.

6 - there IS actually more I can go into about this, but deleting extra navMesh subrecords and 'unchanged' cells is beyond the scope of this posting.

7 - oh yea... I found that if multiple mods change the navMesh of the same cell (I tested this in front of Breezehome in Whiterun), BOTH navMeshes register! I could be mistaken, but I tested this extensively for fear that my Tower mod would be broken by other mods... it wasn't. I believe that the game engine does one of three things: it takes ALL the data and combines it all deleting the overlaps (unlikely, but ideal), it uses ALL the data from both mods period (overlapping navMeshes, which may contribute to slowdown of performance or longer load times... the latter I've experienced specifically and consistently so is probably the case), or some crazy hoo-doo root on them navMeshes to zombify them into working.

 

For an example of how all this ties together, check out my Overlook Tower mod... completely remade postCK, and being updated frequently:

http://skyrim.nexusmods.com/downloads/file.php?id=4514

 

Check out the discussion/comment section there for more details as to how this stuff works and why. Also, I'm about to release a mannequin mod, as well as a 'universal fix' for the 'wandering mannequin syndrome' people experience. These will be tied into the Tower, and I mention IT here because it uses a SECOND ESM, with an ESP to tie it into my Overlook Tower mod (in other words: an example of multiple ESM moddery).

 

Sorry for the winded lecture: I hope at least ONE person got something out of this!

[SLuckyD]

My whole point of the above post was to let you know that a "navMesh bug" may not be to blame for the errors you're experiencing. If you follow the above guidelines, you shouldn't have any problems. I don't have interiors that are more than two cells wide, so I cannot verify the "bug" you refer to... is there a mod I could download which illustrates it? I guess I could just whip up a test world for researching this... hmmm.. I'll post back eventually if noone's come up with anything.

[SkjoldBjorn]

So in other words i need to do the complete opposite of what i previously mentioned, i thought about using esm's for the navmesh and the rest for .esp's. Well i want to conserve set interior and storage when releasing an update for my mods, i want the users experience to be as seamless as possible, so this will help will most likely go a long way for that. On the note of auto-generate navmesh..i totally agree, in the cells i've tried this the navmesh goes fubar and the cleanup takes longer than hand-painting one from the scratch, so i handpaint mine to ensure a 100% working navmesh and making one from scratch makes it a lot easier to controll what you are doing. Im open-minded when it comes to seeing others point of view and this probably changed how i look at .esm's, i don't think i fully grasped an .esm's importance earlier. I will definitly have a master file controlling my mod when im done with all the things im working on. To bad i did not know this from the beginning, i've done a lot of changes to an exterior cell that belongs to vanilla skyrim, most of it is changed and not added, so i'll guess i will just keep the exterior changes to an .esp for now.

[SLuckyD]

You don't have to start all over again.. take your ESM and open it in TESvSnip. Unflag it as an ESM and save as an ESP. Now edit it in the CK as you want. What you do THEN is open that new CK-edited ESP in Snip, create a NEW and blank ESP; then copy (or move) the records you want to place in your ESM (the entire CONTgrup, any custom interiorCells and custom worldSpaces) into that blank ESP. Save it and convert to ESM, while keeping the Snipped ESP (it doesn't really matter if you leave all those records or delete them) as the file you will make changes to in the future.

 

If using this technique, don't forget to load the ESM and the Snipped ESP into the CK (click "yes" to fix header numbers), then save the ESP so the dependency is auto-set... then you can go back in and delete the copied/moved records if you want (for tidiness or whatever). I know it sounds confusing, but once you've done it a couple times it becomes second-nature... and you only really have to go through drama when 'converting' that ESM you already made. The MAIN thing is grasping the theory behind why and how an ESM is used... everything else is logistics and limitations.

 

navMeshes: even if you 'fix' an auto-gen'd navMesh in vanilla space, I'm sure there are aspects to it that noone could easily replicate. That's why I suggest loading that unaltered vanilla cell (with your ESP loaded), placing your objects, then edit the vanilla navMesh... adding a couple vertices if need be. No changes really should be made to the nillaNavMesh unless you door is placed slightly "off the grid." (my Tower mod is on the side of a normally-inaccessible cliff)

 

You also have to click the little "finalize" button if you want your doors to be linked though! But if ANY changes are saved to your ESM (evidenced by the NAVIgrup's presence in your file), the potential for unexpected happenings increases - though may NEVER manifest themselves... why gamble is MY opinion. .. and ONLY auto-gen a custom worldSpace or custom interiorCell... why destroy then rebuild something (vanilla) if it ain't broke to begin with?

[SkjoldBjorn]

Well, Drelas Cottage was a perfect place to rebuild, no quests related to the place and it got a very good location, thats why,

I have yet to experience any bug with eh navmesh though, tested it a lot without any bugs even with the basement added which is not there in the vanilla. The house is comletely untouched by any quests and is a nice home, i've gotten several positive feedbacks on it already and would like to continue this project. I have changed to the location name and cell name to make sure it works as it should, so it's placed on vanilla ground, but the old "Drelas Cottage" excists no more in my mod, it is now called "fjollheimr (mountain home directly translated)"-

So it works great now, but i want to ensure that this is a bugfree mod before it's released. So to answer the question: I do like the house, i just wanted to change into something that could replace any potionally good player house, the only good home so far is hjerim (just my own personal opinion) the other homes lack storage space, racks, mannequins, plaques and Proudspire looks to clean so on. This place was perfect, outside the cities and no quests related to this location. Besides the only thing i canged from the originals is textures and height on the landscape, the rest still is vanilla.

I've also added trees, water, bushes, rocks and so on. But i've used the original navmesh, just moved it around a little to fit the modifications i made.

[SLuckyD]

NavMeshes really aren't that troublesome, if you just stick to what the game already has (for vanilla areas, you'd auto-gen your custom areas, then fix by hand). I don't see any reason you WOULD have a problem with em.. just follow the tutorials (I found the ones on the FO3 sites very informative on this subject). The main thing is that you have to "finalize" after any changes you make to it... so they are recorded into the data and your doors are properly linked. To test this, ask one of your followers to come with you, enter your door (or stroll around the area you navMeshed)... if they follow you without problem, then there IS no problem (hopefully); if they DON'T then something has gone awry.

 

But you won't be able to place nearly ANY of it in an ESM... anything you changed in Vanilla must go in an ESP or you risk crashing Skyrim (or other unexpected results). If you add a new tree to that exterior, THAT can go in an ESM... but not moving the tree that's already there.

 

By the way, I agree with you about that location... http://skyrim.nexusmods.com/downloads/file.php?id=4514

I set up my player home right BEHIND it! heheheh... I scouted the ENTIRE Skyrim world using console-tcl.. this was THE perfect place for what I wanted to do; Drelas' cottage just made it a bit more friendlier. I do NOT alter Drelas' cottage, but in my newer versions I place stairs near the base of that mountain which may interfere with something you may want to do in the back yard area. Of course if someone were to use both our mods, both objects would be seen - but they may overlap (or some other esthetic shortcoming). NO big deal.

 

Conflicts in general aren't really as big as a problem as they were with Oblivion... I think they made revisions to the way the game engine handles mods. I haven't really had a chance to test this out THOUROUGHLY yet.... but in testing navMeshes for my Overlook Tower (in the major cities) showed me that more than one mod can alter the navMesh to a certain area and they both work. (I specifically made a test mod to run simultaneous with the Tower) This leads me to believe that each navMesh is overlaid onto the previous and they are ALL used. But as I said, I haven't vetted this out completely yet; and even if it IS true, users risk performance degradation when multiple mods keep stacking navMeshes up.

[jet4571]

You need to finalize both interior and exterior so followers will enter and exit. I had an issue with a building I added where followers and the NPC inside wouldn't exit. It was a cloned building of another i added and only the decorations were moved around and not the furniture so i didn't redo the interior navmesh. So enter navmesh mode and finalize without changes and it worked.

 

Problem with not changing the vanilla navmesh is most places to add something it would be impossible to do when the navmesh is solid or you are on a cell border. At some point you will need to delete vertices or faces. Not everything can be built on a cliff face.