Provisoners acting weird

[niston]

Lots of my provisioner robots stopped provisioning. Instead, they act like settlers, sandboxing in their settlement.

Their supply lines are still up and sharing resources, it's just that the robots don't travel between settlements anymore.

Re-assigning them to another supply line does not fix it, neither does assigning them to something else and then to supply line again.

 

The only way to get them going again is to kill them and replace them.

 

Wondering if anyone of you have ever seen something like it?

[SKKmods]

Yup. share this info to work it out;

Function ProvisionerInfo(ObjectReference ThisRef) 

DebugTrace("ProvisionerInfo "  + ThisRef + " " + (ThisRef as Actor).GetCurrentPackage() + " WorkshopLinkCaravanStart " + ThisActor.GetLinkedRef(WorkshopLinkCaravanStart) + " WorkshopLinkCaravanEnd " + ThisActor.GetLinkedRef(WorkshopLinkCaravanEnd) + " WorkshopRatingProvisioner " + ThisActor.GetValue(WorkshopRatingProvisioner))

EndFunction

[niston]

Thank you SKK.

 

 

 

 

 

Well... There it is.

The offending Provisioners currently run AI package 0x38c0e, which is the WorkshopSandboxDefault package.

Package 0x26f6c is the proper one, WorkshopCaravanPackage.

 

As to why, no idea.

But I wonder, is there a way to force the proper package upon them, from script?

[niston]

A bit more info...

 

 

 

 

[niston]

Or rather nice formatting?

 

 

 

 

[LarannKiar]

Isn't this the "ghost supply line bug"? Or something very similar? I'm not sure but maybe this could help: Reddit and Nexusmods.

 

When I worked on my Supply Line Management mod, I had to use a bit different functions for robot provisioners.. well, in short, robot provisioners are buggy. Human provisioners are still more reliable :)

[niston]

It's not the "ghost supply line bug" where the actual Provisioner is absent, but their supply line lingers on.

The supply lines (resource sharing) continued to work just fine, as did the lines on the pipboy map - It was just that many (not all) of the Provisioners stopped travelling between settlements.

The reason for this was, they stopped executing the relevant AI package "WorkshopCaravanPackage". Which is applied by the CaravanActors alias, of which the affected Provisioners were still a member.

 

Solution:

- teleport Provisioner to Player, so they are fully loaded (or it won't work)

- remove the Provisioner from the CaravanActors alias

- reset their AI

- re-add the Provisioner to the CaravanActors alias

- reset AI again

- teleport them back to wherever they were

 

All of which can be done by selecting a Provisioner and then simply pushing the [C] button in the Holotape Program I've made to address this problem:

 

 

 

 

 

 

As to the reliability of Automatrons, this is the only problem I've ever encountered with my 110 Automatron Provisioners on a Save that has some 1200 hours played on it.

I'd say, the claims of their unreliability are greatly exaggerated.

[LarannKiar]

I see but it may be connected to the "ghost supply lines" bug: that happens when a robot provisioner get reset during their trip. And it's possible their AI breaks when this happens. Human NPCs can't break like this (or at least I haven't seen it).

 

Nice diagnostic system you have by the way. Your holotape can display all those information about your provisioners by selecting one from the menu? Well..too bad we can't use text replacements on the Pip-Boy.. (Okay, I've seen mods that can, but that's beyond me..).

Edited April 23, 2021 by LarannKiar

[niston]

But if the Automatrons had been reset, they'd have reverted to their base Automatron configuration - According to tales I've read at least; I've never observed this to actually happen.

There was however nothing wrong with my provisioners robot config; They still had all their OMods and voice config etc, just the AI package was borked.

I suspect it was the result of a Workshop Framework upgrade that initially didn't perform as expected, due to my own shortcomings.

 

Re that link you posted, the information there is slightly inaccurate:

 

because there isn't a WorkshopParent.WorkshopCaravanDestination AV stored on the actor anymore

 

 

In practice, it is reflinks from the provisioner to the respective settlement center markers with the WorkshopCaravanLinkStart and WorkshopCaravanLinkEnd (if memory serves) Keywords that govern the Caravan AI package. These reflinks are being set up from the workshop script when assigned to supply line. The AI package then simply makes the Actor travel between the reflinked markers. I've not seen the AVs mentioned in the post being used, so I suspect the workshop scripts may have been updated since the linked post was written.

 

Re the diagnostics tool, it uses a custom SWF program that gives your papyrus scripts full control over the entire Terminal screen, lets them read input from the keyboard and even features a realtime screen editor. It supports a bunch of different text modes from 40x17 to 80x25 and there is Print(), PrintLine(), PrintField(), ReadKey() and ReadLine() so far, and some other functions to move the cursor, enable reverse/inverse text mode etc. It doesn't use text replacement (even tho support for that is planned), but works with strings and provides a bunch of string utility functions (Replace, IndexOf, Substr and more) to Papyrus as well.

 

The SWF itself works fine on the pipboy, I've just not gotten around to implement a substitute for the OnHolotapePlay event, that doesn't ever fire on pipboy - So the interfacing Papyrus script never knows that it's holotape is playing and thus won't start up.

 

Will publish the SWF some day, it's really cool. Make Terminals Great Again!

[SKKmods]

No memory required, thats exactly what I posted in the debug trace fragment at the top of the thread ;)

 

Which drives stuff like this.