New Vegas: stack overflow on EquipItem call

[foxtacles]

I now encountered a specific problem with the EquipItem script
function. It is working fine in Fallout 3. However, in Fallout: New Vegas the same function results in a
stack overflow. The called function returns fine to the caller, so it
must be a side effect of that function. The stack overflow does NOT
occur when you are in any in-game menu (game is paused).

I tried to track the problem down but was unsuccessful so far. I
checked the passed arguments to the EquipItem calls 2-3 times, I
couldn't find an error there. Inspecting the stack, a chain of
functions related to "TESBoundObject" are being called repeatedly (I
really have no idea about that yet)

[roby65]

Can you write what's the address where it goes overflow?

Roby

[foxtacles]

Which address do you mean? To detect the cause of that you'll have to reproduce it

[roby65]

I meant the address where it crashes.
Anyway, to reproduce it, can i use the console?
In what "context" the stack overflow occurs?

Roby

[foxtacles]

The EquipItem script function needs to be called when the game is not paused (not in console, not in any menu)

You can use a vaultscript and make a EquipItem call in a callback like OnActorSneak, or edit the vaultmp source directly.

[Queue--]

I'm starting to investigate this. Modified vaultscript to call EquipItem in OnActorSneak like you suggested, and am getting a reproducible error in New Vegas. I can confirm it only occurs when the game is not paused. My current plan is to set a breakpoint in vaultmp.dll whenever it's going to call EquipItem, then compare what is occuring in New Vegas and Fallout 3 and see if I can tease out the difference. I also intend to whip up a tiny New Vegas mod that simply triggers EquipItem on demand to be doubly certain this error only occurs when EquipItem is called via vaultmp.dll.

[roby65]

I was thinking about that, it could be a problem with threads (reading/writing to same locations).
I can modify the gui to call a function when endscene is called in nv so the game is stopped while EquipItem is called, to test for that case

[Queue--]

No new information, just confirming stuff that Recycler already posted elsewhere:

• stack overflow isn't occuring in the VaultMP thread

I triple-checked argument declarations for EquipItem, made sure there weren't discrepancies between F3 and NV (in number of function arguments, etc.), and didn't see any problems. Well, it appeared that the ''silent'' and ''stick'' arguments were reversed for both EquipItem and UnequipItem in Game.cpp (lines 983 and 1007, ExecuteCommand), however this has no bearing on the bug.

It's a relief that VaultMP code isn't directly at fault, but now I face the arduous task of debugging a rat's nest of foreign code. So, that's what I'll work more on tomorrow. After I isolate which thread is imploding, I plan to watch what occurs when the game is paused versus when it isn't.

[foxtacles]

Just a note: I also tried to call EquipItem in the main thread of Fallout (this is required for all console only commands, otherwise they crash), but that didn't change anything.

[Queue--]

Via the delegator, right? I tried that as well when I was double-checking the memory patch that enables the delegator. When I realized what it was for I had prayed it'd provide a simple workaround for this problem. Of course it couldn't be that easy. Regardless, working on this bug has given me a good opportunity to learn how VaultMP works.

[foxtacles]

Yep, right.

[foxtacles]

I maybe found the cause of it. I don't completely understand the malfunction but here it is:

https://github.com/Recycler1993/vaultmp/commit/b656b24ed350ec7a904500ae8599df6005c2ea1d#L1L73

In fact, it also led to a bug in Fallout 3, which wasn't very clear though. The player's inventory gets borked with the above code. The last item added to the inventory always won't appear in the inventory item list. Instead, the previously added item magically appears. The situation is as follows:

Player joins. Inventory contents:

• 2x PipBoy 3000, one worn. (2 times because the GetContainerItemCount isn't aware of the default pipboy at spawn which will be fixed soon, but that's not the problem)

Player picks up some item, let's say a magnum (doesn't matter if via AddItem script or in-game). Contents:

• 2x PipBoy 3000
• PipBoy Gloves

What happened now is that the default PipBoy Gloves appeared (they are default startup equipment too, and they were missing in the first place). Now we add another item to the inventory (an item with a different base!). Contents now:

• 2x PipBoy 3000
• PipBoy Gloves
• Magnum

The previously added item appears now. That kind of delay continues (and of course leads to massive bugs in synchronization). One item is "popped" as soon as you add a new kind of item to the inventory (new base ID).

I removed the startup adding of PipBoy in the default script (it's unnecessary anyway). To me it looks that there is kind of a race condition in the OnSpawn event of the game and the calls caused by vaultmp at the same time.

(note: that bug only relates to the in-memory representation of the item list (the one which can be retrieved via ShowInventory, which is part of ScanContainer in vaultmp code). in-game, the inventory is fine [that is, all items appear correctly in the PipBoy view and are usable])

Any sequence of AddItem/EquipItem calls in other callbacks work fine both in New Vegas and Fallout 3 for me, if the "startup race bug" has not been introduced.

Maybe it's just related to the PipBoy and works for other items, I didn't test any further yet.

I can't also tell if that was the cause of the stack overflow but I can't reproduce it anymore at least.

[foxtacles]

the bug above didn't have anything to do with this it seems

[foxtacles]

also occurs on respawn - likely due to EquipItem call too, but didn't check yet

[foxtacles]

maybe solved by not hacking with the PipBoy / Gloves. needs further testing.