Overrides and memory

"pbox;803267" wrote:
Something I've always been wondering about .. how does the game actually behave when it encounters overrides / redundant data? Like when there's one resource 0000000000001234 in the game packages, and three with that same instance in the Mods folder: does it use four times as much memory since it's actually loading the thing four times, or does it skip the first three and only reads the last one?

Our package system is designed to handle redundant data. Since the packages is /Mods are configured to have the highest priority, only that data would be loaded should any redundancies exist. It does not use more memory, as it would only load the resource once. When the game attempts to load a resource, it is unaware of duplicate entries. For every unique key, it expects one and only one resource to exist.

"pbox;803267" wrote:

Edit, also, when there are multiple overrides of the same thing in /Mods, is there a rule of thumb to determine which one loads last? (I seem to recall in one of the previous games it wasn't just alphanumerical but something to do with the hierarchy of subdirectories .. also, alphanumerical? alphabetical? asciibetical? Something else entirely?)

I believe you can control the priority inside subdirectories by copying the configuration file and editing the priority. I'm not sure what happens if collisions exist for the same priority. I would suspect the behavior to be non-deterministic, but I will find out for sure for you.

Re key collisions at the same priority level:

If the two packages containing collisions are loaded via the same wildcard specification in Resource.cfg, ie.:

PackedFile *.package

or

PackedFile *\*.package

Then which one "wins" should be considered non-deterministic as the game uses the Windows OS functions FindFirstFile/FindNextFile to iterate through the directory contents, which I am pretty sure is non deterministic. And you can expect that any other hypothetical OS flavor the game might support in the future would behave differently as well.

If the packages containing collisions are loaded via different lines in the resource.cfg then who wins should be deterministic since our code behaves deterministically as it reads through the cfg files. I say *should* because I have not tested that :smile:. That said, even though in practice this might work I would advise against relying on deterministic behavior of collisions at the same priority.

Re. collisions, I specifically meant the same priority, yes. Thank you for looking into it!

The reason I ask is I want to know how my stuff behaves when other people download it -- i.e. when the resource.cfg is out of my control --, also for updates (I could perhaps do something more intelligent than replacing the entire file, if I can predict the behaviour).


Edit: on a related note, a quick Google search gives me very mixed results on the prospect of an OS X version (I believe that has a different idea of "alphanumerical" than most Windowses? Would the OS have an influence here?). Is there any official info on that yet? In case the load order is somehow determined by package name, I guess it would make sense to take any OSX-specific idiosyncrasies into account as well .. unless it's already clear that there won't ever be an OSX version)

My suggestion is to assume that they can be loaded in any order by the game, that way you do not assume anything that is untrue, especially if someone chooses to rename files (and as you mentioned different platforms, could be a difference between file systems on the same platform as well (eg. ntfs vs fat32)). As we do not have the concept of unofficial patches and such I see no reason to mess with priority, it is better to talk about compatibility between mods imo. Could have it as a feature of a mod manager though, if it becomes a problem (one could look at skyrim, though there you explicitly set priority for all mods).

Thank you, that's exactly the info I wanted =).

(Regarding what @Fogity said as well -- sure, I don't want to assume anything (which was why I was asking), but I also don't just want to assume something wouldn't work only because in the past it did not. =)