Need failsafe for MovetoNearestNavmeshLocation function

[SMB92]

Hi folks,

 

I've recently assumed control of the War for the Commonwealth mod, a mod of which is sorely complained about for the many CTDs it causes.

 

Due to the potentially insane number of spawns this mod can deliver, and the way in which spawns were generated and systematically placed throughout the game, the majority of crashes occur when the game tries to correct spawns outside of navmeshed areas (using the ObjectReference.MovetoNearestNavmeshLocation function.)

 

Problem is for a variety of reasons this does not always work out and the game just crashes instantly. It does try to do it a few times, but if it is interrupted by the launch of another script, it will crash the game, or if it just straight up failed it will do the same.

 

I'm not an advanced scripter by any means, no where in the caliber of Engager the original author. He is long gone now so I can't ask him. What I was thinking is, If I had some sort of failsafe script or extension that ran quite often/directly after this function is triggered, I could somehow disable the offending reference before it caused the game to crash. It may bring extra latency/strain to Papyrus in game, but I think it would be a far superior alternative to just crashing all the time.

 

Would anyone happen to know if such a thing is possible? I understand the function is native to the engine, so perhaps a F4SE extension of some sort, if I'm understanding this correctly?

[vkz89q]

What happens if you make quest that has aliases/collection alias with conditions, and those conditions are Xmarker or Retrigger or something similiar spawn points, then move 10% of the groups to marker1, next 10% to marker2 etc.. You can give them getdistance player condition too so they don't move straight to players face.

 

Then, when you need to get new spawn points, just use Reset(), Stop() and Start() on that quest.

 

Do you even need to use MoveToNearestNavMesh? I have been just using MoveTo and it never failed or crashed on me. I just pick random Xmarker and move npcs there. I have not tried to move hundreds? of npc at once tho. Why do you even need to move the npcs? Maybe stupid question but I never played that mod more than 5mins because it always crashed on me when I moved around.

[SMB92]

Well its more or less the game itself calling that function, I can give you a good scenario on how it goes wrong. Lets say you are on the other side of the bridge from Hangmans Alley, in Cambridge. If you are walking East past the top of this bridge you are in range of cells across the river. But as you are walking along you quickly move away from those cells and they unload. Papyrus does not fire off quick enough or the engine is not fast enough to correct any spawns still occurring, which will now be on un-navmeshed ground and because the cell is unloaded.

 

But sometimes the game puts up with it, don't know why.

 

Your ideas are good, maybe instead of looking for a failsafe I should implement better function over the top to begin with and avoid that altogether

[vkz89q]

Hmm, I wonder how packages would work. Instead of moving them, using MoveToPackageLocation function. With many npc's I bet "Red rocket provisioner" effect would appear, they slowly poop out of thin air like provisioners and brahmins do if you have lots of them in one place.

 

For example, that happens me like everytime I sleep in Red rocket and wake up.

 

Another thing could work but again I'm not sure how well with large numbers of npcs, but using quests to do the spawning similiar to some random quests. Spawn point aliases with conditions and then using "create ref to object xxx at spawnAlias01".

 

Oh, now I remember, I actually tested how much that can handle. I made quest that fills like 3 or so random REtrigger aliases(for spawn points), then I had 3 reference collection aliases with 200 ghouls each(total of 600) and gave them travel package and objective marker so I can see where they are going.

 

It actually worked with no problems. Whole map was filled with ghouls. They seem to "snap" to their first travel destination automatically(giving them travel package with multiple random locations, will spread them). I played for hour or so but then I got CTD when I loaded area with god knows how many ghouls, so the engine really is not best for mass number of npcs. But quest with created ref collection aliases works. It took it only like 1-2s to start the quest so it's pretty fast too. Then you can attach counter script to them so you can restart the quest when most of them are dead. The npc's "kicked" out of alias won't disappear immediatly, but nothing is holding them anymore, so they are temp now and will disappear in couple days if they are unloaded.

 

 

[SMB92]

I recall talking to someone about this before now you mentioned - even setting up ambush scenes etc and dropping in via quest.

 

I guess the drama is that the scope of this mod is so huge this would be a total rewrite. It might be better to go back to the drawing board and make something else. I was hoping to put some sort of failsafe into this mod as it is without chopping it up too much, the more I look at it the more tempting it is to tear it down.

 

Maybe I can use the getdistancefromplayer function to stop spawns past a certain point, say between 10-15K units, and see if that reduces the CTDs at least on the sane settings.

 

I guess the problem isn't that it's dropping 100's of NPCs at the lower level settings that users should be using with WOTC, but more that there are too many spawn points altogether in a given area - and Papyrus/engine can't keep up. I recently dropped city spawns to a setting of 35 down from 65 (which are both the lowest options) and it tends to last longer without CTD. In general it's rare I see crashes in the "countryside" but they happen from time to time.

 

Like you said, there is only so much the engine can handle before CTD anyway, it's hard to help an audience that is expecting 50 different groups of 20+ members on patrol :D

[SMB92]

So looking through the scripts I was provided I can see now that they are using the function in the scripts. I was led to believe that it was the game automatically doing (which there is some degree of that still happening, I think when the spawns are occurring in unloaded/unloading areas the scripts aren't keeping up with them. I can't seem to determine whether there is enough failsafe in simply just disabling the groups that spawn if they are outside of navmeshed area, but yeah I think the better way would be to only trigger spawn within a set distance to the player to minimize these ctds for now.

[Lisselli]

IIRC MoveToxx functions are latent and therefor scripts are paused until the move is complete. You may need to re-work the scripts to try and account for this function "taking its time". For example, all the important things need to happen before this function is called.

If you're going to try by distance, use the Event and not the function. You can try and re-work OnUnloaded events to disable and delete(if they are created through PlaceAtMe) when the cell is UnLoaded. OnCellDetach is no good since crossing cell borders are too easy to do. Also look at any OnTimer events. I remember one mod that spawns a lot of enemies and that had a lot of issues with stack dumping. It turns out the Timer event was not coded to stop creating spawns once it started, it was a large nested mess of loops restarting the timer.

Edited April 26, 2017 by Lisselli

[SMB92]

IIRC MoveToxx functions are latent and therefor scripts are paused until the move is complete. You may need to re-work the scripts to try and account for this function "taking its time". For example, all the important things need to happen before this function is called.

 

If you're going to try by distance, use the Event and not the function. You can try and re-work OnUnloaded events to disable and delete(if they are created through PlaceAtMe) when the cell is UnLoaded. OnCellDetach is no good since crossing cell borders are too easy to do. Also look at any OnTimer events. I remember one mod that spawns a lot of enemies and that had a lot of issues with stack dumping. It turns out the Timer event was not coded to stop creating spawns once it started, it was a large nested mess of loops restarting the timer.

Thanks for the input. I wonder if due to this function being latent, if say the MoveToNav function is called but unsuccessful and then successfully disables the spawn, if another spawn spawns and cannot get a hold of this function the game then insta CTDs. In the logs, I see this error spit out a few times for a number of different spawns, and these are usually the last things in the log, apart from sometimes one last script fires off before CTD. Also to note, these scripts utilise OnCellDetach is used quite frequently, so perhaps converting all those over to OnUnloaded would be necessary as well

 

Really good info people, thx a bunch.

[Lisselli]

Downloaded it and looked for myself. Lots of OnCellAttach/Detach use - these ARE more reliable than OnLoad/OnUnLoad. IMO you should look at how the code are structured and try out some optimization tweaks before going to other codes.

I can say, there is no need for the notifications if not testing the events.

 

Edit: I'm thinking the Attach/Detach could be crammed down, and unless the spawn points are under the terrain, or in the sky, there is not need to call MoveToNearestNavmesh, after MoveToMyEditorLocation, because the editor location should be on a navmesh anyway. (But then I would think its better to have created refs unstead of objectreferences).

Edited April 26, 2017 by Lisselli

[SMB92]

Thanks for that info, i'll look into that asap.