AWB Emulator can't read file on Proton, makes a few mods incompatible.

[acanthii]

Under all tested proton versions, the AWB Emulator can't seem to read/edit ACB files.
This makes a few mods (and potentially future mods) incompatible with Linux.

Tested Proton Versions
GE-Proton7-49
GE-Proton7-42
Proton Experimental
Proton 7.0-6

Affected Mods

Randomized Battle Music - Music doesn't play when in battle

P5R Custom Bonus Tweaks - Music doesn't play

[Sewer56]

I'm aware of a small oversight in this project; I'll respond in here when I fix it. Hopefully this week.

[Sewer56]

Hmm, alright; I thought there was an oversight, but seems I did account for that little something I was thinking of.

Here's something to do:

Can you do the following?

• Configure File Emulation Framework: Base Mod and AWB Emulator for File Emulation Framework.
  • Set their log level to debug.
• Upload your log files.
  • They are in AppData\Roaming\Reloaded-Mod-Loader-II\Logs. Normally you can get there from launcher but in Wine/Proton case you might have to look inside your game's WINEPREFIX.
• Upload your mod list [feel free to just upload the .json file output by Save Mod Set].

I'll probably need to make some custom builds after that; but it should provide me the initial needed info.
I take Linux compatibility pretty seriously; so if it comes down to it, am happy to even set up a fresh Linux environment just to debug through this.

[acanthii]

I've made two logs, one with both of the requested mods log levels set to debug, the other one being just your regular Information level log. Weirdly enough, the text that says "Can not open file." is not present in the information log. I hope this helps nonetheless! (And sorry for the wait, navigating on Deck is a bit difficult haha)

modlist.json is formatted as a txt since github won't let me send jsons here, apologies.

infolog.txt
debuglog.txt
modlist.txt

What the console looks like (Contains lines that the info log doesn't, for some reason???)
EDIT: this screenshot is the Information level log, not debug

[Sewer56]

Alright; I'll have a read through later today; and walk through the code to see potential culprits.
I'll let you know if I'll need any more info.

[MrCamel999]

Not sure if this helps at all, but I was trying to get the Battle Music Randomizer to work myself through Proton, and it seems the 1.0 0 version of the mod works. It may use something different that is unrelated and that's why it works, but maybe that helps somewhat

[Sewer56]

1.0.0 of which specific mod?
Might be helpful with narrowing things down.

Am finishing Virtual Filesystem work [I wanna get it done while the complicated stuff's in my head]; and tomorrow I'll probably be getting a live Linux setup going for debugging.

[Sewer56]

Note to self:

Also Hook NtQueryDirectoryFile(Ex) not just NtQueryInformationFile
Also Hook NtQueryDirectoryFile(Ex) not just NtQueryInformationFile
Also Hook NtQueryDirectoryFile(Ex) not just NtQueryInformationFile
Also Hook NtQueryDirectoryFile(Ex) not just NtQueryInformationFile
Also Hook NtQueryDirectoryFile(Ex) not just NtQueryInformationFile
Also Hook NtQueryDirectoryFile(Ex) not just NtQueryInformationFile
Also Hook NtQueryDirectoryFile(Ex) not just NtQueryInformationFile

Maybe it's related, maybe it's not. Repetition for emphasis, I don't want to forget.

[acanthii]

1.0.0 of which specific mod? Might be helpful with narrowing things down.

Am finishing Virtual Filesystem work [I wanna get it done while the complicated stuff's in my head]; and tomorrow I'll probably be getting a live Linux setup going for debugging.

I believe the mod in question is https://gamebanana.com/mods/412327, Battle Music Randomizer
1.x.x used a different method than what 2.x.x uses for randomizing the music. Looking at the files it's hard to discern what the actual difference is, but the 2.x.x builds include a BGM.acb as well as BGM_01 awb and acb. The 1.x.x builds don't contain the BGM.acb file, but do contain the BGM_01 files. 2.x.x also allows the user to modify which BGMs are played within an ingame menu, meaning you don't have to restart the game.

[Sewer56]

Alright; that actually provides a bit of useful context. The intended behaviour is that if a custom ACB already exists; it should be patched instead of the original one in the CPK. I wonder if some logic around that isn't translating nicely.

I'll note that when I get around testing.

[Sewer56]

Sorry for the delay; I've been going crazy trying to finish up Virtual Filesystem stuff; took longer than expected. I'll need to test that on Wine too; so I'm going to be setting up a proper *nix setup for testing. I didn't forget.

[acanthii]

Don't feel rushed! Glad to hear you're passionate about Linux support, though, means a lot to the Linux and Steam Deck community lol
Thank you again

[Sewer56]

Okay, an update on this; and this is unfortunate.

I spent the last 2.5 months or so working on a Virtual FileSystem:
https://reloaded-project.github.io/reloaded.universal.redirector/index.html ; and I wanted to get this released today.

Then fix the issue here; as I would be then using said project to improve load times in CriFsHook, which uses FileEmulationFramework, so I'd also be looking at this at the same time.

Unfortunately, due to low level GC related shenanigans in C#, the upgrade to the Redirector (now full FileSystem) breaks in Wine...

Which means I can't release it; and I can't work on this right now, as I'll need to port the VFS to native code (I'll be going with Rust). This is a bummer... I already have a huge backlog; and now it's going to go up by another month :(

[acanthii]

Dang :(
gotta love wine issues :(
if I got this right, the entire VFS you've been working on just doesn't work on wine due to C#, so you have to spend a lot of time porting it to rust now? That sucks for sure :(
Thanks for the update, though.

[Sewer56]

Technically it's not Wine's fault; it's just that with the way things are set up under the hood in Wine; it replicated on Wine first.

Using .NET to hook Windows OS functions that the native runtime can call (under some circumstances) is not safe; but I've been doing that regardless (in this case to save time), and now I'm paying the cost. This code was always going to possibly break after a major runtime upgrade; I did not expect it to break under Wine however.

FileEmulationFramework itself is also prone to this!! I will be rewriting both so I won't have to deal with this again in the future. It will take a long time however...