PAK Emulator fails to read on Linux

[acanthii]

Tested Proton Versions
Proton Experimental
Proton GE 8-13 (latest)

Related Mod Versions
Persona Essentials: 2.4.1
File Emulation Framework: Base Mod: 2.2.0
PAK Emulator for File Emulation Framework: 1.1.0

Misc. Versions
R2: 1.23.7
.NET: 7.0.2

Context
Trying to load Visible Rankup Ready under proton fails (it works on my windows machine)
From the error below I believe the PAK Emulator is what's failing under proton, not reading something completely or something like that. Let me know if more detail/testing is needed!

Gotta love Proton and .NET...

[Sewer56]

CC @AnimatedSwine37

Normally I'd handle this kind of stuff myself but I don't want to maintain R2's emulators, rather fast track R3's Rust ports instead.

(Also aaaaaaa I don't know file format)

[acanthii]

That's fair :)
Will R3 rely on .NET as well or are you making the switch to rust?
(asking bc .net was the main issue of the AWB emulator, no? ;P)

EDIT: sorry for my blindness, somehow R3 and Rust blended together and i just skipped over the word rust
Are the repos for R3 public or private? I'd love to follow development in the meantime

[Sewer56]

There's an issue which makes .NET unsafe for writing emulators, as hooking OS APIs (that could be used by runtime itself) unsafe. [Since .NET 5]

For R3, I plan to make the loader and core/low level mods in Rust. The launcher will be in .NET, built cross platform with Avalonia and NativeAOT.

[Sewer56]

There's a spec I started writing back in April for R3

https://reloaded-project.github.io/Reloaded-III/

[I will resume working on it when I finish with library stuff]

Since then I've upgraded some of the low level Reloaded libraries (e.g. Memory) to better handle cross platform scenarios (e.g. Reading other processes' memory), and ensure API stability. Not strictly needed but I wanted to clean up some older libraries.

Currently on the Reloaded side I am porting Reloaded.Hooks (at https://github.com/Reloaded-Project/Reloaded.Hooks-rs ) to Rust, while making it platform and architecture agnostic. To achieve that, I already ported Reloaded.Memory.Buffers to Rust, and made it cross platform, also supporting native OSX and Linux (+ Automated Tests against Wine).

Going forward, I plan to have automated tests running against Wine for all of the Rust code I write, including emulators in the future; and any inconsistencies found will be reported straight to Wine devs.

My end goal is to support virtually any platform, including modding native Linux games and even Switch games.

---

This past week though, I took a detour to work on the current CRI Hook, https://github.com/Sewer56/CriFs.V2.Hook.ReloadedII I'm hoping to have all stutters users are experiencing eliminated by the end of this week. It currently works but has case sensitivity issues in some games.

I figured a way I could make it work without full Virtual FileSystem, so I dropped whatever I was doing with hooks temporarily to work on this, as the issue has been prevalent for way too long.

[Sewer56]

I'm daily driving Arch on my machine in any case (I only ever use Windows for debugging native Windows stuff now), so I'll be personally making sure stuff runs smoothly in the nix world in the future.

[acanthii]

I'm really glad to hear platform agnosticism is a focus in R3 (and it's emulators) :)
I've wanted to switch to Linux for a while now since Windows is slowly going downhill and once I transition I'd love to have everything I already have still work haha (once I can spare enough cash for an AMD card I'll probably switch over; nvidia has too many issues I'm facing currently, especially on kde wayland)

Anyways, a lot of stuff to be excited about here!

[Sewer56]

especially on kde wayland

As someone who also had to go through hell to get Nvidia Prioprietary to work on Wayland, you have my condolences.

I couldn't get sway to reliably work at all, even if I got it to work, desktop portals were broken and I couldn't record screen or conference for work. I ended up trying Hyprland and loving it; but it's still not perfect. e.g. Resizing has flickers on x11 (xwayland) windows.

After many tests, it turns out that the error 'The provided stream & offset pairs don't form a complete file.' occurs when Reloaded II or P3P are on the microSD. It worked correctly when moving both to internal storage, allowing PAKs emulation to function properly

[Sewer56]

Oh wow, that I kinda didn't expect. I wonder what's different, they're both regular local internal storage as far as things are concerned.