Script PEX loading priority in the CK ?

[SKKmods]

It is generally accepted that with the right INI settings (bInvalidateOlderFiles=1 sResourceDataDirsFinal=) loose compiled PEX scripts will take priority over those packed in BA2 files. Fine.

 

Question: does it follow that if there are no loose PEX, BA2 Creation Kit unpacking follows the "last one wins" game load order ... or something else ?

 

Here is the thing: I just had a major >PANIC< with Creation Kit "Errors encountered while attempting to reload the script" dialog trying to access properties on my own known good form attached scripts with Warnings:

 

 

SCRIPTS:Error: Unable to link types associated with function [function names I have never used]

 

SCRIPTS:Error: Native function [common and unknown functions] in empty state could find no matching function on linked type ...

 

 

The unknown functions resolve to F4SE ... which I have never ever used :O The on demand reproducible cause was a 3rd party mod I had copied to \data that has some base game PEX compiled scripts (form, objectreference, scriptobject) packed in its BA2.

 

Removing that BA2 from \Data solved all issues.

 

So that brings me back to the question: whilst that mod ESP & BA2 was sitting in the \data folder it was not loaded or marked as active to load. Which suggests that the Creation Kit must be aware of, links to, or loads, resources or pointers from all BA2s in the \Data folder.

 

... anyone got the story ?

Edited March 15, 2018 by SKK50

[JonathanOstrus]

Well something caused CK to load the BA2. It could be the CreationKit.ini or CreationKitCustom.ini has a static line loading that BA2. In the sResourceArchiveList or sResourceArchiveList2 lines probably.

 

I would at least inform the mod author of that mod that he done messed up and didn't check that CK was packing the right files. He shouldn't have packed those loose files since they're likely the ones that are part of F4SE and should never be packed with a mod archive. Though CK will incorrectly assume that any loose files even remotely referenced by a mod, belong to the mod when packing. Which is where the initial issue starts.

 

You could also just fix the archive locally yourself to get rid of the problem. I know this doesn't answer your question about ordering. From my experience packed files have the same sort of overriding behavior in CK as they do in game. Though I have no conclusive proof. And then if they have specific overrides in the ini then that ordering takes precedence over the plugin ordering.

[SKKmods]

Thanks B&F, I have nudged the MA.

 

That mod had just been copied in before the problems started, never got round to looking at it so never seen or loaded before. Checked the CreationKit.INIs and all clear, but it is in Plugins.txt & DLCList.txt where the game has detected it.

 

Just tried again, with the BA2 resident in \data - I cant open any of my script properties.

 

Infact if I try to delete the offending files with the CK running, the ESP clears but the BA2 is locked open by ... creationkit.exe

[MissingMeshTV]

@SKK50:
It doesn’t address the possibility of the CK loading a script from the archive (which sounds really weird), but I had the same level of heart attack this past weekend when I was getting the same exact error and warnings when trying to access script properties. It happened not only on my own scripts, but also on vanilla scripts with only the base game .esm loaded. So, I know full well the level of panic you must have had.

 

I eventually tracked it down to the ObjectReference.pex that came with the latest F4SE update. This was the first time I had tried to do any work in the CK since updating my game install. Once I removed it from Data/Scripts, the errors stopped and all was right with the world again. I don’t normally install loose F4SE scripts because 1) I don’t do anything that requires them; 2) I’m fearful of the CK wanting to pack them into archives and not noticing. But I had been testing Transfer Settlements for the first time in my dev install forgot the remove the F4SE scripts it requires when I was finished.

 

It might be fair to guess the ones in the archive you have are stray F4SE scripts but it doesn’t explain why/how there were read. Is it possible the mod itself has some sort of .ini file that references them? A long shot I know, just a random thought.

[JonathanOstrus]

I suppose there's a chance the behavior of FO4 ck is to load all ba2 to look for files. If you watch when you first launch it, you'll see it say loading archives.

[SKKmods]

Edit:@RedRocketTV ... Yeah scary for personal effort, but a first world issue :wink:

 

I ran the base PEX scripts from the problem BA2 through Champollion and see that they are crammed with F4SE functions, so that's the source of the CK errors as there is no other F4SE on my system having never installed it.

 

Which rather looks like CK is, for some reason, favoring the PEX files from a listed but unloaded BA2 over those in the loaded base game Fallout4 - Misc.BA2.

Edited March 15, 2018 by SKK50

[JonathanOstrus]

I'm under the suspicion it may have some predefined sorting. Like load all ba2, then have the default FO4 ba2's then use whatever else is there in whatever order they happen to be loaded. Without running a debugger to see what method it uses to load them, it could be name order, date order, or whatever order they happened to have been written as they were installed. It may ignore load orders completely. Or it may use the plugins.txt load order as the entire list of what to load. I don't have the skills to use a debugger to do the step through to figure it out.

 

Thinking about it, all of these viable options would make sense. Using the ini settings creates limitations of how many could be loaded, because it can only read so many characters from each line into a pre-defined buffer size. Skyrim's CK suffered from those. You couldn't get assets in a whole lot of BSA's without juggling which ones were loaded each session.

[SKKmods]

The mod's BA2 has been repacked and published without the base PEX and all is well. My learnings are:

 

1) Check data\scripts folder for for loose base game PEX that have wandered in there and clean 'em out (unless your working on them), and/or:

 

2) Pay attention to what the CK is actually trying to stuff into your archives when they are created. I extracted all my current published versions and found a couple randomly had ScriptObject.pex innit. How ? Why ? Who knows ...

[chucksteel]

This tread explains a lot, I had ran into this issue after fulfilling an Xbox port request, it took me a long time to fix the issue but now I understand where it came from.

 

Thanks.

[SKKmods]

OK I just downloaded another mod that was packed in March and its BA2 is "infected" with exactly the same F4SE extended base game files Actor.pex, Form.pex, ObjectReference.pex, ScriptObject.pex

 

This may be a new but common thing to look out for if you are odd like me and don't use F4SE.