Change Details

Bit of a rabbit hole this one. Based on work in D2252. ---- Background: The VFS maintains a unique directory/file tree of paths (called VFSPaths), abstracting the fact that we have several mods and folders to read/write in. To do this, it uses a system of "Mount points", "attaching" and "population". Mount points are basically just aliases, the root mount point is "", but you can load a folder directly at "config" for example. Attaching is the act of associating a `realDirectory`, i.e. a directory on the user's file system, with a VFS directory, which is simply the node in the tree at that `VFSPath`. Populating is the act of actually looking inside the real directory at a given VfsPath (i.e. inside a given VfsDirectory), and creating VFSDirectory/VFS files for all subdirectories and files. A particularity of this system is that a VFSDirectory, despite being attached with multiple "real" directories, and being populated with them, only keeps a link to **one** `realDirectory`. It should be noted that we use some "pseudo" lazy-loading here, by deferring the "populate" call until one of two things happen: - the path is requested. - another real directory is attached to the path (this being a consequence of the above designs we would otherwise lose track of what is in the directory we originally attached). This caused me confusion in D2252, but by itself is functional if a little weird and probably outdated now that we have more mods actually making the lazy-loading somewhat moot. ---- The bug: When mounting anything, the VFS will attach the new folder at the given MountPoint. This will //replace// the link to the `RealDirectory` for that VfsDirectory. Thus the order of attaching is **very** important. Indeed, the code at `InitVfs` in `GameSetup.cpp` is very explicit about the order of things, and folders such as `cache` or `screenshots` are loaded after mods so that the `RealDirectory` of these VfsPaths points to the correct folder. There have somewhat recently been revisions that broke that assumption. The latest its rP21823, which actually remounts all mods, thus overwriting any real directory setup. I think rP21726 also broke this, but haven't actually checked. ---- The fix: This highlights imo the need for a more general refactoring of the VFS and how we mount mods (the original implementation from rP15676 honestly seems pretty poorly abstracted away to me), but in the short term it seems sufficient to handle simple priorities when replacing the real directory. This makes sure config and screenshot folders don't get overwritten, for example. I need to jump through some hoops to get around the lazy-loading "feature", but that could be removed.

Bit of a rabbit hole this one. Based on work in D2252. ---- Background: The VFS maintains a unique directory/file tree of paths (called VFSPaths), abstracting the fact that we have several mods and folders to read/write in. To do this, it uses a system of "Mount points", "attaching" and "population". Mount points are basically just aliases, the root mount point is "", but you can load a folder directly at "config" for example. Attaching is the act of associating a `realDirectory`, i.e. a directory on the user's file system, with a VFS directory, which is simply the node in the tree at that `VFSPath`. Populating is the act of actually looking inside the real directory at a given VfsPath (i.e. inside a given VfsDirectory), and creating VFSDirectory/VFS files for all subdirectories and files. A particularity of this system is that a VFSDirectory, despite being attached with multiple "real" directories, and being populated with them, only keeps a link to **one** `realDirectory`. It should be noted that we use some "pseudo" lazy-loading here, by deferring the "populate" call until one of two things happen: - the path is requested. - another real directory is attached to the path (this being a consequence of the above designs we would otherwise lose track of what is in the directory we originally attached). This caused me confusion in D2252, but by itself is functional if a little weird and probably outdated now that we have more mods actually making the lazy-loading somewhat moot. ---- The bug: When mounting anything, the VFS will attach the new folder at the given MountPoint. This will //replace// the link to the `RealDirectory` for that VfsDirectory. Thus the order of attaching is **very** important. Indeed, the code at `InitVfs` in `GameSetup.cpp` is very explicit about the order of things, and folders such as `cache` or `screenshots` are loaded after mods so that the `RealDirectory` of these VfsPaths points to the correct folder. ~~There have somewhat recently been revisions that broke that assumption. The latest its rP21823, which actually remounts all mods, thus overwriting any real directory setup. I think rP21726 also broke this, but haven't actually checked.~~ << Inaccurate, but there must be one... ---- The fix: This highlights imo the need for a more general refactoring of the VFS and how we mount mods (the original implementation from rP15676 honestly seems pretty poorly abstracted away to me), but in the short term it seems sufficient to handle simple priorities when replacing the real directory. This makes sure config and screenshot folders don't get overwritten, for example. I need to jump through some hoops to get around the lazy-loading "feature", but that could be removed.

Bit of a rabbit hole this one. Based on work in D2252. ---- Background: The VFS maintains a unique directory/file tree of paths (called VFSPaths), abstracting the fact that we have several mods and folders to read/write in. To do this, it uses a system of "Mount points", "attaching" and "population". Mount points are basically just aliases, the root mount point is "", but you can load a folder directly at "config" for example. Attaching is the act of associating a `realDirectory`, i.e. a directory on the user's file system, with a VFS directory, which is simply the node in the tree at that `VFSPath`. Populating is the act of actually looking inside the real directory at a given VfsPath (i.e. inside a given VfsDirectory), and creating VFSDirectory/VFS files for all subdirectories and files. A particularity of this system is that a VFSDirectory, despite being attached with multiple "real" directories, and being populated with them, only keeps a link to **one** `realDirectory`. It should be noted that we use some "pseudo" lazy-loading here, by deferring the "populate" call until one of two things happen: - the path is requested. - another real directory is attached to the path (this being a consequence of the above designs we would otherwise lose track of what is in the directory we originally attached). This caused me confusion in D2252, but by itself is functional if a little weird and probably outdated now that we have more mods actually making the lazy-loading somewhat moot. ---- The bug: When mounting anything, the VFS will attach the new folder at the given MountPoint. This will //replace// the link to the `RealDirectory` for that VfsDirectory. Thus the order of attaching is **very** important. Indeed, the code at `InitVfs` in `GameSetup.cpp` is very explicit about the order of things, and folders such as `cache` or `screenshots` are loaded after mods so that the `RealDirectory` of these VfsPaths points to the correct folder. ~~There have somewhat recently been revisions that broke that assumption. The latest its rP21823, which actually remounts all mods, thus overwriting any real directory setup. I think rP21726 also broke this, but haven't actually checked.~~ << Inaccurate, but haven't actually checkedthere must be one... ---- The fix: This highlights imo the need for a more general refactoring of the VFS and how we mount mods (the original implementation from rP15676 honestly seems pretty poorly abstracted away to me), but in the short term it seems sufficient to handle simple priorities when replacing the real directory. This makes sure config and screenshot folders don't get overwritten, for example. I need to jump through some hoops to get around the lazy-loading "feature", but that could be removed.