Does anyone know if you can disable and enable a navmesh?

In Fallout3, we had the command 'disableNavmesh' and 'enableNavmesh'.

I see we still have the functionality to 'move selection to new navmesh' which works fine, I just can't seem to enable or disable this new 'connected' navmesh.

I have a door that will only open for the player. And I want the navmesh enabled when the door is open, to allow NPC's to follow through.
Then when the door closes, I want the navmesh to disable.

Why? Because other creatures run up against the door thinking they can get through it but can't. They look funny treadmilling on the door.

Unfortunately not. Navmeshes seem to be all or nothing affairs. The two commands you mention don't function, and you can't enable/disable them using other means either.

You could just keep using the current version

Your navmesh will vanish all by itself

Rats. Thanks for the confirmation.

LOL! Just don't leave the cell... never leave the cell... and all the navs will be fine...

I think the engine now assumes the Actors will interact correctly with whatever doors happen to close on the navmesh - either that or the state of the door cutting the navmesh may be supposed to automatically disable any navmesh that it cuts. I have a gate in my mod which Actors will stop and open on the way through - if they can open a gate or door. The only tricky bit is that they sometimes collide with the gate when it is in the open state (and I will, no-doubt, have to slit the navmesh around the open gate position to stop this from happening).
.
I can't say what happens when the actor trying to get through a gate finds it irrevocably locked (i.e. "needs a key" level of locked). I think that might be an acid test of the currently ?automated? state of the EnableNavMesh/DisableNavMesh system.
.
My advaice: don't worry; be happy; then see what happens...

There is a way round it that i stumbled upon by chance (trying to fix my own mod). Instead of using the door, disable it (or remove it and replace it after navmeshing) and put a self activate trigger in front of the door. Attach this script and set the activator script to only allow those you want to pass through.

This way, there is no green triangle on the navmesh, so others won't try to get through the door

Scriptname teleportdoor extends ObjectReferenceimport gameimport utilityObjectReference Property lastdoortraveledto Auto  ObjectReference Property teleport  Auto  ObjectReference PlayerReferenceAlias Property Alias_Follower1 AutoReferenceAlias Property Alias_Follower2 AutoEvent OnActivate(ObjectReference akActionRef )														 player = game.getPlayer()					 lastdoortraveledto.moveto(player)					 player.MoveTo(Teleport)					 Alias_Follower1.GetRef().MoveTo(Teleport)					 Alias_Follower2.GetRef().MoveTo(Teleport)endevent

Change the properties in the defaultActivateSelf script to allow you use it more than once and uncheck disableWhenDone
Change the Teleport properties in the teleportdoor script and link it to an XMarkerHeading in your other cell (you must place this as well). Do the same in reverse for the other door. Works a treat.

I should add that it's not my script. I found it posted on a forum somewhere.

This is an interior door with animations for open and close. I have a trigger zone around it so it opens when the player enters the zone, and closes when the player exits the zone. The door is set with 'BlockActivation()' which prevents anyone from actually activating the door manually.

Since its an interior door, there is no green navmesh grid under it.

With all this in mind, the actors run against the door, probably trying to activate it, but can't, and thus treadmill in front of the door. Its too bad we don't have the abilityto enable or disable the seperate, but connected navmesh, like we could in Fallout.

This is my idea, no idea if it'll actually work:

1. Leave a gap in the nav mesh between your rooms.
2. Put in a door that only the player can open.
3. Put in some doors with no mesh, or no textures (don't know how to make them though), initially disabled.
4. Script the player only door to enable the invisible doors when it's open, disable when closed.

Hopefully NPCs will be able to use the doors even if the player can't.

.
Thank you for the extra detail. It sounds more like EnableNavMesh/DisableNavMesh is broken, and not automated like I suggested. Setting a break in the NavMesh as http://www.gamesas.com/user/696011-randomnoob/ suggests is a good first step, but you'll need to follow up with a trigger zone that tests to see if an Actor entering the zone shares a faction in common with the player - in which case this friendly Actor (including any followers) is bumped across the gap with a MoveTo() function. Everyone else entering the zone is ignored, and that NavMesh gap should take care of the treadmilling - in theory...

Haven't tried it, but something like...

ScriptName DoorScript extends ObjectReferenceEvent OnActivate(ObjectReference akActionRef)        If GetOpenState() As Bool != GetLinkedRef().IsDisabled()                If GetLinkedRef().IsDisabled()                        GetLinkedRef().Enable()                Else                        GetLinkedRef().Disable()                EndIf        EndIfEndEvent 

...should work if a linked cubic collision marker's top surface is just above the NavMesh such that Bendu will walk on the innocuous marker yet other actors would be under the impression there's no way to follow.

What JustinOther suggested will work, I've tested that out before and had no trouble with it. NPCs do take it into account.

http://www.gamesas.com/user/408976-justinother/ & http://www.gamesas.com/user/176330-arthmoor/; thank you.
.
It is possible that there is just one little quirk concerning the behavior of followers that would normally activate the gate themselves when making their way to you after being separated. I think this could be resolved with a triggerbox and script which determines the open state of the gate or door and the NPC's relationship with the player before disabling the L_NavCut collision box on entry and re-enabling it on exit.
.
Of course, if the gate was there to keep some actors out, it would probably be best if it had an autoclose procedure in a script of its own.

I’m following this thread and while doing so and studying some things at TES Alliance, I found the following:


So, please tell me if my hypothetical scenario is correct. Basically, let’s say you want to add a new Inn along a road somewhere. I can place my exterior static of the Inn, draw a Collision box around it, and wherever the box goes through the navmesh, it will “cut” that part of the navmesh inside the box so that NPC’s will not try to walk through my new structure?

If so, this is great news as it eliminates a LOT of edits to the vanilla navmesh you would normally have to do, right? Obviously I’d have to navmesh in steps and porches and so on, but I hope I’m understanding this correctly.

So long as the collision marker REFR's Primitive > Collision Layer is set to http://i.imgur.com/NPly1.jpg, AI won't path over the yellow until it's disabled.

Thanks Justin, that’s great news. One other thing, and I apologize for the elementary questions, but I’ve learned the hard way not to assume too much when it comes to modding. But, logically, even things like cover edges and places where NPC’s can jump down to a lower ledge would also be disabled if they fell inside the collision prim, right? (Just making sure, lol.)

I can't seem to get it to work.

Does the 'collision cube' have to fully cover the navmesh to be disabled? Does it need to be 'in' the navmesh or above it?

All the pictures I've seen have it going through the navmesh.

Admittedly, I haven't yet tried this in game, so but I'm not sure just how precise it is. Try lining up a box so it cuts through two tris right at their edges? Might be that triangles are hidden individually. Optimally, the marker would cut off the NAVM wherever it intersects it, at least that's my understanding of it.

I'll set up a few experiments and see If I can scare up anything useful.

Edit: Working as described, but I'm still not certain how precise it is. I made a cube (512^3 units, persistent, L_NavCut) and, when a NavCutter ring is equipped, the marker is enabled and periodically moves to the player. While equipped, enemies wouldn't get close or follow me through corridors. When unequipped, they'd path to me and I'd have a melee weapon right in my face. If they were standing in the cube when it was disabled and it was then enabled, they'd back up. With the L_NavCut as collistion type, you wouldn't have to worry about anything colliding with it in the normal sense.

You have to put the box through the navmesh. Yes, it works to prevent NPCs from crossing those portions that have been cut this way.

However, you must still link doors from your exterior into your interior and THOSE require the navmesh to be finalized to update the portal data. Thus you can't avoid editing the vanilla navmesh if you expect your NPCs to enter and leave the new cell you attached.

You could script DOOR REFRs to use MoveTo() on any followers if present, positioning them appropriately relative to the connected door.

Which only gets you far enough to move your followers. Unless you intend on making followers out of whole villages, that's not going to do anything for folks wanting to have, say, an inn with regular NPC visitors who live in homes elsewhere in the village. Nor will the occupants of said homes even be able to get out of them without proper finalized door links.

Yeah, it's not perfect as work-arounds go. One could set up packages to activate the door prompting the MoveTo(), but that's a lot more seamy than properly working NavMeshes.

Are there any special 'check boxes' that the collision marker with the collision layer of 'L_NAVCUT'?

I see sometimes it works, and other times not. The door opens and they head through it. But sometimes the door is closed and they still treadmill against the blocked door.

I have the collision box covering all 4 points of the two triangles.

My script on the 'trigger zone'. The 'GetLinkedRef()' points to the navcut collision box.

Scriptname LevelersTriggerDoorScript extends ObjectReference{Trigger to open and close door}ObjectReference Property DoorRef  AutoEvent OnInit()DoorRef.BlockActivation()endEventEvent OnTriggerEnter (objectReference activateRef)if activateRef == Game.GetPlayer()  DoorRef.SetOpen()  GetLinkedRef().Enable()endifendEventEvent OnTriggerLeave(ObjectReference activateRef)if activateRef == Game.GetPlayer()  DoorRef.SetOpen(false)  GetLinkedRef().Disable()endifendEvent

Just a thought, but perhaps setting the marker as persistent (point a property at it) would bump the calculating up in priority? With my experiment, things seemed to update very quickly, like the Draugr who was after me would take as many steps forward as I took backward.

Edit: Another thought is Z rotating it 5-10 degrees so it wouldn't be on the edges, or making it a sphere. Might be that intersecting the tri(s) works better than lining up with the edges.

Mod idea: Dragonbreath.esp to ensure no one will get closer to the player than 256 units.