It's been over a week now, since the beginning of the Mannequin Strike at Questfall Tower. First they wanted their activators connected, then they wanted an xmarkerheading model - but that wasn't enough! No, it had to be their own personal xmarkerheading linked from the manniqiun itself. But that wasn't enough either. Now they want to stand on navmesh - just like all the regular, moving actors get. At Questfall Tower, the mannequin's union demanded and got that too.
.
But now that the Mannequins have got everything they require, the taste of freedom, afforded by their strike tactics no doubt, has them walking the halls every time the player is looking the other way. Only, one player wasn't so predictable.
.
[img]http://realmeleven.net/CAUGHT_MannequinMonkeyBusiness.png[/img]
.
Behold! The face of deception. Notice the furtive glance as if he knew that was the direction the screenshot would come from if the player just happened to walk into the cell at that very moment. Once we only imagined those devilish dummies were conniving behind our back, moving themselves into subtlely different positions to convince us all that we are going stark raving mad. But now we know. They're plotting to take over, hmm, plotting to replace us. No doubt they toss babies in the air and catch them on their bayonets too; when we are not watching.
.
Or maybe the little darlin's are ticked off because I've stuck too many of them in a cell. If they're not careful, they might wind up on the lower level where their antics will never be noticed. The time to act is now - oops, that'd be my problem, not yours - but short of sending in some pyromaniacs to break the strike once and for all, I am open to suggestions.

I've set the little darlin's up with their activation boxes (and activate parent entry made) as well as xmarkerheading with link and the navmesh extended beneath their little feet - just like the player house in Markarth. In spite of this, they wander, they even gesture and, presumably, they talk - just not when my avatar is around. If I was a companion NPC, I'd be totally creeped out. As I am developing this plug-in I am having very great difficulty keeping a straight face, for I am sorely tempted to release the plug-in with wandering mannequins doing what, I am sure, we have all seen in one comedy sketch or another.
.
But there remains a fairly serious question of how to turn this potentially hilarious behaviour on or off. Perhaps it does not help that there are 36 of them in the same cell - but I think that is, perhaps, better than having 72 in the same cell. I have, since, redistributed the interior space across three cells and I am considering moving the mischievous mannequins into a cell where the mannequin monkey business won't intrude so much on the player's use of the plug-in. Some of them have the tendency to wander, and some have less of a tendency. I am considering making a controlled placement to find out whether the order of placement has anything to do with the price of slaughterfish, and whether it really is overpopulation which is causing the problem - in which case it would boil down to performance or, possibly, a resource management problem. The other possibility is that I did something inadvertently, during placement, and now the little brush-golems are restless.
.
Either way, I'd be interested in any suggestions and I will also get back, on this thread, with the results of my proposed experiment...

i read that the mannequin script should be OnCellAttached instead of OnCellLoad. this does help, but i noticed it doesnt completely stop the mannequins changing poses every now and then

i wrote a script that uses a trigger box to physically reset all mannequins when you walk into the room which definitely does end the mannequin strike by killing it with fire, but i'm still testing it out to see if it didnt introduce any new bugs

http://www.gamesas.com/topic/1354348-finally-figured-out-how-to-permanently-disable-mannequin-movementpose-issues/page__fromsearch__1

I fixed my mannequins by first making sure the navmesh is under their feet and also rotating the physical mannequins at a 45 degree angle. Then I set the xmarkerheading in the direction I want them to face and finally ensuring I snap the trigger box to the mannequin then the xmarkerheading to the trigger. So far after several loads no pesky wandering mannequins.

Of course I only have ten of them.

Thank you http://www.gamesas.com/user/782815-crazed77/, I've now got the numbers down to 20, and I've tried 45 degrees to x, y & z axes but it doesn't seem to solve my problem.
.
Thank you, http://www.gamesas.com/user/766649-amethyst-deceiver/, for suggesting an update of the mannequin script with the OnCellAttached event instead of OnCellLoad. I tried this as a dirty edit - which resulted in twenty mannequins all looking around and looking far too alive. I did some other, minor, dirty edits to verify the cause and it is because there is no Self.EnableAI(FALSE) function firing during the cell load. Moreover, none were positioned correctly and when, as a dirty edit, I set up both events, the mannequins found stillness but not their correct positions.

But, I agree with you, the bug is either in the script or in the part of the engine which processes the script. What is happening is that the MoveTo(GetLinkedRef()) line isn't completing before the engine cuts it off and moves on. I was wondering if the action might be taking place after the MoveTo line but I noticed the wait functions don't fire properly.
.
You're right about the MoveTo command only working properly when the Mannequin is disabled - I think that's how the one in Markarth manages to appear in the right place and posture. I think the best place for the disabled moveto routine is in the core game script itself - so I'm going to set up a new base object and attach a separate version of the MannequinActivatorSCRIPT with the OnCellLoad Event replaced by the following:



Assuming things work as documented, this might just allow the problem to be fixed generically, provided the XMarkerHeading can to be linked to the container used by the mannequin - but I'll have to see how things go with only a one-way link from the mannequin to the XMarkerHeading.
.
I'll post back with the results...
.

Those boots were made for walking, mate.

I've got some mannequins in my house mod, and I've seen one of them quickly wiggle into a slightly different pose, but that's it. No wandering. But then, I haven't Navmeshed the house at all yet. Is that what causes it?

The moving mannequin problem reminds me of the http://www.youtube.com/watch?v=ck47goJk7rQin Dr Who (Blink, Time of Angels & Flesh & Stone).

"Don't Blink"

Yes, when you have a navmesh, every actor spawns on the nearest triangle from their editor location. And as they have an AI package that tell them to go to the xmarkerheading, with fragment that try to move them if the AI is disabled before the package execution, you can see them wandering or looking at something and taking any idle pose available in the default package. I have a mannequin who always sit on the nearest chair and after the cell initialisation, he was in the sitting pose but at his place. If you put the xmarkerheading largely above or under the floor, you can have the mannequin in the "flying" pose.

If your navmesh is too far from the mannequins positions, you can finish with all your mannequin in front of your door or at the nearest navmesh triangle from the 0,0,0 position in your cell, because of the pathfinding.

Take a look at the Wandering Mannequin Fix on Nexus: http://skyrim.nexusmods.com/downloads/file.php?id=10652

Also, Daemonjax creator of Just In Time Lighting (http://skyrim.nexusmods.com/downloads/file.php?id=10361) has sent me some VERY promising work on mannequins that he's done. He found a way to get the menu working that the developers either gave up on or could not get to work. It adds multiple animation stances, resetting of mannequins, and pretty much fixes them as far as I can tell. I think he's either going to work with SLuckyD or upload it himself...not sure. But it works great from what I have tested.

.
Well, better - but when push comes to shove (as it often does in the narrow confines of CPU cache) there is still the odd misplaced mannequin, odd pose, extra copies of armour (so now one of them is playing around in the smithy!), and other strange stuff - like collision meshes left behind by the occasional MoveTo command. So, I've rewritten the key portion of the code as a function, and simplified it somewhat while beefing up the relocation part of the routine - and here it is:
.
.
The EnforcePosition function can be added to the script attached to the mannequin, while the line...:
.
.
...can be added to the OnCellLoad event to call the function. This function assumes that the object used to locate and orient the mannequin is a container and not an XMarker. I prefer a satchel because it is small and seems to fit in with a minimum of fuss. So, when one sets up the mannequins, in the render window:

• The container is placed in the position and orientation desired for the mannequin,
  
• The mannequin is linked to the container (not vice-versa)
  
• It is best if the Mannequin's starting position and orientation is then adjusted to coincide with the container
  
• The "T" button (next to the NavMesh button) is clicked with the mannequin selected
  
• In the Activate Parents tab, of the Mannequin Reference window, the triggerbox (just created) is added and the Activate Parent Only checkbox is ticked.
  
• Don't forget to make sure that valid navmesh extends beneath the mannequin's feet...

That concludes the mannequin madness for the time being - at least in my case. I have twenty of the blighters being kept in line by this code and, so far, it seems to perform correctly - but I suspect time will have a few tales to tell; especially once I'm busy trying to do something else!
.
But, for the sake of safety, I'd recommend http://www.gamesas.com/user/137156-jorne/'s advice: "Don't Blink"
.

I'll have to try this out thanks. I have one cell with 3 mannequins that are no problem and another cell with 1 that is driving me nuts. No wondering on mine yet (no navmesh), but one other odd behavior I was wondering if anyone else has seen. My problem mannequin also is not being lit by any of the lights in the room until I either change its inventory or hit it with a resetReference from the console.

Changing the inventory doesn't fix the odd pose, but will get the lights to work on it, while the reset fixes everything, but has other obvious issues.

I'll try out the code you ref to see if it has any impact.

In some http://www.gamesas.com/topic/1358688-navimesh-bugs-2/page__st__90__gopid__20530010#entry20530010, I just managed to break my mannequin position enforcement script (my last post on this thread). Basically, as resource management became more stressed during testing, more and more mannequins strayed out of place. This seems to confirm what I've been beginning to suspect; that the OnCellLoad event doesn't complete if other processes are making higher priority demands. Moreover, this problem intensified the most when the Creation Kit was running at the same time as the game, while it was only minor when the game ran by itself. All this points to the OnCellLoad event getting insufficient priority which would cause the random failure of texture and mesh loads (including NavMesh) and really odd things like this mannequin monkey business - all with greater proliferation as system demands intensify.
.
This gives me an idea for an imperfect workaround involving an activator (such as a switch) and an attached OnActivate event. Next time the system is under stress, I'll report back with the procedure and the outcome.

the dark mannequin bug is caused by having too many lights at the same time.

as soon as i rolled back a couple of my lights in the room, the problem went away

.
I hear it's just the shadow-casting lights that cause this kind of problem and only when there are more than four, but I'm yet to take a closer look at the weird shadows in my plug-in as there have been, ahh, more exciting problems of late...

the shadow casting lights certainly do affect the issue to a higher magnitude, but all lights have a performance cost, even basic omni lights. having too many of them can cause the shy mannequin issue

.
I've actually given the whole lighting optimization thing a go. Well, half a go, anyway. Because the key cell has windows, I set it to daylight ambiance, and reduced the number of lights drastically. While all the major structures are indicating they are lit by more than one light, the overlap is reduced and smaller models are mostly lit by only one light now or two at the most. The mannequins were beginning to act up with all the extra lights but, once I got the lights under control and the cell's base ambiance directional lighting correctly calculated (before committing to the "Use Sky Lighting" checkbox), things calmed down completely. Now I have no more strange blocky shadows, the ambient lighting which varies with time of day in the windowed cell and the few candle-lights fade to deep shadows at night. These nicely balance with the night ambiance so that the contrast shift between the two gives a fairly accurate representation of night vision, courtesy of the game engine accurately approximating the speed of iris response and resulting fade-in & fade-out of night vision as light varies in field of view.
.
So thank you very much for pointing me in this direction...