Linux modding tutorial (Wine, Proton, Lutris)...maybe?

[junglized]

It's not really a bug but rather tutorial request. I'm on Pop!_OS using Lutris for gaming. Everything works just fine. Unfortunately I can't figure out how to run 7th Heaven with any version of FF7. Could anyone provide a simple tutorial on how to mod FF VII with Wine or Steam + Ptoton version?

Thanks a lot!

[sjenkins7]

Still no joy - for whatever reason the only runner that I could get working previously is no longer available. Every other one either causes 7th Heaven to crash on launch, or causes the "code 5" issue, of which the workaround doesn't work at all in wine.

Because vaniglia is unavailable, unsure how Steam Deck users are currently able to use this at all.

Been trying to avoid making a fully native launcher to help lock down all these moving pieces, because it would take a fair amount of time. It's increasingly looking like I might not have alot of choice, unless we can deal with the underlying hooking mechanism ( which i suspect would just break everyone's existing mods.... ). At very least, a native launcher may make it easier for the Steam Deck users to run in Big Picture / gaming mode.

Don't suppose anyone on the team has time to chat about this in Discord in some detail? Feel free to ping / DM me directly on the server - senkins#6194

[PlUmPaSsChIcKeN]

Haven't checked the discord in a while but people have gotten 7th Heaven to work?

I was messing around with it a while ago and managed to get 7th Heaven installed using steam but was having errors whenever I added the game directory to it and tried to run it. I'm wondering if those users are running windows instead. If not, were they able to get it running in game mode?

One of the major hassles with it was the on screen keyboard kept getting stuck and would glitch out so very difficult to maneuver around using only the steam deck. Definitely need to plug it into an external dock

[Hannan100]

Anyone had any luck with this recently? I tried following the earlier Bottle approach today without much success (got 7th installed, but it failed to launch even the vanilla game).

[SeongGino]

Still the same behavior, and will probably stay this way until it's directly addressed.

[cyberconan]

Hi everyone! Thanks sjenkins7 for the advice with vaniglia wine version. At the moment on Archlinux I can play ff7 with the new 7th heaven releases after downloading the wine fork from here and using a little script:

#!/bin/sh
ff7_path="<my ff7 game path>"
wine_bin="$ff7_path/vaniglia-6.23-x86_64/bin/wine"

export LC_ALL="C"
export WINEESYNC=1
export WINEPREFIX="$ff7_path/wine-ff7"

"$wine_bin" "7th Heaven.exe" /PROFILE:Default /LAUNCH /QUIT

Thanks also to The Tsunamods team for keeping the project alive.

[SeongGino]

Unfortunately, am unable to reproduce any working functionality with the linked Vaniglia fork:

Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed!
Monitored process exited.
Initial process has exited (return code: 32512)

Using latest Arch glibc. The newest Vaniglia release doesn't even have a wine executable so Lutris doesn't see it.

[cyberconan]

Unfortunately, am unable to reproduce any working functionality with the linked Vaniglia fork:

Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed!
Monitored process exited.
Initial process has exited (return code: 32512)

Using latest Arch glibc. The newest Vaniglia release doesn't even have a wine executable so Lutris doesn't see it.

To call the wine fork from Lutris you would have to clean up the old library calls in the folder. To avoid this I use the script I posted that calls the compiled Vaniglia binary from bash using the archlinux system libraries instead of the ones it carries. Try to use the script and you will see how the 7th heaven.exe starts.

[SeongGino]

To call the wine fork from Lutris you would have to clean up the old library calls in the folder. To avoid this I use the script I posted that calls the compiled Vaniglia binary from bash using the archlinux system libraries instead of the ones it carries. Try to use the script and you will see how the 7th heaven.exe starts.

Well from what I can tell, all your script does is set the WINEPREFIX, esync, whatever LC_ALL is, and runs the program using a designated wine version; all things Lutris does. I ended up setting the Disable Lutris Runtime setting for my 7th Heaven launcher... er, launcher--and Vaniglia works just fine.

Indeed, 7h hooks seems to work just fine with this specific Wine fork.

I experimented a bit, and the Vaniglia fork is the only one that seems to function with the hooks - allegedly it's "just" Wine Staging patches, but the corresponding Wine-Staging release throws a similar error to every other Wine release. But FWIW, Vaniglia 7.5 (i.e. the release before Vaniglia 7.4) also works. But the following release doesn't, and it seems every subsequent Vaniglia release strips out WoW64 support; hence the lack of a normal wine executable.

I'd also like to point out that using it with FSYNC enabled seems to not have any harmful effects. And now I'm wondering what the point was of using the LC_ALL=C flag...

P.S. Using this Wine version causes 7h to crash whenever clicking on anything that renders a dropdown menu, as well as simply hovering over the status bar/"click here to display logs" area, which is very easy to do by sheer accident.

[Hannan100]

For what it's worth, I was eventually able to get everything working on Steam Deck once I made sure I was using the vaniglia runner. The other stumbling block was setting the drive label with wineconfig not working, but I eventually got around that by placing a .windows-label file in the drive directory.

Everything now works: 7H, vanilla FF7 and modded FF7. The only thing I can't get to work is the Bottles shortcut in Steam to access it in the Deck UI rather than Desktop mode, but that's not the end of the world.

[selektionsrest]

Got Bottles setup and 7th Heaven launches.... but cant get it to recognize the mounted iso and when i start FF7 (the minimal validation option) it crashes

[persunde]

@lumnie Do you or anyone else have any tips for how I can get bast the mounted ISO requirement. I am just not able to get past that requirement...

I have been unable to add a fake drive called FF7DISC1 that Proton will see, so running with Minimal Validation also does not work :(

[persunde]

Is there a reason why 7th Heaven requires the ISO to be mounted? Pretty sure it would be easy to run it if the ISO requirement was circumvented somehow. I can easily play FF7 on Steam using proton, but it does not work when running 7th heaven on Proton.

[SeongGino]

Because the original legal copy has a CD check that requires this workaround. The Steam release is a whole different game technically.

The alternative would be piracy, which I'm just going to guess shouldn't be discussed on a public forum like this. But even then, I doubt the alternative method would work.

The marking a dummy disc as FF7DISC1 method works fine in normal Wine.

[persunde]

Is it possible for this mod to run using the steam release .exe file for those who want to use that? I believe that should solve the problem and make it very easy to run 7th heaven on linux.

It was super easy to run FF9 with the moguri mod using Stream Proton. But because 7th heaven runs using the non-steam .exe that requires disk verification it is very complicated to get it running.

@Hannan100 Can you please describe in more detail how you were able to set the label on the ISO disk. I tried to make a dummy ISO like this: mkisofs -o /tmp/FF7DISC1.iso -V FF7DISC1 /tmp/empty-file

I managed to mount it using protontricks, but 7th heaven just wont accept the CD. I believe the drive label is not set, but I am not sure.

Edit: I think I have the label set correctly now. But it just wont work. Is this not correct setup to run the "Minimal Validation"? It does not work for me... :(

[sjenkins7]

I managed to mount it using protontricks, but 7th heaven just wont accept the CD. I believe the drive label is not set, but I am not sure.

Make sure you have .NET 4.8 installed. There appears to be an issue with mono, where it doesn't return the correct disc label.

[julianxhokaxhiu]

Hey community, I'd like to let you know about the imminent release of what is going to be the 7th Heaven 3.0 release. If you want to know more, you'll find the announcement on the qhimm discord server, but in a nutshell is a .NET 7 version with a completely rewritten injection engine that will work without admin permissions or code 5 issues. Feel free to try the latest canaries and let me know how it goes!

[SeongGino]

For what it's worth, the .NET 7 canary build works better with Linux, so long as the launcher is loaded with a DOTNET_ROOT=c:\Program Files\dotnet\\ environment variable for it to not confuse the native Linux version with the Windows one it installs. It still needs either DXVK disabled or a dxvk.conf file in the 7H directory with

[7th Heaven.exe]
d3d9.shaderModel = 1

to render the window properly, but otherwise it works from 7H's installer on a fresh prefix.

Unfortunately though, trying to run FF7 has been a challenge; on a new prefix using only the .NET and MSVC redists the installer includes, trying to run the game (modded or vanilla) causes FF7 to ignore FFNx and loads its software renderer because it's not respecting any game driver settings and even messed with my desktop resolution, then immediately crashes (with 7H still open). At least running modded isn't technically generating any errors now?

I'm also noticing it keeps trying to re-register registry entries that are already present?

This is with Wine-GE.

[sjenkins7]

After a little bit of playing around last night & this morning - I was able to get the game launched with the new Canary, but no mods appear to take effect:

I could only get this far with Proton 7.0 currently - using WINE 7.0.1 from flatpak currently just segfaults on launching 7th Heaven.

Closing the game currently causes it to freeze & the 7th Heaven Canary doesn't respond to closing the window or ALT + F4.

I have seen the same issue as @SeongGino while building this from clean - I'm wondering if there is something different being done in the Canary on a clean install that isn't taking effect if you upgrade from Stable?

It still needs either DXVK disabled or a dxvk.conf file in the 7H directory with

Thanks for this - trying to disable DXVK when Flatpak bundles it by default has proven difficult. Should go a long way to resolve the glitchy / black-screen rendering i was having.

[sjenkins7]

In addition - Had to install mods & FFNx manually. For some reason 7th Heaven is unable to check for updates or read the catalog

[julianxhokaxhiu]

I'm wondering if there is something different being done in the Canary on a clean install that isn't taking effect if you upgrade from Stable?

Yes, upgrading 7th using the internal update would not install the .NET 7 Desktop Runtime required to run it, as well as the VC++ Runtime for the native injection to work.

I was able to get the game launched with the new Canary, but no mods appear to take effect

Not sure how to check that under Wine but you need to make sure hooking Win32 APIs is allowed as we use Detours in order to do so. If there's a way to make it verbose please check the logs if any error or warning shows up there.

For some reason 7th Heaven is unable to check for updates or read the catalog

If you used the setup to install it and you did on a usually Administrator based path ( Program Files ) I pushed a patch that will fix this permission issues ( at least on Windows ). If you're using the ZIP and installing it on your own path then I have no idea, again check the logs in either 7th or Wine to see if anything shows up. I'd start from the 7th applog.txt and moving around it.

[sjenkins7]

Yes, upgrading 7th using the internal update would not install the .NET 7 Desktop Runtime required to run it, as well as the VC++ Runtime for the native injection to work.

Just to be clear - I am still running the launcher itself over the top of a working ( vanilla only ) Stable install. It automatically installed the runtimes as needed.

Not sure how to check that under Wine but you need to make sure hooking Win32 APIs is allowed as we use Detours in order to do so. If there's a way to make it verbose please check the logs if any error or warning shows up there.

I'll re-run this and try to get some decent logs. Didn't have time to capture everything this morning as it was a quick test before work.

If you used the setup to install it and you did on a usually Administrator based path ( Program Files ) I pushed a patch that will fix this permission issues ( at least on Windows )

This is the 2.9.9.44 install, which has this included? Or are you referring to an additional change since?

[julianxhokaxhiu]

2.9.9.44 has the change I mentioned so you should be good, but only the setup ( the .exe download on the asset list basically )

[sjenkins7]

Fresh install using 2.9.9.44 exhibited the same behaviour - I've attached the 7th Heaven logs that show a couple of attempts to get the catalog & FFNx. applog.txt

You will see a couple of launch attempts, but those immediately crashed - no FFNx was downloaded & I opted not to manually install it yet, until we've got a good base to automate from.

[julianxhokaxhiu]

Tbh looks like a network stack issue than a 7th issue on its own. Maybe check if there's anything related to this issue on Wine forums. I'll also try to dump some more details on the logs so the next time we can see where and why it fails.

[sjenkins7]

Yeah i suspect a chunk of this will be down to the Switch to .NET 7 and how that is handled in Wine. I've been digging around since but so far, we appear to be one of the only ones using such a new version of .NET at this time.

Watching the debug output for Wine has it's usual fixme logs, but didn't see anything related. I'll look into how winetricks handles older .NET installs, as I recall it being somewhat of a pain. Or see if they are willing to support it, though that will take some time.

EDIT: clarification

[julianxhokaxhiu]

Yeah .NET 7 has been recently released so I can imagine the struggle to get it running on Wine but I'm confident the community will find their way out. I honestly don't have time to run in parallel on this as I'm really overbooked with thingas to follow and next things to work on around FFNx and 7th, but I'll be happy to provide any patch required to help on this mission. Patience and willingness is what will make this port eventually succeed. Don't give up!

[julianxhokaxhiu]

Heads up, on the latest .49 canary you'll find this commit which should help with what we discussed today: https://github.com/tsunamods-codes/7th-Heaven/commit/4c0284f906c1bf8af850e6c3d40e83ef186c2f42

Feel free to check/post the applog.txt for more info, it should contain a stack trace of the reason why it's failing.

[sjenkins7]

Thanks for that - re-ran with the .49 canary and seeing a number of the same underlying exception:

System.Runtime.InteropServices.SEHException: External component has thrown an exception.

Added the full log, but there isn't alot else there: applog.txt

I don't see an error code to go with this, so unsure how to help narrow this down

[julianxhokaxhiu]

Looks like some kind of unmanaged exception from .NET perspective: https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.sehexception?view=net-7.0#remarks

I have no idea which component is used to download but I can try to check later what is going on and If I can understand something around it. Although as it works fine under Windows I might think it's something related to Wine and its underlying layer :(

//EDIT: See "Wine Tracing" here: https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html might help debugging

[sjenkins7]

Thanks for the extra info in the edit - Will be very useful. The HTTP Listener part seems interesting, as the flag implies there may be other parts of .NET that could potentially be forced into a Managed implementation, which is likely to be better in terms of compatibility.

I have access to a Windows VM, so I'll download the source and go playing around - see what comes out of it

[julianxhokaxhiu]

Actually, one of the warnings I get from .NET 7 now is that the core component we use to do downloads is deprecated. I'll try to see if I can easily migrate to what .NET suggests, this might fix also your issue perhaps.

[julianxhokaxhiu]

I was able to migrate one of the basic download classes, so most of the catalog should work fine. Google Drive links will still use the old download code until I figure out how to migrate that. Feel free to test the latest canary.

[SeongGino]

Catalog does seem to work at least in latest canary.

Interestingly, I find that the catalog downloader module crashes with current Wine-GE builds (External component as thrown an exception), but using a build of current Wine Staging (which is my system's Wine) allows it to work.

[julianxhokaxhiu]

Were you able to download some mods? What about launching the game? Were you able to load them?

[sjenkins7]

Quick re-run of v2.9.9.58 was the same as before for me - both FFNx updates & mod catalogs failed with the same exception.

[julianxhokaxhiu]

@sjenkins7 I suppose it has nothing to do with .NET then as @SeongGino was able to run it...double check if you're both on the same Wine codebase or something...please also remember that if you use different distributions you might have different patch sets applied on top. Safer option would be to test this on Arch linux.

[sjenkins7]

Agreed @julianxhokaxhiu - Staging seems to be the way to go, but I don't have this as an option for Flatpak currently. I'll re-try it later on my main PC, rather than on the Steam Deck

[julianxhokaxhiu]

Yes please, let's focus on a mainline Linux first so it will be easier to pinpoint eventual Steam Deck issues.

[sjenkins7]

OK wine Staging 7.22 ( wine-staging package on Arch ) - Able to get the catalog now.

Attempting to launch the game out-of-the-box fails, as the registry isn't quite setup right:

[Software\\Wow6432Node\\Square Soft, Inc.\\Final Fantasy VII] 1671188680
#time=1d9113e319f62e8
"AppPath"="C:\\Games\\FINAL FANTASY VII\" /t REG_SZ /f /reg:64"
"DataDrive"="X:\" /t REG_SZ /f /reg:64"
"DataPath"="C:\\Games\\FINAL FANTASY VII\\data\" /t REG_SZ /f /reg:64"
"DiskNo"=dword:00000000
"FullInstall"=dword:00000001
"MoviePath"="C:\\Games\\FINAL FANTASY VII\\data\\movies\" /t REG_SZ /f /reg:64"

Explains why i'm being greeted with multiple command line prompts asking to override the key on each launch attempt

EDIT: package clarification

[sjenkins7]

Just to add - If i manually correct those entries, I get to the same point as @SeongGino previously - Game fullscreens & immediately crashes.

Have to manually reset the display resolution after

[SeongGino]

@sjenkins7 and that's why I've been running in virtual desktop mode, for what it's worth.

Were you able to download some mods? What about launching the game? Were you able to load them?

I actually was able to download a mod (Finishing Touches, just as an example) with Wine Staging (Wine version seems to be a root cause in this, since Wine-GE fails at even downloading previews even with a pre-fetched catalog). The download bar itself doesn't immediately indicate progress, it stayed at 0% and estimated time at pending, but then went right to 100% after a few moments. After which it installed fine and showed up in the mod list, and I can configure it with no corruption or anything.

Er, still same launch issue though. Registry override popups (like Jenkins earlier), then game still only loads the old renderer and crashes outright, whether vanilla or not. FWIW I can go back to my 7H 2.4.1.0 prefix detailed earlier here running that older stable version, using the same instance of FF7 and it'll load FFNx and mods fine. But the new canary version in its own prefix, no dice when actually loading the game thus far.

[julianxhokaxhiu]

May I ask if you can please post the Wine config you're using?

[SeongGino]

Running Arch and doing all this through Lutris, fwiw:

Wine-staging from Arch multilib repos Using Lutris's defaults with the exception of Windowed (Virtual Desktop) enabled, and an environment variable DOTNET_ROOT=c:\Program Files\dotnet\\. All running on a clean prefix using nothing but the dependencies provided from 7H Canary's .exe installer. Then I set a custom D:\ pointing to an install of FF7's directory using the label FF7DISC1.

[sjenkins7]

Spent a bit of time diffing my previously working (stable but vanilla game only ) prefix & one created using the latest canary - seems that there was 2 values missing from system.reg:

[Software\\Wow6432Node\\Square Soft, Inc.\\Final Fantasy VII\\1.00\\Graphics]
"DD_GUID"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[Software\\Wow6432Node\\Square Soft, Inc.\\Final Fantasy VII\\1.00\\Sound] 
"Sound_GUID"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

Both appear to be needed to get Graphics & sound to work at all.

I get back to roughly where I was before - Game freezes if you quit / ALT+F4. I can launch with mods, but none appear to be taking effect ( I picked what i felt to be obvious ones to be sure ).

[sjenkins7]

Possibly related - Missing logs cause 7th Heaven to crash, if FF7 exits uncleanly:

On the face of it, seems like the wrapper is just silently failing?

[SeongGino]

Turns out in my case, it was both the missing keys that @sjenkins7 referenced, and that my AppPath/DataPath/MoviePaths were somehow malformed (which is why 7H kept prompting me to change the registry, because it turns out my paths somehow turned into didn't matter if it was a virtual B:\ or Z:\ ; it always does this) After manually fixing those registry keys, now FF7 boots up fine with FFNx.

But yeah, mods still don't load at all. My guess is it would be the wrapper failing?

[sjenkins7]

@SeongGino I believe the registry mangling was resolved in the latest / .71 canary. I did mine from scratch just to be sure

[SeongGino]

@sjenkins7 I was using .61; I guess I just missed on those fixes from the work I'd been doing the past couple of weeks. Good to know!

[sjenkins7]

Was able to get this working on the latest canary (.86). Make sure you configure dinput correctly

# install dinput native DLL
winetricks dinput

to make sure - go into winecfg and set dinput to be native

[sjenkins7]

Also able to confirm that these additional bits would be enough to get this working on the Steam Deck.

In terms of packaging this up nicely ( Flatpak ), we are currently stuck waiting for a stable release of wine ( 7.0.1 is the current & doesn't work at all )

There are 2 avenues right now:

• There is talk about adding development versions to Flatpak ( which would serve what we need ) - https://github.com/flathub/org.winehq.Wine/issues/20
• We wait for 8.0.0 and see if that works ( they are on RC4 right now, so I can't imagine it will take long ).