Actor weapon equip error on cell change: Mod bug or vanilla bug?

[Tefnacht]

Hello you lovely people of LoversLab. I have a problem and need your expertise.

I have a problem with a follower I am working on. Going through loading doors, thus triggering a cell change, randomly causes my follower to mess up the way she is carrying her weapon. Since she is specialized in “big guns” this looks really stupid and is incredibly annoying.

Take a look at this screenshot to see what I mean:


The first two pictures show the result after going through a loading door (interior to exterior) with my follower running a simple follow package. She should not have the weapon in her hand, it should merely be equipped on her body, ready to be drawn.
The second two pictures show the same situation, this time the follower is running a follow package with the “Weapon Drawn” flag set. This time she should have the weapon in her hand and she does … however, she is playing the unarmed idle animation instead of the weapon idle and the weapon is upside down.

What. The actual. Fuck.

My question now is this: Since my Fallout 3 is heavily modded ... is this a vanilla bug I simply don't remember or did I do this to myself with a mod? In the later case, what kind of mod could cause this? Skeleton? Animation? VATS? Please help.

I know it would be good practice to just reinstall a clean vanilla version and go with that but I really love my modded FO3. For example, the minigun in that screenshot has no backpack. That is a mod I use and love (and removed to test if it causes this mess. It doesn't.)

Hopeful,
Tefnacht

[Guest]

I can tell you that the minigun on a side of the hand was pretty common in my NV, even on vanilla, I remember npcs like that during chaotic fights. I never had a chance to test on a companion on cell change, or to inspect deeper this issue since it never bothered me too much

 

Never seen the other issues on the picture.

 

It's a very nice robot

[Tefnacht]

Thanks for your response, A.J.

Now that you mention it, I too remember seeing the first problem happen in New Vegas. So I guess I'll book that one as a FO3 vanilla bug.

As for the second one with the upside down weapon, my guess is that it is actually the same bug. It is triggered the same way, its just the game doesn't really include any followers who actually use a follow package that has them keep their weapon drawn, so one never gets to see this particular expression of the bug.

Thanks again.

 

Now I'll have to find a workaround because this glitch is driving me nuts.

Anyone know of an elegant way to detect actors moving through load doors? (In FO3 with FOSE.) Maybe GetInSameCell as some marker reference and then, once triggered, drag the marker behind with MoveTo. Wait, that would trigger repeatedly while moving around outdoors. Does the loading screen count as a specific MenuMode?

PS: Is it just me or has http://geck.bethsoft.com been down lately?

[Guest]

You're not the only one, it's down for me too. I saw it down few months ago, too. I'm somewhat scared, I hope they won't replace it to put the one for FO4 without hosting it in some backup place... there's so much documentation out there!

 

However. Yes I do remember a menumode for loadings, but I can't check it (due to the reason explained above...)

 

Considering that OnLoad is not reliable, here some possible workaround for NVSE, I didn't test if it's for FOSE too but I think so.

ref rMyPrefCell
ref rMyNextCell
int iCheck

Set rMyPrevCell to GetParentCell

if rMyNextCell == rMyPrevCell
   ; I didn't change cell
else
   Set rMyNextCell to rMyPrevCell

   If Player.IsInInteriors
      Set iCheck to 0
      ; I'll have to refresh
   else
      If iCheck == 0
          Set iCheck to 1
          ; I'll have to refresh
      endif
   endif

endif

This probably won't refresh if you pass from a worldspace to another, but it's pretty much rare. Putting this on a Default Delay Quest should have a good execution, but in case you want it faster you could down the Delay Time to 1-2 seconds, not less.

 

To refresh the weapon position, you could try MyNPC.PlayGroup Equip 1. Same as before, didn't test, I'm following my feelings.

[Tefnacht]

Ooh.

That is so cool. I was under the impression that GetParentCell would always return the cell where a reference was originally placed in the GECK, not the cell it currently occupies. Good to know. That actually makes that function useful.

I managed to learn that MenuMode 1007 is the “loading screen” by using the WayBack Machine web archive. However, as you hinted at, this MenuMode is not reliable. I did extensive testing and it sometimes fires, usually it does not. Its useless for detecting a cell change.
This block “might” fire if you move into a new cell you've never been to before. It “might” fire if you get to see the loading screen with picture and stats, it'll never fire on a “blank” loading screen. Useless.

Right now I am using this very processor taxing method to reliably detect all kinds of cell changes:

I have a persistent Xmarker reference (CellChangeREF) my follower drags around with her every single frame in GameMode by using the MoveTo command. Every single frame it is checked if follower and this marker are still in the same cell. If they are not, we just went through a load door and need to fix the weapon equip bug.
I originally was worried that this method would repeatedly trigger outdoors as the actor moves from one outdoor cell into an adjacent one … but for some funny reason this does not happen if you MoveTo the marker every single frame. This is the relevant part of the script running on my follower:

Begin GameMode

    ;...

    If GetInSameCell CellChangeREF == 0
        AddItem EquipFixToken 1
        EquipItem EquipFixToken
        RemoveItem EquipFixToken 1
    EndIf
    CellChangeREF.MoveTo MyNpcREF
End

I like my current solution because it works instantly. You'll never see her with a glitched weapon ever again. Instead, every time you move through a load door, you will see her draw her weapon. I also hate my solution because it is so processor intensive. This script is running every single frame and only triggers once in a blue moon. That is not an elegant solution.

 

[Guest]

While I don't consider that much resource intensive, I'd be careful because spamming MoveTo was causing me random CTDs

[Tefnacht]

Hm. I'll keep that in mind.

I've now been playing with my follower using the MoveTo solution for about a week and did not notice any more instability than usual. I mean, sure, the game occasionally crashes or freezes. Its a Bethesda game after all. However, I did not experience an increase in CTDs.

What kind of reference did you spam MoveTo on when it caused your game to crash?

I know from painful personal experience that you should never try to do it to the player or actors. MoveTo doesn't work instantly on those, they only get queued up to be moved later by the engine once it comes around to actually do it (this can take several frames) and spamming MoveTo on them can easily overflow that queue and kill the game.

Marker references (like in my solution) are, as far as I can tell, moved instantaneously and seem to cause no trouble when being spammed with MoveTo.

However, I'll heed your advice and keep an eye on it.

[Guest]

I was MoveTo a xmarker with a frequency of about 1 second if I remember well (a couple of years are passed). It was following me, so that a companion could teleport there if it was gone lost once in a while, and I was passing the extra parameter to make it spawn behind. I then changed the solution with SetPos, referring to the player to get coordinates.