setlinkedref(objectref,keyword) not working for me

[PJMail]

To be more explicit - using it to change an existing linkedref is not working.

 

akActor1.getlinkedref(aKeyword) returns (say) akActor2

I then do akActor1.setlinkedref(akActor3,aKeyword)

akActor1.getlinkedref(aKeyword) still returns akActor2 !!!!

even after akActor1.setlinkedref(None,aKeyword) (normally removes the linked ref)

akActor1.getlinkedref(aKeyword) still returns a non-null answer - you guessed it - akActor2 !!!!

 

These lines are one after another in the same Papyrus procedure (Fallout 4 - latest version).

akActor1,2,3 are objectreferences (NPCs), and the script is on akActor2 (extends Actor).

 

The following context is probably the key - but it shouldn't be...

 

This linkedref is being used in a currently active package on akActor1 (as part of a travel package),

That package also has a conditiional "subject.haslinkedref aKeyword == 1.0".

The keyword is 'known' to the game (a default object) - "LinkVehicle".

The package has no scripts in it that set this linkedref.

 

I am effectively trying to disable this package by removing the linked ref (so the above condition fails), but not only can I not do that, I can't even CHANGE where that linked ref points to.

 

So, is there some mechanism in packages to 'lock' linkedref's they are currently using, or is the game saying 'I know that keyword and I will do something special with it', or something else?

 

Hitting yet another FO4 scripting brick wall...

Edited March 26, 2021 by PJMail

[SKKmods]

Hey I just had exact same thing Switching LinkedRef target on a travel package still persisted to the original inkedref target.

 

Looks like a package caches the target and doesn't release it while it is active.

 

Solution = force a package change, update the linkedref, switch back:

 

 

 

InfectionBot.SetLinkedRef(None, pSKK_COVIDPackageLink)
InfectionBot.EvaluatePackage() ; Conditional linkedref is cleared to release packages for update.  
While (InfectionBot.IsDead() == False) && (InfectionBot.GetCurrentPackage() == pSKK_COVIDInfectionBotTravelPackage)
   Utility.Wait(1.0) ; no bailout counter !
Endwhile
InfectionBot.SetLinkedRef(DestinationWorkshop, pSKK_COVIDPackageLink) ;New package destination
InfectionBot.EvaluatePackage() ; Travel package is top of stack

 

 

 

Pro tip: make sure the actor actually has another package to switch to e.g. default master stack else the logic can get stuck.

[PJMail]

Not sure that helps me as changing the linkedref was what I was attempting to do to cause a package change.

The package with the linked ref is 'top of the stack' already, and the condition holding it there is also the same linked ref it uses - which it won't let me clear.

Obviously I could add another condition (ActorValue say) - but that would involve overriding a base package (and I only do that as a last resort).

 

I assume I am missing something in your explanation, sorry... I can't force a package change without modifying the package itself (which I prefer not to do) or add another package to the Actor's stack (which would require an alias etc - also something I don't want to do).

 

There are other packages lower in the stack - which Iis what I want the actor to run...

 

Papyrus seems to have no way to manipulate the package stack directly either.

Edited March 26, 2021 by PJMail

[SKKmods]

To try another language approach:

 

It looks like package targets (for example but not limited to Linkedrefs) are held persistent in a package whilst it is active.

 

Therefore a simple package target change can not be used to trigger (a) change a package or (b) update/refresh a package.

 

Therefore another condition is needed to release the package, plus an EvaluatePackage() call to ensure it happens now so a target change can take effect.

[niston]

Thanks SKK I was hoping you were going to answer this one :)

[PJMail]

Confusion on both sides I see.

SKK - I appreciate you confirmed the situation, but I thought you were suggesting your code fragment could resolve it. That was all I was asking.

Glad we are all in agreement that it can't without extra conditions being added to the package to break the deadlock.

 

Now to find the least ugly solution.

[PJMail]

Well, even if the NPC is running a package without any reference to the linkedref (linkvehicle), I cannot change it.

 

Looks like the real cause is the "Followers" quest has a 'linked alias" on every follower linking keyword "linkvehicle" to "lastplayerVertibird"

 

So a 'linked alias' locks the linkedref, not the package (at least in my case)...

 

Thanks for your help SKK but obviously I lead us down the rabbit hole in the wrong direction. Do you think your issue may also be Quest "linked Alias" locking the linkedref, or is it still possible Packages can do this too? You implied it was a caching issue though (so I assume you could change it but it was ignored?)

Edited March 28, 2021 by PJMail

[SKKmods]

My issue was for my own unique keywords so definately individual package instances on actors not refreshing targets whilst active. Had the same thing with follow NPC on linkedref, when the leader dies and script switches linkeref the followers stick with the corpse. So package data on an actor will only update when the package is inactive on that actor.

 

Interesting if an actor > object linkedref is forced via a quest alias then it persists, ... as any other forced quest data like factions/keywords/spells can be removed in script. I'll try to find the time to test that out.

[PJMail]

Ah - I have only every moved the location of the Linkedref object (xmarker) before, not changed the object it was pointing to until now, so never had a problem.

Your issue is not entirely surprising once you pointed it out (caching) - so good to know.