ActorUtil.addPackageOverride weirdness

[xkkmEl]

Anyone have experience with ActorUtil packages?

I'm experimenting with it to place quest packages on a number of NPCs, so I don't have to count them and create an alias for each one.

I'm finding the packages don't work quite right... it looks like the package is timeshared by the NPCs... for a few seconds, the NPC is behaving according to the package, and then not, and then again, and then not...

If I put the same package on an NPC using an alias, the behavior is consistent.

I am currently testing a follow package, but I was having the same doubts with a travel package.  The destination is in an alias, so the package does refer to a parent quest.

Should I conclude that ActorUtil.addPackageOverride is broken and just create dozens of aliases?

[xkkmEl]

Unsurprisingly, t'was my own fault.

A bad interaction with a keyword condition on the package and some periodic process in my mod.

I did not expect the package conditions to be reevaluated spontaneously.  This does not happen in my experience with AI packages placed through other means (or was it the keyword that caused the reevaluation?).

[PeterMartyr]

They are packages, that override all packages in the NPC, so it kind of implied, it will not bother checking the other packages, what for?  Which make the evaluation faster.

Used this heaps, but I have never built a Package Stack using ActorUtil, if that what your doing with package conditions and package priority, let me know how it works out.

If your not building a Package Stack, and using a single override package,(edit OR multiple of equal priority) my advice is remove  all Keywords and Creation Kit Conditions from the package, again what for? 

Edit

I would leave any conditions that are part the procedure though, I meant the generic package ones for the stack evaluation.. just to clarify and avoid misunderstanding, on the single override package

[xkkmEl]

Thanks for the advice.

However, in my case, I need the condition because the package overrides even scene AIs, and I do have other scenes running on those actors, at times.  So my condition checks that the NPC has not been scheduled for these other scenes.  This only protects my own scenes, but in practice it looks sufficient since these NPCs are not really involved in other interesting or significant quests/scenes.

What I did instead, is to not attach the "busy" keyword when I temporarily place the NPCs in an alias to check whether it's a proper candidate for these other scenes.  It turns out that I did not need that keyword there at all.