search

sonic2kk / steamtinkerlaunch

Linux wrapper tool for use with the Steam client for custom launch options and 3rd party programs
GNU General Public License v3.0
2.05k stars 70 forks source link

Why MO2 broken ? #1009

Closed AutumnalModding closed 6 months ago

AutumnalModding commented 6 months ago

System Information

Issue Description

MO2 does not start.

Logs

[lily@emdex ~]$ steamtinkerlaunch mo2 start
Fri 12 Jan 2024 16:05:33 NZDT INFO - startMO2 - Starting '/home/lily/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/Modding/MO2/ModOrganizer.exe'
Fri 12 Jan 2024 16:05:33 NZDT INFO - startMO2 - WINEDEBUG="-all" WINEPREFIX="/home/lily/.config/steamtinkerlaunch/mo2/compatdata/pfx" "/home/lily/.local/share/Steam/compatibilitytools.d/Proton TKG Bleeding Edge/files/bin/wine" "/home/lily/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/Modding/MO2/ModOrganizer.exe"
wineserver: using server-side synchronization.
wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
creating minidump for the current process
trying file '.\ModOrganizer-2.5.1rc2-20240112T030537.dmp'
writing mini minidump
minidump written correctly
[lily@emdex ~]$
sonic2kk commented 6 months ago

You're not using the latest STL, this is trying to use ModOrganizer 2.5.1 which is incompatible with most Proton builds, including GE-Proton builds, because of a missing Wine patch for a Qt6 feature.

Completely uninstall MO2 and then use the actual latest STL from git. This will use MO2 V2.4.X.

You would've gotten your answer if you read the wik and changelog. This issue is incredibly low effort too, just saying it's broken and providing terminal output is unhelpful and not good form for any project. Simply saying "it doesn't work, why not?" is borderline spam. The issue template specifically requests a log file from the execution that didn't work and tells you where to find it. Such a log would've also made it obvious you were not using the "latest" SteamTinkerLaunch. It sounds like you might be using the outdated stable release v12.12.

It also seems like you did no research into MO2 on Linux, otherwise you would've also been informed that 2.5.X requires a patch only available in Wine 8.21 and it has yet to be backported to Valve Wind. Likely it won't be and so won't be available until Valve Wine is rebased on top of Wine 9 (a build of Proton-tkg based on Wine Master might work, but this is untested).

The issue template also tells you to read the changelog, wiki, and closed issues to see if your issue has already got an answer.

AutumnalModding commented 6 months ago

This is quite literally the only terminal output given. Had there been more output, then I would have provided it. Additionally the MO2 wiki does not state that the git version is required. It does state that 2.4.4 is required, but as it downloaded 2.5.1 I made the reasonable assumption that that had changed.

(It also used to work perfectly fine on a previous Arch install.)

edit: it does say that -git is required... but it also prefaces it with "On Steam Deck". Perhaps this should be edited to remove the explicit mention? Otherwise, it is a fairly reasonable assumption that it only applies to Steam Deck.

sonic2kk commented 6 months ago

This is quite literally the only terminal output given. Had there been more output, then I would have provided it

You shouldn't be providing terminal output, you should be providing a log file like the issue template requests.

does state that 2.4.4 is required, but as it downloaded 2.5.1 I made the reasonable assumption that that had changed.

v2.5 is still incompatible with Valve Wine with most Proton builds.

(It also used to work perfectly fine on a previous Arch install.)

Old MO2 versions should work fine, and older release candidates for 2.5 did work with Wine, but later release candidates and stable 2.5 do not work.

If v2.5 did work before, that's the first I'm hearing of it, but even in such a case it's entirely possible that v2.5.1 is still incompatible.

edit: it does say that -git is required... but it also prefaces it with "On Steam Deck". Perhaps this should be edited to remove the explicit mention? Otherwise, it is a fairly reasonable assumption that it only applies to Steam Deck.

Sure, I'll do it in the morning, but reading the changelog should've made this obvious anyway in my opinion.

AutumnalModding commented 6 months ago

reading the changelog

Changelogs are per-release and only provided on Github, correct? How are people supposed to know exactly when it changed?

Old MO2 versions should work fine, and older release candidates for 2.5 did work with Wine, but later release candidates and stable 2.5 do not work. If v2.5 did work before, that's the first I'm hearing of it, but even in such a case it's entirely possible that v2.5.1 is still incompatible.

This is entirely possible; but then why was the version not pinned before? Seems strange (in older versions, at least) to always grab whatever's latest.

sonic2kk commented 6 months ago

No, the changelog is on the wiki and it's the first link under "Quick Links". And there is a section with a link on the Readme (emphasis by me):

To find out about the latest release, check out the stable release changelog. To find out about the latest bleeding-edge development changes not yet in a stable build, check out the full changelog.

How are people supposed to know exactly when it changed?

By reading the commit history, looking at PR descriptions, closed issues, and checking the changelog for an overview of what PRs or commits without PRs all amount to.

This is entirely possible; but then why was the version not pinned before? Seems strange (in older versions, at least) to always grab whatever's latest.

You'd have to ask the previous maintainer, but I'd say it's because MO2 did not get updated very often. And as well, no one ever submitted a PR so clearly no one took issue with the script working this way.

Virtually everything in SteamTinkerLaunch grabbed the latest version and this has changed with support from the community with discussion and also on occasion with PRs. I imagine grabbing the latest was the norm in development, long before I ever even heard about STL.

AutumnalModding commented 6 months ago

By reading the commit history, looking at PR descriptions, closed issues, and checking the changelog for an overview of what PRs or commits without PRs all amount to.

There are thousands of commits in this repo. It's unlikely anyone - indeed, myself included - would look through each and every commit (unless they had specific reason to, like finding where a bug was introduced) of a repo with such a large commit count to fix an issue like this (instead of just giving up and playing another game).

This is more of a semi-unrelated nitpick, but why is the AUR package so out of date? Additionally it would be nice to have some more launch feedback for MO2, but that's just a nitpick at this point.

sonic2kk commented 6 months ago

There are thousands of commits in this repo. It's unlikely anyone - indeed, myself included - would look through each and every commit

Of course, but this was recent. As well, you can browse closed issues as mentioned, merged PRs, and the changelog. No one said you were expected to read all commits, but skim the first page or two to see if something related to your issue was changed recently. Likewise, do the same for issues and PRs, even take advantage of sorting by recently updated if a search or skim don't turn up the results you want. Maybe someone commented on the issue recently and sorting by recently updated would help you find it.

None of this is specific to SteamTinkerLaunch, this is just good practice for troubleshooting issues with any open-source project in my opinion.

I just checked the commit history and it seems like the MO2 change (3dc3f301816b287ba36266df9c1c106f0c87147f) was only about 10 commits ago. Ctrl+F for "ModOrganizer 2) or "MO2" or something to this effect also would've turned it up, or cloning the repo and searching the commits from the command line.

This is more of a semi-unrelated nitpick, but why is the AUR package so out of date?

It shouldn't be. There are two AUR packages:

You should also be aware that the AUR package is unofficial and not maintained by me. All distribution packages for. SteamTinkerLaunch are community maintained. Since I use Arch I am more aware of the AUR package, though.

Additionally it would be nice to have some more launch feedback for MO2, but that's just a nitpick at this point.

It's in the log, and SteamTinkerLaunch isn't supposed to tell you about a Wine program crash. Again, terminal output should not be provided, the issue template requests a log and tells you where to find it. The Readme also does, I think (EDIT: It does.)

Further, the "mini dump" logging from Wine should be enough. If you want more launch feedback you'll have to tackle that upstream somewhere, STL just runs programs with Wine. If something isn't working after that it can't do much to tell you what's wrong.

AutumnalModding commented 6 months ago

It's in the log, and SteamTinkerLaunch isn't supposed to tell you about a Wine program crash. Again, terminal output should not be provided, the issue template requests a log and tells you where to find it. The Readme also does, I think.

Except... it's not in the log. The log just says it's starting MO2 aaaaand then nothing happens. Curiously, it works fine from steamtinkerlaunch mo2 start (minus the font being rather squished).

steamtinkerlaunch.log

sonic2kk commented 6 months ago

The log gives information about how SteamTinkerLaunch gets ready to launch MO2. Nothing else can be provided, because at that point it's up to Wine. The feedback in the Wine run log and the terminal output (which should be more or less the same) is all that is provided by Wine and MO2. STL can't give you what doesn't exist.

Curiously, it works fine from steamtinkerlaunch mo2 start

The command you showed previously was using this and it didn't work, so I don't understand.

Troubleshooting Wine incompatibilities isn't something I can help with anyway, only workaround them with things like pinning to V2.4.X.

AutumnalModding commented 6 months ago

The command you showed previously was using this and it didn't work, so I don't understand.

Yes, this is after updating to latest git via AUR. I should have probably specified. It's using 2.4.4, or at least it very well should be.

sonic2kk commented 6 months ago

Well then things should be working as expected, right? Assuming you did a fresh reinstall by removing the prefix, and making sure the game and MO2 are using the same Proton version.

I'm not sure what the issue you're facing right now actually is, if steamtinkerlaunch mo2 start is working and is using v2.4.4.

AutumnalModding commented 6 months ago

Well then things should be working as expected, right? Assuming you did a fresh reinstall by removing the prefix, and making sure the game and MO2 are using the same Proton version. I'm not sure what the issue you're facing right now actually is, if steamtinkerlaunch mo2 start is working and is using v2.4.4.

Launching MO2 from the STL GUI (steamtinkerlaunch %command% in the game's launch options) does not work... and according to startMO2_.log, it's trying to use 2.5.1 (???). And yes, this is after removing ~/.config/steamtinkerlaunch.

sonic2kk commented 6 months ago

You shouldn't be using steamtikerlaunch %command%, as the Readme states this is only for native games. There are also wiki pages documenting this. You should be using SteamTinkerLaunch as a compatibility tool for Proton games.

and according to startMO2_.log, it's trying to use 2.5.1 (???).

Is this perhaps an old file? Remove / inspect the modified date.

There is no information about how MO2 was downloaded or installed so I can't tell what version was being used. Check ~/.config/steamtinkerlaunch/downloads/mo2 and see what EXE it downloaded.

If it's still trying to use v2.5.1 make sure the prefix was removed and created fresh, as MO2 will not be reinstalled or downgraded.

AutumnalModding commented 6 months ago

There is no information about how MO2 was downloaded or installed so I can't tell what version was being used. Check ~/.config/steamtinkerlaunch/downloads/mo2 and see what EXE it downloaded.

It's 2.4.4. So I don't even know where it's getting 2.5.1 from.

You shouldn't be using steamtikerlaunch %command%, as the Readme states this is only for native games. There are also wiki pages documenting this. You should be using SteamTinkerLaunch as a compatibility tool for Proton games.

Huh. That's... how I used to do it. Perhaps it's changed, I will try running it as a compatibility tool. update: no change, whatsoever. I will try another rm -rfv ~/.config/steamtinkerlaunch. Additionally the MO2 button doesn't seem to install it; has to be done via CLI.

update #2: it's still trying to use 2.5.1. trying file '.\ModOrganizer-2.5.1rc2-20240112T041626.dmp'. where is it even executing from???

sonic2kk commented 6 months ago

That has not been valid usage of STL for Proton games for at least a couple of years, since I started using it and before I took over. So it's good to correct that now.

You're not the first to do this, so I'd like to ask: Why are users doing it this way? I'm not getting at you I would just genuinely like to understand what isn't being communicated properly. It had to be corrected often enough that an even more explicit section was added to the wiki (by me, before I was maintainer and was just a user and contributior) and I've had to correct it on more than a few occasions since then.

It's 2.4.4. So I don't even know where it's getting 2.5.1 from.

Sounds like it's an old file. Try removing /dev/shm/steamtinkerlaunch and seeing if it generates fresh log files.

I have a suspicion here that a mismatch of Proton versions is causing the issue. Make sure you're using the same Proton version with the game and MO2 (Game Menu for Game Proton which is used to run MO2 with the game, Global Menu for MO2 Proton which is used to run MO2 from the command line and to install it).

When running with the game it is ran with Proton, and Proton will upgrade/downgrade prefixes. When running with the commandline, MO2 runs with Wine and does not do the same prefix altering that Valve's Proton script does. This can create incompatibilities.

it's still trying to use 2.5.1. trying file '.\ModOrganizer-2.5.1rc2-20240112T041626.dmp'. where is it even executing from???

This is ModOrganizer 2 logging, not STL logging, so I'm not sure (STL just pipes it to a file).

AutumnalModding commented 6 months ago

You're not the first to do this, so I'd like to ask: Why are users doing it this way? I'm not getting at you I would just genuinely like to understand what isn't being communicated properly. It had to be corrected often enough that an even more explicit section was added to the wiki (by me, before I was maintainer and was just a user and contributior) and I've had to correct it on more than a few occasions since then.

The standard procedure for most other fixes and tools is to run them like that - e.g. specific Proton arguments via environment variables (usually PROTON_USE_WINED3D) or wrapper tools (e.g. optirun, primusrun; if those are still around). So logically it makes sense that STL should be run like that - and additionally, I'd wager most users don't even know you can have compatibility tools other than Proton.

sonic2kk commented 6 months ago

Thanks for clearing that up, and I guess the assumption then is that users don't, so to speak, "RTFM".

Well, nothing I can do then, since it's documented well enough. I'm glad there isn't a miscommunication in the docs or some other outdated info (such as some prevalent outdated blog post or something).

AutumnalModding commented 6 months ago

Thanks for clearing that up, and I guess the assumption then is that users don't, so to speak, "RTFM". Well, nothing I can do then, since it's documented well enough. I'm glad there isn't a miscommunication in the docs or some other outdated info (such as some prevalent outdated blog post or something).

No problem :)

sonic2kk commented 6 months ago

Actually, come to think of it, unless wrapper is the wrong word for tools like primerun etc, maybe wrapper is the wrong word for STL. I dunno, I never thought too hard about that part, and I didn't come up with the phrasing. To me having been close to the project for so long I'm disconnected from what a fresh interpretation might be, but I think originally the phrase "wrapped tool" was getting at the fact that it wraps and intercepts the start process.

Not sure it's worth changing now, and usage is noted on the Readme, so I guess it's... "Fine". If someone opens an issue about it in future with some enhancement ideas I'll cross the bridge then.

Or maybe I'm thinking too hard about a word you happened to use in passing and now it's become awkward 😅 Anyway not a big deal, just glad to get some input.

sonic2kk commented 6 months ago

Removed the invalid label as there was significant new information added here. I was too harsh and did not give you a chance to expand on the issue in the OP, the lack of information and structure got to me a little bit and I should've been less rash. Too many low effort issues that were similar to this have worn down my patience, and I'll work on trying to get some of that back.

sonic2kk commented 6 months ago

Some thoughts on the issue, might be repeating myself so bear with me:

AutumnalModding commented 6 months ago

Apologies for the delay in response, but:

MO2 seems to be installing to the game prefix (Skyrim SE, in this case); which would explain both the correct function of steamtinkerlaunch mo2 start (as it does not use the game's prefix) and it not being removed upon wiping STL's config folder (as per-game MO2 is not stored there). I'm not entirely sure if this is intended, then; but it does seem that when running STL via Steam (either as a wrapper or as a compatibility tool), it doesn't respect ~/.config/steamtinkerlaunch/mo2 and instead uses the game-specific prefix (usually <prefix_root>/Modding; I believe there is an option to install in a different location but only within the same prefix.)

If this is a bug, then my (admittedly band-aid) solution would be to symlink <prefix_root>/Modding to ~/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/Modding/ the first time MO2 is used per game, and then run from there. Admittedly I'm not quite sure if this would even work (does Wine respect cross-prefix symlinks?); but it's certainly worth a try.

There is also the issue of the font being squished - see attached image - but I'm not sure if this is a Wine bug or if I've just missed a wiki entry somewhere. image

sonic2kk commented 6 months ago

The squished font is a Wine issue. Wine programs semi-often don't look right. Changing the MO2 theme may help though.

MO2 installing into the game prefix sounds weird, it should be symlinking it to my knowledge. But I don't use the mod tools and I wasn't involved in implementing them, in fact I have hardly looked at any of the MO2 code.

I did a modded Oblivion playthrough a long while ago, I'll check there and check the code to see what's going on, but MO2 should only get installed to the main MO2 compatdata and then MO2 runs in the game prefix. So it's installed once but runs elsewhere. That's how Vortex works and to my limited understanding that's what I understood MO2 to do as well.

Removing MO2 from the game prefix should resolve this then I think?

sonic2kk commented 6 months ago

Okay, ModOrganizer 2 is installed into the game prefix. That's the first I ever noticed that. In the code, I suspect it's setModGameSyms that does this.

Does removing the MO2 install in the prefix re-create it? You can remove / rename the MO2 folder in the game prefix, and then try running MO2 in Game Mode. Directly afterwards, success or otherwise, it would be interesting to check the log to see if STL has anything to say.

On another note, migrating to MO2 v2.5.0 sounds like a disaster on Windows, so I can't imagine what the upgrade path to v2.5.0 will be like on Linux. Hopefully someone comes forward to help maintain the MO2 part of the code and can offer more insight.

sonic2kk commented 6 months ago

In initial testing, removing the MO2 install from the prefix seems to re-create it correctly.

From what I'm gleaning from the code (keeping in mind I have only browsed it for about 15 minutes here), it seems STL will install MO2 into the per-game prefix, so you were correct about that. This is performed the first time MO2 is started in the game prefix, so on MO2 GUI mode. Then, to bridge the gap, it modifies the MO2 INI in the game prefix to point to the paths in the "global" prefix, that is the one at $HOME/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/Modding/MO2.

I'm doing some tests to see how safe this is for existing modded installs, since all the mods should be installed to the global prefix by default it should be safe enough.

This appears entirely safe. I removed the "MO2" folder from my Oblivion game prefix and re-ran MO2 in GUI mode, and it created the new install fine and found all my mods, they also loaded correctly. Or at least all the ones I could tell loaded properly (I had a bunch of texture mods, UI mods, etc). The wrong profile was selected by default, it went back to "Default" but it still had the profiles saved, and selecting them worked fine.

AutumnalModding commented 6 months ago

Does removing the MO2 install in the prefix re-create it? You can remove / rename the MO2 folder in the game prefix, and then try running MO2 in Game Mode. Directly afterwards, success or otherwise, it would be interesting to check the log to see if STL has anything to say.

Yeah, that ended up fixing my install.

sonic2kk commented 6 months ago

Yeah, that ended up fixing my install.

Awesome! I certainly learned something today. It may be worthwhile to add a command to re-create the MO2 install in the game prefix then, although this shouldn't happen too often.

AutumnalModding commented 6 months ago

Awesome! I certainly learned something today. It may be worthwhile to add a command to re-create the MO2 install in the game prefix then, although this shouldn't happen too often.

That's probably a good idea, yeah. Additionally; while this is technically a different problem than before, MO2 now refuses to launch anything.

Error 5 ERROR_ACCESS_DENIED: Accessdenied. (0x5)
 . binary: 'Z:\home\lily\Other\Mountpoints\Games\SteamLibrary\steamapps\common\Skyrim Special Edition\skse64_loader.exe'
 . owner: GetEffectiveRightsFromAclW(), Invalidfunction. (0x1)
 . rights: GetEffectiveRightsFromAclW(), Invalidfunction. (0x1)
 . arguments: ''
 . cwd: 'Z:\home\lily\Other\Mountpoints\Games\SteamLibrary\steamapps\common\Skyrim Special Edition'
 . stdout: no, stderr: no, hooked: yes
 . MO elevated: yes
 . usvfs x86:ok x64:ok proxy_x86:ok proxy_x64:ok

I suspect this is a permissions error; though I have marked it executable.

sonic2kk commented 6 months ago

Are you running on an NTFS drive by any chance?

Also:

That's probably a good idea, yeah.

I thought so too, but this is kind of a disaster. STL is really hardcoded to assume the MO2 version will never change, probably because it was set to v2.4.4 for such a long time. There is no real concept of upgrading. I wonder if it would be feasible for STL to just symlink the global MO2 folder, but I don't really want to touch the MO2 code.

I'll wait for someone to come along who can advise better, but this is likely going to be problematic overtime.

AutumnalModding commented 6 months ago

Are you running on an NTFS drive by any chance?

Nope. Both my local drive and my games drive are ext4.

sonic2kk commented 6 months ago

I'm not too sure what the issue is then, though this is a much more general Wine issue. I'm also not encountering it, but I'm also not using Skyrim.

You shouldn't need to mark any Wine executable as executable, or change any of those permissions.

MO2 is launching and that's generally as far as STL aims to get you. Issues launching games or with mods are a different story, though I really do wonder why it isn't working. Can you run the actual game EXE and not skse_loader64.exe? In case it is an issue specific to this EXE.

AutumnalModding commented 6 months ago

Can you run the actual game EXE and not skse_loader64.exe? In case it is an issue specific to this EXE.

I did try that; but it happens with everything. Even MO2 itself, somehow:

Error 5 ERROR_ACCESS_DENIED: Accessdenied. (0x5)
 . binary: 'C:\Modding\MO2\ModOrganizer.exe'
 . owner: GetEffectiveRightsFromAclW(), Invalidfunction. (0x1)
 . rights: GetEffectiveRightsFromAclW(), Invalidfunction. (0x1)
 . arguments: 'launch "Z:\home\lily\Other\Mountpoints\Games\SteamLibrary\steamapps\common\Skyrim Special Edition\data\tools\GenerateFNIS_for_Users" "Z:\home\lily\Other\Mountpoints\Games\SteamLibrary\steamapps\common\Skyrim Special Edition\data\tools\GenerateFNIS_for_Users\GenerateFNISforUsers.exe" RedirectFiles="C:/users/steamuser/AppData/Local/ModOrganizer/Skyrim Special Edition/mods/FNIS Behaviour Output" InstantExecute=1'
 . cwd: 'C:\Modding\MO2'
 . stdout: no, stderr: no, hooked: yes
 . MO elevated: yes
 . usvfs x86:ok x64:ok proxy_x86:ok proxy_x64:ok
sonic2kk commented 6 months ago

From searching around with wine Error 5 ERROR_ACCESS_DENIED this seems to happen for a variety of different reasons. It would be hard to say why it's happening in your specific case and not mine.

What if you change the path to use the Z:\ drive instead of C:\? I checked my paths and they're using the Z;\ drive, which afaik Wine uses to map your global drive. There could be some cross-drive permissions issues causing the problem you're seeing.

Under the "Modify Executables" section of MO2, the Binary and Start in paths are both using Z:\

AutumnalModding commented 6 months ago

What if you change the path to use the Z:\ drive instead of C:\?

Z:\ is (usually) just the root drive; I'm not entirely sure what you mean? Do you mean I should try specifying an absolute path instead of a prefix-relative path?

Under the "Modify Executables" section of MO2, the Binary and Start in paths are both using Z:\

Yes, they have to be; the game executables aren't stored in the prefix. Additionally I doubt it would be a cross-drive issue, seeing as ~/Mountpoints/Games is a different drive.

sonic2kk commented 6 months ago

Z:\ is (usually) just the root drive; I'm not entirely sure what you mean?

Yes, you should specify an absolute path using Z:\. For example, instead of C:\Modding\MO2\ModOrganizer.exe, it might be something like Z:\home\username\path\to\chosen\pfx\drive_c\Modding\MO2\ModOrganizer.exe.

AutumnalModding commented 6 months ago

Yes, you should specify an absolute path using Z:. For example, instead of C:\Modding\MO2\ModOrganizer.exe, it might be something like Z:\home\username\path\to\chosen\pfx\drive_c\Modding\MO2\ModOrganizer.exe.

I'm actually not sure why it's trying to start itself; though given that it happens with any executable I'd wager it's not cross-drive.

sonic2kk commented 6 months ago

If in doubt, you could always try removing the MO2 install from the Skyrim prefix and the global MO2 install, and re-trying. But I don't know if that'll work, it's a stab in the dark.

AutumnalModding commented 6 months ago

If in doubt, you could always try removing the MO2 install from the Oblivion prefix and the global MO2 install, and re-trying. But I don't know if that'll work, it's a stab in the dark.

How do you mean? Completely uninstall MO2 from the game's prefix and ~/.config/steamtinkerlaunch/mo2? (Wouldn't that cause issues with installed mods?)

sonic2kk commented 6 months ago

How do you mean? Completely uninstall MO2 from the game's prefix and ~/.config/steamtinkerlaunch/mo2? (Wouldn't that cause issues with installed mods?)

It will would cause issues with installed mods but you can back them up from their install location (if default, likely ~/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/users/steamuser/Local Settings/Application Data/ModOrganizer/Skyrim Special Edition. I would back up that whole folder, or even the whole prefix, and then when the new global MO2 install is done, paste the files for the Skyrim SE instance back in.

Outside of that, yep, remove (or just rename) the global MO2 prefix, and the MO2 installation in the game prefix.

I don't mod games, I don't use MO2, but I'm doing my best to help you troubleshoot a general Wine issue. I have about as much idea as you do about how to resolve this unfortunately :frowning_face:

AutumnalModding commented 6 months ago

It will would cause issues with installed mods but you can back them up from their install location (if default, likely ~/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/users/steamuser/Local Settings/Application Data/ModOrganizer/Skyrim Special Edition. I would back up that whole folder, or even the whole prefix, and then when the new global MO2 install is done, paste the files back in.

Hrm. I'm assuming that folder isn't supposed to not exist. Is that another bug?

sonic2kk commented 6 months ago

Nothing so far has been a bug, I'm not sure what you mean by "another bug".

The folder path might be different, you can verify what the mod install path is by going to the ModOrganizer 2 settings and going to the "Paths" tab.

AutumnalModding commented 6 months ago

Nothing so far has been a bug, I'm not sure what you mean by "another bug".

Doesn't STL change MO2 configuration to point there?

Then, to bridge the gap, it modifies the MO2 INI in the game prefix to point to the paths in the "global" prefix, that is the one at $HOME/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/Modding/MO2.

On my install, it still points to a prefix-local directory. (Maybe I'm just misinterpreting?)

sonic2kk commented 6 months ago

Doesn't STL change MO2 configuration to point there?

If the path exists, and MO2 creates the path. STL points to the relevant existing path specified by the global MO2 installation from what I remember. But really, I couldn't tell you in-depth. I rarely even use ModOrganizer 2.

On my install, it still points to a prefix-local directory.

That does not sound correct, maybe you should try re-installing. All of my paths are pointing to the global MO2 installation: Z:/home/emma/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/users/steamuser/AppData/Local/ModOrganizer/Oblivion/ (with downloads, mods, etc on the end).

Although I don't know if any of this will fix the launching issue. I have never ran into it, and I very rarely mod games (and when I do, I do it manually), and this is all very much out of my depth. I'm not sure how much more useful information I'll be able to give if nothing here works.

AutumnalModding commented 6 months ago

That does not sound correct, maybe you should try re-installing. All of my paths are pointing to the global MO2 installation: Z:/home/emma/.config/steamtinkerlaunch/mo2/compatdata/pfx/drive_c/users/steamuser/AppData/Local/ModOrganizer/Oblivion/ (with downloads, mods, etc on the end).

A reinstall has appeared to fix the issue; though STL's MO2 folder is still empty: image

sonic2kk commented 6 months ago

Are you reinstalling with steamtinkerlaunch mo2 install or steamtinkerlaunch mo2 start?

AutumnalModding commented 6 months ago

Are you reinstalling with steamtinkerlaunch mo2 install or steamtinkerlaunch mo2 start?

Neither; I'm launching STL as a compatibility tool and installing via the GUI.

sonic2kk commented 6 months ago

This might be a source of issues then, I haven't ever tested with the GUI. I always install with steamtinkerlaunch mo2 start, although install should also work (I tested that option with the MO2 custom executable a while back and recall it working).

This may also be why the MO2 paths are pointing at your Skyrim prefix and not at the global one.

The wiki does mention the Main Menu, I re-wrote the wiki a long time ago and this may have been a holdover. I'll have to investigate at another time what the Main Menu option actually does, I haven't heard of anyone using it before though.

AutumnalModding commented 6 months ago

This might be a source of issues then, I haven't ever tested with the GUI. I always install with steamtinkerlaunch mo2 start, although install should also work (I tested that option with the MO2 custom executable a while back and recall it working).

This is entirely possible; though as the game seems to function correctly now I think most STL-related (even if loosely) issues are all solved. I do appreciate your help in attempting to fix the MO2 ones, even if you don't use it personally :)

sonic2kk commented 6 months ago

I hope it continues to work! Happy gaming! :-)