ermodk

@Tannin42: Just a quick note that I just now invested in a Nexus lifetime premium membership as I'm impressed with the way you are conducting yourself here and wish to support your work and Nexus as a whole. I don't expect Vortex to be perfect from the get go, but I *do* expect that you and the rest of the Nexus team will continue to do your best to make Vortex -- and by extension the Nexus experience -- the best it can be once you release it. FWIW, this is also my way of sending a thanks your way for the mods MO have enabled me to use in Oldrim. Nexusmods has made a BIG difference in my gaming experience over the years. Cheers! :thumbsup:

You could turn that question on its head and pose it as, "why do I have to start the game from Vortex to play vanilla?" :wink: The beauty of it is that you wouldn't have to, as the original install would live exactly where the game launcher expects it to. It's only when you want the benefit of a modded setup that launching from within Vortex becomes necessary in the scenario I outline. :smile: Besides, if this were to be implemented, there's absolutely no reason you couldn't set up different shortcuts with the requisite startup options, such as: "d:\vortex\vortex.exe --game=fo4 --profile=hardcore" This is no different to Origin launching when I click the ME:A shortcut on my desktop.

I was sort of hoping that limiting the voodoo to intercepting a few simple registry calls would prove easier than it was to make MO's approach work. Then again, perhaps this idea (along with the other ideas you've explored) might end up morphing into something surprisingly useful in your head over time... =)

Nice of you to get back to me. =) Just to clarify: Perhaps I didn't flesh out my idea of the "registry magic" well enough, as this "virtualized registry spoof" is the linchpin that enables the idea of the original pristine "file store" to work in theory. The point here was for Vortex to -- in effect -- become the new "base environment". While I think I understand your concerns, I take the view that what the shortcuts and the registry point to is (IMHO) not terribly relevant insofar as the "Virtualized Registry Spoof" works in the "base environment" or "Matrix" from which the tool in question is launched. Let's take LOOT as an example and show the layers in the stack with Windows at the bottom: LOOT.exe === "Matrix" boundary === %VIRTUAL_REGISTRY_SPOOF% %MY_PROFILE% %MOD_STORES% Vortex.exe == "Vortex" boundary == %FILE_STORE% %WINDOWS% The idea here is for the VRS to encapsulate and transparently intercept registry calls from LOOT.exe such that LOOT reads from/writes to %MY_PROFILE%. You could say that we're essentially sandboxing LOOT into a carefully controlled matrix without LOOT knowing about it. Granted, LOOT is open source and could thus be modified to work in tandem with Vortex, but it should also be trivial (famous last words...) to use the appropriate tools in the Sysinternals Suite to see which calls are executed to read from the registry when LOOT is fired up. The same techniques could in theory be used to voodoo other, non-open-source tools into taking the blue pill and staying in the "Matrix" we've oh-so-carefully defined and constrained from within Vortex. Again, I'm not saying that what I propose is actually possible, just that it strikes me as an elegant solution to a somewhat thorny problem in theory. And can I just add that I very much look forward to seeing how Vortex (and its story) will evolve once it is released.

I've been using MO (oldrim) and NMM (TW3) for a few years now and have come to appreciate both. I've also studied Comp.Sci. and modded a few games for fun, so I do know my arse from my elbow when it comes to programming, even though I'm not employed as a software developer. @Tannin42: One thing that struck me when thinking about the vfs (imaginary filesystem from the game .exe's point of view) vs. virtualization (hard/symbolic links instead of files), is that maybe the overall best approach is actually to adopt something akin to what Plan 9 out of Bell Labs did: Turn the problem on its head and think of the original game as a 'file store' or 'source' instead of as a 'target', and link files from said 'file store' into a new, unique 'profile', which acts as a 'world view' and can 'bind' files from both the 'file store' and the various 'mod stores'. This allows you to keep the original install location *completely pristine* like MO does, yet still reap the benefits provided by symbolic/hard links like NMM 0.6x does. The only thing you might need here is some registry magic, where you trick the game .exe into believing you when you tell it that the game is installed in the 'profile' location. But since every game accesses the registry through a similar Windows API, this *might* not be such a big deal? == EXAMPLE This outlines the case where we have a single game profile configuration called 'my_profile' (there could be an arbitray number of these): - Game was originally installed to D:\Steam\SteamApps\common\Fallout 4 <- %FILE_STORE% (shared between profiles) - Mod archives are downloaded to D:\Vortex\FO4\downloads\ <- %MOD_DOWNLOAD_DIR% (shared between profiles) - Mod archives are unpacked to subfolders under D:\Vortex\FO4\unpacked\ <- %MOD_STORE% (shared between profiles) - Mod profiles live in subfolders under D:\Vortex\FO4\profiles\ <- %GAME_PROFILE_DIR% (each profile is unique) Now, each mod profile would be initialized with hardlinks of every single original game file (assuming that hardlinks are indistinguishable from the original files) placed into the %GAME_PROFILE_DIR%\my_profile\ folder. After that, Vortex would populate the %GAME_PROFILE_DIR%\my_profile\ folder with symbolic links from the %MOD_STORE% folder according to the user's vishes per GUI checkboxes and whatnot, making it easy to distinquish between which files are from the %FILE_STORE% and which are from the %MOD_STORE%. You could potentially allow 'normal' override files as well. When a modder develops his mod, he creates a 'my_mod_environment' profile and then creates his mod as %MOD_STORE%\my_mod and asks Vortex to add it to his %GAME_PROFILE_DIR%\my_mod_environment\ folder. Each time he makes a change in %MOD_STORE%\my_mod, he asks Vortex to re-populate %GAME_PROFILE_DIR%\my_mod_environment (this is the DevOps way -- you reset state every time you deploy for consistency's sake) and does the rinse-repeat dance until he's satisfied that he can cut a release of my_mod. This way, both the user and the developer get the freedom they need and absolutely NOTHING is changed in the original install location. END EXAMPLE == Thoughts?