sResourceArchiveList and MO managed archives 3rd party executables

[sheson]

When MO manages archives so that BSAs are loaded without esp it does so by adding them to the sResourceArchiveList in skyrim.ini

Obviously in reality it uses shorter names aaa,aab,aac, etc, and it may actually always do this despite the manage archive setting.

 

It seems that this sResourceArchiveList change is only visible to tesv.exe but not any other program that is executed from MO.

 

Am I missing something or is this the current known behavior?

 

This poses a problem when scanning "loaded" archives for resources with other tools started through MO, like xEdit.

These tools see something very different to the game.

 

Is there a known or planed fix?

Edited January 26, 2015 by sheson

[Tannin]

The sResourceArchiveList is turned into short-names and mapped back to regular file names for every application run through MO.

If an application sees something different than the game this may have two reasons:

a) it uses a different list of archives (i.e. hard-coded) in which case the application is inheritantly unreliable in this regard anyway.

b) the application reads the archive list in a different way than the game. I.e. an application could open the ini file as a txt file and parse it manually. There is no way MO could then "fix" the list. Again one could argue that if the application reads the archive list in a different way than the game it's the applications fault if it gets different results.

 

A little known fact: ini files can be placed in the registry and the regular windows ini-reads (which skyrim uses) would transparently fetch the values from registry instead of the ini files. Doing this for skyrim might even make sense to improve startup time. Of course tools that don't use windows ini-reads would not get the registry values.

This, combined with the fact that ini files are not a standardized file format and therefore every method of reading them might produce different results (i.e. because of different syntax for comments, different character encoding support, ... ) means that all tools that use different means of reading ini files than the game should also, technically at least, be considered unreliable.

[sheson]

Thanks. That is very helpful information. I will see if I can get expected result using the proper methods for the ini.

 

EDIT:

For future reference: Kernel32 - GetPrivateProfileString

Edited January 27, 2015 by sheson