Software Archeology - Plugin Load Order

[Null 45 3,019]

TL.DR. The game's load order system works by accident and is entirely dependent on the operating system behavior.

For reference here is an example of the 'standard' load order:

• \plugins\*.*
• \plugins\asubfolder\*.*
• \plugins\asubfolder\asubsub\*.*
• \plugins\asubfolder\bsubsub\*.*
• \plugins\bsubfolder\*.*
• \plugins\z_subfolder\*.*
• \plugins\z__subfolder\*.*

This load order is what Windows provides with the NTFS file system, the order file system entries are returned in is an implementation detail that Microsoft could change any time they wanted. It can also vary depending on the underlying file system type, e.g. Windows FAT32-formatted disks versus NTFS-formatted disks. This also doesn't include the behavior of macOS and Linux/WINE in this area.

Microsoft's Raymond Chen has a blog post describing the directory scan orders for various Windows file systems. I will quote the NTFS part below along with his disclaimer:

Quote

The NTFS file system internally maintains directory entries in a B-tree structure, which means that the most convenient way of enumerating the directory contents is in B-tree order, which if you cover one eye and promise not to focus too closely looks approximately alphabetical for US-English. (It’s not very alphabetical for most other languages, and it falls apart once you add characters with diacritics or anything outside of the Latin alphabet, and that includes spaces and digits!)

...

Of course, none of this behavior is contractual. NTFS would be completely within its rights to, for example, return entries in reverse alphabetical order on odd-numbered days. Therefore, you shouldn’t write a program that relies on any particular order of enumeration. (Or even that the order of enumeration is consistent between two runs!)

@memo mentioned on the SC4E Discord that some Linux user's ran into this issue:

Quote

The thing is, in the past people reported having this problem on Linux when using non-NTFS file systems like EXT4. You had to set up an NTFS partition to effectively mod the game. I don't observe this problem anymore though and am not sure if that's due to a fix in the digital edition 1.1.641 or a change in Wine.

I am not sure if this OS variation is an issue that needs to be fixed by my Startup Performance Optimization DLL. Even if it is, the hard part would be coming up with a sorting algorithm that preserves compatibility with the Windows sorting behavior that everyone came to accidentally rely on.

[memo 1,439]

See also SOLVED: Linux Plugin Load Order for more information on this topic.

As already mentioned, I currently don't observe this problem anymore with current versions of Wine on Linux and the digital edition of the game, so I don't think it needs to be addressed by your DLL (though, I haven't tested the behavior with your DLL yet).