Calling EVP will only work once

[FiftyTifty]

So I've made a companion framework, and it works by having a wee UDF that changes the number of tokens in the NPC's inventory, and then calls EVP afterwards. This works once, but calling EVP subsequently doesn't do anything, the NPC continues with their old package despite it's conditions no longer being valid.

 

There are two sets of package flags:

 

Sandbox & Follow packages - Continue if PC Near

Guard packages - Continue if PC Near, Weapon Drawn

 

The script that calls EVP is:

scn AAAFyTySetActivePackage

int iNumTokensToAdd
ref refInventory

Begin Function {iNumTokensToAdd, refInventory}

    refInventory.RemoveItem AAAFyTyCompanionToken 13
    refInventory.AddItem AAAFyTyCompanionToken iNumTokensToAdd
    refInventory.EvaluatePackage
    
End

And this is one of the dialogue scripts:

 

 

call AAAFyTySetActivePackage 5 GetActionRef

 

As it works the first time it's called on the NPC, it should work just fine. The appropriate number of items are given to the NPC depending on it's package, so it's not an issue of residual tokens staying in the NPC's inventory.

 

Any idea what the problem is?

Edited November 19, 2018 by FiftyTifty

[dubiousintent]

Make sure that only one AI package condition variable (or set of variables) is TRUE at a time. Otherwise the first package that evaluates to TRUE (from the top down in the list of packages) is always the one executed by an EVP.

See the note (at the bottom) in the 'TIP: Making NPCs move (aka "AI Packages")' regarding the use of "AddScriptPackage <packagename>" under the Custom NPCs section of the wiki "Getting started creating mods using GECK" article. From the GECKWiki on that function:

Unless the added package has some constraint on it ("must complete" and/or "must reach location"), it will be removed the next time the actor reevaluates his package.

The further implication is that a package added by that function is removed once it has completed, period. Such added packages are intended to be "temporary".

 

Also: Your function is removing "AAAFyTyCompanionToken 13". The purpose of that is not clear, but unless you are restoring it elsewhere, one would expect that statement to "fail" after the first execution. As it is a valid statement the first time, you won't get a compiler error. I'm not clear on what will happen the second time through, but it might be causing the UDF function to fail at that point.

 

-Dubious-

[Mktavish]

I wish I knew more about these ... But this line in the wiki stood out at me since your problem is a recursive one.

 

Notes

• UDFs may be used recursively by saving the script once first without the sub call.

~~~~~

 

Ahhh dubious ninja ... hehe

But ya , that makes sense .

[FiftyTifty]

Make sure that only one AI package condition variable (or set of variables) is TRUE at a time. Otherwise the first package that evaluates to TRUE (from the top down in the list of packages) is always the one executed by an EVP.

 

See the note (at the bottom) in the 'TIP: Making NPCs move (aka "AI Packages")' regarding the use of "AddScriptPackage <packagename>" under the Custom NPCs section of the wiki "Getting started creating mods using GECK" article. From the GECKWiki on that function:

Unless the added package has some constraint on it ("must complete" and/or "must reach location"), it will be removed the next time the actor reevaluates his package.

The further implication is that a package added by that function is removed once it has completed, period. Such added packages are intended to be "temporary".

 

Also: Your function is removing "AAAFyTyCompanionToken 13". The purpose of that is not clear, but unless you are restoring it elsewhere, one would expect that statement to "fail" after the first execution. As it is a valid statement the first time, you won't get a compiler error. I'm not clear on what will happen the second time through, but it might be causing the UDF function to fail at that point.

 

-Dubious-

 

I'll clarify.

 

The packages are arranged top-down as per the wiki, and each of them rely on a specific number of these item tokens to be present in their inventory. For example, the waiting package requires 1 token present in the NPC's inventory, and the far sandbox package requires 10 tokens to be present. The highest number of tokens that can be present is 13 (i.e, 13 is what the last package requires). Through dialogue, the player sets the number of tokens in the NPC's inventory. I do this by removing the max number of tokens that could possibly be in an NPC's inventory.

 

All the packages have one condition, i.e, GetItemCount AAAFyTyCompanionToken == 7

 

According to the wiki, packages are re-evaluated every ten seconds. With the number of tokens being different, the actor doesn't change his package, even after calling EVP and waiting ten seconds.

 

 

 

I wish I knew more about these ... But this line in the wiki stood out at me since your problem is a recursive one.

 

Notes

• UDFs may be used recursively by saving the script once first without the sub call.

~~~~~

 

Ahhh dubious ninja ... hehe

But ya , that makes sense .

 

I've no clue about that recursive thing. I guess I could just copy-paste the script into the dialogue entries, but that doesn't solve the fact that EVP isn't working, even when done through the console.

[FiftyTifty]

I'm so god damn big brained. I just have to call resetai after changing the number of tokens.

[Mktavish]

LOL you mean with "ResetAI" it now does work ?

 

Coolies :thumbsup:

 

Seems with your UDF the drastic measure was needed ?

[FiftyTifty]

LOL you mean with "ResetAI" it now does work ?

 

Coolies :thumbsup:

 

Seems with your UDF the drastic measure was needed ?

 

Yeah, it's weird. I also tried adding the packages to the npc through the console and calling evp, but that had the exact same behaviour. It would work for the first time, but not subsequently. Calling resetai, however? Suddenly it works. It's not a problem with the calls being from a UDF.

[Mktavish]

Hmmm ... well I would guess it had something to do with the Ref being created by the "PlaceAtMe" function.

Instead of a Ref you placed in geck. Which you could place them all in a remote cell , then use "MoveTo"

Albeit more tricky I suppose. Since the playerRef couldn't be used as the moveto marker , nor the dead robot.

At least I don't think so ???

 

But if ResetAI works with no hitches ... no reason to fix what ain't broke :happy:

[FiftyTifty]

Hmmm ... well I would guess it had something to do with the Ref being created by the "PlaceAtMe" function.

Instead of a Ref you placed in geck. Which you could place them all in a remote cell , then use "MoveTo"

Albeit more tricky I suppose. Since the playerRef couldn't be used as the moveto marker , nor the dead robot.

At least I don't think so ???

 

But if ResetAI works with no hitches ... no reason to fix what ain't broke :happy:

 

The intention is that the player will be able to have as many robots as they want, rather than just one of each type. That's why they gotta be spawned dynamically.

[Mktavish]

 

Hmmm ... well I would guess it had something to do with the Ref being created by the "PlaceAtMe" function.

Instead of a Ref you placed in geck. Which you could place them all in a remote cell , then use "MoveTo"

Albeit more tricky I suppose. Since the playerRef couldn't be used as the moveto marker , nor the dead robot.

At least I don't think so ???

 

But if ResetAI works with no hitches ... no reason to fix what ain't broke :happy:

 

The intention is that the player will be able to have as many robots as they want, rather than just one of each type. That's why they gotta be spawned dynamically.

 

 

I figured that was your intention. But this may well be the root of the problem ? So at this juncture is just a mention for possible future problems.