Swapping 2 idle markers in patrol package causes CTD

[Belthan]

This is a really bizarre problem. I have 3 linked idle markers in a non-repeatable patrol package, which starts at Marker1. If they are linked in the following way, everything is fine.

 

Marker1 linked ref is Marker3

Marker3 linked ref is Marker2

Marker2 has no linked ref

 

However, if they are linked in the following (correct) way, it causes a CTD as soon as the NPC reaches Marker2. Marker2's patrol data doesn't have any script, but if I add a showmessage for debugging, the CTD happens before the script runs.

 

Marker1 linked ref is Marker2

Marker2 linked ref is Marker3

Marker3 has no linked ref

 

The only thing that changed here is the order in which they are linked, not the patrol data or the idles associated with the markers. I'm considering the obvious solution (move the idles from Marker3 to Marker2 and vice versa, and just leave them switched). However, I'm worried that will just hide the symptom and not fix the root cause, and a different symptom will appear somewhere else.

 

And of course, the problem is pseudo-intermittent. If you save right before the NPC starts the package, and the error occurs, it will happen every time you load that save. If you save and it doesn't happen, it will never happen when you load that save. This has been reported by multiple users of the mod, and it sometimes happens going straight from the Vault 101 exit to the quest giver to the NPC's location without saving at all (other than autosaves). That obviously isn't a feasible way to debug the problem, but it proves it isn't just one corrupted save file.

 

Ready for some more weirdness? If they are linked the following way, the problem does not happen:

 

Marker1 linked ref is Marker3

Marker3 has no linked ref

Marker2 is not linked from anything, and does not link to anything, but is still in the cell unused.

 

But if I delete Marker2 from the cell, leaving Marker1 linked to Marker3 and Marker3 linked to nothing, the problem comes back.

 

One more piece of info: most of the time the CTD just results in the standard "program stopped responding" dialog box from Windows, but every once in a great while I get a Visual C++ runtime error before the CTD. FO3Edit error check reports no warnings, but I suspect something in the ESP might be corrupted nonetheless. Anybody know of any tools that would detect that kind of thing?

[Belthan]

Sorry about the duplicate post, it's late and I hit Quote instead of Edit.

 

[rickerhk]

Have you tried testing with the esm bit set in the plugin? Navmesh in FO3 is buggy if the esm bit is not set, and can cause strange AI behavior and CTD when loading a save in such a cell.

 

Also, if you make a save in a cell, make changes in that cell, then load the save, you basically have a 'dirty save' situation and anything can happen. So Ideally you should load a save from before you ever entered the cell for testing.

[Belthan]

Unfortunately, the ESM bit is already set (mod has custom races, and resources designed to be used by other mods, both of which require it to be a master). And the save from which I'm reproducing the problem is in a different cell than where the problem happens. And the plot thickens. After a bunch of trial and error experiments to figure out why that particular idle marker is causing problems, I discovered that if I put this code in the patrol data result script, the problem goes away.

additem ArmorCombat 1
equipitem ArmorCombat
removeitem ArmorCombat 1

The net result is, of course, that the NPC re-equips the armor that was equipped before reaching the idle marker, and since it all happens in the same frame it isn't visible, and the CTD doesn't happen. However, it's a complete hack, the idles used by the idle marker don't have any conditions based on what armor the NPC has equipped or anything that seems related to that.

[freddy_farnsworth]

I have fixed a lot of mods that used xmarkers and idlemarkers for patrol markers,

I use xmarkerheadings, for the route, in the patrol pack, set a pause at each one.

I usually ping pong em, or circle a large multi cell area.

If you look what beth did, the xmarkerheadings are used for the traders. they can go from megaton to RC and work, xmarkers and idle markers cannot. So I set a idle marker in the base of the XMH to allow a idle to play if allowed/wanted. I prefer the standard pause with weapon out rather than a hand on brow scan, cause if I was sniping would wait till he did the thing to pop em. At least when normal patrol pause is used, he looks alert, hand on trigger, head tracks back and forth, looks like he is really careful. Be Careful with timing, and it works well.

I do not know what you need exactly, but use XMH for patrols way better.

I have had to delete many xmarkers and idle markers that were corrupted also.

[Belthan]

The markers are for the photo shoot sequence in Quo Vagis. Marker1 has the first half animations, Marker2 is the "intermission" where the models pause and optionally change outfits, and Marker2 has the second half animations. Since only 1 anim plays during the intermission, I experimented with using XMH instead of idle marker, and while it didn't fix the issue, it did demonstrate that the CTD actually happens when the NPC leaves Marker1, rather than when they arrive at Marker2.

 

All three markers have exactly the same XYZ coords, and I thought the lack of travel time between them might have something to do with it, but I moved them to opposite ends of the room for testing and it made no difference.

[rickerhk]

You can try testing with the NPC having no armor.
I've seen idles in packages cause intermittent CTD with modded armor. Somehow the animation mesh and armor mesh cause the CTD when together. Might happen with idle markers too. Just thought it was interesting that forcing a re-evaluation of inventory made the problem go away. Maybe the timing was just right to avoid the issue?
I've also seen modded armor cause intermittent CTD when equipped/unequipped through a gamemode script.
Unfortunately, forcing an inventory evaluation with an add/equip/remove is a necessary hack for FO3 if you are going to be manipulating NPCs. There's the weapon wristwatch issue and the double-weapon bug for starters.