Bethesda's RavenRock02 cell has 1673 triangles in its navmesh. It doesn't seem that we're meant to be limited to a number below 1000. Geck whines at 2000 so....

Yes, I'm well aware that they exceeded the limits I was getting in that cell. Thinking about it now, I don't think it necessarily has anything to do with JUST the number of triangles in a navmesh. I think it pretty much has to be some combination of things that we haven't considered, or at least, haven't considered together. I'm willing to bet that someone, somehow, could make an 1000+ triangle navmesh, and not have the bug pop up.

I've had the problem with ~550-600 triangles, there's no hard limit.

I agree with this, and would argue that the number of triangles is Not the only factor here - but I have no solid proof of that without testing alot more cells. It must be at least 2 factors playing into what creates the error in the first place.

Furthermore, we have at least 3 ways to bypass the issue at present:

1. Duplicating a completed cell, deleting the original and re-linking the doors.

2. Using FO3Edit's MasterUpdate Mode to masterfy the entire mod list.

3. Convert our plug-in into a master file or master/plug-in combination as many of the big mods do.

There are pros and cons to each of the above fixes - but the point is, they Are fixes. I'm quite satisfied with that personally, though I'm going to keep testing as well to see if I can help further isolate the other factors.

Miax

Updated Testing:

I have done a bit more testing based on PoHa's assertion that he isn't (or at least wasn't) getting the bug. What I reported earlier about the "hole" in the NAVM wasn't the cause, it was merely coincidental. I tried again without leaving any empty spaces and got the bug. I started trying with different numbers of triangles and discovered that it wasn't the number of triangles or the "hole" issue at all. It is the actual shape of the NAVM.

If we think of an X-Y co-ordinate system with X being left/right and Y being up/down, what I discovered (referring back to those two pictures) is that once I NAVM the bottom section of the test level so that the NAVM in the bottom section was about equal in "X" value to the origination NAVM (where the teleport door is) that's when the bug popped up. If I removed a few triangles from the bottom area, the bug went away. Its like if you make a loop of the NAVM (even if you don't complete the loop) the bug appears. I did this repeatedly with varying number of triangles. I was able to NAVM the area in those two pictures with as little as 55 triangles all the way up to 200 triangles with the same results. As soon as my NAVM crossed an imaginary "Y" line (of equal "X" value) that emanates from somewhere close to the teleport door (or the teleport door marker or the origination NAVM vertex - as they are all very close to one another in my test cell), that's when the bug appeared.

PoHa should be able to verify this as he has done similar testing. PoHa, did your NAVM between the 404 triangle test (which worked) and the 810 triangle test (which failed) cross an imaginary "Y" line that emanated from something like I described (again the teleport door/marker or origination NAVM Vertex? This would explain why many cells do not exhibit the bug as those cell's NAVM probably don't cross back over this "line".

My next tests will be to move the teleport door marker to different locations in the cell and see if that changes the imaginary "Y" line. I am pretty sure that the bug is not related to a COC marker as I have other cells without them that still manifest the bug. If moving the teleport marker does not affect the location at which the bug appears, then I would have to say that the imaginary "Y" line is based on the origination NAVM vertex.

I'm afraid the Y line theory doesn't hold up in my cell. When I added triangles to go from 777 to 811, I crossed a Y line that I had already crossed earlier.

If this works:



Then it leads me to believe that there's something, somehow that we're doing in the navmesh that it just doesn't like; that being because you'd have to recreate the navmesh in the new cell, no? A particular setup of triangles (ie, too narrow a path, too thin of triangles, or too large of triangles; perhaps in a completely different location from the test area, just so long as its in the navmesh somewhere) + a certain number of triangles as determined by some wonked out formula, might cause it. Just another theory to throw in our little bucket.

[tests something]

Dang... I did a balance for optimization on the 811 navmesh, which changed it down to 770 and got no bug.

Duplicated a room, and navmeshed the bottom floor

845 triangles: no bug

I tried the Balance for Optimization on my small test cell, but the bug remained.
Hmm... I'll start playing with your test cell PoHa, and see if I can't find some (any) similarities as to when the bug starts to manifest.

Hey, PoHa. I was able to reproduce the "Y" line test with your cell quickly. The layout of the cell from your previous posted link didn't have any area that looped back toward the teleport door. So that cell shouldn't (and didn't) produce the bug in its native format. I added a hallway that looped around the back to test my theory. I only had to NAVM a short distance to reproduce the bug. I have included a link below to your updated "TESTCELL". That ESP will not produce the bug. All you have to do is extend the NAVM one full hallway piece to re-produce it yourself. Note that when you do extend the NAVM, it will be equal to or "behind" your teleport door on an "X" axis. Your test cell and my test cell are oriented 90 degrees different (Your entrance is at the bottom, mine was on the left side). So your's needs an "X" line, while mine needed a "Y" line for referencing where the NAM crosses back. I can produce and remove the bug at will using this technique. Removing the offending NAVM triangles does remove the bug (not that the triangles themselves are the culprit, only where they are located in reference to the teleport door/marker/triangle).

I would be curious as to what you did to get the bug to manifest during your testing. Did you add new dungeon pieces that weren't in the linked esp?


http://www.megaupload.com/?d=WMR2G7TM

EDIT: This can't be the only "thing" that causes the bug to manifest, as I have other cells that do not loop around behind the "entrance" area but still have the bug. These cells do have other looping sections though. More testing is required.

Yet, when I was duplicating vault pieces and adding more triangles to the navmesh, I never looped back, along either axis, and got the error.

Although... after a balance for optimization, the error went away...

[tests]

(Added another room, which runs past the door's X axis, and navmeshed a ways in; made sure that the navmesh crossed the door X line)

858 triangles: bugged

(Got rid of the triangles that were past the door X axis)

854 triangles: not bugged

Soo... it seems you have something.

Hey Yall..

It's a big deal that now we're finally to where we can have a small cell that works, then add a couple triangles, and that induces the bug, and we can really just see it happen plain and clear.

One of us should do this:

Make a level that is as small and simple as possible in which the problem can be caused. Save two versions of it to hard drive. One version will have the navmesh made all the way up to where the problem does not happen, but is about to. Other version will be that, plus, it has the extra triangle(s) that breaks the .esp. Then, a text explanation of just how to create the problem goes with it.

Others among us should verify that the problem is duplicable with what's in the zipfile - - meaning, that if someone sends someone else the zipfile, that person can test the version of it that does not fail and it works as expected, and then when the person makes the edit to that level so that it corresponds with the navmesh in file #2, they clearly induce the bug.

Then, that stuff should then be packaged up and gotten to Bethesda. I feel sure that whoever created and continues to work on their navmesh system would find it interesting, maybe even interesting enough to fix it for us :>. But let's not waste his time, let's get it perfectly duplicable for him.

The exact reasons for the problem are interesting to try to find out on our own, but I am certain that Bethesda's navmesh guy is much better at it than we are. Like, to a whole different scale of better.

What would be an interesting test is if someone could try this on different versions of the game and/or GECK to see if a patch created the error or not.

I agree completely. I don't know if the esp that is linked in my last post is small enough for what your saying, but it is setup just like you have said. It does not show the bug. If you add 1-2 triangles, it will break. Try it out and see for yourself. The instruction are in my last post as well.

It exists in all versions of the game, including the CD-installed, unpatched one, I tested for exactly this.

I can't speak for the earliest version of the GECK but it's done it for at least the last 2 versions.

I've found that the cell can be used this way, but I had to extend that section of navmesh 2 sections down, not 1. And, deleting the offending new triangles does restore the navmesh's function, so that's cool.

So we have 100% reproducible errors. Can someone with contacts at Beth PM this thread so we can get an official response?

They are already looking at it.

Per Tarrant's post, we should summarize Good and Bad copies of the test cell, write up a bug report and post it for them.

Great work on finding the bug!

I re-iterate for all of us who have built cells with complex Navmeshes, at least we can "fix" the big through cell replication/replacement. Heh, kinda funny, sounds like Gene Therepy.

Miax

I've put together a zipfile which I think will allow anyone with GECK understanding to duplicate the problem themselves. I'm uploading it now, but because the file contains video, it's going to be about half an hour for it to finish (my upload speeds from home are ass). I'll post back when the upload is complete.

When it's done uploading, I'd like for a couple people to download it and see if they can use it to create the problem themselves. Assuming it does work for people other than me, we could at that point get it to Bethesda.

Assuming that the zipfile I've put together works as we're hoping, I don't think it's a matter of waiting for a response to a forum thread. We just wait for next patch and either a cool surprise will be in it, or there won't be.

When it's done uploading, it will be at http://www.finhosting.fi/~fallout/downloads/HowToBreakNavmesh.zip . But' it's not done yet, and you can probably download faster than I can upload, so you're gonna end up with a truncated file if you try to grab it before it's up all the way.

Just upload the video to youtube seperately?

*gulp* I can't just copy my cell and delete it... the deletion being the bigger issue.. the REFs don't copy over and I'm referencing the refs elsewhere..

..Assuming that the copy-delete truly works, even for a complex level like mine, that's so harsh to do in my case that I'd sooner wait for the underlying problem to be fixed and then make whatever changes are necessary at that point.

I think that I'd rather re-navmesh the whole thing by hand than delete my cell and then have to figure out which invalid condition in which AI package is causing the GECK to crash.

Nah... this way, people can watch the videos and pause and rewind and do whatever to them without svcking bandwidth down more than once. And, these videos aren't of interest to the entire world.

Neither is most of the stuff on Youtube! :rofl:

I'm with Tarrant on this one as my mod is just full of NPCrefs that are also refed elsewhere. I'd prefer the ESMify fix over the dup/delete fix. I'll uust live with the bug until such time as the mod is ready for release, then ESMify it. If a true patch fix comes, I'll modify the mod then accordingly.

Assuming nothing bud, this was tested by two people and confirmed - try it yourself!

As for re-navmeshing, that depends on how complex the navmesh is versus how many references have to be re-clicked. Certainly it will depend on the mod author and the complexities of the mod.

I don't relish you having that situation, I was merely stating that I'm grateful the option at least exists eh?

Miax

The file is up, please let me know how it works out!


http://www.finhosting.fi/~fallout/downloads/HowToBreakNavmesh.zip


And Miax, on the copy/delete/ fix... it sounds great if you know about it during level building and can use it then. Then meaning, BEFORE you put all the refs in and set up a gazillion AI packages that reference them.

It svcks have the GECK crashing every time you try to look at the AI packages. The GECK crash is THE reason I don't want to do it. If you have that kind of bad condition in a package like that, you can't even examine the list of packages in the GECK, you get insta-splat. You have to guess the correct NPC that the package lives in, view it there, and edit it in that spot.

Oh.. and if the package isn't in an NPC... *wonders*.

I am downloading it now. At 122Kb/sec it going to take a while.....