[Amber Hubbard]

How exactly is "a moderate amount of clutter" being determined? What do you mean by exiting the cell? What if the ESP doesn't HAVE custom cells? Are you sure this isn't just because of some issue with using an incorrect patch level on the game and CK? Does it only happen in isolation with only your mod loaded and NOTHING else? Are all of the mods in the mix being built with the correct version of the CK for the currently released version of the game?

There are a lot of reports about this, both here and on the Nexus. I, myself had the same problem.

A moderate amount cannot be specifically determined, but mods the size of Breezehome, with an extra room, seem to kick the problem into play.

By exiting the cell, it means that when you go to exit via the door, into the exterior world, the game either crashes, or sends you to the big grey void (which can be quite scary at times).

No it doesn't just happen with ADs mod, as I mentioned at the start of this post. There have been a lot, possibly 100s of people who have had the same problem (including me). With many folk, the mod is fine up to a certain point and then they add more to it and suddenly the game crashes when they exit their interior room.

It happens on both the 1.4 and 1.5 matching CK/game versions.

[Edit] It doesn't only happens with custom cells. Editing the current vanilla cells can also cause it to happen. It does however, only happen in mods that have cells. By that I mean, armour mods and suchlike are not affected.

[Kerri Lee]

Yes, but are those problems of a nature that are useful to figure out the problem? That's basically all I'm getting at. There's been vague "memory problem" reports with mods going all the way back to Morrowind, and in every case I've ever stopped people to anolyze in enough detail on, it's been because of poor load order management or grossly overloading the game with mods.

Loads of people with Oblivion have well groomed load orders that push beyond the load limits. Not a single one was accomplished though without mod cleaning (something we can't do yet), proper load ordering (BOSS), liberal use of Wrye Bash, and sensible numbers of texture and graphics mods. If Oblivion can handle someone who has 500 mods loaded, Skyrim should be able to do the same so long as people are following good modding habits.

I've had plenty of exchanges with people who, for example, chose to blame one of my mods for some mysterious issue. When I pointed out the fact that I too was using the same things they had in their load orders, but mine was ordered properly and theirs wasn't, it usually put an end to the blame game posts I see everywhere.

There's far too much of that going on with Skyrim. FAR more so than there ever was in Oblivion or Fallout 3. Especially from the crowd that flood comment threads at the Workshop. For whatever reason, there seems to be a massive rebellion against the established tools for the job. TES and Fallout modding will never work as a random plug n play system. It simply can't. BOSS and Wrye Bash will be absolutely necessary for the long term health of the modding scene. The only missing component here is something that can fill the shoes of TESVEdit. Until we get one, Skyrim's modding scene will be plunged into as much chaos as Tullius blamed Ulfric for causing.

[Mark Hepworth]

I actually agree with Arthmoor on virtually everything he's been saying. I believe people using Skyrim seem to complain more than previous games because there are more Users who simply don't know anything about mods or modding. Many seem to think you can just tack it on the end of the game and have it run... and to be honest, I was the same way when I first began using mods for Oblivion. It wasn't until I was using so many that I had to start merging and fixing things... which started my actual modding. How many out there aren't THAT interested in it though? How many just want to play? That's why I don't use the Workshop.. too many things can go wrong as it's too young a 'technology' to offer so one-click-edly.

But regarding the memory issues... I kinda remember in Oblivion there was a limit as to how many items could be placed in a single cell (256 was it not?). While I haven't seen any mention of that for Skyrim, and some Vanilla interiors have WAY more than 256 objects, is it possible that this may somehow still be a hidden issue in some cases? Could there be yet-more legacy code floating around causing problems?

And it isn't just memory issues either; there's GPU management issues... then the whole script timing drama. SaveGame data seems sloppier as well, but that may just be a new over-reliance on that data which modders haven't come to grips with (or worked-around) yet. I've said it before... Skyrim is a huge step up in gaming, and its potential is phenomenal.. but I believe it coulda stayed in the oven a little longer, got a little more brown before serving it up to all us hungry modders.

[EDIT: While I'm being honest... I'm not ashamed to admit that I had a crush on Laura Ingles back in the 80s (Mary was too old for me). Why'd ya have to go and mention 'Little House'? heheheh.]

[ANaIs GRelot]

i can replicate the issue (both cause and effect) every time. no conspiracy theories here.

i have it isolated with no other mods active. theres nothing to elaborate on. there is a threshold, once you hit a certain number of objects and script-based items (some times more than others, i don't know an exact number), when you save the esp, the game will CTD when exiting the cell anywhere besides Tamriel or another interior (usually doesn't CTD when you exit directly to skyrim, but will CTD 100% of the time going into a smaller worldspace or custom one, or even the main menu).

this issue only exists on esp's, more specifically, if the navmesh is on the esp. you can have the cell with all the clutter in the esp, but if you move the navmesh into an esm, the problem is gone.


and btw i'm not talking about 400 bookshelves here.

my interior started crashing on exit even before it hit the object count of a large vanilla interior like Blue Palace

if ESP's limit your build to a size that is smaller than what vanilla game is capable of, then what is the point

[naome duncan]

I'm not aware of any such 256 reference limit in a cell in Oblivion. I'm pretty sure some of my own stuff even has more than that scattered about. I know I've seen other mods with insanely long lists of references in a cell. You sure that's not a Morrowind limitation? That sounds more like something that would affect that game since it has a crude representation of cells as we know them today.

Script lag is a whole other beast that's starting to become a real problem. From what I've seen, it's more or less like Papyrus regressed back to how awful Morrowind's scripting engine was and where a simple mistake could cost you measurable frame loss along with blocking up all the other scripts that want attention. Many of the same issues seem to get discussed with MW and how things stick to the saves. Apparently before the MW Code Patch, you couldn't even reliably change your load order. Even with the MWCP you can't change a game script on the fly with a mod update. Much like what we're seeing with Papyrus holding on to invalid script data.

It's almost enough to make you want to ask if they're sure they built Skyrim using the correct source code branch.

@Amethyst: Have you got a file that reliably causes this problem that you'd be ok with sharing to test?

[Stephani Silva]

i can replicate the issue (both cause and effect) every time. no conspiracy theories here.

i have it isolated with no other mods active. theres nothing to elaborate on. there is a threshold, once you hit a certain number of objects and script-based items (some times more than others, i don't know an exact number), when you save the esp, the game will CTD when exiting the cell anywhere besides Tamriel or another interior (usually doesn't CTD when you exit directly to skyrim, but will CTD 100% of the time going into a smaller worldspace or custom one, or even the main menu).

this issue only exists on esp's, more specifically, if the navmesh is on the esp. you can have the cell with all the clutter in the esp, but if you move the navmesh into an esm, the problem is gone.


and btw i'm not talking about 400 bookshelves here.

my interior started crashing on exit even before it hit the object count of a large vanilla interior like Blue Palace

if ESP's limit your build to a size that is smaller than what vanilla game is capable of, then what is the point

This bug is very real for me and many other modders as well. It think this has been reported at least a month ago.

[Lucy]

this issue only exists on esp's, more specifically, if the navmesh is on the esp. you can have the cell with all the clutter in the esp, but if you move the navmesh into an esm, the problem is gone.

So let me get this straight, please let me know if this is wrong:

1. Make a backup .esp
2. Make a duplicate of the .esp and change to .esm
3. Using tesvsnip/mod details button remove everything in the new esm except for the navmesh's
4. Using tesvsnip/mod details button remove navmesh's from every cell in the .esp
5. Load only the esm in the ck, accept the header change. Save. Quit CK
6. Open CK, load esm and esp and make ESP active file. Save

Am I missing any steps? I am at work at the moment otherwise I'd try myself. Do I need to do anything else to make the esp dependent on the esm?

- Hypno

[Ashley Tamen]

honestly, i don't recommend it unless it is an absolute last resort. i was making a point that esp's and esm's are fundamentally different in handling memory in relation to navmeshes (whether this is intentional or not). although yes, it does fix that issue if you have the navmesh on the esm, but you are opening it up for other problems. for one, you cannot have your interior properly connect to tamriel, and 2, having the esm navmesh like this seems to cause the missing architecture bug more severely than if it were on esp.

its a lose/lose situation unfortunately. there is no real fix to any of these problems. you just have to decide, would you rather get punched in the face or in the ****

[Lexy Dick]

If want to look at 2 mods that offer an esm+esp option over on Nexus ... check Terramis and ExplorerDungeonPack .. for both using what they did was able to get them to load where as pure esp's they would not load.

Simplified (a lot) the esp has the connection to the outside world (to include the doors in the interior and exterior cell) and whatever is placed in the outside world (building .. doors .. etc), and the esm has the interior cell (with navm and all).

[Undisclosed Desires]

The connection to the Tamriel space requires navmesh edits though. So you're still going to have the issue no matter how you go about it. Otherwise your doors are only good for the player. NPCs won't be able to use them.

[katsomaya Sanchez]

If want to look at 2 mods that offer an esm+esp option over on Nexus ... check Terramis and ExplorerDungeonPack .. for both using what they did was able to get them to load where as pure esp's they would not load.

Simplified (a lot) the esp has the connection to the outside world (to include the doors in the interior and exterior cell) and whatever is placed in the outside world (building .. doors .. etc), and the esm has the interior cell (with navm and all).

it will function, it's just not the correct way to do it (although we have no choice otherwise).

the navmeshed esm has navmesh info in the NAVI group with no ONAM. it may work fine for you during testing and initial playthrough, but as soon as you start adding in other mods with NVMI edits, the whole thing starts to cave in (missing architecture and statics in several RANDOM places, but most frequently in DB sanctuary, Helgen, and whiterun)

long story short, it works, but its dirty as hell. it is NOT a solution to the navmesh bug, it just offers an alternative bug in place of another bug (you decide which is worse).

it is physically impossible to create a clean esm/esp pair with the given tools we have. some are more successful than others, but none are legit

[Jerry Jr. Ortiz]

I'd like to reiterate (yet again..) that NOT all Vanilla areas are affected by the NavMesh Bug. My Overlook Tower mod works just fine; as have other test-mods I made to expressly prove this. That mod adds NEW navMesh to Vanilla cells already containing some; specifically the cells behind Drelas' Cottage (other side of the Labyrinthian mountain). It connects to custom interior cells (two diff Van cells connected to two diff custom interiorCells)... everything works flawlessly; followers go anywhere I intended them to with my custom navMesh (some of which is on the peak of a mountain, and are "island" navMeshes).

What I do (and I've explained this several times already, though in the other threads I believe)... basically I use the procedure that hypno88 posted in the last comment; except I use TESvSnip to manually change the file header to be an ESM (not use the CK to somehow trigger that change, too shady for me when it takes10sec to change it manually). TESvSnip saves proper header data, but if the record count isn't manually changed to be correct (after adding/deleting records)... the CK is what changes the version # back to .85 - NOT TESvSnip. I use Snip v4.2, so it may have been updated since then - possibly breaking itself or whatever.

Another difference is where it's stated to 'Snip' ONLY the navMesh into the ESP; I Snip over ANYTHING having to do with Vanilla, most importantly ALL navMesh data (NAVI & NAVM records), as well as ANYTHING placed/added to or changed in a Vanilla cell. But yes, I make a copy of the original plugin's ESP; then convert it to ESM and Snip out anything NON-Vanilla (and vice-versa for the ESP.. Snipping out whatever remains in the ESM). This technique enables me to move or change Player-storage (in subsequent versions of the mod's ESP) without Users having to remove items before updating... THIS is one reason why I use ESMs (other than NavMeshery drama).

The other reason is to prevent anything potentially legacy from interfering - as in Oblivion, ESMs couldn't CHANGE another ESM (though ADDING to one seemed/seems to be generally acceptable, but MAY backfire). I'm fairly certain everything that is TES and FO are ALL based on previous versions, whichever was most recent at the time. If they 'disabled' code in a previous version somehow but 'mistakenly' reinstated it in a later game, it could cause issues not unlike what we're experiencing... with SEVERAL aspects of Skyrim, not just navMesh. (mannequins and their poses.. AHEM..)

THIS may be where some people's mods fail while others' work. I KNOW that ONAM lists were implemented in FO3 to enable ESMs to alter other ESMs, but that may or may not be working as intended. All I know is the way I do it, works every time UNLESS.... trying it in certain cells (see the 'Riften/Whiterun Experiments' posts in this/previous threads). Supposedly this ESM-on-ESM action taboo doesn't exist anymore... and maybe what I do is overkill, but my technique works (again, NOT for ALL areas), unless tried in an 'Anathema' area. (ONE cell WILL affect all those connected to it when navMesh is involved)


Regarding the memory issue: It cannot be defined universally because everyone's memory is being used/managed differently, depending on operating system configuration, background stuff, INI settings, etc etc - a MILLION things can be affecting this enough so as to make it 'non-universal'. Someone with less mem is presumably more prone to these issues than those with more RAM than the ghost of Steve Jobs (..too soon?). Personally, I'm not convinced it's the actual memory... my work with intense real-time scripting showed me that vidMem is NEVER max'd out on my system (even in Ultra default it only uses 3/4 of my 1gig vidRAM); and sysMem never even comes CLOSE (unless I run background progs like a 'full' CK, 3DSMax, Photoshop, etc). What my testing showed me was that the GPU is what causes script-timing issues... and LITTLE else (except for OBVIOUS system stress, induced before Skyrim is even started)

This can be extrapolated to explain Amethyst's issues with shadow lights.. 1.5gig vidRam with a decent GPU; yet two or more shadow-casters in highly-cluttered areas causes drama. My contention is that it isn't the lights per se, but the shadows they are casting that cause the drama... more objects means more shadows having to be drawn - NOT more memory being used (though that actually IS the case, more shadows=more vidMem used... but it never max's out, so shouldn't be an issue). I'd be willing to wager that the same lights +1 would work just fine if the # of objects affected by them were reduced. My GPU is ALWAYS max'd when I have issues with real-time script.. but if I reduce detail to allow less-than-100% GPU usage, it seems to work fine (unless affected by other known issues).

[Arthmoor: I never played or modded Morrowind... perhaps the supposed Obliv limitation on # of objects per cell was heresay or carry-over from MW? Of course it's possible that I'm simply remembering disinformation, or even experiencing faulty memory reconsolidation. I believe Skyrim isn't affected by a hard-coded #, but I haven't actually tried counting any cells... heheh. I HAVE added about fifty actors to a single cell in Whiterun... and nothing out of the ordinary happened (even when they ALL have onCellAttach scripts and displaying equipment). I only suggested it as some people's issues seem to only happen when in highly 'detailed' areas. While it may not be hard-coded, some Users' GPUs/etc may not be able to handle X amount of whatever.]

[EDIT: I'm not entirely convinced that what Amethyst just said really is the case.. regarding having 'clean' ESM/ESPs. Personally, I believe my files are clean, but issues in the game-engine/CK may be interfering with certain functionality (eg- LOD for large statics). I see no evidence that they cause drama of any sort... so how is it 'dirty'?]

[Tanya]

Oh agree it may not be 'correct' but I now have 5 mods working that didn't work before using this technique and although haven't really played with them all a lot, have gone in and out of 1 of them (with a follower), left the area and come back and still there. So may corrupt saves or other nasty stuff in the future but at this point I get to play some mods really wanted to try. Now not recommending or endorsing this method, just comment on what others are starting to do and what has happened only to me when tried them. The guy that has been helping folks on this goes by the handle 'cataxu' so I really take no credit for his system. it's possible that they are all lucky and picked vanilla areas that can be edited .. aka SLuckyD .. no idea. Still if notthing else works the method he came up with has so far worked and allowed more then 1 mod done this way to load .. for me anyway.

Real reason brought it up was don't like closing doors on any method that may hold a nugget of info on what is happening.

[jennie xhx]

TESvSnip saves proper header data, but if the record count isn't manually changed to be correct (after adding/deleting records)... the CK is what changes the version # back to .85 - NOT TESvSnip. I use Snip v4.2, so it may have been updated since then - possibly breaking itself or whatever.

Not true and easily demonstrated as such. Modify something in TESVSnip. Open Wrye Bash. Witness it complain about invalid or corrupt version data. The CK is not involved with that. I've run into this plenty of times myself, although at this stage I don't think it's safe to use TESVSnip. It was never updated after the last CK update and has been shown to incorrectly handle compressed record data for NPCs and some worldspace data.

[Miss Hayley]

Oh agree it may not be 'correct' but I now have 5 mods working that didn't work before using this technique and although haven't really played with them all a lot, have gone in and out of 1 of them (with a follower), left the area and come back and still there. So may corrupt saves or other nasty stuff in the future but at this point I get to play some mods really wanted to try. Now not recommending or endorsing this method, just comment on what others are starting to do and what has happened only to me when tried them. The guy that has been helping folks on this goes by the handle 'cataxu' so I really take no credit for his system. it's possible that they are all lucky and picked vanilla areas that can be edited .. aka SLuckyD .. no idea. Still if notthing else works the method he came up with has so far worked and allowed more then 1 mod done this way to load .. for me anyway.

Real reason brought it up was don't like closing doors on any method that may hold a nugget of info on what is happening.

mods will work using this method regardless (i.e. they dont crash when multiple are installed), and i am not saying it is a bad thing necessarily (i have also had to resort to an unclean esm/esp pair). the only point i was trying to make is that if people are resorting to this method, they should fully understand that it is not a solution, it only replaces one bug with another, and the author should decide if the new bug is "less worse" than the navmesh bug. and also because of the random nature of it, that the bug is almost impossible to detect on your own through testing, unless you literally visit every cell in skyrim and comb every inch of landscape. to say that there's "no problems" either means you are lucky so far, or you just havent discovered the infected void areas yet.

it could very well go through without a hitch, but in the end it is a gamble regardless. authors just really need to make themselves aware of all the risks, and maybe give a heads up to the mod users who download the mod to do so at their own risk. blindly creating esm's without understanding the potential risks is just irresponsible IMO (again, i'm not saying those authors are, i'm just saying that if people are going to advise how to create the esm/esp pair they should fully disclose all negative factors as well).

[Sierra Ritsuka]

I don't use Wrye Bash.. I never liked it for Oblivion, so I never bothered to get it for Skyrim. Not for nothin, but the version number doesn't seem to matter... one of my pre-CK releases actually had .85 I think, but there were no apparent issues with it. I understand wanting everything the way it should be; but personally, I'm willing to forego much more than some it seems.

I knew about Snip not saving compressed records, which is also not a big deal in my opinion. But both version number and compressed records are fixed when the 'Snipped' plugin is loaded in the CK then saved... so even if this drives one nuts - it isn't ALWAY like that if you don't want it to be.

I agree about warning people using 3rd party anything... the CK itself doesn't even work as it's supposed to, it's unreasonable to think any 3rd party app could do better (unless it only changes text or some phenomenally menial task like that heheh). While I try to warn and disclaim when giving advice; it ALWAYS comes down to "buyer beware".

But regarding the lingering errors Amethyst is talking about... I'm not sure I know what you're talking about. The only static-disappearance I get is because of the LOD bug, which I believe has nothing to do with navMesh, Snip, or anything but a buggy CK... at least in MY case. I haven't seen ANY negative side-effects from using this technique (ESM/ESP); but I agree that because I don't perceive them doesn't necessarily mean the issues aren't there.

And isn't ALL Skyrim moddery a gamble at this early stage? Though the CK's been out for 3 months, there are still a lot of new aspects and drama to learn, compared to previous games. Since we're all in the same boat (CK only having been seen by Ma Beth employees prior to Feb).. there are many people putting out damaging mods, even though they do everything 'correctly' (no 3rd party apps, tricks, workarounds, etc); simply because certain techniques can't be used with mucking up scripting, saveGame data, etc etc.

[Hannah Whitlock]

But regarding the lingering errors Amethyst is talking about... I'm not sure I know what you're talking about. The only static-disappearance I get is because of the LOD bug, which I believe has nothing to do with navMesh, Snip, or anything but a buggy CK... at least in MY case. I haven't seen ANY negative side-effects from using this technique (ESM/ESP); but I agree that because I don't perceive them doesn't necessarily mean the issues aren't there.

it most likely isnt happening to you because you have your navmesh in the esp (seems less prone to this type of behavior) and you dont have other multiple esm/esp mods installed which are using the navmesh in the esm. it only seems to happen when at least more than one esm navmeshed mod is installed (my guess is because we cant generate ONAM, and conflicts are possibly happeneing at the NVMI level)

if you scroll through user comments in the popular mods that use this method, you will notice more than a handful of "this mod made helge/db sanctuary/whiterun disappear"

[Chris Cross Cabaret Man]

Yea, I've seen those complaints from time to time (in others' mods' comments). I always chalked it up to conflicts or krappy modding, and have never seen it myself so never really cared. I'll test the theory about multiple ESM mods doing this...

One thing I'd LOOOOVVVVE to know is how the game actually HANDLES navMesh. When CK was first released, I tested my mod with a very popular mod (which alters the same Vanilla cells, eg: Whiterun in front of Breezehome). BOTH mods worked as expected, which means that somehow BOTH navMeshes were working - and presumably VANILLA'S as well. What I want to know is are the NAVIs stacked on top of each other? Do they somehow get merged into one? I couldn't find anything anywhere about this and gave up looking. But it sounds like it may still be a concern/issue, at least in some cases.

But if they get stacked, that poses problems if too many navMeshes are applied; how many until the engine 'seizes'? If they are merged, perhaps the game-engine can't handle it in some cases.. for whatever reason. If this is the case, it could be system performance causing some people's issues (like it does for script-timing)... too many objects, too many scripts, overly-high detail level, multiple/too many mods adding navMesh to the area, etc.. it could be several things.

[Danel]

One thing I'd LOOOOVVVVE to know is how the game actually HANDLES navMesh.

whoever figures this out conclusively not only gets a free gold ticket to visit the Chocolate Factory, but they get to keep it without having to be tricked into giving the Gobstopper back.

[Lil Miss]

I don't use Wrye Bash.. I never liked it for Oblivion, so I never bothered to get it for Skyrim. Not for nothin, but the version number doesn't seem to matter... one of my pre-CK releases actually had .85 I think, but there were no apparent issues with it. I understand wanting everything the way it should be; but personally, I'm willing to forego much more than some it seems.

I knew about Snip not saving compressed records, which is also not a big deal in my opinion. But both version number and compressed records are fixed when the 'Snipped' plugin is loaded in the CK then saved... so even if this drives one nuts - it isn't ALWAY like that if you don't want it to be.

Yes, you appear to be willing to forego an awful lot, much of which are things I can never in good conscience recommend people do. TESVSnip is responsible for the 0.85 thing. Bash will simply bring it to your attention. I never said it couldn't be fixed. Resaving it in the CK will do the job, but....

It's been found through some experimentation that TESVSnip isn't just saving uncompressed records. That by itself would be harmless, though terribly inefficient. It's that it's SKIPPING the processing of certain compressed subrecords due to an error in it's handling of the zlib data. Those subrecords then get lost and NPCs lose information. This has apparently been the case for as long as the utility has existed in Skyrim.

Because of the zlib issue, there may be issues with how it processes navmesh data (those are compressed too) as well as landscape data. I'll admit this may be exactly why Open Cities is malfunctioning in that regard, TESVSnip was used to clean out dirty edits. There could have been data loss afterward. I'd go clean out the navmeshes, but then it's a catch 22. I also have landscape data to deal with and, well, yeah. I just don't trust the thing anymore.

For my own purposes I've concluded it's NOT SAFE to use it at all now except to see what records a mod has. As long as you don't save anything with it you should be ok. I'd recommend people stop relying on it to fix things. It appears to be making things much worse instead.

[butterfly]

Morrowind on PC had a hard limit of 1024 items in a single cell, go beyond that, and you would get the Over-Flowing Loot Bag. Didn't seem to be as much of an issue in Oblivion.....

[Danel]

Ah. Well if Oblivion has a limit, it's beyond the memory capacity of the CS to display a cell that would exceed it. I duplicated a bunch of stuff until one had 22,000+ references in it. It hit just over 3GB of memory in use and was lagging so bad it took nearly 3 minutes just to display the selection indicator on all those objects. Pretty sure doubling that to 44,000 would have crashed it.

[Dagan Wilkin]

What I want to know is are the NAVIs stacked on top of each other? Do they somehow get merged into one?

Yes. Each NAVI will have the same FormID, 00012FB4, regardless of what plugin it's in. Any plugin with a NAVM will have a NAVI which, unlike every other record type, amends the Skyrim.ESM iteration rather than overriding it. Each portal added/moved/removed in a plugin is recorded in NAVI as an NVMI entry it appears, so that's probably the mechanism which allowed both mods to work in tandem.

[Dj Matty P]

Arthmoor: Using your own logic, I demand to know which subrecords are damaged by Snip and how to exactly reproduce it. I'd be curious to know the list of things you seem to presume I forego... and specifically what my mods damage. BTW... your Open Cities won't work even without using Snip... I thought I proved that with my Riften/Whiterun Experiments, but I realize that every one of those posts made you cringe; rendering you unable to read them. [not for nothin, but if CK fixes the aforementioned problems, as you seem to agree to, how is STILL not an exceptable work-around?]

JustinOther: I already knew the NAVI GRUP record is always the same single record... but it isn't true that each NAVM creates a unique NVMI subrecord in the NAVI when appending Vanilla. If one alters a Vanilla navMesh, the NVMI for that navMesh is changed but NOT given a new FormID (just as any other Vanilla ref retains its FormID if altered). What my question was, is how can multiple mods changing the SAME NVMI subrecord ALL work correctly? Either they stack, merge, behave buggily, or I'm mistaken. Maybe THIS is where they should be looking to make their bug-fix; changing the NVMI subrecords to unique non-sub records. I know, I know... that requires extensive changes in the code and game-engine... but hey; this is the THIRD (or so) game that has this issue... can they not "fix" it before the NEXT release causes drama as well? Or is it as someone suggested somewhere... regarding it being an intentional shortcoming to limit the amount of free/superior mods which would compete too much with expensive DLC?

But try it yourself... test two mods which both add a simple door to the same NAVM - they'll both work; yet if those same two mods change the same non-navMesh ref, only ONE of them registers. Why does navMesh seem to be immune to load-order & conflict? It's possible I'm mistaken, as I only tested this the week the CK was released... and not for very long; but long enough to know the mods didn't conflict. I suppose I'll go and check this again myself, heheheh - so if I'm wrong I can admit it before everyone jumps on me.

About the total ref # limit: As I said, I only seemed to remember something relating to this and suggested it out of lack of anyone else offering ideas. It came to mind since recent discussion has highlighted system performance; which may have been a side-effect of some sort of limitation. Whether this is hard-coded (you guys say no and I believe you) or manifest dynamically depending on individuals' system usage and specs...

Amethyst: How is it that they deleted the entire scene responsible for Charlie's transgression in the original film? No fizzy-lifting-drink stolen, no gobstopper redemption... and how could they go from one racial stereotype in the book (Africa), to a seemingly innocuous & fictional substitute in the orig film, then back to another racial stereotype (Latin America)? They didn't even hire more than one Latino for the acting... just digitally cloned him. Oh how this represents SO much in modern American society... and if the metaphor is stretched far enough - the discussion right here in NavMesh Bug's threads heheheh.

[Charlie Sarson]

JustinOther: I already knew the NAVI GRUP record is always the same single record... but it isn't true that each NAVM creates a unique NVMI subrecord in the NAVI when appending Vanilla. If one alters a Vanilla navMesh, the NVMI for that navMesh is changed but NOT given a new FormID (just as any other Vanilla ref retains its FormID if altered). What my question was, is how can multiple mods changing the SAME NVMI subrecord ALL work correctly?

i wonder this as well, especialy after that post i made in the other navmesh bug thread where the CK automatically writes the same 9-10 NVMI records (with vanilla ID's all in the same group of navmesh cells - whiterun, helgen, and a few others) regardless of your mods location, or even if your mod doesnt touch anything vanilla whatsoever.

i'm not convinced the questionable auto-NVMI's are supposed to generate and that it really is a bug in the CK afterall