Open TheMerricat opened 3 months ago
Sounds like it failed to realize that it is being run through a standalone instance. Can you post the console output? Do you have a portable.txt
in your standalone instance folder? Which version of MO2 are you using?
MO2 is 2.5.0 Revision 22714e5c - the latest release version I believe.
No portable.txt was created when I generated the instance from a fresh install of MO2. However the program fully believes it's a portable instance already - Instance Manager screen and Add an instance blocks additional portable instances due to one already existing; and the ModOrganizer.ini is located in the instance folder, not the AppData folder.
My understanding from the commit comments that added the feature was that the portable.txt was more of a feature added for things like Wabbajack to avoid user confusion rather than a requirement. I have no problem placing one in there if that's what the problem is though.
Just added the portable.txt file and that fixed the issue on my end. Don't know if you'd still want to either warn the user or switch to looking for the ModOrganizer.ini file instead though.
Thanks!
Yeah no, I still want to properly fix this. I thought portable.txt was the way to do this, but I guess I was wrong. Adding portable.txt manually is a viable workaround for now at least.
So, if there is a ModOrganizer.ini next to the ModOrganizer.exe, that's what makes the instance standlaone?
That file will lock MO2 to prevent it from being switched to a global instance, or in other words forces that copy of MO2 into portable mode.
Otherwise you'd need to a) detect that the MO2 directory contains ModOrganizer.ini and b) check that HKEY_CURRENT_USER\Software\Mod Organizer Team\Mod Organizer\CurrentInstance
is blank. Otherwise it will store a global instance name which will be automatically loaded as a global instance.
Okay, so, like this?
That part with the registry is probably what I missed, when I tried to figure this out initially and was trying to make a portable instance on my machine...
A hard override for it is probably still a good idea.
That sounds correct. The reason I mentioned checking for the ini is because MO2 will launch the instance creation dialog if there's no portable instance and no global instance set. It may prompt you to select an instance if any exist, which is basically any directory in the local app data location.
I finally found the time to look into this, and am more confused:
for my own setup:
HKEY_CURRENT_USER\Software\Mod Organizer Team\Mod Organizer\CurrentInstance
is blank. it seems to use the appdata... so what is the rule between appdata and registry?
Edit: as for the registry, what even would be there under CurrentInstance? A path to a directory with a ModOrganizer.ini?
@Silarn
So Praecipitator and I had a conversation on the MO2 discord trying to hash out the details. It starts here.
https://discord.com/channels/265929299490635777/265929299490635777/1261706775745532106
At the end of the day, I think what Praecipitator is looking for exactly is a 'foolproof' method of detecting if Synthesis is being run via MO2 and if so, where to look for the ModOrganizer.ini file to parse it.
Right now, his plugin for Synthesis is checking to see if there is a portable.txt file in the instance folder. If there isn't, it's assuming that the MO2 instance is a non-portable install and looking in the AppData folder.
Would I be correct in saying that really all that needs to be looked for is if the ModOrganizer.ini is in that folder, if it is - portable. If it isn't - non-portable?
I think I figured it out: it is in portable mode, either if there is a portable.txt, or if the registry key HKEY_CURRENT_USER\Software\Mod Organizer Team\Mod Organizer\CurrentInstance
does not exist or is an empty string. The code for this is now on dev
.
It's looking in AppData\Local\ModOrganizer\Fallout 4 instead of the instance folder. Might be a good idea to just let the user set the location directly in settings.