Open PSebs opened 4 years ago
jobucaldas
commented
4 years ago I tried with 5.9-GE5-ST, it shows a window and crashes after a second.
With 5.0.9 the launcher was super unresponsive and after getting the start button to work, the game never opens.
redstarcoder
commented
4 years ago I encounter the same behaviour as @PSebs running 5.0-10 RC. Similar hardware.
cyrv6737
commented
4 years ago I tried with 5.9-GE5-ST, it shows a window and crashes after a second.
With 5.0.9 the launcher was super unresponsive and after getting the start button to work, the game never opens.
Same exact experience here. This game uses nProtect GameGuard, which is a rootkit anticheat. I feel like unless someone makes a patch specifically for this game (or nProtect GG in general) it's very unlikely it will be playable.
ahjolinna
commented
4 years ago well for some reason I got the SEGA intro playing before I got that same error (with the same '5.9-GE5-ST' proton version): steam-1056640.log
for some reason when I tried launching the game the first time I never got any error screen ....just a blank screen (neither SEGA intro either): steam-1056640.log
...oh and, at least for me the launcher worked really, no issues with it's responsiveness
my system spec:
inxi -bxx
System: Host: 91-158-92-139 Kernel: 5.3.18-lp152.36-default x86_64 bits: 64 compiler: gcc v: 7.5.0 Console: tty 1 dm: SDDM
Distro: openSUSE Leap 15.2
Machine: Type: Desktop Mobo: ASUSTeK model: Z170 PRO GAMING v: Rev X.0x serial: 150647662404153 UEFI: American Megatrends
v: 3805 date: 05/16/2018
CPU: Quad Core: Intel Core i5-6600K type: MCP arch: Skylake-S speed: 4400 MHz min/max: 800/4400 MHz
Graphics: Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: eVga.com. driver: nvidia v: 450.57 bus ID: 01:00.0
chip ID: 10de:13c2
Display: server: X.org 1.20.3 compositor: kwin_x11 driver: nvidia tty: 286x41
Message: Advanced graphics data unavailable in console for root.
Network: Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: 3.2.6-k port: f000 bus ID: 00:1f.6
chip ID: 8086:15b8
Drives: Local Storage: total: 35.95 TiB used: 191.53 GiB (0.5%)
Info: Processes: 285 Uptime: N/A Memory: 15.57 GiB used: 1.98 GiB (12.7%) Init: systemd v: 234 runlevel: 5
target: graphical.target Compilers: gcc: 7.5.0 alt: 7 Shell: bash v: 4.4.23 running in: tty 1 inxi: 3.1.00 
guglovich
commented
3 years ago Until there is a patch for GameGuard, this will all be a lottery. For example Lineage 2 in isolated cases works with GameGuard.
ahjolinna
commented
3 years ago some progress...I get now this far:
and then it stops on GameGuard...but it does ask to send crash report or something...well once the 2nd time it just crashes/stops and sends you to this link: https://www.gameguard.co.kr/gameguard/faq/eng/FAQ_114.htm
system info:
inxi -b
System: Host: localhost Kernel: 5.12.4-1-default x86_64 bits: 64 Desktop: KDE Plasma 5.21.5
Distro: openSUSE Tumbleweed 20210524
Machine: Type: Convertible System: HP product: HP ENVY x360 Convertible 15-ee0xxx v: Type1ProductConfigId
serial: <superuser required>
Mobo: HP model: 876F v: 13.40 serial: <superuser required> UEFI: Insyde v: F.15 date: 11/12/2020
Battery: ID-1: BAT1 charge: 49.6 Wh (100.0%) condition: 49.6/51.0 Wh (97.2%)
CPU: Info: 8-Core AMD Ryzen 7 4700U with Radeon Graphics [MCP] speed: 1486 MHz min/max: 1400/2000 MHz
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel
Display: x11 server: X.org 1.20.11 driver: loaded: amdgpu,ati unloaded: fbdev,modesetting,vesa
resolution: <missing: xdpyinfo>
OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.12.4-1-default LLVM 12.0.0) v: 4.6 Mesa 21.1.1
Network: Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter driver: rtw_8822ce
Drives: Local Storage: total: 593.96 GiB used: 196.73 GiB (33.1%)
Info: Processes: 298 Uptime: N/A Memory: 15.01 GiB used: 4.08 GiB (27.2%) Shell: Bash inxi: 3.3.03 
cr08
commented
3 years ago So with the announcement of the Steam Deck and mention of other anti-cheat platforms being worked with to add support in Proton, is it possible someone at Valve could reach out to nProtect/GameGuard to do the same? This is one game I'd like to have on the device, but short of loading Windows on it, this is likely a no-go unless there is some push to get GameGuard to actually support the platform or Proton.
As an additional note: GameGuard seems to be the only roadblock here. Sega has provided a 'Character Creator/Benchmark' tool which runs the same engine but does not have GameGuard added as it is 100% an offline only tool and it has been reported to work fine via Proton.
guglovich
commented
2 years ago It is. GameGuard used to be popular in Lineage 2 and is still in some versions, and everything works fine without it. There have been many tests by me.
SeongGino
commented
2 years ago Unfortunately (though not unexpectedly), issue still persists as of current Experimental and forks. Since this is one of the few games I keep a Windows install for, I'd really like to see this resolved.
nepnep1111
commented
2 years ago Currently the game is now booting, but has huge performance issues related to IO. Unless the game has terrain render distance set to the minimum it takes too long to load and times out. Even when in game the game has huge stuttering from IO unrelated to shader caching. Base PSO2 is playable for the most part, but NGS is nearly unplayable to the performance.
SeongGino
commented
2 years ago Indeed, I can confirm that the game now boots, on both GE and Experimental.
PSO2 classic works perfectly, as far as I can tell. Which is a good thing. But like the comment above, NGS seems to have issues. Bad IO seems like a very familiar problem NGS has, even on Windows - from my experience, a first boot will always take a really long time; but on the high capacity rotational drive I'm playing it on (not enough space on solid state to put it in), in Linux, I can't seem to connect - quits on Error 630... usually just as the player character spawns in. Might be a network connectivity error, however I have yet to confirm this on the Windows side.
5MIN EDIT: So I went back and checked. The same machine on the Windows partition can successfully connect and load into NGS spawn just fine. On Linux, I've noticed that it does get as far as loading the event call, and even receives a local convo from some players amidst the duration of loading, but most of this time is spent staring at a frozen display w/ sound while it's fetching data. With KSysGuard, I can tell that it's still connected and receiving/sending some KBs of data back and forth for most of this. But as soon as the screen unfreezes, the connection is immediately killed in Error 630 as it jumps into a disconnected Aelio.
Proof:
Could this be linked to the I/O problems? Perhaps. But I've also no other choice due to lack of space on solid state storage. Said drive is NTFS (the compatdata is symlinked back into a BTRFS user home dir - the same setup I use for all my other games and reports).
nepnep1111
commented
2 years ago F2FS stutters extremely hard, but is borderline "playable" compared to ext4 and xfs which I tried also. It seems like the game is unloading everything from memory the moment it is able to. The game seems to result in a ton of standby cache memory generated extremely quickly on Windows.
sethdmoore
commented
2 years ago I don't think I can agree that it's IO bound. I have the game installed on an NVME ext4 disk. Like everyone else, I have to set the game settings to minimum or else I get timed out. But I'm pretty sure this has to do with longer shader compilation times and not disk.
While the game was loading in, I didn't see read speeds exceeding 22MB/s. My NVME is capable of speeds many factors greater than that.
Contrived example:
dd if=/dev/urandom of=some_file bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.4026 s, 436 MB/sI also recorded the tracepoint block_rq_issue, which according to the kernel docs and this person's blog should indicate which process is causing heavy disk usage.
This screenshot is from graphics setting 1 - Lowest
sudo perf record -e block:block_rq_issue -ag
# run game, run around teleport places
^C
sudo perf reportAccording to this report, pso2.exe accounted for <6% of total disk activity.
Prometheus Node Exporter accounted for more disk usage than the game, and that's supposed to be a lightweight metric collecting daemon.
I repeated the same test with graphics setting 6 - Super and got similar results.
I'm fairly certain that the issue in this game is DXVK cache related. I can correlate each stutter with a change. While hardly scientific, it still appears to be a common problem with a lot of proton games.
EG: open terminal
while true; do
sleep 1
md5sum ~/.local/share/Steam/steamapps/shadercache/1056640/DXVK_state_cache/pso2.dxvk-cache
doneMove around, experience stutter, watch md5sum of cache change.
Sitting still or rotating the camera does not cause stutter.
To reinforce this theory I teleported to Camp Keeland, experienced one stutter (which may have been caused by the sudden sand storm). I then cleared the pso2.dxvk-cache file and redid the same test. The stutters were measurably longer.
kisak-valve
commented
2 years ago Phantasy Star Online 2: New Genesis framerate problems
Issue transferred from https://github.com/ValveSoftware/Proton/issues/5781. @CathyRina posted on 2022-04-22T20:12:43:
Game boots up fine however the framerate dies after selecting a character & loading the main map.
Boot up the game, select a server, select a character
cr08
commented
2 years ago Can confirm seeing these loading/stuttering issues on my 256GB Steam Deck loaded onto main storage, current stable SteamOS build. All default launch/proton options. Just install and launch.
Even lowering all graphics settings that I can on the PSO2 Classic side and trying to switch to an NGS block it still stutters bad when trying to load. Eventually gets in but throws the Error 630 'No response from PSO2 server'. Even the PSO2 classic lobby stutters good, similar to the early days of the PC Launch. But classic does load and run.
Honestly shocked to see the GameGuard concern just solved out of nowhere, though. So close to being functional.
nepnep1111
commented
2 years ago I still believe it is an IO issue given that if DXVK is used on Windows for this game the stutters clean up even on the AMD proprietary drivers under Windows which compile shaders much slower than ACO. Also the game has extremely small sizes per file compared to most games. The game contains over 500,000 files with some of them being as small as a few hundred bytes.
nepnep1111
commented
2 years ago I'm curious if using an Nvidia gpu or the AMDGPU-PRO drivers would have any effect as both vendors with dxvk on Windows do not have the issues that are occurring on Linux with the RADV drivers.
CathyRina
commented
2 years ago Base PSO2 seems to run at a perfect 60fps unless an asset needs to be loaded. This is worst in Lobby, minor annoyance in quest and basically not a issue in private quaters. This might suggest that the asset streaming isn't optimized because once the assets are loaded it seems to run just fine.
nepnep1111
commented
2 years ago and once an asset unloads the moment it loads again it still has the same stutter even when a shader cache is built up.
SeongGino
commented
2 years ago I'm curious if using an Nvidia gpu or the AMDGPU-PRO drivers would have any effect as both vendors with dxvk on Windows do not have the issues that are occurring on Linux with the RADV drivers.
FWIW I'm using Nvidia, so. . . I'm definitely noticing somewhat repetitive pauses with repeat assets in the same session in classic, but would still call playable regardless. Again; PSO2 was never a very well opt'd game in the first place, so it isn't much of a shocker that it has some problems that only now crop up.
GloriousEggroll
commented
2 years ago game doesnt load on the amdgpu-pro driver, don't think that makes a difference.
I played ngs intro with a new character up to the attack, then my game kept disconnected during the loading screen for after the attack occurred with error code 630. -- I checked reddit, found this https://www.reddit.com/r/PSO2NGS/comments/o385fs/ngs_630/, then based on point (2) set my graphics to lowest -- it allowed me to login again.
As a test, I then let the in-game cinematic play for after the attack, set settings back to ultra, logged out, then tried to log in and once again was greeted with error 630. So -- something funky is going on with loading the games assets over the network I assume.
DistantThunder
commented
2 years ago I confirm that now that it appears the Anti-Cheat lets us join, there are heavy stutters that appear to be caused by asset loading. Using DXVK HUD, I could confirm there's no shader compilation happening during the stutters/freeze.
Also, setting the Terrain Draw Distance to 1 and everything else to max has allowed me to avoid any disconnection issue before, but I do experience timeouts today.
Also, someone suggested that DXVK may still be a worthy culprit somehow but the game do runs with PROTON_USE_WINED3D=1and when it did, I still encountered the exact same loading issue that prevented me to get in-game. So while DXVK state cache shenanigans may be a symptom, I don't believe it's the crux of the matter.
This looks like a potential Wine issue with the client. Could be the AC as well, who knows...
Proton Log:
GloriousEggroll
commented
2 years ago Replying to https://github.com/ValveSoftware/Proton/issues/4122#issuecomment-1107814338
Setting terrain draw distance to 1 did indeed allow me to connect to ngs without getting the 630 error without needing to set everything to low.
nepnep1111
commented
2 years ago It maybe placebo, but I compiled a new kernel linux518-tkg-cfs with the multigen LRU v10 patch and I seemed to have a slightly smoother experience with PSO2NGS compared to the build of linux517-tkg-cfs without the LRU patch I was using before. The amount of time the stutter occurs seems to be a bit shorter most of the time. I'd assume 5.17 with the Multigen LRU v9 patch would fare the same. The kernel patch did not seem to effect loading into the game initially at least for what I noticed.
For what I have looked into and heard from people who are experienced from tinkering with the game on Windows apparantly the file names for the assets are extremely long as they are based off the MD5 of the path as well as the file name and extension. I'm thinking the long file names could be causing performance issues on most file systems. Would this be a possibility?
DistantThunder
commented
2 years ago For what I have looked into and heard from people who are experienced from tinkering with the game on Windows apparently the file names for the assets are extremely long as they are based off the MD5 of the path as well as the file name and extension. I'm thinking the long file names could be causing performance issues on most file systems. Would this be a possibility?
As far as filesystems go, I had installed the game on ZFS backed by SSD, with 16 GB ARC. ZFS ARC I believe has a comprehensive cache subsystem with "innovative" algorithms compared to "simple" LRU and I didn't get the impression I was having it better than anyone else.
During the stutters indeed, I notice what appears higher I/O on loading the "checksum-like named" assets. I believe there core of the issue is there, especially since the game doesn't looks like it's using more than 2 cores, possibly just 1 if we say the second one is for the rendering but I may be wrong.
In PSO2 basic, you can notice the same phenomenon, but since the base game is "instance areas"-based, it happens mostly when the game loads all assets for the area, and almost not at all afterwards while you're playing in the area.
In constrast, NGS appears to be more "open-wordly" and loads assets as gameworld encounters them (very apparent in PSO2 basic lobby as well where there are many assets that couldn't be predicted/pre-loaded) Somehow, between the way Wine translates the file calls or the way Linux handles such calls, or how the game expects the system to answer back, something is wrong...
clebercasali
commented
2 years ago I'm trying to play PSO2 classic. It stutters on loading assets, but is mostly playable. However, in the lobby, it stutters to the point it's almost unplayable. Sometimes the game freezes on a black screen right after I choose my character and select "Start Game [PSO2]", so I have to kill it and start over. The xorg mouse cursor shows up in the middle of the screen every time I go to a different location/scene, and sometimes when a menu pops up. I'm playing with a gamepad, so I have to reach for the mouse and move it, and then it goes away. Very annoying.
Fulgurance
commented
2 years ago Somebody have a workaround for me ? When I finished the tutorial, and the multiplayer mode was enabled, I was disconnected, and now, when I try to be connected to the server, I have always an error after a long time my game screen was freezing on the loading screen
Result : https://www.zupimages.net/up/22/21/hceh.png
Is there any workaround as well to avoid sometimes latency ?
I use Proton GE 7-14 and I'm on Gentoo Linux
intrnl
commented
2 years ago Try reducing your terrain draw distance to the lowest first, if that doesn't work then try reducing graphics settings completely using the presets.
What do you mean by latency, are you referring to the stutters? because the stutters are unavoidable currently.
Fulgurance
commented
2 years ago Reducing terrain draw distance solved my freezing issue. I don't know if it's stutters, but normally the game is very fluide, but sometimes, when the game load something (I guess), I have a small latency.
SeongGino
commented
2 years ago Reducing terrain draw distance solved my freezing issue. I don't know if it's stutters, but normally the game is very fluide, but sometimes, when the game load something (I guess), I have a small latency.
These be the problems we've been discussing in this thread earlier (regarding New Genesis, which is what's displayed in your screenie), which has yet to be addressed. NGS is essentially unplayable; PSO2 Classic is fine with only marginal loading hitches in the lobby, in comparison.
cr08
commented
2 years ago Just as an FYI as this was something I personally missed in all this: The terrain draw distance option is only available in the options from the main character/ship select menu. Once you are in-game, the options there do not have this.
As a Steam Deck user, the game still stutters a lot with asset loads with terrain draw distance and other settings lowered to minimum. This does permit NGS to load successfully however. It can be playable but I definitely wouldn't recommend any heavy/high level combat.
scramble45
commented
2 years ago Replying to https://github.com/ValveSoftware/Proton/issues/4122#issuecomment-1144801589
Not sure if I'm missing something but the terrain draw distance option should be at the bottom of the graphics menu when you pause. Not at my deck to look at the moment but that's how I turned it down to one, I thought on mine. Didn't do a whole lot.
Also random question for the group here: Are there any gains when running this in DXVK Async mode? Can you even make it into a ship without anticheat blowing up because of it?
cr08
commented
2 years ago Replying to https://github.com/ValveSoftware/Proton/issues/4122#issuecomment-1145390916
I had looked repeatedly for the terrain draw distance setting in-game on the classic side but have not been able to find it. If it's there and I'm overlooking it, I'd love to know where. I never looked at the settings on the NGS side as obviously I was never able to get in without that setting turned down first. 😛
As far as the Async thing, I added the DXVK_ASYNC=1 parameter to the launch options in Steam but it seemed to make little or no difference for me at least.
CathyRina
commented
2 years ago Replying to #4122 (comment)
I had looked repeatedly for the terrain draw distance setting in-game on the classic side but have not been able to find it.
PSO2 and NGS have separate graphics settings.
TauAkiou
commented
2 years ago Based on my observations, the stuttering always happens when anything 'new' is being loaded. This pretty much means it happens just about everywhere, because new things can be loaded at virtually any time thanks to the open world nature of the game. If you go into a place where new assets aren't being streamed constantly, such as a story mission, the stuttering will often stop during encounters such as bosses, when enemies are no longer being loaded in.
PROTON_USE_WINED3D=1 does not seem to stop the stuttering in any meaningful way, either. I am suspecting less that this problem lies in the graphics subsystem and is probably related to something in WINE & whatever really bizarre way SEGA handles this game's data.
clebercasali
commented
2 years ago Has anyone tried to install the game in a case insensitive filesystem? Just a wild guess here.
SeongGino
commented
2 years ago Has anyone tried to install the game in a case insensitive filesystem? Just a wild guess here.
Holy crap, this was the root cause the whole time.
I spent the better part of the day (it is 3am as I'm typing) just to rule out that this wasn't the case; uninstalling PSO2, formatting a part of one of my drives as strict case-insensitive ext4, redownloading the whole game to it...
And now the load times are fixed; are roughly equivalent to Windows, and works up to the highest draw distance setting. And performance isn't hitching on loading assets anymore. Now that it works, sans some of the caching on DXVK's side on the first go, the performance is about where it should be.
(This is regarding both first load, login cycling, normal area transitions, and quick travel warp transitions; at least for my hard disk, it's exactly what I'd expect this game to be at).
Which I'm guessing, if both this game under Wine, and the WIP BeamNG native port are the poster children of (seemingly) the exact same issue regarding case-sensitive file systems performance... something at the filesystem level regarding casing checks is mucking things up.
intrnl
commented
2 years ago Wine has a known issue with trying to prove whether a file exists or not in a case sensitive filesystem, it has to traverse through directories making note of the casing.
The reason it has to do all this is because Windows on NTFS is case insensitive. (Note that NTFS itself does support case sensitive, Windows opts not to for legacy compat reasons)
https://wiki.winehq.org/Case_Insensitive_Filenames
I'm rather surprised that this was it all along, but it does line up with Wineserver seemingly having a lot of overhead and resulting in drastically lower read throughput, especially as PSO2's unique file structure means that it has to read a lot of individual files with it being mostly 3-4 KiB in size.
It might be good if there's a way of telling Wine to not do this at all? though I've never really checked how PSO2 tries to load files off of disk (if it passes a path that is entirely uppercase or lowercase for example, not exact)
intrnl
commented
2 years ago After reformatting my F2FS partition with casefold, and recreating the directory structure with casefold as I am restoring from rsync, I can confirm that: Yes, case folding does help immensely. :tada:
Initial loading time from character selection to Kvaris Camp now takes 13 seconds instead of 47 seconds on a 1 TB Samsung 980 NVMe drive.
cr08
commented
2 years ago Can confirm this also solves it on the Steam Deck and is actually very easy there since Valve already configures the Micro SD partitions with the necessary casefold feature (not sure about internal storage).
Basically just need to drop into desktop mode and run chattr -R +F on the PSO2 directory.
Doing this on my 256GB deck with PSO2 installed on Micro SD this change is a night and day difference. Zero stutters in the usual places where I'd get them like crazy. No other changes were made.
SeongGino
commented
2 years ago Had around a four hour session this morning, and can confirm that perf is perfectly smooth post-casefolding, no issues with either loading or graphics/performance. Anecdotally, FPS might be slightly reduced compared to an intended setup, but my 1060 is running at 4K with the game's resolution scaler set to "low" - rather than a native 1080p I was running at before on Windows (and I'm not sure if PSO2's scaler stops at 50% or if it's higher than that).
Really, the only problem is that this is the only example I can think of where casefolding improves performance--let alone being a necessity like this one. This isn't a common knowledge kind of fix like DXVK-async is, yet it's something that a user would have to be aware about before even setting up their drives - many distros (and myself included) default to btrfs, which doesn't even have a case-insensitivity flag option (and this is the first time I'm hearing F2FS has it :sweat_drops:). And even on the Deck, as @cr08 noted, though the formatting is already set, toggling the flag still requires some user intervention in the super scary hacker mode terminal.
/rant I'm happy this works and I can play my addiction again on Linux... not happy about reformatting my games drive (it's pretty much only for Windows games anyways, and something like Vortex Mod Manager has the occasion casing snafu, so I may as well-).
TauAkiou
commented
2 years ago After some testing on the Steam Deck, it looks like it's rock solid with acceptable framerates and little to no stuttering. The game works more or less perfectly in casefold mode.
There is a minor hang when the On Screen Keyboard is opened, but since that doesn't really happen in normal gameplay, it is more of an annoyance when trying to chat with people then a game-breaker.
Kind of funny that the extremely poor way SEGA designed their game's file structures has put a long-standing WINE issue into the spotlight. Here's hoping that the WINE maintainers find a good solution, since the way they do it now is extremely inefficient and exasperates problems like this one.
intrnl
commented
2 years ago The hang also occurs when opening the Steam Overlay on PC, I suspect it might be related?
snitzelhammer
commented
2 years ago Can confirm this also solves it on the Steam Deck and is actually very easy there since Valve already configures the Micro SD partitions with the necessary casefold feature (not sure about internal storage).
Basically just need to drop into desktop mode and run
chattr -R +Fon the PSO2 directory.Doing this on my 256GB deck with PSO2 installed on Micro SD this change is a night and day difference. Zero stutters in the usual places where I'd get them like crazy. No other changes were made.
Getting a „operation not supported while setting flags on PHANTASYSTARONLINE2…“ error myself. I guess it’s not as easy as described?
intrnl
commented
2 years ago Getting a „operation not supported while setting flags on PHANTASYSTARONLINE2…“ error myself. I guess it’s not as easy as described?
You might want to try the approach that I did which involves recreating the folder structure, it might be because +F should only be toggled on empty directories.
# Rename the current `pso2_bin` folder
mv pso2_bin/ tmp/
# Make a new folder, and mark it as case insensitive
mkdir pso2_bin/
chattr +F pso2_bin/
# New folders created inside `pso2_bin` will inherit F attr
# Next, we'll recreate the folder structure using find command
cd tmp/
find . -type d -exec mkdir -p ../pso2_bin/{} \;
# Now you just need to move all the files back into `pso2_bin` directory
# In this case I just did a drag and drop from file manager
# You might want to do this for other folders
# like the Wine prefix folder if that's already been madeI did the same thing for the prefix folder as well because I wasn't so sure.
cr08
commented
2 years ago Replying to https://github.com/ValveSoftware/Proton/issues/4122#issuecomment-1166409494
Yep. Apologies. I forgot about that step and had to do it myself as well. I took the longer route and simply deleted the contents from the PHANTASYSTARTONLINE2 directory, ran chattr, then had Steam validate and SLOWLY redownload all the files. Could have probably saved myself the headache with the above steps. lol
CathyRina
commented
2 years ago Replying to https://github.com/ValveSoftware/Proton/issues/4122#issuecomment-1166409494
Still doesn't seem to work, i suppose this must be done on a SD card directory and not internal storage?
intrnl
commented
2 years ago Still doesn't seem to work, i suppose this must be done on a SD card directory and not internal storage?
This is with Steam Deck, right?
I don't know if Steam Deck's internal storage is formatted with casefold, no, but what I do know is that the SD card is if you chose to format it via the Deck's interface (someone has to correct me on the internal storage thing because I don't own a Deck unfortunately, but if we go by this Reddit thread, yes it does?)
You can confirm if the F attr is present on the directory by using lsattr
[intrnl@azalea PHANTASYSTARONLINE2_NA_STEAM]$ lsattr
-----------I-----FN--- ./pso2_bin
[intrnl@azalea PHANTASYSTARONLINE2_NA_STEAM]$ lsattr ./pso2_bin/
# Command output truncated for brevity
-----------I-----FN--- ./pso2_bin/data
-----------I-----FN--- ./pso2_bin/GameGuardInfo for making a casefolding enabled sd card (or USB thumb drive!):
Make sure your kernel supports ext4 casefolding:
$ cat /sys/fs/ext4/features/casefold
supportedInsert your sdcard. Use lsblk to find it. If it's mounted, unmount the location:
$ lsblk
....
sde 8:64 1 953.6G 0 disk /mnt/Portable
....
sudo umount /mnt/Portable
Create a new ext4 partition with casefolding enabled using the entire device:
sudo mkfs -t ext4 -O casefold /dev/sde
Verify 'casefold' shows up in options:
sudo dumpe2fs -h /dev/sde | grep 'Filesystem features'
Make a location to mount it:
sudo mkdir -p /mnt/Portable
Mount the device:
sudo mount /dev/sde /mnt/Portable
Make the location owned by your user:
sudo chown username:username /mnt/Portable
Make the location fully writable for good measure:
sudo chmod -R 777 /mnt/Portable
Open Steam. Navigate to Steam>Settings>Downloads>Steam Library Folders
Add the new location as a new steam library
Navigate to SteamLibrary/ inside your new library and enable case folding on the 'steamapps' folder:
cd /mnt/Portable/SteamLibrary/
chattr +F steamapps
Make sure it has the 'F' flag:
lsattr
Go back to Steam and download the game to that library.
This will allow everything -- the game files, the wine prefix, the shader cache, the temp directory, etc within that library to be case insensitive -- which shouldn't leave the game with any reason to complain.
FWIW I use a Samsung Duo Plus 128GB USB stick -- it has a stupid fast read/write speed and is only around $25 on amazon. (Note the game is roughly 100GB in size)
udf
commented
2 years ago I used strace to see what the file accesses look like:
sudo strace -f -t -e trace=file -p $(pgrep pso2.exe)
The game is trying to load 4faefcffad1ca8a5f1e8fef157e2b542 which doesn't exist anywhere in the game data (thanks SEGA). That causes wine to walk the whole tree and list all the files there (newfstatat). There's also a check for a .ciopfs file there, which I assume is a marker for the case insensitive on purpose filesystem. After that the game checks for the same file, but this time in win32_na (the first one checked in win32).
Pretty much the entire trace looks like this (with different files each time), sometimes it succeeds at finding the archive in the first data folder, other times it has to scan everything because the file doesn't exist anywhere.
However, since the game is accessing the files with the correct case, it should be sufficient to tell Wine to not scan directories if possible, or create a patch that adds a flag to skip this behavior.
Compatibility Report
System Information
I confirm:
Symptoms
The game would not launch when you click the Start Game button in the game's own launcher. pso2.exe runs in the background as a zombie process.
Reproduction
Log
Google Drive link to steam-1056640.log, It kinda blew up to 53 MB in just a few seconds when opening up the game.