_Updated: 04-14-20_, added WINE and GE-Proton build on 04-19-20:
If you are looking to run FFXIV via Proton, there's a few instructions for current installs:
1) Default Proton _will not work_. You will need to grab a release from GloriousEggroll's repo and follow his installation instructions.
2) You will need to run the following command:
WINEPREFIX=$HOME/.steam/root/steamapps/compatdata/39210/pfx winetricks hidewineexports=enable assuming you use the default location for your library of a regular Steam installation. If you do not, adapt the path appropriately.

Other launcher / non-Steam versions instructions:

• If you want to run FFXIV outside of Steam, please use Lutris' Standalone - DXVK version installer.
• If you want to use Lutris to run FFXIV outside of Steam and your game is purchased through Steam, add the -issteam argument to your Lutris configuration for the game.
• If you want to use Steam to run a non-Steam version of FFXIV, set FFXIV's launch options to: echo "%command%" | sed 's/-issteam\(freetrial\|\)//' | sh. (Thanks to jbal91 for reminding me that sed is magic!)

Issues of note:
1) The new launcher is disabled by Steam / GE-Proton by default -- at some point, this will likely stop working. It has an open wine ticket here.
2) If you're using a post-processing injector (ReShade, GShade, etc), the game is hampered by a several-second stutter whenever the mouse is moved. It has an open wine ticket here. You can get a working WINE here (based on WINE 5.4) and a working Proton (built from GloriousEggroll's repo on 04-18-20) here.

_Previous updates_:
_Updated: 07-31-19_:
Hello, Warriors of Darkness / Light! If you are attempting to play FFXIV via Proton, it has been greatly simplified!

Once XIV is installed via Steam, simply open the file at ~/.steam/steam/steamapps/compatdata/39210/pfx/drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/FFXIV.cfg and change CutsceneMovieOpening 0 to 1. (If you are running the demo, always swap 39210 with 312060.)

If you do not see the option to install the game via Steam after purchase, you need to, inside of your Steam client, open Steam -> Settings -> Steam Play, then check both 'Enable Steam Play for supported titles' and 'Enable Steam Play for all other titles', restart Steam when prompted, and you should be set!

Welcome to the community!

Original post:
I'm not sure if this is the same issue directly. I've gotten XIV working via Proton, but I had to follow well-known wine answers to get it playable. Namely, I have to edit two files in the steamapps/compatdata/39210/pfx/drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/ directory.

In FFXIV_BOOT.cfg, I had to edit BrowserType to 2, and in FFXIV.cfg I have to edit CutsceneMovieOpening to 1.

The first change allows me to get to the launcher at this point -- if it's left to its default value I get 'A system error has occured: 404. HTTPS System Error'. Afraid I did the install mid-week, so I'm not sure if this is how I got past nstgc's issue during installation.
Obviously the latter change means I don't get to see the opening cutscene the first time I play the game, but if I leave it at default value, the game launches but hangs up after selecting a Data Center.

As these edit game configuration files I'm not sure if this is something Valve wants to consider for Proton, but at the least it's information.

FFXIV Freezes when Real Time Reflections are enabled

Issue transferred from https://github.com/ValveSoftware/Proton/issues/627.
@ulzeraj posted on 2018-08-26T05:58:03:

Final Fantasy 14 (ID: 39210) works on DX11 mode after some manual workarounds which are editing the INI files to set browser type to 2, disable the opening cutscene and use winetricks xact into its prefix.

However… graphics stop working immediately after I enable “Real Time Reflections”. Enabling any level of this particular option freezes the game and X11. I can still log into through SSH and there are these messages:

[ 384.698959] [drm:amdgpu_job_timedout [amdgpu]] ERROR ring gfx timeout, last signaled seq=202749, last emitted seq=202751
[ 384.698964] [drm] GPU recovery disabled.

GPU is Saphire R9 390. System is OpenSUSE Tubleweed with kernel 4.18.0-1, using amdgpu and Mesa 18.1.6 LLVM6. Same hardware and game works fine on Windows 10 with Real Time Reflections on.

Thanks for the hard work.

@doitsujin commented on 2018-08-26T10:47:10

Please test with LLVM 7 and Mesa 18.2, as suggested in PREREQS.md.

@HereInPlainSight commented on 2018-08-26T15:37:13

System info: Gentoo x86_64 | 4.14.65-gentoo | i5-6500 | NVIDIA GeForce GTX 1070 | NVIDIA 396.51

I had previously done the config file edits, just emerged llvm7 and added the xact winetricks to the prefix, switched to DX11 and can confirm I'm able to run with Real Time Reflections at any setting I want.

@doitsujin commented on 2018-08-26T16:12:39

@HereInPlainSight The LLVM version is only relevant for AMD drivers because they use LLVM to compile shaders. Mesa needs to be built against LLVM 7 in order to work correctly.

@HereInPlainSight commented on 2018-08-26T16:50:18

@doitsujin I wasn't 100% on that because the DirectX11 info seems to indicate that LLVM7 is recommended to avoid GPU hangs, which is mentioned after the drivers section. My gaming on Linux before the new SteamPlay info was fairly casual, so I opted to go safe over sorry.

Using the recommended libs fixed the issue for me but now I have the missing fonts issue described by @nstgc. I should mention that the fonts issue didn’t occurred in OpenSUSE Tumbleweed.

I’ve switched to Ubuntu Bionic in order to fill the requierements described on PREREQS.md. Installing from those repos gave me Mesa 18.3 compiled against LLVM 8.0. I also installed LLVM and CLANG 8 since the document does not make it clear if libllvm8 is enough. I’m still using amdgpu from kernel 4.18.5-041805 which I installed from UKKUU.

By the way the wine and winetricks from Ubuntu default repos are too old and applying xact through them will cause the game to fail on launch.

somehow I manage to add those fonts using "winetricks allfonts"
But I seem to be unable to actually input Japanese characters using iBus anthy on Ubuntu 18.04
Can anyone else confirm? (Or is able to write Japanese in FFXIV chat really)

Neither my steam controller or xbox 360 controller works.
They are they both show up in the gamepads list in the setting menu so they are detected, but button presses don't work.

Here the controllers do not work through steam as they should but I've managed to use them through the SDL native system.

For DS4 this works by adding the following variable to your profile (.bashrc or /etc/environment) and disabling the steam controller system.

export SDL_GAMECONTROLLERCONFIG='030000004c050000cc09000011810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,platform:Linux,050000004c050000cc09000000810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2,platform:Linux,'

Thing is... I should be able to disable the controller just for that game but Steam somewhat renames the device node paths so to make it work I need to disable everything. The device renaming thing do not happen in OpenSuSE.

The cinematics do not play, could be related to issue #1464.

I found the solution to my issue here: https://www.reddit.com/r/archlinux/comments/9bl3l7/steam_controller_not_working_with_protonsteam/

The issue was that two inputs were being created for one controller.
running sudo rmmod hid_steam and restarting steam fixed the issue.

Failure to load embedded web page in game launcher (appid: 39210)

Issue transferred from https://github.com/ValveSoftware/Proton/issues/2183.
@TenaarFeiri posted on 2019-01-02T23:58:28:

Compatibility Report

• Name of the game with compatibility issues: Final Fantaxy XIV Online
• Steam AppID of the game: 39210

System Information

• GPU: GTX 980M
• Driver/LLVM version: nVidia 390.87
• Kernel version: 4.18.0-13
• Link to full system information report as Gist: https://gist.github.com/TenaarFeiri/2733a8f25f8818a5c3e85777eed9be22
• Proton version: 3.7-8

I confirm:

• [ ] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

https://gist.github.com/TenaarFeiri/9e560a89346b17cc2de0ac9b508259e8

Symptoms

The issue is Proton doesn't seem able to help ffxivlauncher.exe use the correct web browser to embed its login page with. I've had reports that the game itself is functional once you get past the launcher, but I'm unable to test it as this is a crucial step for downloading the game.

The launcher itself reports a HTTPS 404 error, as it can't find a browser to use for the launcher's landing page.

Reproduction

• Download and install Final Fantasy XIV Online.
• Launch the game. ffxivboot.exe will launch, and will give you no useful information as the font is broken.
• ffxivboot.exe will eventually finish its download, and then it will open ffxivlauncher.exe
• Inform the launcher that you already have an account with the game.
• Proceed through its prompts until it's done guiding you through it.
• Observe the launcher attempt to open a webpage necessary to initiate the running of the game and fail.
• Close and restart the game as many times as desired.

EDIT: Got the game to run :D
Currently I'm having an issue that there's no audio in DX11, but there is audio in DX9. I much prefer to play in DX11 as the performance is better. Any ideas?
I'm using Proton 3.16-6 (Beta) now.

I just found this and applied some of the tweaks mentioned above and I got the launcher working =)

It remains to see if I can get the game itself to run when it's finished downloading but we'll see!

I notice prefixes being mentioned above. I'm not terribly tech savvy; how would I go about applying them if I need them?

Any idea how to get sound going in DirectX 11? DX9 has sound but it's virtually unplayable.

@TenaarFeiri With Wine I had to install xact and then override xaudio2_7

Do you know how to do this with Proton Wine? I'm not entirely savvy with this stuff yet.

@TenaarFeiri With Wine I had to install xact and then override xaudio2_7

I figured it out! Thank you so much for pointing me in the right direction.
I installed a proper version of Wine as instructed at winehq.org, and then did: WINEPREFIX=game_folder_in_steam winecfg and set xaudio2_0 and xaudio2_7 in the override.
That did the trick! I now have audio and great performance!

EDIT: Turns out the issue was my desktop environment. I uninstalled Ubuntu 18.10 and replaced it with Kubuntu 18.10 and now Windowed Mode is working great!

Okay!
New problem!
So the game works perfectly in Windowed Fullscreen with no issues whatsoever (that I can see). But I actually prefer to play the game in Windowed mode, and that's where problems emerge: I have skills bound to num pad keys, that activate when I press my mouse buttons. In Windowed Fullscreen they work great with no errors, but when I use them in Windowed more, there is a noticeable FPS plummet/freeze that makes it hard to play like that.

I recorded a video: https://youtu.be/iqLxMQLCLe4 (the low framerate of the game is a result of the recording, but thankfully it also makes it super obvious when I hit the mouse buttons so you can observe).

Any ideas on how I could fix this?

The latest FAudio revision fixes audio for the DX11 version:

https://github.com/FNA-XNA/FAudio/commit/83f8734ef15f76fcbacd7279f890aefde9d62021

EDIT: As long as you turn reverb off... add return buffer; after this line if you really try this out:

https://github.com/FNA-XNA/FAudio/blob/master/src/FAudio_internal.c#L628

Latest FAudio revision fixes effects too! The game sounds fine on my own setup now without modifications (minus some attenuation, but that shouldn't be ear-wrenching).

Together with all of the above, and with xact, xaudio2_0-9, I think official support shouldn't be that far away?
It works perfectly with those fixes in Proton 3.16-6 Beta, and really the biggest hurdle is just changing the BrowserType to 2, and CutsceneMovieOpening to 1 as described by @HereInPlainSight.
But that's something I'd wager the Steam client should be able to do on its own when the game is installed, surely?

Proton 3.16-7 includes the latest FAudio changes, so audio should work properly with the DX11 version.

With the 3.16-7 beta, I recreated the compatdata for this game to completely undo any manual modifications. I did still have to change BrowserType to 2, and CutsceneMovieOpening to 1. Audio now works without xaudio dll overrides but, the audio gets progressively more delayed with playtime. After ~20-30 minutes of playtime all audio gets delayed by 1-2 seconds.

Is anyone else experiencing something similar?

Took a quick look and I believe you've stumbled upon a design issue with SDL_AudioStreams. I've swapped out the resampler, so if I did everything right the lag should be gone (and hopefully the sound quality is still okay):

https://github.com/FNA-XNA/FAudio/commit/fe31f1b6b021f4896016dc2eacc85026005abdf9

I'm still having issues with an HTTPS error in the launcher despite BrowserType having been set to 2. Tested under GNOME with Wayland, GNOME on Xorg, and Plasma to no avail.

I'm still having issues with an HTTPS error in the launcher despite BrowserType having been set to 2. Tested under GNOME with Wayland, GNOME on Xorg, and Plasma to no avail.

Try deleting the "web" folder in ~/.local/share/Steam/steamapps/compatdata/39210/pfx/drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/

I have 2 Fedora 29 machines where on one I have to constantly delete that folder for the launcher to load while on the other does not require it. Although, I'm not sure what is different between the two machines

Sometimes you'll also get the problem when you just can't connect to their
landing page.

I'm guessing you already have, but on the off chance you haven't, check to
see that your BrowserType is set to 2 in boot.cfg (I believe?).

Den lør. 2. mar. 2019, 03:37 skrev Equivocal90 notifications@github.com:

I'm still having issues with an HTTPS error in the launcher despite
BrowserType having been set to 2. Tested under GNOME with Wayland, GNOME on
Xorg, and Plasma to no avail.

Try deleting the "web" folder in ~/.local/share/Steam/steamapps/compatdata/39210/pfx/drive_c/users/steamuser/My
Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/

I have 2 Fedora 29 machines where on one I have to constantly delete that
folder for the launcher to load while on the other does not require it.
Although, I'm not sure what is different between the two machines

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580#issuecomment-468874158,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APgQqIDNj5NfLmXrWkWA0EMScT75Ts9Hks5vSePkgaJpZM4WMfqx
.

Sometimes you'll also get the problem when you just can't connect to their landing page. I'm guessing you already have, but on the off chance you haven't, check to see that your BrowserType is set to 2 in boot.cfg (I believe?). Den lør. 2. mar. 2019, 03:37 skrev Equivocal90 notifications@github.com:
…
I'm still having issues with an HTTPS error in the launcher despite BrowserType having been set to 2. Tested under GNOME with Wayland, GNOME on Xorg, and Plasma to no avail. Try deleting the "web" folder in ~/.local/share/Steam/steamapps/compatdata/39210/pfx/drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/ I have 2 Fedora 29 machines where on one I have to constantly delete that folder for the launcher to load while on the other does not require it. Although, I'm not sure what is different between the two machines — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#580 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/APgQqIDNj5NfLmXrWkWA0EMScT75Ts9Hks5vSePkgaJpZM4WMfqx .

On my machine that has the issue BrowserType is set to 2 and it gives a different https error. It either succeeds or gives me a -22 or -21 error until I delete the folder I specified earlier.

Question for people playing this game: Is just the initial cutscene that needs to be skipped, or are ingame cutscenes also not working? I managed to get the game to work, but since this is the first time playing the game, I don't know where I am supposed to see cutscenes ingame.

@Equivocal90

I'm not sure how to deal with that. =( I have been lucky enough to avoid having that problem! Which version of Proton are you using? I'm using the latest one (Beta). I thought maybe desktop environment might be an issue but you've tested it on a few. But I'm using Kubuntu/Debian, so it could be Fedora has a different problem I'm not able to guess.

@Mushoz
In-game cutscenes will work fine, and you can even view the cinematics in FFXIV from the opening menu when the client has been opened.
Interestingly, there seems to be no obvious reason why the client wouldn't start with initial cutscenes enabled, as it handles actually playing them just fine once it's running?
Either way, all in-game cutscenes should work! I've yet to encounter any issues.

I'm slightly dreading Shadowbringers, though! No idea how that's going to mess with the current performance on Proton.

@flibitijibibo and @Equivocal90 :
I can confirm that latest faudio fixes the progressive sound delay.

I seem to have run into a different problem though...

After a while playing (sometimes its < 30 minutes, sometimes it's more than 2 hours), I begin getting huge variance in frame time that cause the game to stutter.
I changed "DXVK_HUD": "full" in user_settings.py for proton to observe exactly what's going on... and after about 50 minutes of gameplay, it happened again.

What I found was that the following cause huge spikes in time taken to render frames:

• mouse moved
• mouse clicked
• key typed (and yes, it is specific to the typing of the character, not just pressing the button)

How I know it's key typed:

1. Press and hold a key (ie D to turn right): stuttering starts, then the stuttering stops for a moment, then resumes a moment later.
2. If you now tap another key (like W to move forward), the stuttering will stop when you release the 2nd key (W in this case) even though you're still holding the first key.

This is the same behavior my system has when typing in a textbox.
Once the game gets like this, it doesn't stop until the game is restarted.

Note that the game works _flawlessly_ up until this starts (if it weren't for this, I'd say it could have official support). It happens at such random times that I haven't figured out a way to reproduce it myself (other than just playing for a long time - just sitting idle doesn't seem to work).

OS: Kubuntu 18.04 LTS (compositor disabled)
GPU: RX 580 8GB
Proton: 3.16-7 Beta
Mesas tried: 18.2, and 19.0.99 (Oibaf latest)
LLVM: 7.0.1

I have:

• Watched the GPU memory usage, clock speeds, etc. - which are the same as before the change (the one exception to this is that when moving/clicking the mouse or typing - which seem to cause the stuttering - the GPU usage will _decrease_)
• Watched CPU clocks and utilization - which also remain the same (I didn't see it while providing input though)
• Disabled all forms of frame-limiting in the game
• Tried different mouse settings in the game
• Checked dmesg for any I/O or interrupt problems with hardware - nothing logged
• Checked the dxvk log in the steam folder - nothing abnormal
• Compared all the stuff shown in the dxvk hud before and after the stuttering starts, only fps and frame-time seem to change, and that change only happens during input

I'm fresh out of ideas, so any help is welcome.

The game in the graphic part works flawlessly
But the audio gets delayed after a short time (10 min I'd say) and it becomes annoying

The game in the graphic part works flawlessly
But the audio gets delayed after a short time (10 min I'd say) and it becomes annoying

My understanding is that issue should be fixed when Proton gets a newer version of FAudio

The game in the graphic part works flawlessly
But the audio gets delayed after a short time (10 min I'd say) and it becomes annoying

You may be able to solve this by opening Properties on the game and set launch options to this:

PULSE_LATENCY_MSEC=60 %command%

It really should just fix crackling, but for lack of other suggestions until FAudio is updated, it's worth a shot?

@Turbito if you clone and build FAudio, then replace the libFAudio.so used by steam with the one you built, the sound is perfect:

https://github.com/FNA-XNA/FAudio

Just build and replace proton's current. If you're on Ubuntu, you'll need the following packages:

• cmake
• libsdl2-dev
• build-essential

I'm currently using one that's slightly older at the moment (https://github.com/FNA-XNA/FAudio/tree/e5c9c20c3a1e24efb35a1eb2156e7d306f94e518), but current master should work as well.

P.S. If you end up running into the problem I described in my previous post, I'd like to know.

Sometimes you'll also get the problem when you just can't connect to their landing page. I'm guessing you already have, but on the off chance you haven't, check to see that your BrowserType is set to 2 in boot.cfg (I believe?). Den lør. 2. mar. 2019, 03:37 skrev Equivocal90 notifications@github.com:
…
I'm still having issues with an HTTPS error in the launcher despite BrowserType having been set to 2. Tested under GNOME with Wayland, GNOME on Xorg, and Plasma to no avail. Try deleting the "web" folder in ~/.local/share/Steam/steamapps/compatdata/39210/pfx/drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/ I have 2 Fedora 29 machines where on one I have to constantly delete that folder for the launcher to load while on the other does not require it. Although, I'm not sure what is different between the two machines — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#580 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/APgQqIDNj5NfLmXrWkWA0EMScT75Ts9Hks5vSePkgaJpZM4WMfqx .

It turns out Steam creates a new My Games folder under SteamPlay. The config file being read was in the new prefix.

The game in the graphic part works flawlessly
But the audio gets delayed after a short time (10 min I'd say) and it becomes annoying

You may be able to solve this by opening Properties on the game and set launch options to this:

PULSE_LATENCY_MSEC=60 %command%

It really should just fix crackling, but for lack of other suggestions until FAudio is updated, it's worth a shot?

@Turbito if you clone and build FAudio, then replace the libFAudio.so used by steam with the one you built, the sound is perfect:

https://github.com/FNA-XNA/FAudio

Just build and replace proton's current. If you're on Ubuntu, you'll need the following packages:

* cmake

* libsdl2-dev

* build-essential

I'm currently using one that's slightly older at the moment (https://github.com/FNA-XNA/FAudio/tree/e5c9c20c3a1e24efb35a1eb2156e7d306f94e518), but current master should work as well.

P.S. If you end up running into the problem I described in my previous post, I'd like to know.

I have been playing for about one and half hour and the only graphic issue is that the camera doesn't move as smooth as in a Windows system... It only happens in high desktop graphics configuration. In the standard laptop one the camera works as intended

I just tried but none of these (even at the same time) fix my audio delay...
The audio quality is nice, the only problem is the small (but noticeable by 2 or 3 seconds) delay/desync of the sound

edit: I just noticed I copied the library into the lib/ folder... I'm testing into the lib64/

Which version of Linux are you running and what's your Proton version?
Have you tried activating all xaudio channels with wineconfig for the
compatdata pfx as well as xact?

I'm currently running the latest proton beta under Kubuntu 18.10.

>

Now, copied into the lib64 folder of proton seems to be working without delay. In this half hour I haven't noticed delay. The audio is perfectly synced. Thank you all.

I haven't touch anything into the winecfg of Proton, just copied the lib and set

PULSE_LATENCY_MSEC=60 %command%

into the launch parameters

Using Linux 5.0, Mesa 19.1.0-devel (git-cb4e3e3ef6), xf86-xorg-amdgpu up to day etc. in Proton 3.16-7 beta (not sure If that the number... It's the most recent version that steam client displays)

Awesome! I'm glad that fixed it for you!
I was looking for the distro actually. My bad, that, I'm still acclimating to the linux world :D
Happy gaming!

Awesome! I'm glad that fixed it for you!
I was looking for the distro actually. My bad, that, I'm still acclimating to the linux world :D
Happy gaming!

Gentoo "testing"? (~amd64). But It should work as well in any other distro I guess.

@schives I have experienced this same issue, while it will be choppy without input, input definitely makes it worse. It also seems to take exactly one hour for me. If I restart the game everything works flawlessly again. Please let me know if you come across any workarounds or solutions for this.

Attempting to get some documentation of the issue I'm experiencing that seems to be the same as @schives 's where after an hourish it's really jerky and bad. I had to do this with a phone camera unfortunately but it seems to come through a little bit, especially when compared to when it works correctly

After an hourish:
https://witches.live/@anna/101786126154372039

Normally:
https://witches.live/@anna/101786130006475213

followup, it seems to be a consequence of active play. I left the game on all night after only just logging in and chatting a bit and in the morning, the stutter is not there.

One more comment to absolutely confirm I have the same thing @schives has, and has documented it better than I have. It does seem to be something related to input, and indeed it seems to be a function almost of how many buttons you press, if you are active and doing questing and instances it seems to come up quicker, meanwhile I didn't have it happen for damn near 18 hours because I left it on overnight to test this and then played very sporadically mostly watching cutscenes, and it only started happening right before I did the new dungeon (thankfully before I went in, heh). I helped some people clear Tsukiyomi normal and it kicked in in the middle of the second part and this is REALLY fun to deal with when you're running out of AOEs and yet input makes everything worse...

It's so bizarre. If you wouldn't mind @schives can we see what is similar about our setups to maybe help pin down the problem?

I'm using gentoo, kernel version 4.19.27-gentoo-r1
I fixed the sound by using this command though I am running the game through the "free trial" option since I have a legacy non-steam account so it's not exactly this number:
protontricks 39210 xaudio2_{0,1,2,3,4,5,6,7,8,9}=native

My glxinfo:

anna@eurekapyros ~/.steam/steam/steamapps/common/FINAL FANTASY XIV Online $ glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1070 Ti/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 418.43
OpenGL core profile shading language version string: 4.50 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 418.43
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 418.43
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

Proton version is 3.16-8 Beta
CPU is Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz

I have made a twitch clip of this issue happening as I am streaming

https://clips.twitch.tv/CarelessPeacefulAirGuitarYouWHY

When the mouse camera movement thing happens, is it choppy still if using the keyboard to move the camera?

It has been a while since I was in FFX|V, and I don't remember if there are default bindings for the camera, for the keyboard, if it can be done built-in-like, but if it is, has anyone tried that?

Also, does just moving the mouse around (even without moving the camera) make the choppiness happen?

(Apologies if I missed mentions of these things somewhere; I am getting mail on each message under ValveSoftare here, but I may have missed these, and I'm not reading all of these comments right now ^^;).

Yes, it does. Any time there is input it gets choppy, whether you use the mouse or keyboard. It's still kiiiinda choppy if you look closely at the animations while you stand still and don't type, but it gets bad again even if you're typing in the chatbox or something. Any sort of input at all seems to make it choppy.

Okay it does not seem like the things I've seen elsewhere, with regards to movements and inputs.

One thing that seems also similar, with this title, is graphics memory running out after a while of playing. All is fine for a time, but then things get crazy...

I'm speaking from the past a little, running the game via Wine, since the very first Alpha to Beta and what ever releases they now have. :]

Point being, I'd pay attention to the graphics memory being used, as it seemed like I was running out of it (memory leaks?). Things went very similar to what I have seen here, after a while, and it matches that you need to actually move around, not just idle).

@witcheslive and @Chiitoo
It doesn't seem to be VRAM, radeontop shows memory usage is roughly consistent on my RX 580 and never peaks above 3 GB, even while other applications are running.
The memory usage is minor, with no obvious memory leaks.

I've even tried removing other pcie cards in case there's some problem there (a bit extreme for debugging), but there was no change.

It really looks like a problem with how either proton or FF14 handles input. By enabling full dxvk HUD, you should be able to see a momentary stutter on the frame-time graph when left-clicking (fraction of a second - the kind of thing you wouldn't normally see). This stutter on left-click is present even before the game goes all stutter-on-all-input-mode.

As far as a little experiment, when the game gets choppy, alt-tab out, disable key repeat using xset r off (this will turn off key repeat in xorg) and start running around using the WASD keys. You'll notice that even if you're holding the key down, as long as you don't move the mouse or push new keys, the game isn't really choppy. To re-enable key repeat, use xset r on.

I have also seen that the time it takes for the game to go choppy seems to be inversely proportional to the number of keys I press.

Things I could think of that might be causing problems:

1. There could be some sort of data structure acting as a buffer that holds all the keys pressed and needs adjustment (e.g. a stack or queue) in some way when it gets excessively full and isn't flushed. It would make sense that such a data structure needing to move all values over one space might run into a memory bandwidth bottleneck.

1. It is also possible that the audio fix is at fault.

2. We both have Intel processors: maybe one of the mitigations for those excessively numerous hardware vulnerabilities is causing problems?

3. Something could be wrong with how proton is translating the input for FF14.

As far as system specs go, the only thing I see that's similar is our CPU vendor (Intel)...

Detailed specs

OS: Kubuntu 18.04 LTS
Proton: 3.16-8 Beta

$ uname -srvmpio
Linux 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              8
On-line CPU(s) list: 0-7
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               45
Model name:          Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz
Stepping:            7
CPU MHz:             1200.413
CPU max MHz:         3800.0000
CPU min MHz:         1200.0000
BogoMIPS:            7203.91
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            10240K
NUMA node0 CPU(s):   0-7
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts flush_l1d

# lshw -class memory
  *-memory
       description: System Memory
       physical id: 2e
       slot: System board or motherboard
       size: 16GiB
     *-bank:0
          description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns)
          product: F3-1600C9-4GAB
          vendor: Undefined
          physical id: 0
          serial: 00000000
          slot: ChannelA_Dimm1
          size: 4GiB
          width: 64 bits
          clock: 1600MHz (0.6ns)
     *-bank:1
          description: DIMM Synchronous [empty]
          product: ChannelA_Dimm2_PartNum
          vendor: ChannelA_Dimm2_Manufacturer
          physical id: 1
          serial: ChannelA_Dimm2_SerNum
          slot: ChannelA_Dimm2
          width: 64 bits
     *-bank:2
          description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns)
          product: F3-1600C9-4GAB
          vendor: Undefined
          physical id: 2
          serial: 00000000
          slot: ChannelB_Dimm1
          size: 4GiB
          width: 64 bits
          clock: 1600MHz (0.6ns)
     *-bank:3
          description: DIMM Synchronous [empty]
          product: ChannelB_Dimm2_PartNum
          vendor: ChannelB_Dimm2_Manufacturer
          physical id: 3
          serial: ChannelB_Dimm2_SerNum
          slot: ChannelB_Dimm2
          width: 64 bits
     *-bank:4
          description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns)
          product: F3-1600C9-4GAB
          vendor: Undefined
          physical id: 4
          serial: 00000000
          slot: ChannelC_Dimm1
          size: 4GiB
          width: 64 bits
          clock: 1600MHz (0.6ns)
     *-bank:5
          description: DIMM Synchronous [empty]
          product: ChannelC_Dimm2_PartNum
          vendor: ChannelC_Dimm2_Manufacturer
          physical id: 5
          serial: ChannelC_Dimm2_SerNum
          slot: ChannelC_Dimm2
          width: 64 bits
     *-bank:6
          description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns)
          product: F3-1600C9-4GAB
          vendor: Undefined
          physical id: 6
          serial: 00000000
          slot: ChannelD_Dimm1
          size: 4GiB
          width: 64 bits
          clock: 1600MHz (0.6ns)
     *-bank:7
          description: DIMM Synchronous [empty]
          product: ChannelD_Dimm2_PartNum
          vendor: ChannelD_Dimm2_Manufacturer
          physical id: 7
          serial: ChannelD_Dimm2_SerNum
          slot: ChannelD_Dimm2
          width: 64 bits

$ vulkaninfo | head -243
===========
VULKAN INFO
===========

Vulkan Instance Version: 1.1.70

ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32


Instance Extensions:
====================
Instance Extensions     count = 16
        VK_KHR_device_group_creation        : extension revision  1
        VK_KHR_external_fence_capabilities  : extension revision  1
        VK_KHR_external_memory_capabilities : extension revision  1
        VK_KHR_external_semaphore_capabilities: extension revision  1
        VK_KHR_get_physical_device_properties2: extension revision  1
        VK_KHR_get_surface_capabilities2    : extension revision  1
        VK_KHR_surface                      : extension revision 25
        VK_KHR_wayland_surface              : extension revision  6
        VK_KHR_xcb_surface                  : extension revision  6
        VK_KHR_xlib_surface                 : extension revision  6
        VK_KHR_display                      : extension revision 23
        VK_EXT_direct_mode_display          : extension revision  1
        VK_EXT_acquire_xlib_display         : extension revision  1
        VK_EXT_display_surface_counter      : extension revision  1
        VK_EXT_debug_report                 : extension revision  9
        VK_EXT_debug_utils                  : extension revision  1
Layers: count = 5
=======
VK_LAYER_VALVE_steam_fossilize_64 (Steam Pipeline Caching Layer) Vulkan version 1.1.73, layer version 1
        Layer Extensions        count = 0
        Devices         count = 1
                GPU id       : 0 (AMD RADV POLARIS10 (LLVM 8.0.0))
                Layer-Device Extensions count = 0

VK_LAYER_VALVE_steam_fossilize_32 (Steam Pipeline Caching Layer) Vulkan version 1.1.73, layer version 1
        Layer Extensions        count = 0
        Devices         count = 1
                GPU id       : 0 (AMD RADV POLARIS10 (LLVM 8.0.0))
                Layer-Device Extensions count = 0

VK_LAYER_VALVE_steam_overlay_32 (Steam Overlay Layer) Vulkan version 1.1.73, layer version 1
        Layer Extensions        count = 0
        Devices         count = 1
                GPU id       : 0 (AMD RADV POLARIS10 (LLVM 8.0.0))
                Layer-Device Extensions count = 0

VK_LAYER_VALVE_steam_overlay_64 (Steam Overlay Layer) Vulkan version 1.1.73, layer version 1
        Layer Extensions        count = 0
        Devices         count = 1
                GPU id       : 0 (AMD RADV POLARIS10 (LLVM 8.0.0))
                Layer-Device Extensions count = 0

VK_LAYER_LUNARG_standard_validation (LunarG Standard Validation Layer) Vulkan version 1.0.70, layer version 1
        Layer Extensions        count = 0
        Devices         count = 1
                GPU id       : 0 (AMD RADV POLARIS10 (LLVM 8.0.0))
                Layer-Device Extensions count = 0

Presentable Surfaces:
=====================
GPU id       : 0 (AMD RADV POLARIS10 (LLVM 8.0.0))
Surface type : VK_KHR_xcb_surface
Formats:                count = 2
        B8G8R8A8_SRGB
        B8G8R8A8_UNORM
Present Modes:          count = 3
        IMMEDIATE_KHR
        MAILBOX_KHR
        FIFO_KHR

VkSurfaceCapabilitiesKHR:
=========================
        minImageCount       = 2
        maxImageCount       = 0
        currentExtent:
                width       = 256
                height      = 256
        minImageExtent:
                width       = 256
                height      = 256
        maxImageExtent:
                width       = 256
                height      = 256
        maxImageArrayLayers = 1
        supportedTransform:
                VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
        currentTransform:
                VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
        supportedCompositeAlpha:
                VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
                VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
        supportedUsageFlags:
                VK_IMAGE_USAGE_TRANSFER_SRC_BIT
                VK_IMAGE_USAGE_TRANSFER_DST_BIT
                VK_IMAGE_USAGE_SAMPLED_BIT
                VK_IMAGE_USAGE_STORAGE_BIT
                VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT

VkSurfaceCapabilities2EXT:
==========================

        supportedSurfaceCounters:
                None


Device Properties and Extensions :
==================================
GPU0
VkPhysicalDeviceProperties:
===========================
        apiVersion     = 0x40105a  (1.1.90)
        driverVersion  = 79691875 (0x4c00063)
        vendorID       = 0x1002
        deviceID       = 0x67df
        deviceType     = DISCRETE_GPU
        deviceName     = AMD RADV POLARIS10 (LLVM 8.0.0)
        VkPhysicalDeviceLimits:
        -----------------------
                maxImageDimension1D                     = 16384
                maxImageDimension2D                     = 16384
                maxImageDimension3D                     = 2048
                maxImageDimensionCube                   = 16384
                maxImageArrayLayers                     = 2048
                maxTexelBufferElements                  = 0x8000000
                maxUniformBufferRange                   = 0xffffffff
                maxStorageBufferRange                   = 0xffffffff
                maxPushConstantsSize                    = 128
                maxMemoryAllocationCount                = 4294967295
                maxSamplerAllocationCount               = 65536
                bufferImageGranularity                  = 0x40
                sparseAddressSpaceSize                  = 0xffffffff
                maxBoundDescriptorSets                  = 32
                maxPerStageDescriptorSamplers           = 9586978
                maxPerStageDescriptorUniformBuffers     = 9586978
                maxPerStageDescriptorStorageBuffers     = 9586978
                maxPerStageDescriptorSampledImages      = 9586978
                maxPerStageDescriptorStorageImages      = 9586978
                maxPerStageDescriptorInputAttachments   = 9586978
                maxPerStageResources                    = 9586978
                maxDescriptorSetSamplers                = 9586978
                maxDescriptorSetUniformBuffers          = 9586978
                maxDescriptorSetUniformBuffersDynamic   = 16
                maxDescriptorSetStorageBuffers          = 9586978
                maxDescriptorSetStorageBuffersDynamic   = 8
                maxDescriptorSetSampledImages           = 9586978
                maxDescriptorSetStorageImages           = 9586978
                maxDescriptorSetInputAttachments        = 9586978
                maxVertexInputAttributes                = 32
                maxVertexInputBindings                  = 32
                maxVertexInputAttributeOffset           = 0x7ff
                maxVertexInputBindingStride             = 0x800
                maxVertexOutputComponents               = 128
                maxTessellationGenerationLevel          = 64
                maxTessellationPatchSize                        = 32
                maxTessellationControlPerVertexInputComponents  = 128
                maxTessellationControlPerVertexOutputComponents = 128
                maxTessellationControlPerPatchOutputComponents  = 120
                maxTessellationControlTotalOutputComponents     = 4096
                maxTessellationEvaluationInputComponents        = 128
                maxTessellationEvaluationOutputComponents       = 128
                maxGeometryShaderInvocations            = 127
                maxGeometryInputComponents              = 64
                maxGeometryOutputComponents             = 128
                maxGeometryOutputVertices               = 256
                maxGeometryTotalOutputComponents        = 1024
                maxFragmentInputComponents              = 128
                maxFragmentOutputAttachments            = 8
                maxFragmentDualSrcAttachments           = 1
                maxFragmentCombinedOutputResources      = 8
                maxComputeSharedMemorySize              = 0x8000
                maxComputeWorkGroupCount[0]             = 65535
                maxComputeWorkGroupCount[1]             = 65535
                maxComputeWorkGroupCount[2]             = 65535
                maxComputeWorkGroupInvocations          = 2048
                maxComputeWorkGroupSize[0]              = 2048
                maxComputeWorkGroupSize[1]              = 2048
                maxComputeWorkGroupSize[2]              = 2048
                subPixelPrecisionBits                   = 8
                subTexelPrecisionBits                   = 8
                mipmapPrecisionBits                     = 8
                maxDrawIndexedIndexValue                = 4294967295
                maxDrawIndirectCount                    = 4294967295
                maxSamplerLodBias                       = 16.000000
                maxSamplerAnisotropy                    = 16.000000
                maxViewports                            = 16
                maxViewportDimensions[0]                = 16384
                maxViewportDimensions[1]                = 16384
                viewportBoundsRange[0]                  =-32768.000000
                viewportBoundsRange[1]                  = 32767.000000
                viewportSubPixelBits                    = 8
                minMemoryMapAlignment                   = 4096
                minTexelBufferOffsetAlignment           = 0x1
                minUniformBufferOffsetAlignment         = 0x4
                minStorageBufferOffsetAlignment         = 0x4
                minTexelOffset                          =-32
                maxTexelOffset                          = 31
                minTexelGatherOffset                    =-32
                maxTexelGatherOffset                    = 31
                minInterpolationOffset                  =-2.000000
                maxInterpolationOffset                  = 2.000000
                subPixelInterpolationOffsetBits         = 8
                maxFramebufferWidth                     = 16384
                maxFramebufferHeight                    = 16384
                maxFramebufferLayers                    = 1024
                framebufferColorSampleCounts            = 15
                framebufferDepthSampleCounts            = 15
                framebufferStencilSampleCounts          = 15
                framebufferNoAttachmentsSampleCounts    = 15
                maxColorAttachments                     = 8
                sampledImageColorSampleCounts           = 15
                sampledImageDepthSampleCounts           = 15
                sampledImageStencilSampleCounts         = 15
                sampledImageIntegerSampleCounts         = 1
                storageImageSampleCounts                = 15
                maxSampleMaskWords                      = 1
                timestampComputeAndGraphics             = 1
                timestampPeriod                         = 40.000000
                maxClipDistances                        = 8
                maxCullDistances                        = 8
                maxCombinedClipAndCullDistances         = 8
                discreteQueuePriorities                 = 2
                pointSizeRange[0]                       = 0.000000
                pointSizeRange[1]                       = 8192.000000
                lineWidthRange[0]                       = 0.000000
                lineWidthRange[1]                       = 7.992188
                pointSizeGranularity                    = 0.125000
                lineWidthGranularity                    = 0.007812
                strictLines                             = 0
                standardSampleLocations                 = 1
                optimalBufferCopyOffsetAlignment        = 0x80
                optimalBufferCopyRowPitchAlignment      = 0x80
                nonCoherentAtomSize                     = 0x40
        VkPhysicalDeviceSparseProperties:
        ---------------------------------
                residencyStandard2DBlockShape            = 0
                residencyStandard2DMultisampleBlockShape = 0
                residencyStandard3DBlockShape            = 0
                residencyAlignedMipSize                  = 0
                residencyNonResidentStrict               = 0

Edit: added compressed sections for hardware info

Extremely corroborating that it seems to have to do with the number of inputs in a session, and it takes about one hour of active play, and doing instances seems to make it happen faster because of so much button pressing. I play with a very active style, jumping around a lot, multihitting buttons to ensure they're queued for GCDs, spinning camera around, so I think that's why the only time I got more than an hour of active playing was when I was doing the new patch MSQ and taking my time watching the cutscenes.

I do wonder if it's something with the audio fix, but without it audio is so bad that I don't even last 10 minutes let alone an hour, heh. But at the same time I know someone (who helped me get this set up) who has nearly identical hardware (same GPU anyway) that DOESN'T have this problem, though they also play a more relaxed style than me so it is hard to say if they're just not hitting it or something too. Only other things I can think of are my primary monitor runs 144hz with a secondary 60 hz monitor, both at different resolutions. I'm using i3 and not a full window manager.

If the audio library slows down it'll most likely manifest as audio stuttering - the client's interaction with XAudio2 does have some mutexes involved but it's usually per-source and not across the entire API, which I could see causing time losses if there were a few dozen thousand voices (as opposed to the ~32-64 that most games work with).

@witcheslive
I am running a single 4k (3820x2160) 60Hz monitor.
I happen to have the steam overlay disabled in-game (because I use shift-tab as a hotkey).
If you have also disabled steam overlay, our problem may be related to https://github.com/ValveSoftware/steam-for-linux/issues/5727.

The differences continue, at least it's narrowing things down. I have not disabled the overlay.

Woah that link is interesting. I'm more wondering if it's a problem with Vulkan or Proton and doesn't even involve the overlay or FFXIV specifically, it's just not experienced as often because it involves ~an hour of active play to hit so it's escaped detection.

I briefly tried to replicate the stuttering issue by running around Eureka before maintenance tonight, but was not able to do so.

Just for testing, have those being affected by it tried the Lutris script? It might at least narrow down if it's something only in Proton / Steam-specific or if it's something shared between them.

I had tried using the Lutris script a week ago, same issue on my end.

I again,
this time I was testing with Ubuntu 19.04 dev and it requires some additional steps.
Vulkan drivers for mesa come installed, but not the 32 bit ones.

sudo apt install mesa-vulkan-drivers:i386

This enable dxvk (before this fallback to dx9c)

@HereInPlainSight the best way to replicate it is to do instanced dungeons where you're pressing a lot of buttons. Eureka works too if you're actively doing it, it's not going to happen if you're AFK farming haha

Just tried a fresh install with Proton 4.2. Still needed to use the BrowserType and Cutscene edits to the cfg files. 2 hours of play, mostly gathering/crafting as I am a newb and playing on my very underpowered laptop. No audio lag. Cannot comment on the stuttering. I didn't see any, but then the activities I was engaged in might not trigger it.

After getting 4.2 going (I had to jiggle the handle a bit, it didn't download for some reason, so if anyone gets binary format errors, go download, or delete and download, Realm of the Mad God or something to get it to actually download Proton 4.2) I did some roulettes, left it on overnight, then did more roulettes, and I've definitely been mashing buttons for over an hour and it seems to be OK now, knock on wood!

I am unable to enter Full Screen Mode without my entire desktop environment freezing. When I installed the game with Lutris previously, I was able to accomplish this by manually editing the appropriate settings in FFXIV.cfg. Now with Proton 4.2, even that fails; the whole desktop will freeze up and I need to SSH in and kill the FFXIV process to recover.

Distro: Ubuntu 18.04.2
Proton: 4.2-2
GPU: RX 480 8GB
Driver/LLVM version: Mesa 18.2.8/LLVM 7.0.0
Kernel version: 4.18.0-17-generic

@e3b0c442 That's a known issue with DXVK. Fortunately, a fix is already available in DXVK 1.0.2 (look a the changelog): https://github.com/doitsujin/dxvk/releases

Proton is still using an earlier version of DXVK, hence the issues.

I am unable to enter Full Screen Mode without my entire desktop environment freezing.

Can you do Windowed Full Screen? I'm playing several hours a night without issue, but I am playing in Windowed Full Screen.

I am running into a black screen with a loading circle in the bottom/right corner of the stream on a fresh install of Linux Arch right now. This loading screen happens after select a datacenter to connect to. Used to be able to play it ~2 months ago on my previous Linux installation. Not sure exactly what broke it, but while the infinite loading screen is showing, this is being spammed in the logs over and over again:

830.883:0102:0103:trace:module:LdrGetDllHandle L"C:\\windows\\system32\\dinput8.dll" -> 0x7f0f134e0000 (load path L"Z:\\home\\jaap\\.local\\share\\Steam\\steamapps\\common\\FINAL FANTASY XIV Online\\game;C:\\Program Files (x86)\\Steam;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem")
830.883:0102:0103:trace:module:LdrAddRefDll (L"dinput8.dll") ldr.LoadCount: -1
830.883:0102:0103:trace:module:LdrUnloadDll (0x7f0f134e0000)
830.883:0102:0103:trace:module:LdrUnloadDll (L"dinput8.dll") - START
830.883:0102:0103:trace:module:LdrUnloadDll END

Any thoughts?

@e3b0c442 That's a known issue with DXVK. Fortunately, a fix is already available in DXVK 1.0.2 (look a the changelog): https://github.com/doitsujin/dxvk/releases

Proton is still using an earlier version of DXVK, hence the issues.

I reinstalled with Lutris and everything was hunky-dory, aside from it being slower than I remembered. Thanks.

Is there anything preventing me from just running the upgraded DXVK setup script in the Steam wineprefix? I'd prefer to have the game managed through Steam.

@Mushoz you need to change CutsceneMovieOpening in FFXIV.cfg to 1.

Did anyone figure out the mouse movement stuttering? Experiencing the same issue and troubleshooting it is driving me kind of nuts!

We have two almost identical PCs where we play the game. One where the mouse movement stuttering was very obvious and one where it didn't seem to happen.

The main difference between the PCs was that the one without stutter issues was running compton, while the problematic one wasn't. So, we disabled compton on that PC and now both are experiencing the stuttering. The fun thing is, even turning compton back on isn't fixing it. Somehow turning compton off caused the issue to start, if that would be of help to anyone.

(Restarting etc doesn't make any difference now..)

Plugging in an XB360 controller corrected the mouse stuttering for me. (I didn't even use it, just having it plugged in was enough)

Had to try, sadly that doesn't do anything at all for me :(

Tbh I've found FFXIV to be very temperamental on Linux. Maybe you've seen the issues I described above. Moving to Kubuntu fixed it, but then I got FPS stutters in general so switching desktop environments helped a bit.
Then suddenly FPS was smooth af and there was no stuttering even in 24-mans for a week, and then I get hiccups under those same scenarios (I don't update my computer frequently, so no changes are made to the system).

Mouse stuttering has happened to me too, but strangely after applying the PULSE_LATENCY_MSEC=60 %command% fix also took care of that. SOMEHOW. I don't know why.

Other observations I've made related to game stuttering is video playback in the background (even on minimized windows), the use of Caprine (a Facebook messenger implementation for Linux desktops which has consistently caused stuttering in FPS and mouse responsiveness when running), or if another process is doing something that breaks 7% CPU usage while engaged in gameplay.

Another thing I do when my mouse hiccups is I disable and re-enable it through xinput and that somehow seems to magically fix things, if for a time.

Beyond that, I'd suggest disabling the Steam overlay and see if you can maybe exit Steam entirely after booting the game and see if that makes a difference?

I wonder if there could be driver issues causing these problems at this point...

Already switched to a different desktop enviroment, applied the pulse latency fix, started with nothing else running... Now I tried the xinput thing, and disabling steam overlay. Still experiencing the issue 100% of the time.

Might it be a mesa bug, somehow? But I don't think that touches input at all

Could you try this: PROTON_USE_WINED3D
This will ask Proton to use WINE's OpenGL implementation of wined3d instead of Vulkan's DXVK. If that doesn't help then I'm afraid I'm out of suggestions for now.

But you could look here to find things to try: https://github.com/ValveSoftware/Proton#runtime-config-options

Thank you very much for helping me troubleshoot. Sadly I have the same issue with or without dxvk.

Regarding the mouse stuttering issue. I finally found a workaround that works (including many other winegames too).

I had to install polychromatic (to access the settings for my razer mouse) and reduce pollingrate to 125 or 500. 125 means no framedrop, 500 gives some framedrop. 1000 kills my frames.

Apparently this has been a known issue with wine for a long time.

I'm not sure if this is the same issue directly. I've gotten XIV working via Proton, but I had to follow well-known wine answers to get it playable. Namely, I have to edit two files in the steamapps/compatdata/39210/pfx/drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/ directory.

In FFXIV_BOOT.cfg, I had to edit BrowserType to 2, and in FFXIV.cfg I have to edit CutsceneMovieOpening to 1.

The first change allows me to get to the launcher at this point -- if it's left to its default value I get 'A system error has occured: 404. HTTPS System Error'. Afraid I did the install mid-week, so I'm not sure if this is how I got past nstgc's issue during installation.
Obviously the latter change means I don't get to see the opening cutscene the first time I play the game, but if I leave it at default value, the game launches but hangs up after selecting a Data Center.

As these edit game configuration files I'm not sure if this is something Valve wants to consider for Proton, but at the least it's information.

This worked for me, on Arch linux with Kernel 5.0.8, nvidia 780 TI and kde. Cheers!

So... it seems the latest patch of FFXIV, which also had an update to the boot program, broke it for me now.
Now I'm getting HTTPS 404 errors again, even with BrowserType correctly configured. I'm going to attempt a reinstall and see if reinstalling the launcher will work.
Any other ideas?
Currently running on Pop_!OS.

EDIT: Reinstalling did not help.

Same issue on Arch @TenaarFeiri. Did they sneakily disable something wine depended on?

Lutris forum is talking about this issue too.. https://forums.lutris.net/t/final-fantasy-14-wont-start-after-latest-update-dxvk/5598

A bit off-topic: Why must all launchers suck so much? :)

EDIT: It might be important to note that this issue is proton-exclusive. Wine affected too.

Hello @TenaarFeiri, @fosspill, can one of you please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

PROTON_LOG=1 %command%

Absolutely!
steam-39210.log

Same issue on Arch @TenaarFeiri. Did they sneakily disable something wine depended on?

Lutris forum is talking about this issue too.. https://forums.lutris.net/t/final-fantasy-14-wont-start-after-latest-update-dxvk/5598

A bit off-topic: Why must all launchers suck so much? :)

And I have no idea. Sometimes they seem to be deliberately designed to make it harder for people to run their games on other systems that could otherwise support them :D

EDIT:

I looked at the logs myself and this part seems very interesting:

1040.629:0030:0031:fixme:ieframe:ClientSite_GetContainer (0x1b0b8c)->(0x32e1dc)
1040.630:0030:0031:fixme:urlmon:InternetBindInfo_GetBindString not supported string type 20
1040.630:0030:0031:fixme:urlmon:InternetBindInfo_GetBindString not supported string type 12
1040.630:0030:0031:err:mshtml:on_stop_nsrequest RemoveRequest failed: 80004005
1040.630:0030:0031:fixme:ieframe:ClientSite_GetContainer (0x1b0b8c)->(0x32ea9c)
1040.631:0030:0031:fixme:urlmon:InternetBindInfo_GetBindString not supported string type 20
1040.631:0030:0031:fixme:ieframe:DocHostUIHandler_GetDropTarget (0x1b0b8c)
1040.631:0030:0031:fixme:ieframe:DocHostUIHandler_GetDropTarget (0x1b0b8c)
1041.008:0030:0031:fixme:ieframe:DocObjectService_IsErrorUrl 0x1cd080 L"https://frontier.ffxiv.com/version_4_0_win/version_4_0_win/index.html?1556023343664" 0x32e460
1041.028:0030:0031:trace:module:GetModuleFileNameW L"C:\windows\system32\user32.dll"

Could the problem be Gecko-specific now? I notice after that, there are a lot of failed attempts to load it.

There's
1041.008:0030:0031:fixme:ieframe:DocObjectService_IsErrorUrl 0x1cd080 L"https://frontier.ffxiv.com/version_4_0_win/version_4_0_win/index.html?1556023343664" 0x32e460
in the log, someone on reddit says it should be contacting https://frontier.ffxiv.com/version_4_0_win/index.html instead (version_4_0_win only once).
https://www.reddit.com/r/ffxiv/comments/bgeluh/any_other_linux_users_getting_404_errors_when/

I made a +relay log and the duplicate version_4_0_win seems to get created in a call to CoInternetCombineUrlEx. I think they're passing https://frontier.ffxiv.com/version_4_0_win and version_4_0_win/index.html as arguments and wine is supposed to cut out version_4_0_win from the first argument.

My + relay log
+urlmon log

EDIT:
main.c, compiled with x86_64-w64-mingw32-gcc main.c -I /usr/include/wine/windows/ -lurlmon -lmsvcrt -lucrt -L /usr/lib/wine/fakedlls/ -o main.exe gives a duplicate version_4_0_win on both windows and wine so this might not be the issue after all.

Nice detective work, guys. Would it be possible to somehow redirect the incorrect URL (with a firewall, a custom wine-patch, a shim or anything?) until the bug is properly found and rectified?

Has XIV's launcher always used Gecko rather than Chromium as it's rendering engine? Could it maybe be that the BrowserType flag is no longer supported?

I've wondered about that too @nourez but the url issue people have pointed out makes it seem like that might not be the case?

Just on a whim, I've been going through the BrowserTypes 0 through 20 without luck :P
I'm starting to think that's not the issue. Also been changing... well everything. I've been messing with every thing in the config file now to no avail.

It seems the problem is indeed the incorrect URL, which I doubt we'll be able to remedy on our end. It's up to Valve! Or Square. Whoever gets to it first.

@fosspill @TenaarFeiri Yeah, I didn't see that it was a malformed URL, just saw the post regarding issues trying to call Gecko. I think Fosspill's idea of redirecting the URL is probably the best option to try for the time being, but I won't be able to really mess around with it until after I get home from work today. Maybe try editing /etc/hosts to handle it?

Sadly /etc/hosts wouldn't work as it only does hostnames/ips. I think the only possibility is some kind of shim/custom wine patch to fix it temporarily until SE fixes it permanently.

I'd imagine doing a substring deletion on the URL might fix it for now? But it would be a very specific fix and if the URL got longer or shorter for any reason, we'd be back to this.
Idk how to accomplish it with WINE patching though. That's not really my deal.

It's indeed true that it would be a weird and overly specific fix, but I'd love to see that working! :)

Any IE version work in a 64-bit prefix? That might be a way around it

not sure if this is helpful but i grabbed urlmon.dll and its dependency iertutil.dll from a 32-bit windows 7 vm and set them as native overrides, but it doesn't seem to have affected the duplicated path segment

@exolyte I'm not sure I understand your edit, while something deeper might be a problem, that URL with version_4_0_win repeated definitely doesn't exist while the the one with it just once does, though maybe this is just a symptom of a bigger problem?

EDIT:
main.c, compiled with x86_64-w64-mingw32-gcc main.c -I /usr/include/wine/windows/ -lurlmon -lmsvcrt -lucrt -L /usr/lib/wine/fakedlls/ -o main.exe gives a duplicate version_4_0_win on both windows and wine so this might not be the issue after all.

Well, that's not good news. Is there anything I can do to help troubleshoot this?

@witcheslive My assumption was that the CoInternetCombineUrlEx was implemented incorrectly in wine, but the test in my edit suggests that the issue lies somewhere else. So I either messed up something in my test or the duplication of version_4_0_win happens somewhere else.

A third possibility is that the double version_4_0_win is actually correct. It's definitely weird, but it's not necessarily the cause of the problem.

A third possibility is that the double version_4_0_win is actually correct. It's definitely weird, but it's not necessarily the cause of the problem.

i don't think this is the case, since un-doubled in a browser it definitely returns a 200 response but doubled produces a 404

The launcher only contains a single instance of the strings https://frontier.ffxiv.com/version_4_0_win/ and index.html. Zeroing out version_4_0_win/ from the former causes the log to show that it attempted to access https://frontier.ffxiv.com/index.html Also there are no instances of version_4_0_win on its own.

So, it still does appear that version_4_0_win is being duplicated somehow but it doesn't have to do with when index.html is appended to it.

Is there any way to proxy/redirect the duplicated version_4_0_win to the correct URL to see if that fixes it?

@witcheslive i don't think it's possible with just a proxy as the url uses a https scheme. but if we patch the string in the binary to use http it may be possible

Is there any way to proxy/redirect the duplicated version_4_0_win to the correct URL to see if that fixes it?

Not easy with HTTPS unfortunately

I don't think using http is a good idea for sending login credentials, though if we're patching the binary anyway doing a URL rewrite there is probably a better idea. Not to mention if they set up their authentication servers correctly it wouldn't even accept http anyway.

we can try rewriting the url to point at a local proxy. as far as we know so far that's the only url affected, and we can tackle problems iteratively as we get further in

Would we gain any knowledge from patching wine to deal with the URL issue, if that's even possible?

Going to http://frontier.ffxiv.com/version_4_0_win/ does appear to allow access, although I get instructed to enable JavaScript and other things (even though I have it enabled).
If the servers were configured properly though, I shouldn't have been able to go to a regular HTTP version of the page at all.

If we can patch the binary temporarily to go through HTTP, then those of us who are willing to risk it (myself included) would love that until it gets an official fix.

Local proxy would require installing a spoofed HTTP cert, in addition to actually running the proxy. This might put the entire system at risk. It'd be better to patch the binary/wine

since it uses a browser embed, it might follow redirects as well so if we don't end up with a real fix soon we could try hosting a simple redirect at a path and patching the url in the binary to point at that. just speculation though, of course

Also, I noticed that the launcher now downloads libcef.dll, but it doesn't seem to actually use it, which is too bad because I think this is a Gecko issue.

Regarding patching the binary to point at a proxy, it'd be just as easy to patch it to point to the right URL in the first place, without trying to bypass HTTPS.

Local proxy would require installing a spoofed HTTP cert, in addition to actually running the proxy. This might put the entire system at risk. It'd be better to patch the binary/wine

if we rewrite the url to point directly at the proxy we wouldn't need a cert at all (assuming they don't hardcode the correct certificate or something)

i'm not entirely sure it would be as easy to point it at the correct url, since it does some manipulation on the url string which we don't understand, producing the duplicate path in the first place.

I redirected the frontier.ffxiv.com domain to my server using the hosts file and I put /version_4_0_win/index.html and /version_4_0_win/version_4_0_win/index.html on my server. The launcher accesses both files, but stays black after that. If I move /version_4_0_win/index.html or /version_4_0_win/version_4_0_win/index.html on my server, I get the regular 404 error.

I redirected the frontier.ffxiv.com domain to my server using the hosts file and I put /version_4_0_win/index.html and /version_4_0_win/version_4_0_win/index.html on my server. The launcher accesses both files, but stays black after that. If I move /version_4_0_win/index.html or /version_4_0_win/version_4_0_win/index.html on my server, I get the regular 404 error.

anything show up in logs?

I did patch my wine to use the (assumed) proper URL which results in it accessing https://frontier.ffxiv.com/version_4_0_win/index.html?1556042120789.

The 404 error is gone with that. However after doing a bunch more http requests the patcher then just sits there with a black screen and doesn't seem to react to any input.

Heres the patch to get past the 404.. though it doesn't seem overly useful.
https://gist.github.com/sschroe/963f1d7aa3fc366e155e5ac6bc84cc71

anything show up in logs?

Nothing interesting except the absence of 012e:fixme:ieframe:DocObjectService_IsErrorUrl 0xda6848 L"https://frontier.ffxiv.com/version_4_0_win/version_4_0_win/index.html?1556042270260" 0x32e428 which occurs when not redirecting to my own server.

anything show up in logs?

Nothing interesting except the absence of 012e:fixme:ieframe:DocObjectService_IsErrorUrl 0xda6848 L"https://frontier.ffxiv.com/version_4_0_win/version_4_0_win/index.html?1556042270260" 0x32e428 which occurs when not redirecting to my own server.

It looks almost like the launcher is attempting (and succeeding) in loading https://frontier.ffxiv.com/version_4_0_win/ and the issue we're getting is it's failing to authenticate with a file in https://frontier.ffxiv.com/version_4_0_win/version_4_0_win/ and that's what's causing the error?

Interestingly, going through the javascript files of the Frontier page, I'm seeing a lot of old code from when you created characters in the launcher. There is actually a lot of code in here that just isn't in use... Not really relevant. Just an aside.

I redirected the frontier.ffxiv.com domain to my server using the hosts file and I put /version_4_0_win/index.html and /version_4_0_win/version_4_0_win/index.html on my server. The launcher accesses both files, but stays black after that. If I move /version_4_0_win/index.html or /version_4_0_win/version_4_0_win/index.html on my server, I get the regular 404 error.

@exolyte I'd be curious if the launcher would attempt to access both files from a Windows machine. I dumped the launcher process memory and found several instances (10+ each) of both the single version_4_0_win and it doubled up.

When I get home, I'll try to see if I can find both URLs when the launcher is run under Windows

I booted up my Windows partition and changed the BROWSER_TYPE to 2 and it works fine, just to ensure something wasn't broken with Gecko overall.

I also tried to do some packet captures with wireshark to see what URLs its trying to access but I think those are encrypted beyond the domain (I do see it connect to frontier) and I am not very good at wireshark otherwise.

Another thing i tried was to replace ffxivlauncher.exe with the previous version and with this the launcher will start up and let me login. However after login it then complains that it cannot perform the version update.

Perhaps someone who has the fully patched client from windows could try if this gets them past the issue.

I booted up my Windows partition and changed the BROWSER_TYPE to 2 and it works fine, just to ensure something wasn't broken with Gecko overall.

Are we sure that the Browser_Type flag isn't completely ignored? Is there a visible difference between the browsertypes so we are sure Windows actually ran with Type=2?

EDIT: Tested on a windows partition here. No visible difference at all, to what I can see. Unsure about how to tell if browsertype is ignored or not.

Another thing i tried was to replace ffxivlauncher.exe with the previous version and with this the launcher will start up and let me login. However after login it then complains that it cannot perform the version update.

Perhaps someone who has the fully patched client from windows could try if this gets them past the issue.

Tried, sadly the same issue happens. You have to have an updated launcher to be able to launch the game even if the game is already up-to-date.

It appears the BrowserType does now get ignored, assuming a value of 2 meant it would use CEF (instead of IE). libcef.dll doesn't get accessed anymore by the launcher (you can check this with stat libcef.dll in the launcher dir and looking at the access time, which for me gives the last time I ran the launcher before the update).

The weird thing is that this update did modify libcef.dll, which is weird if it isn't used anymore at all...

If BrowserType no longer affects anything I don't think there's an easy fix, Wine's Gecko is in a rather sorry state so I don't have much hope of getting it to cooperate.

Proper IE support, whether through making Gecko more faithfully emulate it, or getting native IE 11 working, is something Wine sorely needs, there are a lot of apps that don't work very well in Wine because of it.

has anyone tried installing IE in the prefix, then?

The latest version of IE that "works" in Wine is IE8 and only in 32-bit prefixes. That would mean no DXVK/DirectX 11 support, even if someone got that working.

Basically, unless Square fixes it, the best bet of getting the game working again in the short term is going to be bypassing the launcher entirely

I noticed a variance in performance with using BrowserType so I don't think it gets ignored. Setting it to 0 produces the expected result of several seconds (up to a minute) of black before it errors out, while setting it to 2 produces the HTTPS error after a matter of <10 seconds. This is reproducible for me every time.
There may be something wrong with libcef.dll
Could we try using libcef.dll from an older version? If we have one available?

libcef.zip

EDIT: I also Contacted support to see if we can get a straight forward answer to whether or not BrowserType is still respected or not.

I just tried reverting to my previous version of libcef.dll (from prior to this update) and it still fails with the same 404

libcef.zip

Oh. I was beaten to the punch!
And that's a shame :(

icudt.zip

What about using both the old libcef and icudt?

EDIT: No change on my end either. Damn it =/

no change using both

Nothing. I even tried using cef from http://opensource.spotify.com/cefbuilds/index.html and still got a 404.

definitely looks like it's ignoring it, whether this is by accident or by design is the issue

They're shipping both a 32 and 64 bit ffxivlauncher.exe, but only a 32-bit libcef.dll, they can't both be using CEF.

did we even figure out what exactly is causing the error? If the launcher pointing to the wrong URL is the real issue, shouldn't windows users also have problems?

is the prefix 64 bit? i was pretty sure it wasn't, i had to use dlls from 32 bit windows when testing native overrides

The prefix needs to be 64 bit to run the DirectX 11 version of the game. If you were using it, your prefix was 64 bit.

did we even figure out what exactly is causing the error? If the launcher pointing to the wrong URL is the real issue, shouldn't windows users also have problems?

I don't think anyone has figured out what's causing it, no.

But, in theory windows and wine could behave slightly differently with the URL and therefore works properly in one while not working in the other one.

I hope we see someone smart in here figure it out and find a workaround, or that someone else writes a tool to bypass the patcher all-together.

So then it's probably not libcef.dll, but we may be right in thinking that the browser just doesn't use it anymore.
@Selhar Not necessarily. The launcher is specifically coded for Windows, so they may be using tricks specific to Win that WINE doesn't quite support.

Square DID announce that they were going to make sure that Steam versions of the game could only be used through Steam. This inability to access the game for us could be a direct consequence of those upcoming changes.

Moreover, DX9 FFXIV doesn't matter anymore; come ShB, they are dropping DX9 support for the game so we basically -have- to get it running on a 64-bit prefix if we want to play.

They're dropping support, but they will still distribute it with zero guarantees that it works. Essentially, Windows DX9 users will have exactly the same support as Linux users

if you recall, this is likely the same issue we worked around before with BrowserType 2. it's probably 404ing on windows as well, but since we don't have IE it doesn't catch the error and redirect to the intended page or something funky like that

https://github.com/xivapi/ffxiv-launcher has authentication code, I'm looking into if it'd be possible to just write a simple command line node.js script that uses it to log in. Still no way to patch without copying files from Windows though (and if they enforce Steam auth it probably wouldn't work for Steam users.)

Square DID announce that they were going to make sure that Steam versions of the game could only be used through Steam.

god why does SE have to be like this

Another way, that could work in the mean time, is logging in in a Windows VM and replacing ffxiv.exe with a dummy app that just dumps the session token, then passing that to the exe in Wine

Another way, that could work in the mean time, is logging in in a Windows VM and replacing ffxiv.exe with a dummy app that just dumps the session token, then passing that to the exe in Wine

I'm still a beginner with this tech tech stuff so I have no idea how to accomplish that!
But it does seem a decent solution.
The custom launcher that was linked earlier, could that be modified (and compiled for Linux) to output the session ID when logging in via it? May not even need the VM.

Basically, the launcher just passes the session token as a command line argument. An .exe that just dumps it's command line arguments to a file would work. Then you wine /path/to/ffxiv.exe $TOKEN_GOES_HERE

We would need an alternative to patching the game, however. How could that be accomplished?

We would need an alternative to patching the game, however. How could that be accomplished?
Maybe someone magical would find a solution.

I believe Glorious Eggroll made an alternative patcher for Warframe that worked fine.

something like this?

https://github.com/xivapi/ffxiv-launcher/

Or this? https://github.com/mclark4386/FF14Launcher (only login/token)
I presume the user agent might need to be updated to match the newer releases up the game. But if we manage to bypass this issue we can at least patch in a vm and then play properly.

that's the one I meant to link actually

that doesn't work on it's own however, I tested it earlier and it returns a separate error: http error 409 conflict

So, you can fix https://github.com/xivapi/ffxiv-launcher/ 's UI problems by installing MS fonts.

Still doesn't help with patching the game, though

If anyone is in need of an updated (or old version) of the game or the launcher for testing/debugging purposes, feel free to contact me and I may be able to help.

With the font fix, I got https://github.com/xivapi/ffxiv-launcher/ 's GUI to work but now it's running into the issue that the game can't detect DirectX at all, so it won't run. I made sure to install DX on that prefix as well as dxvk.
I couldn't get the launcher running under Proton 4.2-3 however. I think if I can do that, I might be able to at least launch the client. And if that works, then we can take a look at maybe forking a fully updated copy of the game for testing.

As an aside, the thread in the official tech support forums now has over 1,100 views in less than a day -- far more than most tech support topics in there. Square has to recognize that a big enough portion of their customers use Linux to warrant offering some minor support, surely?
It's not like we're asking them to make a native Linux client (tho it'd be great!).

With the font fix, I got https://github.com/xivapi/ffxiv-launcher/ 's GUI to work but now it's running into the issue that the game can't detect DirectX at all, so it won't run. I made sure to install DX on that prefix as well as dxvk.

I got past the DirectX error by running the installer for the game for the bundled DirectX installer, then cancelling installation after that gets installed. It needs a specific version of DirectX.

Now, nothing happens at all when I try to start the game. Presumably because it's not up to date, so it just coughs and dies.

@TenaarFeiri I wish it was that simple, but from experience Square will only act on something if a sizable portion of the Japanese playerbase raises the issue.

With the font fix, I got https://github.com/xivapi/ffxiv-launcher/ 's GUI to work but now it's running into the issue that the game can't detect DirectX at all, so it won't run. I made sure to install DX on that prefix as well as dxvk.

I got past the DirectX error by running the installer for the game for the bundled DirectX installer, then cancelling installation after that gets installed. It needs a specific version of DirectX.

Now, nothing happens at all when I try to start the game. Presumably because it's not up to date, so it just coughs and dies.

I had some really odd results with my tests with it at work on my laptop -- I could use the launcher to log in and launch the old game, but I couldn't connect to a data center.

When I copied the updated game from my Windows partition, I ended up not being able to open the game at all, ending up with the issue described in https://github.com/xivapi/ffxiv-launcher/issues/11 (though I didn't try and test with DX9 -- I just got the same error he mentioned for the DX11 part).

Because it was easier to work with, I was messing around with my Lutris wine bottle, just piping it through my system's wine (staging -- I forget what version exactly but I can pull it if it interests someone) itself. When I tried to launch it through the version of Wine Lutris had installed (I think it was tkg?) the XIVAPI launcher wouldn't even come up.

So the patching itself is done by ffxivupdater.exe, trying to figure out if there's a way to force it to run directly. According to Process Explorer on Windows in a VM, it's just passed a token, but giving it the same token on Linux doesn't seem to start it up.

Or not, the launcher is downloading the patches and the updater is updating them...

Well, I can't get Wireshark to not hang in a VM so I'm about to give up. Sub ends in a couple of days, hopefully someone comes up with a solution by Shadowbringers.

My solution for now will just be to use the PS4 version. I'm glad now that
I got the console version as a backup. But it's not ideal at all and it's
frustrating to be unable to play on the platform I prefer :(

More information here https://forums.lutris.net/t/final-fantasy-14-wont-start-after-latest-update-dxvk/5598/7

Could it help?

@TenaarFeiri The fact that it gives an mshtml error for them proves that it's trying to use the IE-based browser frame and not CEF, i.e. that the BrowserType setting is ignored.

I redirected the frontier.ffxiv.com domain to my server using the hosts file and I put /version_4_0_win/index.html and /version_4_0_win/version_4_0_win/index.html on my server. The launcher accesses both files, but stays black after that. If I move /version_4_0_win/index.html or /version_4_0_win/version_4_0_win/index.html on my server, I get the regular 404 error.

@exolyte I'd be curious if the launcher would attempt to access both files from a Windows machine. I dumped the launcher process memory and found several instances (10+ each) of both the single version_4_0_win and it doubled up.

When I get home, I'll try to see if I can find both URLs when the launcher is run under Windows

Memory dump of the launcher running under Windows has no instances of https://frontier.ffxiv.com/version_4_0_win/version_4_0_win/index.html only 21 instances of https://frontier.ffxiv.com/version_4_0_win/index.html

So, it seems WINE is messing up string manipulation somewhere but it sounds like that isn't the only issue the launcher is running into if it just results in a black window.

@lesderid It might not be ignoring it, it's possible it's just falling back to mshtml when initializing cef fails.

Also, do we know if it's the launcher itself calling CoInternetCombineUrlEx or mshtml calling it on it's behalf?

Seems Square maybe directly attacking Linux Proton users

// ユーザーエージェント
userAgent: {
    name: "",// JSP,header.htmlにて代入
    Type: {
        WIN: "windows",
        PS4: "playstation 4",
        PS3: "playstation 3",
        MAC: "mac"
    },

    is: function(type) {
        return Browser.userAgent.name === type;
    }
},

This could be the reason why we are getting a blank screen. Just dove into the Ecma they are using. Look under Browser and luancher code base via the debugger, they seem to be doing something fishy in the Login by disabling the login parts of the screen if you are running on anything not on that list.

@ArulinTheUnicorn I doubt they're going out of their way to directly attack Linux users. Wine's MSHTML should be sending a Windows user agent anyways (Wine "implements" Windows) if it's not, it's a bug in Wine.

However, I get a black screen when opening the page on any normal desktop browser, including IE11 on Windows. So if we can figure out how to force the site to display on a normal browser, it might help getting the launcher to work too.

However, I get a black screen when opening the page on any normal desktop browser, including IE11 on Windows. So if we can figure out how to force the site to display on a normal browser, it might help getting the launcher to work too.

You are thinking along the same lines I am. This seems to be more of a intentional action by Square Enix then a bug

@jbal91 I checked with WINEDEBUG=+loaddll, it doesn't try to load libcef.dll.

Edit: it loaded these on my machine: https://pst.moe/paste/deyccu

@jbal91 I checked with WINEDEBUG=+loaddll, it doesn't try to load libcef.dll.

That interesting....Either that DLL is buggy or is a red herring

attachment.txt
This is @lesderid 's paste, in case someone stumbles upon this issue 2 years from now and pst.moe no longer exists.

@jbal91 I checked with WINEDEBUG=+loaddll, it doesn't try to load libcef.dll.

That interesting....Either that DLL is buggy or is a red herring

strings ffxivlauncher.exe | grep libcef.dll matches, so it's referencing that dll somewhere even if it doesn't actually try loading it.

strings ffxivlauncher.exe | grep libcef.dll

If it not getting loaded and the BrowserType is being ignored then that might be the issue and not Wine.

The code to load libcef.dll still exists, AFAICT it's just a matter of somehow making it reach that code path. I already tried disabling the IE DLLs (through winecfg), but that just made the launcher fail early on.

It's possible they hard-coded it to only run on the Mac version or something like that. (They might be using the same executable on macOS, as the code of the launcher checks for some functions exported by TransGaming DLLs.)

The code to load libcef.dll still exists, AFAICT it's just a matter of somehow making it reach that code path. I already tried disabling the IE DLLs (through winecfg), but that just made the launcher fail early on.

It's possible they hard-coded it to only run on the Mac version or something like that. (They might be using the same executable on macOS, as the code of the launcher checks for some functions exported by TransGaming DLLs.)

Mac versions are having similar issues so I heard on the official forums

http://forum.square-enix.com/ffxiv/threads/388198-MAC-Launcher-white-screen-A-system-error-has-occurred-7-HTTPS-System-Error

strings ffxivlauncher.exe | grep libcef.dll

If it not getting loaded and the BrowserType is being ignored then that might be the issue and not Wine.

I mean, Wine's MSHTML being buggy is the reason why we needed BrowserType=2 in the first place. If we can somehow get MSHTML able to work with the launcher, that'd be the ideal solution because it might also fix other apps/games

@ArulinTheUnicorn That post is from the 20th, before the patch was available. It's coincidental, but unlikely to be related.

The page does nothing in a real browser because window.external.user(...) does not exist, and they're squelching the exception so you don't even get an error in the log.

Well, I've managed to hammer a version of this python launcher together that lets me launch the game directly through wine, but I'm hit with some lies. I promise, none of that's true -- but I've no idea how to convince the game of that, given the Mog Station knows I'm innocent.

I'm also in over my head and have no idea what I'm doing, but figured I'd share what I've got, even if it's still broke.
Edit to add: I don't know how this will deal with un-updated versions of the game, I copied my updated windows version over to see if I could use it to get in.

Well, I've managed to hammer a version of this python launcher together that lets me launch the game directly through wine, but I'm hit with some lies. I promise, none of that's true -- but I've no idea how to convince the game of that, given the Mog Station knows I'm innocent.

I'm also in over my head and have no idea what I'm doing, but figured I'd share what I've got, even if it's still broke.
Edit to add: I don't know how this will deal with un-updated versions of the game, I copied my updated windows version over to see if I could use it to get in.

Same lies happen when I tried to run the 64-bit boot executable that seems to load into the folder (running Lutris version) Except the lies happen in the launcher saying I need to use a CD key. Granted the 64 bit launcher is a lie in its own right and shouldn't be used but thought it might be food for thought. I messed with the python script a bit as well since it didnt run under Python 3 but eventually gave up trying to convert and resolve issues when I came across one that went over my knowledge of python. coding. (I enjoy trouble shooting but skill level I am a novice in both programming and linux)

I installed linux during this patches downtime to get away from Windows 10. It is just my luck that this happens. Actually its always my luck, getting things to function whenever I try to move to Linux is never fun. Granted I am a user, so I am at the mercy of a community.

Poster of the Reddit thread here... I'm no closer to working out what's going on, but I did update the Reddit post with the latest from this thread.

Someone mentioned that libcef.dll was updated with this patch, but I compared the libcef.dll in this version with a version of FFXIV on my Windows OS that hasn't been updated for ages and it appears to be exactly the same:

sophie@home ~/ffxiv-new/wineprefix/drive_c/Program Files (x86)/SquareEnix/FINAL FANTASY XIV - A Realm Reborn/boot $ ls -l libcef.dll "/mnt/e/Games/SquareEnix/FINAL FANTASY XIV - A Realm Reborn/boot/libcef.dll"
-rw-r--r-- 1 sophie sophie 24992336 Apr 24 05:32  libcef.dll
-rwxrwxr-x 1 mounts mounts 24992336 Jul 28  2018 '/mnt/e/Games/SquareEnix/FINAL FANTASY XIV - A Realm Reborn/boot/libcef.dll'
sophie@home ~/ffxiv-new/wineprefix/drive_c/Program Files (x86)/SquareEnix/FINAL FANTASY XIV - A Realm Reborn/boot $ sha256sum libcef.dll "/mnt/e/Games/SquareEnix/FINAL FANTASY XIV - A Realm Reborn/boot/libcef.dll"
3dedbde8ebf98aa667300f0d8b78d6a886abf00b517a297bf00f120e31f17fe0  libcef.dll
3dedbde8ebf98aa667300f0d8b78d6a886abf00b517a297bf00f120e31f17fe0  /mnt/e/Games/SquareEnix/FINAL FANTASY XIV - A Realm Reborn/boot/libcef.dll

This is definitely a change in the launcher, not in CEF.

@Sophira Oh, I guess it wasn't changed then. The update did overwrite it for me though: stat libcef.dll outputs Modify: 2019-04-23 17:48:28.693396317 +0200 for me.

Edit: Looks like all files in the boot directory get rewritten when you update the launcher.

Does anyone happen to have a version of ffxivlauncher.exe from the previous update? (Maybe someone who hasn't run the launcher yet?) I'd like to do some digging and see what changed.

Iii have an old one from September 1st if you'd like? http://etherelements.com/ffxivlauncher.exe

I pulled the previous launcher from backup and forced it to run by swapping boot directories during the boot version check, and I can confirm it still displays the login UI properly with BrowserType=2 (I haven't tried actually logging in just to be safe). So one assumes that by fixing Wine's mshtml (or maybe somehow modding it to use that libcef.dll?) the login flow would work again.

Interesting observation - the 64-bit launcher from the previous version does not work even with BrowserType=2, giving the same 404 error as the 32-bit launcher gives now. So I suspect SQEX may have been planning to drop this functionality for a while, and may have killed it in the 32-bit launcher now as a kind of trial balloon to see how many people would be affected, since 5.0 will apparently be dropping 32-bit support entirely.

All worlds emergency maintenance just got announced, for 12:00am PDT tonight (~1.5 hours from now): https://na.finalfantasyxiv.com/lodestone/news/detail/d4c5bb45f1d8c550093b4d9d8da19c5dce13e463

Fingers crossed it fixes the Linux problems. Even if it's unintentionally.

Also, I tried @HereInPlainSight's custom launcher fork after copying the updates from Windows, got to the main menu, and ran into the same error as him, saying I'm not subscribed. I also tried the custom launcher at https://github.com/goaaats/FFXIVQuickLauncher and got the same thing (after installing a bunch of .NET stuff). Feels like there's some piece of authentication that's not happening there, or something.

All worlds emergency maintenance just got announced, for 12:00am PDT tonight (~1.5 hours from now): https://na.finalfantasyxiv.com/lodestone/news/detail/d4c5bb45f1d8c550093b4d9d8da19c5dce13e463

Fingers crossed it fixes the Linux problems. Even if it's unintentionally.

Likely has to do with all the world visit issues, so I wouldn't get my hopes up.

I'd also like to quickly remind everyone to stay positive and to not jump to any conclusions before we know exactly what's going on. <3

As other's have pointed out, what we do know is that they will 1) drop 32-bit support, 2) force steam users to authenticate through steam. It's almost certain that we linux users got caught in some technical crack here.

Regarding the maintenance. At least the login server has not been down at all during the maintenance window so far, unless I missed it.

Looking at the official tech support forums, it seems more people are having problems after the launcher update. I've seen plenty of people being able to get in, but it's at least comforting to see that some Windows users are also having trouble.
Maybe there's hope that Square might finally look at it ;)

It doesn't look like there was a patch to the game or launcher after maintenance

No patch. HTTPS error continues to bedevil us; just tested.

Somebody said something about Transgaming, so I tried adding an IsTransgaming function to Wine: https://gist.github.com/achurch/3d01aad515b1784c671637018f076ecd

This lets the launcher start up (so the libcef code is in fact still live), but once you actually log in you get that "no service account" message. I wonder if IsTransgaming makes the launcher think it's running on a Mac, so the server checks for a Mac service account?

In any case, this still only works on the 32-bit binary, so however useful it is, it's only good for another couple of months - beyond that we need a proper fix to Wine's mshtml.

Is there any decent way of incentivicing someone to look into fixing mshtml for this issue?
And does anyone have any SE contacts where we could get some of this information properly confirmed?

I guess ask on wine-devel? I'd look into it myself but I'd be starting from zero knowledge on any of mshtml, wine-gecko, or libcef. (I actually tried building wine-gecko just now and it died almost immediately; the fact that it's so old and apparently now broken might be a good argument for reimplementing mshtml on top of libcef, for example.)

And to be fair, I don't know that the the bug(s) are only in mshtml, or in mshtml at all; that just looks like the most likely culprit at the moment.

if we can get it working by patching wine to say it's transgaming, maybe we can patch the executable to check for a steam service account regardless?

While that could be a potential workaround, figuring out exactly what's going wrong (likely within wine) and get those issues ironed out would be much better.

It's also important to remember that we'd have to make sure it could check for both steam and standalone windows license.

yeah i agree, patching the executable is definitely not the approach we want

If we could make a temporary launcher that would tell the client what it wanted to know though, that would be a decent bandaid, sadly I lack the expertise to pursue that.

Additional data point: I patched Wine to load the previous version of ffxivlauncher.exe (the one which worked fine up until the last update) when the current version was requested, and that also results in a "no service account" error. But if I log in from a true Windows machine, it works fine. I suspect something changed in the login flow and only the mshtml side of the Windows launcher supports the new flow, with old-flow logins being treated as Mac or possibly even "invalid platform". (Perhaps they disabled BrowserType checking just to save themselves the effort of updating the libcef code which was due to be retired anyway.)

My Windows machine actually has a better GPU than my Linux box, so maybe SQEX is trying to help me out?

Huh, that's very interesting. So the only realistic, decent option is to get focus on mshtml.
I made a bug report on the wine bugzilla, as mshtml would be rather technical https://bugs.winehq.org/show_bug.cgi?id=47069

Got around to testing a custom launcher on Windows, and it works fine! If we manage to replicate the work in https://github.com/goaaats/FFXIVQuickLauncher/ and make it work in wine we should have a bandaid.

Since the url that the patcher loads can be opened in a regular browser and shows a black screen there as well perhaps we could start by figuring out the cause for that? With the debugging tools available there it shouldn't be difficult... for someone with a clue about all the javascript/css stuff.

Does the mentioned "no service account" error appear within the launcher or does it come from the actual game executable (ffxiv_dx11.exe)?

Huh, that's very interesting. So the only realistic, decent option is to get focus on mshtml.
I made a bug report on the wine bugzilla, as mshtml would be rather technical https://bugs.winehq.org/show_bug.cgi?id=47069

Got around to testing a custom launcher on Windows, and it works fine! If we manage to replicate the work in https://github.com/goaaats/FFXIVQuickLauncher/ and make it work in wine we should have a bandaid.

I mean yes, but apparently, no.

So here's something I don't really understand. I took the updates I made to the launcher I mentioned yesterday (that, to reiterate, do not work in Linux and talk about a service account issue -- it's a pic in my last post) and I ran in it Windows.

And I do not get the error, I just logged in with the little Python launcher. Same code (I commented out a line that supposedly causes a crash in Windows, but all it does is center the launcher box), different results, sole worthwhile difference is it works in Windows, not in Wine.

And I do not get the error, I just logged in with the little Python launcher. Same code (I commented out a line that supposedly causes a crash in Windows, but all it does is center the launcher box), different results, sole worthwhile difference is it works in Windows, not in Wine.

That's really, really interesting indeed. Does activating "Hide wine version" do anything (in-case they are somehow checking specifically for wine)?

So the python launcher works on windows? Could you try running the python launcher on windows and let it print the command it would execute, then run that command on Linux? If you still get the error then we have yet another problem as that would mean that ffxiv.exe is also doing something different on wine.

Since the url that the patcher loads can be opened in a regular browser and shows a black screen there as well perhaps we could start by figuring out the cause for that? With the debugging tools available there it shouldn't be difficult... for someone with a clue about all the javascript/css stuff.

Does the mentioned "no service account" error appear within the launcher or does it come from the actual game executable (ffxiv_dx11.exe)?

Huh, go to https://frontier.ffxiv.com/version_4_0_win/index.html. Most of the elements have a class of "Hide". If you remove said classes the launcher partially renders in normal browsers too. Are they somehow starting it all with DIsplay:None and then unhiding with some kind of javascript magic??

by the way, it appears to be just some css that's hiding the ui when you navigate to the page in a browser. i don't know exactly, but is it possible it's looking for some user agent or similar in order to display the ui?

Does not seems to be based on user agent.Likely somehow trying to check if it's ran from a proper install before unhiding?

if we figure out what conditions it wants before unhiding, that may give us some clue as to why it isn't doing that in wine

There certainly is a lot of javascript involved there that will toggle on/off those elements. At first glance i didn't find any OS detection or such nor did the firefox console throw any obvious errors.

But if we can figure this out it might help in our quest of making the launcher work a little more.

So the python launcher works on windows? Could you try running the python launcher on windows and let it print the command it would execute, then run that command on Linux? If you still get the error then we have yet another problem as that would mean that ffxiv.exe is also doing something different on wine.

I already switched back to Linux -- and... Hiding wine version... and I'm on my character select screen.

It occurs to me that if their Mac version uses a specialty wine wrapper, and hiding Wine from them lets us in, and not hiding Wine gets us told we don't have a service account...

They think we're Mac users.

What are you doing to hide the wine version? This could be our workaround then if the python launcher along with this gets us in.

I'm doing a WINEPREFIX=<path-to-prefix> winecfg . It's under the Staging tab. Again, due to this being easier for me to test, I'm using my lutris install, and not specifically steam's version yet.

Admittedly, I'm on my laptop trying to run the DX11 version, so it's not pretty (alright, it's pretty but it's a slideshow), but I'm able to get in game.

I hid WINE version and still get the same error.

So, time for a quick summary?

1. Wine parses the url incorrectly, hence a custom patch is needed to fix this issue
2. With the custom url patch the launcher is rendered black and unusable. mshtml issue?
3. If you manage to get into the game with any of the custom launchers you'll get errors related to your service accounts
   3.1. This can however be worked around by hiding wine version. They believe we are Mac users.

Please correct me if any of the statements are wrong or if I left out something important.
The fact that they believe we are mac users should be something SE is willing to fix, hopefully?

I hid WINE version and still get the same error.

Not entirely sure what to tell you. :/

3. 3.1. This can however be worked around by hiding wine version. They believe we are Mac users.

To be clear, this is conjecture on my part, but if what people say about the Mac client is true, and we're being told we don't have service accounts... it seems plausible. If we have someone with a Mac license, we can find out fairly quickly if that's what's happening.

Confirming that I can also get to the character select screen if I activate HideWineExports from the "ntdll-Hide_Wine_Exports" staging patch. (key HKCU\Software\Wine, string value HideWineExports, value "1")

@HereInPlainSight would it be possible for someone to make a trial account for the Mac version, then try it in Wine on Linux? I'd try myself but I'm currently logged in attempting to grab a house, and can't reboot back into linux for the time being.

logged in attempting to grab a house

Oh frak me.

@achurch to be clear, you're using a 3rd party launcher for that?

Did anyone get the proper launcher to work with the wine patch for the url (+ browsertype 2?) If yes, then we have workarounds for all issues, without the need for custom launchers!

I used the official launcher from the previous version, with BrowserType 2. I suspect (but haven't confirmed) that the current version launcher with the IsTransgaming patch would also work; when I tried earlier, I didn't see any calls to IsTransgaming from ffxiv_dx11.exe so I don't think that would trigger a Mac identification (edit: but of course it's possible the launcher also does platform detection).

I tried to get the patch into a clone of proton, but I'm too new at this to do the patching. Total failure ;)

I'll try to patch wine with both the isTransgaming patch and the wine patch (https://bugs.winehq.org/attachment.cgi?id=64251) when I get home and see if either helps.

Awesome!
Question: has anyone tried with an older version of gecko? If that is even possible?

So I figured I know my luck and I'll never get a house anyway. I made a Mac trial account and tried to log in via The Python Method (makes it sound all fancy-like), but I'm hitting a wall where I'm failing the login where the original code even says 'This will fail with a 401 error for someone with an expired subscription'.

I'm getting a 401 error, so I guess there's something extra necessary to say you're a trial account.

Trials accounts have specific trial version of the game, so you'll have to install the trial version :)

Trials accounts have specific trial version of the game, so you'll have to install the trial version :)

Oh, well, that complicates and possibly taints the testing process, does it not?

It'd be best if we had someone with a retail Mac license to test it, as then it's all guaranteed the same everything -- including client.

most of the patches needed for ntdll-Hide_Wine_Exports do not apply on the version of wine in proton and will have to be modified to fit

After adding the IsTransgaming patch and removing the wine_get_version exports i was able to fully update the game and login.

So this seems to come down to two main issues with this update:

• The patcher now ignores the BrowserType setting and only uses libcef if the IsTransgaming function is found.
• ffxiv.exe checks for the wine_get_version function and reports it as a MAC login if found.

I guess for the time being we can get around both issues relatively easily however the Launcher could become a larger issue if they eventually remove libcef completely. Although as long as they support the MAC version that seems unlikely.

The patcher now ignores the BrowserType setting and only uses libcef if the IsTransgaming function is found.

... and returns 1 at a specific point in the startup sequence. The function in the patch returns true on only the second call because if I make it return true all the time, the launcher crashes on startup (probably trying to set up some Transgaming-specific data which doesn't exist because I haven't implemented any other TG-specific functions).

[...] if they eventually remove libcef completely. Although as long as they support the MAC version that seems unlikely.

I wouldn't be so sure about that; remember that 5.0 will drop 32-bit support, and the 64-bit launcher doesn't use libcef at all. I saw a couple of Mac support threads on the forum suggesting that in at least some cases, the Mac launcher uses native HTML rendering, like mshtml on Windows. So this is probably something that needs to be addressed on the Wine side sooner rather than later.

Unfortunately this doesn't help me right now since I run Proton and my regular WINE installation is being very bothersome. I may not even be able to use a non-steam client.

I know it's a big ask, but I don't suppose you could fork the latest Proton release and see if you could patch it in? The truth of it is I'm just a regular Joe; this stuff here is kind of way above my skillset.
I'm pretty sure I remember how to use a custom Proton version. I recall I had to install one for Elite: Dangerous.

Can confirm that the transgaming patch & HideWineExports works here.

I was using proton-tkg to achieve that

not sure how to use proton-tkg to be honest

I was adding the transgaming patch to PKGBUILDS/wine-tkg-git/wine-tkg-userpatches and replaced the file extension with .mypatch

Then I just executed the proton-tkg script and it built everything for me.

Where do I get a hold of the IsTransgaming patch? Google is failing me.

EDIT: Was buried and hidden above. Think I got it. Let's see how proton-tkg works...

I'm leaving this here.
I was looking forward to make a specific Linux alternate launcher.
Did't get enough informations to do that but maybe I can leave what I got here :

1/ Steam launch ffxivboot (which I want to replace) given the -isSteam option
FF XIV launcher . exe

FFXIV boot get his update information by querying this webpage :
http://patch-bootver.ffxiv.com/http/win32/ffxivneo_release_boot/[Current Boot Version, example : 2019.04.19.0000.0001]/?time=[Current time in AAAA-MM-DD-HH-MinMin format]

During this step, the user agent is "FFXIV PATCH CLIENT".

The page response is contained in the HTTP header "X-Latest-Version" which return the last boot version.

I didn't get where it get the last version (the communication was encrypted in TLS)

2/ Getting interface data

2.1 / The actual interface is obtained by displaying the file :
https://frontier.ffxiv.com/version_4_0_win/index.html?rc_lang=[LANG]&time=[TIME IN FORMAT AAAA-MM-DD-HH]

The user agent used is : SQEXAuthor/2.0.0(Windows 6.2; ja-jp; [A NUMBER])

You instantly get a cookie named "s" which does not seems to be needed for the launcher usage.

2.2/ The world status is get in a JSON format by querying this webpage :
https://frontier.ffxiv.com/worldStatus/login_status.json?[TIMESTAMP in ms]

2.3/ The news are available in a JSON format by querying this adress :
https://frontier.ffxiv.com/news/headline.json?lang=[LANG]&media=pcapp&[TIMESTAMP in ms]

2.4/ The different server states are avalaible by querying this adresse :
https://frontier.ffxiv.com/worldStatus/current_status.json?[TIMESTAMP in ms]

It seems that the value 3 means maintenance (as it was when I was trying this)

3/ Login

The login form in stored in this webpage.
https://ffxiv-login.square-enix.com/oauth/ffxivarr/login/top?lng=fr&rgn=3&isft=0&issteam=1

There is a "issteam" variable.
I don't know to what rgn and isft refers.

The user agent is important : SQEXAuthor/2.0.0(Windows 6.2; ja-jp; [A NUMBER])

In the form there is :

• Input hidden name "_STORED_", containing an id (which seems to not change between login session, I don't think that it is a token)
• Input name "sqexid" containing id
• Input password "password" containing password
• Input otppw for otp password

It targets : https://ffxiv-login.square-enix.com/oauth/ffxivarr/login/login.send

So to get logged you need to realize a POST request to https://ffxiv-login.square-enix.com/oauth/ffxivarr/login/login.send with the _STORED_, sqexid, password +/- otppw values.

In the response page, there is a javascript execute command which contains many variable including something that seems to be a token.

4/ The post-login part

That's where I don't get everything.

4.1/ Version check

It seems that the boot exe launch "ffxivlauncher.exe" only after login, I got that by doing some process monitoring.
With which argument ?
ffxivlauncher.exe reclaims to be launch from ffxivboot.exe, does it need a specific argument ? Or does it realize a parent process check ?

A request is done to check for last update, I got that from the other launcher source code, as it was encrypted queries.
It is done by querying this adress :
https://patch-gamever.ffxiv.com/http/win32/ffxivneo_release_game/[CURRENT GAME VERSION]/[TOKEN OBTAINED PREVIOUSLY]

In the request body, it is needed to specify the current filesize and sha1 of ffxivboot.xex, ffxivlauncher.exe and ffxivupdater.exe. And their 64 bits equivalents.
That give us that :
"ffxivboot.exe/filesize/sha1ofthefile/ffxivboot64.exe/filesize/sha1ofthefile,ffxivlauncher.exe/filesize/sha1ofthefile,ffxivlauncher64.exe/filesize/sha1ofthefile,ffxivupdater.exe/filesize/sha1ofthefile,ffxivboot64.exe/filesize/sha1ofthefile,ffxivupdater64.exe/filesize/sha1ofthefile/"

It is sent as a raw text.
The user agent is important : SQEXAuthor/2.0.0(Windows 6.2; ja-jp; [A NUMBER])

It returns an X-Latest-Version which is the last version id and X-Patch-Unique-Id which is the UID of that version (which change a each request).

What is this UID needed for ?

4.2/ Update downloader

Update are downloaded from square server.
The download URL are static and don't seems to change.

I recorded that before downloading the file, the server received a request at :
http://patch-gamever.ffxiv.com/gen_token

With "FFXIV PATCH CLIENT" user agent and an "X-Patch-Unique-Id" variable in the header.
This one seems to be the one obtained previously.
In that request, the body contains the URI of the update file.

It answer with the exam same URI.

I didn't get what does this step stand for. Is it used to log the user updates downloads ?
The update files were downloadable with or without doing that step.

I didn't get where it gets the update files URI. But as they are static I can easily replace it by a link registry.

4.3/ Update install

That's my main obstacle.
The updates files are a .PATCH file which does not correspond at an archive file.
The file is described in his header as a "ZIPATCH" file.

Which process integrade this update to the game ?
If you have information about that it would great as it is to me main obstacle for realized a full working linux portal.

5/ Ultimate check

The launcher verify the "gate statut" at :
https://frontier.ffxiv.com/worldStatus/gate_status.json?lang=fr&[TIMESTAMP in ms]

Then the game in launched.
I didn't get how but it seems to have already been determined by the other launcher authors.

TL DR version :

• Trying to make a linux specific launcher to get rid of the official one
• Need to determine how the actual one get the update URIs (but that is not blocking)
• Need to determine how is done the actual update process

@achurch

... and returns 1 at a specific point in the startup sequence. The function in the patch returns true on only the second call because if I make it return true all the time, the launcher crashes on startup (probably trying to set up some Transgaming-specific data which doesn't exist because I haven't implemented any other TG-specific functions).

Thanks for figuring that out! We got lucky with that implementing the IsTransgaming function was enough to get it to work.

I wouldn't be so sure about that; remember that 5.0 will drop 32-bit support, and the 64-bit launcher doesn't use libcef at all. I saw a couple of Mac support threads on the forum suggesting that in at least some cases, the Mac launcher uses native HTML rendering, like mshtml on Windows. So this is probably something that needs to be addressed on the Wine side sooner rather than later.

Yeah, this is an ugly hack at best. The only legitimate way forward is fixing the urlmon and mshtml implementations and hoping that planned future update requiring Steam auth won't cause any issues.

Edit:
@alibell

I don't know to what rgn and isft refers.

I assume 'region' and 'is free trial' respectively.

Some more info on the launcher and updater is available here: http://ffxivclassic.fragmenterworks.com/index.php?controller=post&action=view&id_post=30. As the name of the site suggests it's mostly about 1.0, but it seems some of this still applies to 2.0+.

I was adding the transgaming patch to PKGBUILDS/wine-tkg-git/wine-tkg-userpatches and replaced the file extension with .mypatch

Then I just executed the proton-tkg script and it built everything for me.

Well that was a bust; apparently something called "makepkg" wasn't found and I can't seem to find which library adds it.

can someone share a proton build with the patches? i'm trying to get wine-tkg working but am having trouble

apparently something called "makepkg" wasn't found and I can't seem to find which library adds it.

makepkg is for building packages on arch linux

apparently something called "makepkg" wasn't found and I can't seem to find which library adds it.

makepkg is for building packages on arch linux

I see! I'm currently running Pop_!OS (so Ubuntu/Debian-based). I guess I can't run the proton-tkg.sh script then?

TL DR version :

• Trying to make a linux specific launcher to get rid of the official one
• Need to determine how the actual one get the update URIs (but that is not blocking)
• Need to determine how is done the actual update process

I don't currently have access to an install that's not updated, but when I briefly bashed the launcher I duct taped back together against an older install at home I hadn't updated I _believe_ it spat out the update file locations, so the source there might be able to help. Check login.py for 'patch_url'.

I see! I'm currently running Pop_!OS (so Ubuntu/Debian-based). I guess I can't run the proton-tkg.sh script then?

You'd have to deal with the Debian build system.

In the near future we need to look into getting the patches into a Lutris build (Lutris has Wine builds with fixes for specific games, in addition to various flavours of Wine.)

Despite the documentation on the ntdll-Wine_Hide_Exports, it appears to be independent of anything else in staging, and I imagine the dependency list is only because of colliding patches to ntdll_misc.h. I'm building now to test, but it looks like you should be able to apply the loader.c part of ntdll-Hide_Wine_Exports, and manually insert the added lines in ntdll_misc.h.

(FYI, I'm using vanilla Wine with a few selected staging patches, not Proton, so I'll have to leave Proton build directions to others.)

I think I'll just wait for Valve to patch it into Proton then. But at least I'm glad to hear all hope is not lost. =D
Hopefully it'll go fast now we seem to have a workaround.

I'm pretty sure this is too hacky to be included in official builds of Proton.

I wouldn't expect to see the IsTransgaming patch in official Proton/Wine anytime soon, it is far too hacky for that. Unless very patient you might want to try your luck with Lutris or a custom wine build.

Well, the stonewalling begins. We are having to hack around a seemingly intention block against Linux users. Valve needs to show a stance here. Hacky patches and make shift launchers are not the stance I wish to make. I want Square to "bleed , just like me" ~ Deadman's Wonderland

Well, the stonewalling begins. We are having to hack around a seemingly intention block against Linux users. Valve needs to show a stance here.

This is definitely not intentional. Strange and even straight up dirty programming/porting choices, sure, but it's not an attempt to block linux.

I doubt this is specifically targeted at Linux users. Far more likely they were making changes for MAC and since they don't test on Linux unintentionally introduced issues for us, but that is to be expected with no official support.

Yeah it'll work on Lutris for now (when the build comes), but not in the long term. When Square finally locks me out of non-Steam copies of the game, if Proton doesn't do the trick then I can't play!
I'm not even upset at Valve even if they don't implement the IsTransgaming hack; I'm mostly just upset with Square that they have to be so difficult. Especially when the game itself isn't the problem; it's just the launcher being screwy.

yeah we have no evidence that this is intentional, just because it broke in a weird way. square enix has never officially supported linux or proton so obviously they just didn't realize it might break like this. they have no obligation to us, we're making our own path.

This is almost definitely them changing how the Mac client does things in preparation for the removal of 32-bit support and us getting caught in the middle of it

The good news is, as long as SE continues supporting the Mac client this way, we can probably just emulate more of Transgaming if this breaks in the future (even if it might mean buying Mac licenses)

The really silly thing is, why are they using IsTransgaming to detect Mac in the launcher, but looking for Wine exports in the actual game? Ironically, if they used IsTransgaming for both, it'd be more difficult to work around without needing a Mac license

Yeah, it's really silly, but I'm fine with paying for a mac license when the time comes and they fix that :)

It also makes me wonder if the Mac FFXIV players can modify their game to hide wine and hence count as a windows version

Tbh I never really understood why we have to have different licences for different platforms to begin with. It makes no sense for a subscription-based MMO. I guess for money reasons, but even so!

We will see, someone on here said they cannot find in the ECMAscript of the useragent checks. Browser.js lines 60 to 72....Pretty clear there. As for LibCEF and MAC support, since MAC is using a custom Wine layer the hope is that we can piggyback on it. If this is the best we can hope for, I suggest looking at LostArk when it hits Russia.

The mere fact that they are trying to control licensing in a more strict fashion should tell of the plan and the intent. If you cannot figure that out then you should sheep tort back to Windows.

Update: I could careless if you like this or not, it the fact of what the code is saying

there is zero evidence that this is malicious. things break, especially when they are not officially supported. it happens, and we'll work around it.

Yeah, man. Shit happens.

there is zero evidence that this is malicious. things break, especially when they are not officially supported. it happens, and we'll work around it.

If the code is not enough proof then what would be? A direct confession from Yosuke Matsuda? This is why we have Trump in office and Title 2 Network neutrally barely got off the ground. No one has any backbone to stand up and say no anymore. Since that the case, I will bow out and can my sub.

HideWineExports patch applied to Proton's Wine fork, for those who want it: https://github.com/achurch/proton-wine/commit/e77d4e14f42aa3721480a2ea6cdb713f4e5aceb4

I haven't actually tested the behavior, but it's a straightforward patch and it builds cleanly, so I'd be surprised if it didn't work.

I haven't added the IsTransgaming patch because that's a very kludgey fix which shouldn't stay around, but it should apply cleanly.

If the code is not enough proof then what would be?

there is no code pointing to this being malicious, and this is offtopic.

Tbh I never really understood why we have to have different licences for different platforms to begin with. It makes no sense for a subscription-based MMO. I guess for money reasons, but even so!

They probably have to for Steam and PS4.

Tbh I never really understood why we have to have different licences for different platforms to begin with. It makes no sense for a subscription-based MMO. I guess for money reasons, but even so!

They probably have to for Steam and PS4.

To make more money. No they do not have to for Steam or PS4. The sub system is hosted and managed by Square Enix. They may say that is the reason but look at Aura's Kingdom. You can download the non-steam or steam version but log in on the same account, no need for blocking. That is just smoke and mirrors. But yes I will say it getting a bit side-tracked to a degree. The reason behind this code is quite blunt even if there are those who stick their heads in the sand. Hope it gets a another patch, then another patch after that, and another just to avoid Square's business plan. That what has all of this going on, plain and simple of it. Jbal91, I am a Principle Engineer by trade, I WRITE SHIZ LIKE THAT FOR A DAMN LIVING! I know the corporate mind because I am in it at neck level. So please pull your head out of your daisy chain... That goes to the rest who believe this is just some mistake.

can we quit talking about this? it's totally irrelevant to the topic at hand.

Back on topic, it's kind of unfortunate they're specifically checking for Wine, because it means that sadly even if we fixed Wine's mshtml it would still think we're Mac users when we try to launch the game. That means it's unlikely it will ever work with vanilla wine/proton again.

i don't see why proton (and lutris) wouldn't merge the wine-staging patch to get the game working, since it isn't really that hacky anyway. as for mshtml, we'll have to figure out what exactly is wrong with it

If SE takes notice of this they might still change that check to use IsTransgaming instead. Otherwise disabling the wine_get_version symbols should be simple enough either by adding an registry option or just outright removing them from proton.

I've updated the Reddit post with all the information we have so far. Please let me know if I'm missing anything!

I wonder how difficult it'd be just to write a DLL that hooks GetProcAddress and returns 1 for isTransgaming, then we wouldn't need a custom wine build. We'd still need staging for hiding Wine though.

@jbal91 If FFXIV implements any kind of anti-cheat (or does in the future), then that would probably trigger it. Ideally, it would be best not to modify any of the FFXIV files, I think.

@jbal91 If FFXIV implements any kind of anti-cheat (or does in the future), then that would probably trigger it. Ideally, it would be best not to modify any of the FFXIV files, I think.

DXVK would already trigger it anyways

been trying to build proton with wine patches using the makefile but meson keeps complaining about things. not sure what the root issue is. if anyone can get it to build with all 3 patches please put it up somewhere to download? i'll keep trying in the meantime

Well, I managed to log in. I'll try and build a Proton release with Proton-tkg

i got it to build just now, had to destroy the entire vm and rebuild from scratch but the launcher works now. forgot to change the registry entry, doing that now

OK let's say hypothetically im baby and don't know what to do to get it working. I'm on Gentoo and have been running through Steam free trial but do not have the steam version and as I guess that's not going to be A Thing I Can Do Anymore Soon Probably, I wouldn't mind compiling and running my own Proton to run ffxiv if that's what it's going to take, but I'm not sure what I need to do and how to apply the necessary patches.

i will zip up the proton build once i confirm it works, you should be able to simply drop it in .steam/root/compatibilitytools.d

i've got stuff to do for a bit so it'll probably be at least an hour before i can confirm that

I have a working Arch package, just recompiling for Proton. Should have it up in a lot less than an hour if people can't wait, lol

I've waited a whole day, at least. I can wait a while longer =)
Potentially dumb question but: Do you suppose the arch package would work on Debian? WINE/Proton should be distro-independent right?

I really doubt it'd work on Debian without a chroot

Well I'm looking forward to giving it a shot nonetheless! :D
If it can work, I'll figure it out.

It built and launched but wasn't detecting DX11, I think because I winelib'd DXVK, trying again

how do i set the registry key, exactly?

winetricks hidewineexports=enable

Hello everyone. I just wanted to thank you all for your work on this issue.

You truly are amazing <3

okay it WORKS and i'll be zipping up the proton distribution now

https://mega.nz/#!PpVQUCwI!lWMwHYsKZtQ6WdGZbZ2UAqWpp-Iq1NlursEwKJt0R34

ahaha or @jbal91 will snipe me. i'll still put mine up tho, in case anyone wants to use that instead

took longer than it should have because I had to rebuild it.

You'll need to WINEPREFIX="$HOME/.local/share/Steam/compatibilitytools.d/proton_tkg_4.6.r0.g3f8edce5.ffxiv/dist/share/default_pfx" winetricks hidewineexports=enable to get to the character selection screen

And yeah, it needs to be extracted to "$HOME/.local/share/Steam/compatibilitytools.d"

Do you just add that to the launcher?

Tbh I never really understood why we have to have different licences for different platforms to begin with. It makes no sense for a subscription-based MMO. I guess for money reasons, but even so!

They probably have to for Steam and PS4.

To make more money. No they do not have to for Steam or PS4. The sub system is hosted and managed by Square Enix. They may say that is the reason but look at Aura's Kingdom. You can download the non-steam or steam version but log in on the same account, no need for blocking. That is just smoke and mirrors. But yes I will say it getting a bit side-tracked to a degree. The reason behind this code is quite blunt even if there are those who stick their heads in the sand. Hope it gets a another patch, then another patch after that, and another just to avoid Square's business plan. That what has all of this going on, plain and simple of it. Jbal91, I am a Principle Engineer by trade, I WRITE SHIZ LIKE THAT FOR A DAMN LIVING! I know the corporate mind because I am in it at neck level. So please pull your head out of your daisy chain... That goes to the rest who believe this is just some mistake.

It's one thing to put heads in the sand, it's another to have one's head on the moon. Neither are recommendable:

There being code talking about user agent means nothing in terms of filtering. Or there being filtering based on user-agent doesn't mean s.o. is out to "get" Linux users.

Maybe actually expose the so-called "anti-Linux" flow control before resorting to conspiracy:

Accept:           */*                                                                       
Host:             frontier.ffxiv.com                                                        
User-Agent:       SQEXAuthor/2.0.0(Windows 7; ja-jp; 7bf5f44656)                            
Referer:          https://frontier.ffxiv.com/version_4_0_win/index.html?rc_lang=fr&time=2019
                  -04-23-23                                                                 
Accept-Encoding:  gzip, deflate                                                             
Connection:       Keep-Alive                                                                

This is what the launcher through Wine actually sends down the pipe.

And the response body

Browser.userAgent.name = Browser.userAgent.Type.WIN;

The remote webservice identifies the Launcher as running on Windows.

You select it either as your default SteamPlay version, or specifically for FFXIV in properties (I recommend the latter)

Sorry, I was referring to the

WINEPREFIX="$HOME/.local/share/Steam/compatibilitytools.d/proton_tkg_4.6.r0.g3f8edce5.ffxiv/dist/share/default_pfx" winetricks hidewineexports=enable

You put that into "Set Launch Options" or need to do it differently?

Sorry, I was referring to the

WINEPREFIX="$HOME/.local/share/Steam/compatibilitytools.d/proton_tkg_4.6.r0.g3f8edce5.ffxiv/dist/share/default_pfx" winetricks hidewineexports=enable

You put that into "Set Launch Options" or need to do it differently?

no, you just execute that command once in terminal, and youre done

^ Just put it into the shell.

If you don't have Winetricks you can also do it via winecfg instead

Hello, I'm using wine-staging standalone. How would I apply the transgaming patch exactly?

No luck here, launches, then immediately closes.

@jbal91 Where do I put this ? I have no compatibility.d under ~/.steam/root Running Manjaro i3.

I tried pointing my existing Lutris install of the game to the new wine64 from jbal91's build, but it is failing to launch at all:

wine: failed to initialize: RIGIN/lib64/wine/ntdll.dll.so: cannot open shared object file: No such file or directory

I admit I'm not good with the finer points of WINE; am I missing something//is it possible to get this running with a Lutris install? I can get around to installing/trying with Steam itself later when I have some more time, but I wanted to test it out.

@sangoku116 create the folder ~/.steam/root/compatibilitytools.d/ and export everything there. Should end up with ~/.steam/root/compatibilitytools.d/proton_tkg_4.6.r0.g3f8edce5.ffxiv folder with everything in there, then go into steam and select that Steam Play version for FF14 only

I tried pointing my existing Lutris install of the game to the new wine64 from jbal91's build, but it is failing to launch at all:

wine: failed to initialize: RIGIN/lib64/wine/ntdll.dll.so: cannot open shared object file: No such file or directory

I admit I'm not good with the finer points of WINE; am I missing something//is it possible to get this running with a Lutris install? I can get around to installing/trying with Steam itself later when I have some more time, but I wanted to test it out.

From reading up on Proton with this issue I think Proton and Wine are not interchangeable. Proton does some checks with Steam specific stuff, so it won't be compatible with the win in Lutris

As far as I'm aware Proton and Wine are not interchangeable. I think Proton does some checks with Steam.

That would make sense. I'm probably mixing up people asking if/wanting it to work as a runner as it being one.

https://drive.google.com/open?id=1dLqEsHrRuBxau0Is4oEqSvSSvoRmBBwi

I tried both copying my existing install files over to the Steam directory for FF after letting Steam install the launcher, and clearing that and starting a fresh install without the data, both immediately aborted after clicking Play before even getting to the launcher at all.

Same error as my earlier attempt, wine: failed to initialize: RIGIN/lib/wine/ntdll.dll.so: cannot open shared object file: No such file or directory

https://drive.google.com/open?id=1dLqEsHrRuBxau0Is4oEqSvSSvoRmBBwi

Even after running
WINEPREFIX="$HOME/.local/share/Steam/compatibilitytools.d/proton_4.2-local/dist/share/default_pfx/" winetricks hidewineexports=enable

I get the no service account error.

But at least I got into the game, so one step further

I ran the command into a terminal, selected the file to run as protonffxiv and now my game does not launch. It launches when I select 4.2-3, but not the ffxiv one.

@sangoku116 did you use @ashkitten or @jbal91 build? I had the same issue with @jbal91 but not with @ashkitten

I'm encountering the same issue as @Undeadhunter, proton with @jbal91's proton enables the launcher to work flawlessly and patch the game, but I'm still receiving a no service account error (despite setting hidewineexports=enable in the prefix).

I used @jbal91 's build will try the other one.

worked perfectly for me, thank you very much! @ashkitten

Yeah, I think something might be funky with mine

@jbal91 think it's related to the name, steam is launching without the .ffxiv part of the folder name. Did you rename it perhaps?

Actually I got an error trying to connect to the data center. It says my game is not registered with my service account.

@sangoku116 what wineprefix did you use when running the command to enable hidewineexports?

for me what worked was WINEPREFIX=$HOME/.steam/root/steamapps/compatdata/39210/pfx winetricks hidewineexports=enable

for me what worked was WINEPREFIX=$HOME/.steam/root/steamapps/compatdata/39210/pfx winetricks hidewineexports=enable

Fixed it!

glad!

Still no luck here, checked WINEPREFIX=$HOME/.steam/root/steamapps/compatdata/39210/pfx winecfg and under Staging Hide Wine is checked.

Hello! I just wanted to chime in and say that I am using @ashkitten 's build (with hidewineexports enabled in the 39210 prefix), and I have successfully logged in, patched, launched the game, and connected to a character. So, it seems to be working for me. Many thanks to everyone for their hard work so far. :)

@Undeadhunter What helped me was WINEPREFIX=$HOME/Data/SSD/SteamLibrary/steamapps/compatdata/39210/pfx/ winetricks hidewineexports=enable because I installed FFXIV to custom location

Also remember that if you're using the trial, the number after compatdata is '312060', and if you're using the retail client, it's '39210'.

Could someone please explain how to apply this to a non steam version of FFXIV

@Wyziqi was just coming to post this, indeed, I have a custom install location as well, but you figured it out before me. Thanks for that!

To make it clear for everyone, run WINEPREFIX="<install location>/SteamLibrary/steamapps/compatdata/39210/pfx/" winetricks hidewineexports=enable

Could someone please explain how to apply this to a non steam version of FFXIV

Build wine with the fixes that are posted here, mainly the hidewineexports feature in wine-staging, and the fix to add isTransgaming from https://gist.github.com/achurch/3d01aad515b1784c671637018f076ecd

I'm trying to use the build from @ashkitten but selecting that in Steam as the Proton version is also refusing to start the launcher and just instantly aborting. I'm in over my head at this point and am not sure if it's somehow something on my system acting up or what, but neither of these solutions gets nearly as far as when others have tried them. Trying the regular 4.2 from Steam will load the launcher to the black screen.

From ashkitten's:

GameAction [AppID 39210, ActionID 1] : LaunchApp changed task to ProcessingInstallScript with ""
sh: /home/jim/.local/share/Steam/compatibilitytools.d/proton_4.2-local: Is a directory
sh: /home/jim/.local/share/Steam/compatibilitytools.d/proton_4.2-local: Is a directory
sh: /home/jim/.local/share/Steam/compatibilitytools.d/proton_4.2-local: Is a directory
sh: /home/jim/.local/share/Steam/compatibilitytools.d/proton_4.2-local: Is a directory
[2019-04-24 16:21:51] Startup - updater built Apr 16 2019 21:00:51
[2019-04-24 16:21:51] Opted in to client beta 'publicbeta' via beta file
You are in the 'publicbeta' client beta.
[2019-04-24 16:21:51] Verifying installation...
[2019-04-24 16:21:51] Verification complete
installscript_posix.cpp (418) : Assertion Failed: Standalone evaluator returned error code for app 39210
installscript_posix.cpp (418) : Assertion Failed: Standalone evaluator returned error code for app 39210
Installing breakpad exception handler for appid(steam)/version(1555457005)
assert_20190424162217_27.dmp[7678]: Uploading dump (out-of-process)
/tmp/dumps/assert_20190424162217_27.dmp
GameAction [AppID 39210, ActionID 1] : LaunchApp changed task to ProcessingShaderCache with ""
GameAction [AppID 39210, ActionID 1] : LaunchApp changed task to SiteLicenseSeatCheckout with ""
GameAction [AppID 39210, ActionID 1] : LaunchApp changed task to CreatingProcess with ""
GameAction [AppID 39210, ActionID 1] : LaunchApp waiting for user response to CreatingProcess ""
GameAction [AppID 39210, ActionID 1] : LaunchApp continues with user response "CreatingProcess"
Opted-in Controller Mask for AppId 39210: 0
Game update: AppID 39210 "", ProcID 7680, IP 0.0.0.0:0
Starting app 39210
Installing breakpad exception handler for appid(steam)/version(1555457005)

Adding process 7680 for game ID 39210
GameAction [AppID 39210, ActionID 1] : LaunchApp changed task to WaitingGameWindow with ""
ERROR: ld.so: object '/home/jim/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
/bin/sh: /home/jim/.local/share/Steam/compatibilitytools.d/proton_4.2-local: Is a directory
GameAction [AppID 39210, ActionID 1] : LaunchApp changed task to Completed with ""
Adding process 7682 for game ID 39210
Game removed: AppID 39210 "", ProcID 7680
Exiting app 39210

And how do I apply the patch? It doesn't seem like it matches the format of the other patches in wine staging.

Could someone tell me if I have to do anything special if I'm using Lutris ?

@kgnotte those are diffs, they don't contain commit info so you need to apply them with git apply

Thanks @ashkitten

https://github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git
That would be a possibility to build yourself a custom wine environment. Put diff into the userpatches folder, and run the build script

Could someone tell me if I have to do anything special if I'm using Lutris ?

So far the only builds I've seen shared are for Proton, you need to wait on a Wine build to show up, or compile one on your own.

When one shows up you'll need to sort how to install that into Lutris as a wine runner and switch your wine version for XIV to it.

You can also add non steam game into steam and use proton threw it.

once everyone is fine with the workaround we should really start looking into an actual fix for the issues with mshtml, since this is pretty hacky and liable to break next time they push a similar update

@kgnotte someone here posted a fix for lutris, so you can just use that https://forums.lutris.net/t/final-fantasy-14-wont-start-after-latest-update-dxvk/5598/9

@ashkitten prton 4.2-local worked fine for me. Copied the files under ~/.steam/root/compatibilitytools.d/

Restarted Steam and forced the game running this version. Thank you

@ashkitten Thank you so much! Proton 4.2-local works great!
I'm also on ArchLinux now, just to be safe ;]

@HereInPlainSight I have a request for you: Could you add the proton 4.2-local file with instructions on how to install it to your comment near the top?
That way people who come here looking for a fix for this issue won't have to dig through literally hundreds of comments for it while we're waiting for an official patch.

And hopefully... HOPEFULLY that's going to be a solution that sticks for a while.

I just added instructions to the Reddit post. Been meaning to do that for a few hours now, I just only got around to doing it now. I haven't tested these instructions, so please let me know if I got anything wrong!

I just added instructions to the Reddit post. Been meaning to do that for a few hours now, I just only got around to doing it now. I haven't tested these instructions, so please let me know if I got anything wrong!

Thank you! Also, even though BrowserType now gets ignored with the Proton 4.2-local environment, CutsceneMovieOpening in "FFXIV.cfg" still has to be set to 1, otherwise you'll get a new error that says it couldn't establish a datacentre connection. It at least no longer gives the infinite black loading screen.
You probably covered it already (I haven't looked at it yet) but this is also for people who look here and don't check the reddit one so...

Oh my God, Square!
http://forum.square-enix.com/ffxiv/threads/388444-Wine-Launcher-404
They moved the thread to General Discussion, are you kidding me? xD That thread is as technical as it gets! It's gonna get buried :<

So, first time compiling wine, I opted to use tk-git-wine, but it's fairly arch-specific, so I followed their recommendation for non-Archers in making a docker container to do the compilation, but after compiling I come back with a non-working build for my other machines because wine: failed to initialize: /lib32/libm.so.6: version 'GLIBC_2.29' not found (required by <wine>/lib32/wine/ntdll.dll.so)

So it appears that my home system's running a pre-2.29 glibc. There's some -- what I find to be -- complex instructions on how to deal with this, but does anyone know any simpler version of instructions, or at least how to deal with that in this specific instance? _EXTERNAL_INSTALL is set to true.

Yes, I can wait until a non-proton build pops up, but if I can expand my knowledge for the future, I'd prefer to know it for the hopefully-never-happens next time.

@TenaarFeiri Well that is... Bad. Should we open a new one, more technically-oriented? There was some... heated opinions being shared at some points in the thread. We might want to make specific suggestions for what they can do to help us avoid this in the future, maybe? I'm not totally sure, here.

Edit: Also, a post on the official forums confirms that we're being identified as Mac users.

@HereInPlainSight Yeah, I'm ShiningWolf on there and I'll admit to some heated opinions myself, my bad. It was frustration but either way the topic isn't locked, just moved to General for some reason.

I'd suggest we make a new topic in Tech Support describing the specific steps needed to get FFXIV running on WINE/Proton again. Especially Proton, since that appears to have worked exceptionally well with a bit of minor tweaks (such as hiding wine exports on the game's pfx).
I know Square isn't being very cooperative with us but I think if they could just leave us alone instead and have our topic there, they don't need to do anything. Except maybe pin it. It would've been awesome if they could just do that!

To further justify the tech support topic, we could do a postmortem of the problem?

@kisak-valve Hey! I hope you don't mind me tagging you but I have a question: Would it be possible to integrate a FFXIV-specific Proton build as part of the SteamPlay download? Seeing as there's an already built one that works now (and might even continue to work in the foreseeable future)?

@TenaarFeiri I was thinking a postmortem as a good option, but if that's the case as far as I know we've currently only got a Proton-compatible download, and no Lutris-compatible build yet (which is where my earlier questions came from -- I can compile a build, but it's not runnable on an otherwise working Lutris-using machine).

Also, no worries on getting heated -- it's fine to have feelings about the situation, I just think we need to keep the topic of how we feel about it separate from the 'tech support' side of the problem so we don't give them any reason to move a new topic again, that's all.

Also, given we're confirmed to currently be viewed as Mac users, we should definitely include that in any postmortem write-up on the forums, and highlight that this affects how we purchase our games, and could cause issues in the future for new players. Filtering us based on if we've got wine exports is a non-optimal solution, since most Linux gamers would assume to buy the Windows version of the game.

To confirm -- at this point, as far as a more permanent fix for when the 32-bit launcher gets retired, do we only have two options? Fix mshtml (I think that's what it was called) or put together our own fully-featured Linux launcher? Because both of those sound non-trivial, and if we need them, I'm not sure how to go about furthering either cause very much besides emotional support. <.<

I think the best course of action would be to fix mshtml and swat all the probably hundreds of flies out there causing similar problems. Mshtml and a custom Linux launcher currently seem like the only two _feasible_ options.

A custom launcher would absolutely be the most convenient solution for us, but fixing mshtml would provide a greater benefit to the whole WINE gaming community.

For a custom launcher, I think a good starting point would be to fork this project and build a GUI on top of that. I haven't tested it yet, but I heard from a friend that it pretty much works (he wouldn't give me a 100% clear answer though) so that's the core of such a launcher already written.
The challenge then would be to determine how the standard launcher downloads updates so the new launcher could perform that task as well.
OR
And this would be inconvenient, BUT
one or some of us could keep an up-to-date game installed on a GDrive-synced directory. Getting 100 gigs of GDrive space is fairly cheap, and the launcher could be coded to sync the client from there. But if we can't download updates to that copy of the game without an active account, then there's no guarantee it can serve as a permanent, if patchwork solution.
We'd also be wholly beholden to whether Google decides it wants to give us good bandwidth that day.

Bottom line is I fear moving forward, we may need to hobble past the launcher in inconvenient ways.

i really think that a custom launcher is not the way forward. it would really inconvenience a lot of steam users, especially once square implements their steam login requirements. we need to figure out what is wrong with mshtml and fix it instead.

Yep looking into mshtml (or whatever else might be causing the black screen) seems to be the way to go. Figuring out why the page remains black in a regular browser still seems like a good first step on that.

indeed. i get the feeling it may not be as deep an issue as we initially thought.

I suspect that the launcher sends some kind of header to the webpage to authenticate. Luckily it just seems to be a case of unobscured JavaScript and CSS magic? If I look in the blank page's source, I can find the scripts but I can't find the important part to take out yet. I'm only half literate in both, but if I figure it out, you'll be the first to know.

@kisak-valve Hey! I hope you don't mind me tagging you but I have a question: Would it be possible to integrate a FFXIV-specific Proton build as part of the SteamPlay download? Seeing as there's an already built one that works now (and might even continue to work in the foreseeable future)?

Hello @TenaarFeiri, I'm not a Proton dev, so I can't answer that.

In general, I don't think it would be a bad idea to make a pull request with the patches needed to get things going, but in this case there's a good chance only the mshtml url fix could land and that alone is not enough to get things working.

Chrome, and by extension libcef dropped support for 32 bit windows builds back in 2017 and leaning on it as a workaround sounds like a ticking time bomb to me, so figuring out what snafus are happening in mshtml sounds like the best way forward.

Apologies for my ignorance on this -- a lot of this is outside my bailiwick. Is the fix for mshtml aiming to be fixing the overall wine issue with it (which I get the impression of that it's a large problem), or a targeted fix that requires specific wine patching?

My concern with the idea of a mshtml fix is that it's been sounding like a beast that wine's been unable to tackle for a long time -- but my impression might just be totally wrong, which would be great.

there's a good chance only the mshtml url fix could land

@kisak-valve what about hiding wine exports? if we get mshtml working we'll still need that to run the game, presumably

@HereInPlainSight wine_gecko works for many things, and so far we don't have strong evidence that the issues we're having with it are more than surface deep (the black screen could very well be the same issue as displaying it in a browser window!)

I posted the fix with step by step instructions on protondb.

@HereInPlainSight wine_gecko works for many things, and so far we don't have strong evidence that the issues we're having with it are more than surface deep (the black screen could very well be the same issue as displaying it in a browser window!)

Well, from what I can see at one point someone had a wine patch that let them fix the address error (ending up at https://frontier.ffxiv.com/version_4_0_win/index.htmlinstead of https://frontier.ffxiv.com/version_4_0_win/version_4_0_win/index.html, and said they ended up at a blank launcher. (I kinda can't test all that -- my tk compiling docker keeps looking for a version of glibc I don't have on my actual system.) Trawling through Square's website, at the very least if it was a completely blank launcher, it looks like that's the default and perfectly normal.

https://img.finalfantasyxiv.com/ft/version_4_0/scripts/launcher/launcher.js then _presumably_ should start trawling through and start making things visible (it changes index's tag from the default id tag of 'bodyMasking' to 'bodyDisplay', which basically makes the launcher visible even in a browser), and then the rest of the file looks like it's used to ask the launcher for settings to display the right region's news and login page, all that fun jazz.

It doesn't look like that's happening for us. We're just not processing the relevant scripts correctly. Or at least that's what it looks like, but I have no idea where to go with that knowledge as understanding how programs interact like that haaas always been black magic to me. I mean, a lot of this is black magic but that's why I main BLM -- to learn the universe's dark secrets about its unpaid parking tickets.

I figured I should report back in case anyone else would rather use a solution without proton. I was able to get an older version of wine (3.18) to build and work with the patch, but the version I built with the latest release doesn't seem to work. It just hangs whenever I try to run anything with the binaries. I think this is why I was having problems when I tried to use wine-tkg-git to build packages. If anyone is willing to help me figure out why this is happening I would appreciate it.

I figured I should report back in case anyone else would rather use a solution without proton. I was able to get an older version of wine (3.18) to build and work with the patch, but the version I built with the latest release doesn't seem to work. It just hangs whenever I try to run anything with the binaries. I think this is why I was having problems when I tried to use wine-tkg-git to build packages. If anyone is willing to help me figure out why this is happening I would appreciate it.

Please give relevant links. I've been googling and cloning for days, it's really getting exhausting.

I figured I should report back in case anyone else would rather use a solution without proton. I was able to get an older version of wine (3.18) to build and work with the patch, but the version I built with the latest release doesn't seem to work. It just hangs whenever I try to run anything with the binaries. I think this is why I was having problems when I tried to use wine-tkg-git to build packages. If anyone is willing to help me figure out why this is happening I would appreciate it.

There was a bug in wine-staging yesterday, maybe you were building from that? Had the exact same problem and fixed it by rolling it back a few commits.

Managed to build a version that should work with any lutris install. Seems to work for some people so far. Maybe it would work for you as well? https://files.feffe.it/wine-tkg-ffxiv-feffe-4.6-1.8-x86_64.tar.gz

Thanks @feffes, that build worked for me.

can confirm, build uploaded by @feffes runs the game in lutris on ubuntu 18.04, so for now people on steam and on lutris can login again, the solution is still hacky, so it should still be worked on properly to fix mshtml

@feffes Confirming your build works for me on Lutris / Arch Linux.

If you want to build it yourself, TKG already patched that wine freezing bug yesterday, and the FFXIV userpatch is present in the latest wine-tkg. All you have to do is follow the instructions to edit the customization.cfg enabling the FFXIV fix and DXVK, then buld it. I'm on Manjaro so after the build it just installed, and I could select it as the 'system' runner from Lutris. https://github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git Otherwise just use feffes build. I played for quite a few hours yesterday without any problems at all.

looking at the javascript code for the launcher, i see that the function which appears to make everything visible appears on line 206 of index.js, as an anonymous function registered to listen for App.protocol.Receive.RESUME_INFO. searching for other usages of that brings us to app.js, line 366, in fromAppResumeInfo - searching for this in the source reveals no callers, so i can only assume that it is called from outside... or is supposed to.

Yes, the launcher injects some JS into the page.

yes, but i don't have any familiarity with what tools wine_gecko provides for debugging

@feffes Is it okay if I link that build in the Reddit post? If so, can you give some instructions on how to use it? I don't use Lutris myself.

@feffes Is it okay if I link that build in the Reddit post? If so, can you give some instructions on how to use it? I don't use Lutris myself.

sure. The short gist of it is that it works as any other wine runner, so you extract tkg-ffxiv-feffe-4.6-1.8-x86_64 from the tar into ~/.local/share/lutris/runners/wine and switch to it under FFXIV > Configure > Runner options

Would be nice in case anyone hasn't done it, to update their experience in Proton DB, would be great to get FF14 into Gold, instead of downwards Silver

In order to further poke at the black screen issue i setup a local webserver and copied the launcher site to it, this allows me to modify the html/javascript that the patcher loads.

Adding an additional script tag with fromAppResumeInfo(); at the bottom of index.html will make the launcher appear in a regular browser (to some extend) - and also does so in ffxivlauncher! So this is clearly not a rendering issue and indeed hints at some script not being called the way it should.

Using WINEDEBUG=mshtml we will also find the these:

002d:trace:mshtml:WindowDispEx_GetDispID (0x17c5390)->(L"fromAppResumeInfo" 10000001 0x33e8d4)
002d:trace:mshtml:DispatchEx_GetDispID (0x17c53cc)->(L"fromAppResumeInfo" 10000001 0x33e8d4)
002d:trace:mshtml:HTMLDocument3_getElementById (0x181eb48)->(L"fromAppResumeInfo" 0x33e7c8)

Along with a bunch of DispatchEx_InvokeEx calls later on. I suspect this might be what the launcher uses to interface with the javascript on the page, although i'm not entirely sure on what these functions really do.

What particularly caught my interest in this regard is this warning:

002d:fixme:jscript:JScriptProperty_SetProperty Unimplemented property 70000002
002d:warn:mshtml:set_script_prop SetProperty(70000002) failed: 80004001

70000002 maps to SCRIPTPROP_ABBREVIATE_GLOBALNAME_RESOLUTION according to https://docs.microsoft.com/en-us/scripting/winscript/reference/iactivescriptproperty-setproperty

The documentation on this is a bit thin but the name does suggest that it somehow modifies how the javascript engine to handle global name space resolution differently. The previously mentioned interface seems to use global variables mapped to functions so this might be an possible culprit here as the function clearly isn't implemented at all and could lead to the launcher not being able to use these global variables.

Though we'd need more information on what SCRIPTPROP_ABBREVIATE_GLOBALNAME_RESOLUTION actually does to know more. Simply changing the function in wine to return S_OK regardless changed nothing in the launcher.

@sschroe do any other errors pop up related to jscript/mshtml? i would expect another error if some operation depended on this property being set, yes?

edit: talked to someone in #winehackers and they said this property is always set

Does always set mean that this function is always being called or that in wine the requested functionality is the default state already? I hadn't spotted anything that seemed noteworthy besides.

My last attempts were to use the code from https://github.com/dns/WinAPI-Embed-Browser/blob/master/embed-browser.c as a base to build an example where the issue can be reproduced. Changing that code to load the launcher URL is simple enough but i didn't manage to interface with the Javascript yet. The shitty windows API and lack of documentation make me want to die.

they said that the reason that property is unimplemented is because that's the default state

A tiny bit of "progress":

The first thing the launcher seems to do after loading the page is to Navigate the browser to a javascript url:
002e:trace:ieframe:WebBrowser_Navigate2 (0xe935d0)->(0x32bb5c {VT_BSTR: L"javascript:fromAppConfig( {lang:\"en\",region:3,eula:1,startup:1,issteam:0,query:\"none\",ver:\"2019.04.19.0000.0001(4143105)\",skip_confirm_expansion_install_dialog:\"0\", inst 0x32bb6c {VT_EMPTY} 0x32bb6c {VT_EMPTY} 0x32bb6c {VT_EMPTY} 0x32bb6c {VT_EMPTY})
This pretty much just executes the given javascript string within the current page, in this case calling the function fromAppConfig with a bunch of arguments. And this part works fine so far and among other things will run App.message.send(App.protocol.Send.REQUEST_RESUME_INFO);.

App.message.send looks like this:

send: function(type, opt) {
    // オプションがあるなら処理する
    if (!utils.isUndefined(opt)) {
        type = utils.string.build(type, "=", opt);
    }
    try {
        window.external.user(type);
    } catch(e) {}
}

window.external is normally used to pass data back into another program. So in this case this should be the communication back to the launcher. I suspect that this is the part where things might fail as not much else seems to happen after this. Adding an alert() there on my locally hosted copy shows that the code is being executed with proper values in wine. Additionally commenting out window.external.user(type); results in the launcher coming up with just a black screen in Windows, showing the same behaviour as we see on wine.

So what might be happening is that the launcher doesn't receive the REQUEST_RESUME_INFO and thus does not continue.

I don't think that's the issue.

Using the mshtml patch from https://bugs.winehq.org/show_bug.cgi?id=47069#c2 allows you to run the launcher with BrowserType 0 up to the login form. Clicking the log in button will show an error (https://pomf.soupwhale.com/ltibnw.png).

This is a deeper mshtml issue (or rather a series of issues) that most likely doesn't have an easy solution, not to mention the fact that even that patch is a hack.

Edit: I haven't checked this in a few days, so I might be wrong, but I believe that error was coming from JSProtocolFactory_CreateInstance not being implemented.

Indeed if the browser renders with the patches from there then the previously mentioned parts shouldn't matter as it does already progress beyond that point then.

@lesderid Does that error still come up if you push enter instead of clicking on the button in the password field?

Curiously, with the hack to make it use BrowserType 2 has the same behavior; clicking the button produces that error, pushing enter on the one-time-password field logs in successfully. (The same should work without a OTP)

Pressing enter instead of clicking the play button did start the game for me. So using the url fix + browser busy hack from https://bugs.winehq.org/show_bug.cgi?id=47069#c2 we can login and run the game.

This way i'm also able to use the 64bit launcher, this one however also requires the wine version to be hidden as it otherwise says that my account isn't registered. With the wine version hidden it works as expected and i can login.

@sschroe I am running into the same problem as you (account not registered). What do you mean by hiding the wine version?

@nmalacarne Currently, XIV seems to believe that running Wine means we're on Macs, so it's specifically -attempting- to tell you you don't have a Mac license. To avoid this, we have to hide that we're using Wine. Either do something along the lines of WINEPREFIX=<path-to-prefix> winetricks hidewineexports=enable (or protontricks instead of winetricks if you have it), or WINEPREFIX=<path-to-prefix> winecfg and change the setting in the Staging tab.

It seems my snooping may have helped after all. I been watching this. Please do not say they did not intentionally do this act, they know exactly what they are doing. Open your eyes to see Microsoft, Apple and Sony are all data mining. Proton hinders that since it allows for a bypass of their platforms, so to keep it under the table this little screw ball tactic was used to wall garden Linux out yet have a weasle hole to run back to. Square supports the data collecting tactics of the rest.

Let just say if Microsoft shiles were slaves, then Microsoft is a jugalo. Sony and Apple are both in on it too. Well have fun playing rats vs cats with Square, unless Val gets off the dime like they should have with Half-Life 3 then a hacker's life we sail. Like it or not.

Thanks @HereInPlainSight , that makes sense. Everything is working alright now with DX11 after setting hidewineexports via winetricks.

So this is going to be a long shot, but I have no idea where else to ask. I've been having issues where randomly, the game will not "update" for 5 seconds (as in, from the network) then everything will update all at once, repeat. This goes on for periods of hours and then mysteriously disappears for a few days and comes back for a few days. Restarting the computer does nothing, restarting the router/modem does nothing, mudfish makes the problem worse, mtr reports no packet loss and reasonable ping, and I have no idea where to go from here. It seems to affect nothing but the game and the launcher when trying to update the game. Ethernet driver bug? Linux TCP stack bug that only affects games for some reason? Wine TCP stack bug? I have no idea where to even start to debug this.

This happens on Windows too. Methinks the code doth protest too much?

It's a bad launcher and an equally bad updater.

søn. 12. mai 2019, 23:03 skrev jbal91 notifications@github.com:

So this is going to be a long shot, but I have no idea where else to ask.
I've been having issues where randomly, the game will not "update" for 5
seconds (as in, from the network) then everything will update all at once,
repeat. This goes on for periods of hours and then mysteriously disappears
for a few days and comes back for a few days. Restarting the computer does
nothing, restarting the router/modem does nothing, mudfish makes the
problem worse, mtr reports no packet loss and reasonable ping, and I have
no idea where to go from here. It seems to affect nothing but the game and
the launcher when trying to update the game. Ethernet driver bug? Linux TCP
stack bug that only affects games for some reason? Wine TCP stack bug? I
have no idea where to even start to debug this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580#issuecomment-491629097,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKE3KPYIGKXJFSNHGXDPVCA3DANCNFSM4FRR7KYQ
.

This happens on Windows too. Methinks the code doth protest too much? It's a bad launcher and an equally bad updater. søn. 12. mai 2019, 23:03 skrev jbal91 notifications@github.com:

It's not just the launcher, it makes the game unplayable when it happens. It feels like bad packet loss but MTR disagrees.

Does anyone know how to install and run ffxiv using proton without using Steam or running the Steam version? I want to ensure I can get out all my data while I still can, and I have a non-steam account and have been logging in through the trial which is supposed to stop working in the future. However for the life of me I cannot find any information about running your own proton build for arbitrary applications and not through the Steam launcher

Does anyone know how to install and run ffxiv using proton without using Steam or running the Steam version? I want to ensure I can get out all my data while I still can, and I have a non-steam account and have been logging in through the trial which is supposed to stop working in the future. However for the life of me I cannot find any information about running your own proton build for arbitrary applications and not through the Steam launcher

Proton is just another binary that you can run. If you want, you can make a bash alias for it and then run it like you would Wine.

Was working fine after updating this morning now I get an unable to complete version check

Was working fine after updating this morning now I get an unable to complete version check

I had to reenter the "WINEPREFIX=[pfx location] winetricks hidewineexports=enable"

What is even the purpose of Wine exports? Why is it enabled by default?

ons. 15. mai 2019, 00:52 skrev zangoku notifications@github.com:

Was working fine after updating this morning now I get an unable to
complete version check

I had to reenter the "WINEPREFIX=[pfx location] winetricks
hidewineexports=enable"

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKAP3IRFUAZ2IKNOCRDPVM7CTA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVNASGI#issuecomment-492439833,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKADDKQZJ3Q6W3NNBKTPVM7CTANCNFSM4FRR7KYQ
.

My guess would be for programs with special support for Wine, such as those compiled with winelib. Having these exports would allow a program to easily use special workarounds for bugs in Wine.

As we've seen, of course, it can also be used to deny Wine users the right to run their Windows programs. :/ But that's why the option to hide them exists.

Does anyone know how to install and run ffxiv using proton without using Steam or running the Steam version? I want to ensure I can get out all my data while I still can, and I have a non-steam account and have been logging in through the trial which is supposed to stop working in the future. However for the life of me I cannot find any information about running your own proton build for arbitrary applications and not through the Steam launcher

Proton is essentially a patched Wine with a launcher script. So to do this you can:

1) You can run the wine binary in your Proton build directly as if you were using a normal version of Wine
2) Examine how Steam calls Proton and set the appropriate environment variables before calling the proton script with the appropriate command line parameters. You can find this information by writing a shell script that dumps this information, then setting it in Launch Options in Steam, or you can examine the proton script to see what variables and parameters it uses.

To get the data from Steam, though, you don't need to run anything, just copy it from your ~/.local/share/Steam/steamapps/compatdata/312060/pfx/drive_c/users/steamuser/My Documents/My Games/FINAL\ FANTASY\ XIV\ -\ A\ Realm\ Reborn. Alternatively, if you can run the game, use it's cloud backup to save all your settings.

Then, import them into your non-Steam installation of FFXIV, whether it be via Lutris, Windows, or a manually patched Wine.

My guess would be for programs with special support for Wine, such as those compiled with winelib. Having these exports would allow a program to easily use special workarounds for bugs in Wine.

As we've seen, of course, it can also be used to deny Wine users the right to run their Windows programs. :/ But that's why the option to hide them exists.

That's basically it, hiding itself from Windows programs has never been in the scope of the Wine project, so I guess the idea is, providing a straightforward way to identify Wine and Wine version information is preferable to the Wine crew than devs trying to detect Wine by relying on it's behavior. Some anti-cheat and DRM software does the latter regardless though.

I still don't think SE is going out of their way to fuck over Linux users - I doubt we're even on their radar - but they're moving the Mac version to the DirectX 11 client (as the DirectX 9 client is being removed) with a new wrapper, and this is how they're detecting it.

To be clear, I don't think that's what SE are doing either. (I did think that the hidewineexports trick might start to not work in 4.58, but that was only because of the potential impact to their Mac license revenue.)

SE have been very cordial regarding this, actually - the reply they gave me to my support request (see the original post in my Reddit thread) suggests that they're taking us seriously and not simply dismissing the configuration as not being supported (which they'd absolutely have the right to do), which is encouraging.

When I said "it can also be used to deny Wine users the right to run their Windows programs", I wasn't referring to Linux. I was referring to how the Mac version of the game is mostly an (old) Wine wrapper, and that the way they decided to detect Mac versions was by checking for the presence of Wine at all.

(Actually I suspect that the launcher is created by a different team, considering that it uses IsTransgaming and not get_wine_version like the game itself does. That said, I'm glad they're separate considering that IsTransgaming is currently what's letting us even use the launcher right now.)

If they used get_wine_version for both it'd still be relatively easy to work around (just mod the symbol lookup out in the client) with the added bonus of working out of the box if you did, indeed, have a Mac license.

The launcher fonts work with just the "droid" fonts. No need to install proprietaries.

Anyone have any luck getting the benchmark to work?

@jbal91 thank you for the tips but I am still incredibly lost in trying to figure it out. I did finally figure out that steam is running the following to launch the game, if I include my custom launch options:

PULSE_LATENCY_MSEC=60 /home/anna/.local/share/Steam/compatibilitytools.d/proton_4.2-local/proton waitforexitandrun /home/anna/.local/share/Steam/steamapps/common/FINAL FANTASY XIV Online/boot/ffxivboot.exe -issteamfreetrial

however when I run that I get:

Proton: No compat data path?

Clearly there's a bunch of other stuff missing. Lutris drives me up the wall as I can't easily figure out what in heck it's choking on or how to get it to find that custom 4.2 proton that's being used in the above command so I have not had much luck with it.

Edit: giving lutris the ol' college try and started fresh but it just... doesn't work. The launcher pops up with the loading window but then just quits, no error no nothing, and there is nothing in the lutris log of value, or at all. Why can't SE stop threatening me and just let me use the steam free trial without worrying I'm going to be locked out forever with no way to get my stuff out or spend hours on SHB launch day trying to run out of Steam while recovering my data or whatever, indefinitely ; ;

Another edit: after trying... a lot of things I found this script someone posted on reddit: https://pastebin.com/NJxfe8Ex and modified it to use the custom proton I'm running on Steam that has the istransgaming patch (it's ashkitten's, in particular) and... it's doing the same thing Lutris is doing, flashing the boot check version and sometimes a blank launcher window briefly then just quitting with no error messages or anything. So... something must be wrong in general but I cannot figure out what it could possibly be.

Unfortunately I have the same problem with the Shadowbringers benchmark. It just exits without loading anything at all. So I have no idea if it's possible to run at all right now.

A... lot happened and I think I might be close to getting it to work by running a Lutris wine build similar to the proton ones here that support hidewineprefix that I found in a Lutris thread but also directly in bash because that loads the launcher and running it from Lutris doesn't. For some reason. I don't know I'm still working on it and it's patching right now.

That said if any wine witches or wizards have any idea how to run the benchmark, that'd be cool, the hour I spent in Windows to play with it was horrifying lol.

If I try to run it, I get:

The entry point method could not be loaded due to Could not load file or assembly 'PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

Looking this up it seems like it might be kind of nasty and something with some version of .NET that will never be supported or something, but this is really far out of my depth and y'all probably have a better idea of how to get it running, or solid reasons why it isn't happening.

If I try to run it, I get:

The entry point method could not be loaded due to Could not load file or assembly 'PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

Looking this up it seems like it might be kind of nasty and something with some version of .NET that will never be supported or something, but this is really far out of my depth and y'all probably have a better idea of how to get it running, or solid reasons why it isn't happening.

Actually as of a few days ago that has a chance of being supported in the near-ish future. (https://github.com/dotnet/wpf/pull/720)

just for the update so someone doesn't waste time if they saw my last messages, I finally did get FFXIV working on a dxvk-enabled WINE prefix, it was a bit of a journey that involved a lot of recompiling (gentoo yay) and finding someone in the Lutris discord that had their own fork of Lutris that works better [on Gentoo at least] but I am now safe from the impending Newellpocalypse :)

@witcheslive Didn't know you were on Gentoo -- personally I run the lutris-9999 version, but either way just make sure you disable the Lutris runtime as your default setting and Lutris should work fine. The runtime does not work well at all in Gentoo in my experience.

I don't know if this is useful, but I've been playing FFXIV with Lutris relatively fine for the past 3 days.

• I'm using standalone FFXIV (no Steam login or client involved)
• I had a few random disconnects, but if I heard right, there was some DDoS'ing going on as of lately and this may not be Wine/Linux-specific
• I was getting frequent launcher errors out of nowhere within the last day (-21?), but managed to start it consistently by deleting the web folder; aside from that though, the launcher lets me log-in no problem
• With distro Wine Staging 4.8 on openSUSE TW and Fedora 30, FFXIV's installer would crash right after accepting the first prompt about language. I don't know what this is about, but Lutris works fine (haven't tested Steam/Proton directly)
• On Lutris, I've been using the ge-faudio-protonified-4.8 runner and generally default Lutris settings (kept Lutris Runtime enabled)
• The Lutris install script hides the wine version, and does the cutscene and browser cfg setting changes
• I use DXVK with a RX 580 on openSUSE TW
• I'm also able to run on a laptop with a RX 560 in an eGPU
• Wasn't able to get the Shadowbringers benchmark running (got the above 4.0.0 Presentation error, and even after installing dotnet45 (benchmark requires 4.5 at a minimal), I got some other error)

The Lutris ge-faudio-protonified-4.8 runner has the Transgaming patch applied:

% strings .local/share/lutris/runners/wine/ge-faudio-protonified-4.8-x86_64/lib/wine/ntdll.dll.so | grep Transgaming 
IsTransgaming
IsTransgaming

https://github.com/GloriousEggroll/proton-ge-custom/blob/4ddc7a9916294334ca634dbf5c741cf4f53f6f70/game-patches-testing/ffxiv-launcher.patch

Lutris' FFXIV installer script also applies the HideWineExports hack via registry:

- task:
    arch: win64
    description: Adding Registry Entries for FFXIV Launcher
    key: HideWineExports
    name: set_regedit
    path: HKEY_CURRENT_USER\Software\Wine
    prefix: $GAMEDIR
    type: REG_SZ
    value: Y

So for anyone on a distro with Lutris support, that's going to be your best bet going forward. Install Lutris, have it set up the game for you, and it should just work.

any progress on getting the launcher working with mshtml?

We can get the 64-bit launcher working with a patch that was posted to the wine bug tracker.

The only issues I've had using this patch are:

• The launcher doesn't remember my username no matter what I tell it.
• After typing your login info, you have to hit 'enter' instead of clicking 'log in.' Clicking crashes the launcher.

Neither of these problems bother me, so I've been using the 64-bit launcher.

btw, aside from the launcher i've encountered 2 distinct issues:

• the opening movie for at least ARR does not play properly, and sitting too long on the title screen or trying to play it from the movies menu gets you a nonresponsive black screen with a loading indicator (stormblood opening movie has no issue)
• in thornmarch (hard) there is a very loud crackling/popping noise at one point, i have experienced this both times i did that trial and nowhere else

It looks like the 404 error & black screen was fixed in wine-git. The launcher actually displays the content now, but you get a javascript error if you actually try to log in.

Someone on the VKX discord said that this is the commit: https://github.com/wine-mirror/wine/commit/d535df42f665a097ec721b10fb49d7b18f899be9

EDIT: Pressing enter instead of the log in button makes the launcher work.

EDIT: Pressing enter instead of the log in button makes the launcher work.
That worked for me! albeit only once. but i got into game and past character select

Someone on the VKX discord said that this is the commit: wine-mirror/wine@d535df4

Compiled a git version today from Tk-Glitch's scripts with no custom patches -- the 64-bit launcher works, and remembers my ID in Lutris. When Proton catches up to this, we shouldn't need any special patches for XIV to work through Steam any more, and we _should_ (Hydaelyn willing) be okay for when the 32-bit launcher gets retired.

Not that I expected it to change, but I made another prefix to test, and we _do_ still have to hide wine to not be seen as needing a Mac license. Light grumbling.

When Proton catches up to this, we shouldn't need any special patches for XIV to work through Steam any more,

FFXIV still needs Staging because there is not really a way to get around the MacOS license error otherwise.

i should think proton would be more willing to incorporate staging patches than incredibly specific hacky workarounds, though

FFXIV still needs Staging because there is not really a way to get around the MacOS license error otherwise.

I was under the impression that one could either winetricks or protontricks the prefix itself, but since I haven't been able to compile my own proton against the latest wine for whatever reason, I can't check it. I admit I don't know much about wine behavior at that level.

I was under the impression that one could either winetricks or protontricks the prefix itself

you need the patch from staging, in addition to that

The problem is also that you really don't want wine hiding itself by default, as some anti cheats check if you're running wine to ensure it doesn't ban you for having a "modified" windows install or whatever. So it's really something that should only be done explicitly.

the patch only takes effect if you also change the registry entry, so it should be fine

There are other ways to work around the Mac license issue:

• Buying a Mac license
• Modding out the Wine symbols in the game client (unlike the launcher, the game files are not checked for integrity when the game is started) - could be done with a simple sed script.

If people are willing to do that then they can use vanilla Proton once it merges from Wine upstream. But yeah, otherwise Staging will be needed and I don't see Valve merging the hide wine export patch unless Wine itself does.

@kisak-valve can we get some official feedback on what patches proton will or will not incorporate to make a game run?

Hello @ashkitten, friendly reminder that I'm a moderator for Valve's issue trackers on Github and not a Proton dev myself, so I can't answer that question.

You can make a pull request with the patch(s) and they will be evaluated on a per-case basis.

yes of course, i had forgotten 😅

i made a new build for personal reasons but figured i should share it here - it's still using the same patchset as the one from may 24, but i rebased it on the latest commit of the proton_4.2 branch

https://drive.google.com/open?id=1yAb_YvOKK1KRcfeQErIKwH6dkKbjZ9kp

It's still necessary to build proton from source with upstream wine for the https error?
I don't like the wine hiding thing or any strange workaround.

If I get it I need to
1) compile proton/wine from sources
2) update proton by hand

I don't know how to use the lutris script since I have the steam version of the game. I have to install steam with lutris and later install/copy the game?

@Turbito
For Steam you will need to hide wine still, unless you want to buy the mac version as well. However getting that to work is a matter of copying a custom version of proton like the one @ashkitten just posted into the proper location and setting FFXIV to use that version. It's not difficult at all once you set it up, but will be necessary for the forseeable future as even with the work being done to get the 64 bit launcher working, the game still sees a wine prefix and thinks you're on a mac even when you manage to log in with the 64 bit launcher instead of the current workaround which is to load the 32 bit launcher using environment variables that are used by the mac version to allow such.

In other words it will eventually work more or less out of the box without any fiddling, and probably pretty soon... if you have a mac license. If not you will need to do minor fiddling to hide the wine prefix from the game, but that's a very set-it-and-forget-it thing.

does proton not have setup scripts per game? i'm sure it could just make the appropriate registry entry to have the game run properly.

does proton not have setup scripts per game? i'm sure it could just make the appropriate registry entry to have the game run properly.

Proton does not, Steam itself does.

I don't see them merging hide_wine_exports or applying the registry entry because of legal issues (we're effectively bypassing SE's per platform licensing "DRM" here which could be a DMCA violation in the US.)

So is it ridiculous to hope that if someone submits a pull request for the exports, Valve might just... _ask_ Square to not use Wine to see if someone's on Mac, as it interferes with Proton, a Steam-supported utility, on a game they sell on their platform, and specifically interferes with licensing?

It may not mean anything, Square might not care either way, but the request coming from Valve would mean way more than coming from us, clearly.

If Steam could get scripts to set up the FFXIV_boot.cfg and Square stopped filtering Wine users as Mac users, once Proton caught up to the update that fixes the launcher I think the game would work out of the box for most people.

I am getting a lot of direct x errors and dll errors. It was not doing this before.

This with the latest version of Proton or 4.2_local ? (The one someone
compiled for us above)

søn. 16. jun. 2019, 08:49 skrev zangoku notifications@github.com:

I am getting a lot of direct x errors and dll errors. It was not doing
this before.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKD7AHWERLWHCANIRSLP2XO7RA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZGVCA#issuecomment-502426248,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKD75DW3NWMOABL5XKDP2XO7RANCNFSM4FRR7KYQ
.

@TenaarFeiri It is with 4.2_local

for those who care this custom proton build works out of the box (I've tested it): https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/4.10-GE-3

for those who care this custom proton build works out of the box (I've tested it): https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/4.10-GE-3

Works great! Thank you for sharing <3

for those who care this custom proton build works out of the box (I've tested it): https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/4.10-GE-3

is this based on proton 4.2-7 ?

for those who care this custom proton build works out of the box (I've tested it): https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/4.10-GE-3

is this based on proton 4.2-7 ?

well..kinda, it's really custom build:

-updated to wine 4.10 with improved clock_monotonic patches
-imported changes from proton 4.2.4 through 4.2.7
-backported gamepad changes from 4.10+ and proton 4.2 to 4.10
-integrated d9vk
-added nod3d9 option to proton to allow disabling of d3d9 override for d9vk
-dxvk updated to 1.2.2 with async patch enabled for PoE and Warframe
-faudio updated to 19.06.07 - fixes performance regressions in several games
-integrated protonfixes into the build. This allows for game-specific fixes to be added without users repeatedly messing with their setup, similar to lutris install scripts. 
+++ much more

this is from the previous relese notes

So I tried both the updated proton_4.2-local as well as the Proton-4.10-GE-3 builds, however if I launch the game in DX11 mode (which there will be no way around I suppose once shadowbringers lands) then I always end up the the 3109 not yet registered or subscription expired error. This does not happen under DX9. Is there any config setting or launch parameter I'm missing here?

I'm running directly via steam on ubuntu.

EDIT: Figured it out, had to actually enable hidewineexports via winetricks. Runs like a charm using the Proton-4.10-GE-3 now <3

Now I'm having a problem with Proton-1.10-GE-3 in that the game seems unable to remember my system settings, although character settings and UI layout and whatnot is remembered just fine...

Any ideas?

Having the same issue, seems like ProtonFixes Utility is tweaking the configuration on each start, however it appears that it either replaces everything with default values or breaks something and the game resets the config.

As a Quickfix I made the FFXIV.cfg read-only... this results in the "Proton Fixes being applied" Window to get stuck when launching the game but simply closing it has no further affects :)

yeah I notice this minor issue myself, maybe @GloriousEggroll could check this out

Hi all. I've been keeping track of this thread via e-mail. I've just made corrections to the ffxiv protonfixes scripts:

gamefixes.tar.gz
Extract those into Proton-4.10-GE-3/protonfixes/gamefixes/

Changes made:
https://github.com/GloriousEggroll/protonfixes/commit/e0466f61447b1aa5e9cd494236777a6cb9d9b4d4

Also just some info:
My version has both the hidewineexports patch ported from staging and the transgaming patch.
The transgaming patch tricks the launcher into running the CEF version of itself instead of the mshtml version. the mshtml version has a broken java error if clicking the login button, hence why we want the cef version. the hidewineexports patch allows hiding wine exports from the game, which fixes the game from thinking the account does not have ffxiv registered on it.

The build itself contains fixes for multiple games, not just ffxiv. It's faudio build is also built with ffmpeg support so that wma and wmv audio works. It is also built on wine-4.10 vanilla with proton's commits/patches ported over.

The patches made to wine in my version can be found here:

https://github.com/GloriousEggroll/proton-ge-custom/blob/proton-ge-4.10/game-patches-testing/proton-prep.sh

While non wine related game fixes are done by protonfixes.

Thanks a ton, @GloriousEggroll ! <3 That did the trick!
About the java error, is there any chance of a fix for that going into the pipeline some day? Or are we just abandoning hope for mshtml at this time?

thats up to the wine devs. you can still login by pressing enter, but atm the cef version works perfectly using either enter or mouse click.

@GloriousEggroll You are a life saver! Thanks so much for sharing your build with us!

Hopefully the whole thing does not break on Friday.

And the Launcher is broken with an HTTPs Error once again :(

What error? I've always had some error, restarting fixes it.
I just close the launcher and relaunch the launcher.

Restart steam if you get https errors, it fixes it. I confirm the game works with out current work around, I am in queue.

The launcher is sadly a POC and you're gonna get HTTPS errors occasionally
for no real reason on any system, Windows, Mac or Linux.
I wish they would do away with it altogether tbh.

fre. 28. jun. 2019, 11:04 skrev zangoku notifications@github.com:

Restart steam if you get https errors, it fixes it. I confirm the game
works with out current work around, I am in queue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKB3DUXG3E5GERVRQVTP4XHZZA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYZQX5Y#issuecomment-506661879,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKH4ZMH4NVKFPRYAVOTP4XHZZANCNFSM4FRR7KYQ
.

I can confirm that the 5.0 launcher works in wine-4.11, including updates (I had a couple of HTTPS errors during the update which I imagine were due to servers being overloaded, but restarting the launcher let the update complete normally). HideWineExports is still needed to avoid being detected as a Mac, and clicking the "login" button instead of pressing Enter in the password field still causes a Javascript error, but otherwise no patches seem to be needed.

The game itself now throws an "unexpected error has occurred" dialog as soon as the main game window opens, even before the title screen appears; this appears to be a bug or missing feature in FAudio (the error is triggered by a crash in FAudioFXVolumeMeter_Process() which I'm still investigating). I seem to recall that either wine-staging or Proton disables FAudio at the moment so it may not be a problem when using Proton, but just FYI.

The game itself now throws an "unexpected error has occurred" dialog as soon as the main game window opens, even before the title screen appears

Happens on Lutris currently with both 4.10 Wine runners (including the ge-protonified one); Launcher seemingly works fine, but game crashes immediately after pressing Play

Works with the ge-faudio-protonified-4.8 runner though

I know it isn't helpful to you but if it helps anyone at all, Glorious Eggroll's latest
thing ( https://github.com/ValveSoftware/Proton/issues/580#issuecomment-504688485 ) does work with me. I am in game right now.
I hope you can get it sorted. If I can share any info to help you, let me
know!

Edit: I do know I am not using FAudio, however. I'm using xaudio/xact(?).

Latest revision should fix crashes in the latest FFXIV patch: https://github.com/FNA-XNA/FAudio/commit/6de5c86b27ec3c5f3aac2dab431563a89a1460b2

EDIT: Note that the game uses neither WMA nor F3DAudio, so no custom builds should be necessary, the default CMake configuration should be enough to get this to run.

Works with the ge-faudio-protonified-4.8 runner though

Do you know what version of FAudio that runner uses? (look for libFAudio.so.* if you're not sure)

EDIT: Never mind, looks like it's fixed upstream.

I know it isn't helpful to you but if it helps anyone at all, Glorious Eggroll's latest thing ( #580 (comment) ) does work with me. I am in game right now. I hope you can get it sorted. If I can share any info to help you, let me know! Edit: I do know I am not using FAudio, however. I'm using xaudio/xact(?).

I'm currently using my build as well, and am able to login with no issues. I have no xact/xaudio overrides in place. I've also tried using my lutris ge-protonified-4.10 build. both builds are able to log in successfully.
I must note that the lutris build is built on a buildbot using ubuntu 18.04 with lutris libraries in use, and the proton build is built with vagrant, the same way valve's proton builds are made. The lutris build also uses the faudio libraries from my proton build, so they are identical in that aspect. None of my builds are built directly on my own system using my own libraries. They are made to be largely portable.

So I've had HTTPS errors sometimes but I've also found an easy way to fix them.

If the rest of the launcher loads but the login form in the top-right doesn't, then eventually the launcher will timeout with an error. However, I've found that an easy way to force the login form to load if it's having trouble is to simply hover the mouse over one of the buttons at the bottom of the launcher. The help text for that button will appear, and for whatever reason, that seems to allow the login form to load.

If for whatever reason you can't hover with the mouse you can also do it by going into the Config screen in the launcher and then immediately backing out, which will also cause the form to reload and appear.

I'm currently using my build as well, and am able to login with no issues. I have no xact/xaudio overrides in place.

I've now tried that build, but it gives the same problem as a vanilla (+HideWineExports) Wine build.

Could you (or anyone else for whom audio works) get a log from Wine with WINEDEBUG=+xaudio2? A couple hundred lines of xaudio2 logging should be plenty. I note that 5.0 uses xaudio2_8.dll rather than xaudio2_7.dll (as in 4.x) so there may be a different code path involved that misbehaves in certain environments.

I'm using wine-staging 4.11 on Gentoo with no xaudio override, and audio works fine for me.

I'm trying to attach a log to this comment... if it doesn't work, the same log can be found at https://matrix.theblob.org/xaudio-log-excerpt.txt . It's a log of the first 1000 lines that Wine outputs with WINEDEBUG=+xaudio2. If you want more, let me know.

I should point out, the above log is not from Lutris or any pre-compiled binary build, but from compiling the app-emulation/wine-staging-4.11 ebuild with the IsTransgaming patch added manually and with the wineprefix in question hiding the Wine exports.

Thanks for the log. I see your install is creating an XAudio version 27 instance (unlike version 28 in mine), so maybe there's an environmental trigger that's triggering selection of different API versions.

Can you check which XAudio DLL (xaudio2_7.dll or 2_8.dll) is loaded into your ffxiv_dx11.exe process? Maybe also check whether SoundCoreBridge.dll or SoundCoreBridge7.dll (from the game directory) is loaded.

I was able to get sound working by switching the reported Windows version in winecfg from Windows 10 to Windows 7. It looks like the game chooses between XAudio APIs based on that reported version, and I guess there's a bug or missing feature somewhere in the XAudio 28 implementation. (For the record, the game loads SoundCoreBridge7.dll which links to xaudio2_7.dll under Windows 7, and SoundCoreBridge.dll which links to xaudio2_8.dll under Windows 10. Version 4.x didn't have those local DLLs and always used xaudio2_7.dll.)

At any rate, I guess the answer to "game crashes with an unexpected error immediately after the game window opens" is "check that the Windows version in winecfg is set to Windows 7".

I can confirm that; I had my Windows version set to Windows 7 already. Setting it to Windows 10 immediately crashes the game on launch.

Oh, I just noticed your question. If you still want me to answer the question, can you let me know how to check with DLLs are loaded? I'm not entirely certain. (I don't have a debugger in this wineprefix.)

You don't need to worry about the DLLs at this point, but for reference, you can look up DLLs (and .so's for Linux programs) with cat /proc/PID/maps where PID is the PID of the process in question. Shared objects are all mapped directly into memory, so just look down the list of mapped ranges for blocks associated with *.so files.

Ah, okay! Thank you. <3 I didn't realise DLLs would show up in that list too.

But yes, for completion's sake, I do indeed have xaudio2_7.dll.so and SoundCoreBridge7.dll loaded when running using the "Windows 7" config, and when using "Windows 10" that changes to xaudio2_8.dll.so and SoundCoreBridge.dll.

Good call!

The XAudio 2.8 issue sounds plausible, perhaps it’s the 2.8 mastering voice that’s getting corrupted:

https://docs.microsoft.com/en-us/windows/desktop/xaudio2/xaudio2-versions

FAudio targets 2.8 internally, so we’re looking at xaudio_dll.c in this case.

Filed a bug against Wine: https://bugs.winehq.org/show_bug.cgi?id=47437

I've diagnosed the issue. Something is very very wrong and I'm not sure how this is possible:

There's a submix in the engine that's supposed to be dedicated to reverb, which is fully supported via CreateAudioReverb. In the case of 2.7 it's a macro that creates the IXAPO object with the usual COM goo we all know and love, but for 2.8 they changed
XAudio2Create/CreateAudioReverb/CreateAudioVolumeMeter to all be exported C functions, which again is fine because compiling against the 2.8+ SDK will just work.

The bug is that SoundCoreBridge 2.8 is calling CreateAudioVolumeMeter. It then sets this volume meter on the submix and immediately begins passing it reverb parameter data, resulting in our assertion failure and eventual crash.

I... honestly don't know how that is happening. I can't think of a reason why Wine would incorrectly direct a call to a completely different function, and at the same time there's absolutely no way FFXIV is calling a totally different function from what is probably the exact same code for both modules, unless the 2.8 engine crashes for everyone else on Win8+ as well. (To re-emphasize: There's no way this is the game's fault)

To summarize, 2.7 is doing this:

CreateAudioReverb(&reverb);
CreateSubmix(&submix, reverb);
submix->SetParameters(submix, reverb, ReverbParameters, sizeof(ReverbParameters));

And 2.8 is doing this:

CreateAudioVolumeMeter(&reverb); /* ?! */
CreateSubmix(&submix, reverb);
submix->SetParameters(submix, reverb, ReverbParameters, sizeof(ReverbParameters));

Does this sound weird to anyone else?

It sounds very weird but that might actually explain why many games crash in Windows 10 mode and not 7.
This could be a significant bug you've stumbled upon!

FWIW, my trace log says this:

00ac:trace:xaudio2:xapocf_CreateInstance (0x100c5960)->((nil),{00000000-0000-0000-c000-0000000000000046},0x100c57c0)
FAudioCreateVolumeMeterWithCustomAllocatorEXT(0x100c59a0 0 0x7f0420f5eb80 0x7f0420f5eba0 0x7f0420f5ebc0)

As an entry issue, that GUID looks weird, but the code flow would seem to be that xapo.c:get_fapo_from_clsid() is finding a CLSID match on the volume meter object and creating that, instead of creating the presumably intended reverb effect.

Again, I'm way out of my depth here -- hopefully this is useful information.

You might be looking too deeply into it... this is much simpler than the actual code itself, it's just the functions being exported.

For reference, this Bad and Do Not Use This patch fixes the crash:

diff --git a/dlls/xaudio2_7/xaudio_dll.c b/dlls/xaudio2_7/xaudio_dll.c
index da0b0aa606..88ca3fe2c1 100644
--- a/dlls/xaudio2_7/xaudio_dll.c
+++ b/dlls/xaudio2_7/xaudio_dll.c
@@ -2070,11 +2070,17 @@ HRESULT WINAPI XAudio2Create(IXAudio2 **ppxa2, UINT32 flags, XAUDIO2_PROCESSOR p
     return S_OK;
 }

+#if 0
 HRESULT WINAPI CreateAudioVolumeMeter(IUnknown **out)
+#else
+HRESULT WINAPI CreateAudioReverb(IUnknown **out)
+#endif
 {
     IClassFactory *cf;
     HRESULT hr;

+    TRACE("%p\n", out);
+
     hr = make_xapo_factory(&CLSID_AudioVolumeMeter27, &IID_IClassFactory, (void**)&cf);
     if(FAILED(hr))
         return hr;
@@ -2086,11 +2092,17 @@ HRESULT WINAPI CreateAudioVolumeMeter(IUnknown **out)
     return hr;
 }

+#if 0
 HRESULT WINAPI CreateAudioReverb(IUnknown **out)
+#else
+HRESULT WINAPI CreateAudioVolumeMeter(IUnknown **out)
+#endif
 {
     IClassFactory *cf;
     HRESULT hr;

+    TRACE("%p\n", out);
+
     hr = make_xapo_factory(&CLSID_AudioReverb27, &IID_IClassFactory, (void**)&cf);
     if(FAILED(hr))
         return hr;

Okay so apparently it is in fact entirely possible for functions to be exported in an incorrect numeric order and this is something actual Windows developers know about:

diff --git a/dlls/xaudio2_8/xaudio2_8.spec b/dlls/xaudio2_8/xaudio2_8.spec
index 0b9f23866b..50a2090f44 100644
--- a/dlls/xaudio2_8/xaudio2_8.spec
+++ b/dlls/xaudio2_8/xaudio2_8.spec
@@ -1,6 +1,6 @@
 @ stdcall XAudio2Create(ptr long long)
-@ stdcall CreateAudioVolumeMeter(ptr)
 @ stdcall CreateAudioReverb(ptr)
+@ stdcall CreateAudioVolumeMeter(ptr)
 @ cdecl CreateFX(ptr ptr ptr long)
 @ cdecl X3DAudioCalculate(ptr ptr ptr long ptr)
 @ cdecl X3DAudioInitialize(long float ptr)
diff --git a/dlls/xaudio2_9/xaudio2_9.spec b/dlls/xaudio2_9/xaudio2_9.spec
index 0b9f23866b..50a2090f44 100644
--- a/dlls/xaudio2_9/xaudio2_9.spec
+++ b/dlls/xaudio2_9/xaudio2_9.spec
@@ -1,6 +1,6 @@
 @ stdcall XAudio2Create(ptr long long)
-@ stdcall CreateAudioVolumeMeter(ptr)
 @ stdcall CreateAudioReverb(ptr)
+@ stdcall CreateAudioVolumeMeter(ptr)
 @ cdecl CreateFX(ptr ptr ptr long)
 @ cdecl X3DAudioCalculate(ptr ptr ptr long ptr)
 @ cdecl X3DAudioInitialize(long float ptr)

Will submit this to WineHQ today...

Is there a practical reason why this is possible/developers would do that? Or do you think this might be an unintentional bug?

On the Wine side this is definitely unintentional. As for why Windows DLLs are like this... I have absolutely no idea. I'm sure it's buried in Raymond Chen's blog somewhere >_>

Fix is in upstream Wine: https://github.com/wine-mirror/wine/commit/92a5299b1d0a0775e1158f334c0348a3ffe8f063

Uh, question: I was trying to write the word "touché" in the chat the other day and realized I can't seem to do é in the chat at all. It just prints the ' character immediately. Do we know any workarounds to make that work properly?

Has anyone even tried to use ACT? I'd love to be able to run parsers though I'm not sure how feasable that is :(

Afaik WINE currently doesn't support DLL injection (if this has changed,
let me know!), so even if you got the app to work (it doesn't, it locks
up), you probably couldn't do it.

søn. 7. jul. 2019, 04:30 skrev witches dot live home of live witches <
[email protected]>:

Has anyone even tried to use ACT? I'd love to be able to run parsers
though I'm not sure how feasable that is :(

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKAAW423NKBSXBSWJMLP6FILRA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZLDOLI#issuecomment-508966701,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKEROJLQ6A3XJOWWNATP6FILRANCNFSM4FRR7KYQ
.

Isn't ReShade DLL injection? That seems to work fine so long as you configured the DLLs you need as native.

I don't know anything about ACT, I tried downloading it and running it inside my wine prefix, but it just dies. Not really interested enough to research it any further, personally.

Incidentally, so long as I'm replying, I just used /echo touché (I copy-pasted yours from this thread, I don't even know how to make the character independently) and it showed up just fine in-game.

ACT required .NET, and you can make it run kinda, but it will crash a lot and i havent figured out a way for it to read the parses correctly out of the game.
AFAIK, ACT isnt using DLL injection, its just reading memory, according to the accompanying FFXIV plugin for it, which may be a problem if you dont run it as Admin in windows, and that functionality isnt available in wine, right?

Ah I see! Then yeah it could work.

On the touché thing, copy pasting it works fine but it's the actual typing
of it. On my keyboard you would hit altgr+\ which would queue it up,
followed by e to make é. It works elsewhere in the system but in game it
just types the indent directly as though I'd hit space.
Sadly my phone can't do the same to demonstrate and it's not an important
issue, it's just I like being able to write words like touché :P

søn. 7. jul. 2019, 14:41 skrev HereInPlainSight notifications@github.com:

Isn't ReShade DLL injection? That seems to work fine so long as you
configured the DLLs you need as native.

I don't know anything about ACT, I tried downloading it and running it
inside my wine prefix, but it just dies. Not really interested enough to
research it any further, personally.

Incidentally, so long as I'm replying, I just used /echo touché (I
copy-pasted yours from this thread, I don't even know how to make the
character independently) and it showed up just fine in-game.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKBEZKGPX3SQB2WYO63P6HQARA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZLKYKY#issuecomment-508996651,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKFSUPDPTJTEZTYLO5LP6HQARANCNFSM4FRR7KYQ
.

from what I understand, ACT taps into network drivers somehow to do packet capture which is probably extremely not a thing WINE is capable of being pretty much entirely out of scope, but I could be wrong about this so wanted to make sure I haven't written off being able to run it without checking

I have also been unable to get Japanese input to work in game. I use FCITX-mocz, but when typing in game chat it will only type English characters. I also tried with ibus and no lock there either. I assume it is the same as the touché issue.

I have no(*) trouble entering Japanese using ATOK X3, so non-English input is at least possible.

(*) There are a few cursor movement glitches if I toggle Japanese input off in the middle of a text line, but I haven't checked whether they also occur with ATOK on Windows, so it could just as well be a bug in the game itself.

Hi, I'm having an issue saving the game's graphics settings. Every time I reload the game it comes back with default graphics settings making it a pain in the butt. Anyone else has had this issue?

Hi, I'm having an issue saving the game's graphics settings. Every time I reload the game it comes back with default graphics settings making it a pain in the butt. Anyone else has had this issue?

No, but the first thing I would check is to make sure you have read -and- write access to the appropriate settings files (and that you own them). You should have a compatdata directory inside your steamapps folder. You'll either use the demo Steam ID of the game (which eludes me currently) or 39210 for the retail version. Drill down to pfx/drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/ and check your permissions.

Anyone else getting random crashes? Started today. I'll give more info once/if it crashes again, around 3rd time in a row.

It's a directX 11 issue. I was running on maximum (solid 60fps, no issues until today, lowering the settings seems to have fixed.
I switched to level a rogue and then the crashes started. If anyone is interested and needs more logs, just tell me what you need and i'll provide them over the weekend.

@Selhar Nvidia GPU? If so, see https://github.com/doitsujin/dxvk/issues/1100

If that's the problem you're running into, you could try playing the game with wined3d instead, although performance will suffer. If it's something else, then we're going to need a lot more info (especially how to reproduce it).

@doitsujin I'm using AMD, RX580.
And i'm not really sure how to reproduce it, it just started crashing last night. After lowering graphic settings and restarting my computer, the game seems stable again.

Are there any specific logs i could give in case it happens again?

Edit: Irrelevant outdated information now. Proton 4.11 is released and just works.

Make sure you press enter on the login page text field instead of clicking the login button.

Alright, so it was once-upon-a-time suggested I edit my early-on post in this thread with current instructions, and given the above post saying it was hard to find current and accurate info, and that we now seem fairly stable with ShB currently, I just now finally did so.

If I messed anything up, please let me know. Also, there's a lot of builds thrown around in the thread and I didn't know where they were at, so I made one from the default version that would compile from Tk-Glitch's PKGBUILDS repo for proton. The only change I made was I added 'ffxiv' to be appended to the resultant proton build name so it could be easily identified. It was built against an Arch Docker that was updated against the Arch Archive from 05-01-19, being the earliest version I could find that would compile everything without issue, hoping that would make it as compatible as possible. I confirmed it just worked against an updated Pop OS! install, but YMMV, and I'd appreciate it if someone could confirm it works outside of my own small test environments.

If you came here from the post above because I promised you an explanation about why we need a custom Proton version, here it is:
At the moment, FFXIV is checking to see if you log in using Wine. If you do, it identifies you as a Mac user. In order to avoid being seen as a Mac user, we have to hide that we're using Wine, which is what the winetricks command is for. Unfortunately, at this time, default Proton does not provide the ability to hide wine, and so we need a custom version to be able to do this.

Fixes required for the game were released in recent Proton 4.11 update. Please give it a try.

Running the game with proton 4.11 does not work, it throws a java script error.

If you clicked the Login button when getting that error then try pressing Enter on the login form instead to get around that.

4.11 works beautifully. Thanks @cjacek for your hard work to get FFXIV running on Wine and now Proton.
I have a small question: How did you get around the license check error? Does Proton ship with HideWineExports enabled by default or does the game have the check removed entirely?

The last FF update removed the check.

Whoah! Do you suppose Square listened to us Linux users??

ons. 31. jul. 2019, 18:16 skrev Jacek Caban notifications@github.com:

The last FF update removed the check.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKF53SVUXGOND2ACTJTQCG3EXA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3HY3HY#issuecomment-516918687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKAOTMJJ7UM6UOAL6O3QCG3EXANCNFSM4FRR7KYQ
.

FFXIV Mac moved to a CrossOver-based build which doesn't use the old Cider hacks, so for the Shadowbringers update all that stuff got removed.

this is great news! so our only prominent issue atm is the launcher crashing if you click the login button? is there a wine bug open for that?

I can get up to the data center selection screen in 4.11. Once I confirm a server, the game starts to load something, but stops there. The game responds to key presses (IE: pressing Alt+F4 brings up a small pop-up asking if I want to exit the game), and the little circle in the lower-right corner animates, but nothing else ever happens.

Assuming that you haven't created a character yet, that sounds like it's trying to play the opening movie cutscene and failing. You can skip it by editing the "~/Documents/My Games/FINAL FANTASY XIV - A Realm Reborn/FFXIV.cfg" file and editing the line "CutsceneMovieOpening 0" to "CutsceneMovieOpening 1". (Or adding that line if you don't see it.)

Also, if you want to look at the opening movie cutscene outside of the game, it's at https://www.youtube.com/watch?v=443ogl24K0Y .

Thanks! Looks like that did it!

I have a small question: How did you get around the license check error? Does Proton ship with HideWineExports enabled by default or does the game have the check removed entirely?

FFXIV Mac moved to a CrossOver-based build which doesn't use the old Cider hacks, so for the Shadowbringers update all that stuff got removed.

That doesn't appear to be the case in at least 5.05; running with vanilla Wine 4.12.1, the launcher still throws a license error on login. Patching in HideWineExports and toggling it on makes the launcher work normally again.

i have started to have dll errors recently; strange enough, limiting fps seems like a solution for the time being...

has anyone else observed/experienced this behavior too?
obsolete, bad hardware was the cause

What do you mean by "dll errors", how recent is "recently", which Proton version are you using and what's your hardware?

@doitsujin nay, it appears that it was a hardware issue

still as a side note, updating drivers did cause errors with d3d11.dll & ntdll.dll back in the day. cleaning prefix solved that issue.

That doesn't appear to be the case in at least 5.05; running with vanilla Wine 4.12.1, the launcher still throws a license error on login. Patching in HideWineExports and toggling it on makes the launcher work normally again.

Contrary experience here, I toggled HideWineExports off on my install and I can log in normally still. Which launcher are you using? Have you switched over to ffxivboot64.exe?

Yes, I've been using ffxivboot64.exe since 5.0 launched.

EDIT: The boot and launcher windows both give the version number 2019.06.10.0000.0001 in the title bar. The boot version check passes normally, but is it possible I'm somehow not getting the latest version?

Confirming that on the latest version, unticking "Hide Wine version from applications" still works to let me get onto the game.

The latest launcher version is 2019.06.10.0000.0001, but the latest game version string is: "Version: 2019.07.24.0001.0000 (4438681 , ex1:2019.06.12.0000.0000 , ex2:2019.05.31.0000.0000 , ex3:2019.07.24.0000.0000)" It looks indeed like you might not be getting the latest versions, @achurch.

I should also say that I'm not using ffxivboot64.exe; I apparently forgot to update that, and am using ffxivboot.exe. Still, it appears to be working...

I do have the latest game version, but I didn't bother mentioning it since it was the launcher that was throwing a license error.

That said, since it seems to work for everyone else and I'm fine with keeping HideWineExports active, I don't know if there's any need to dig further.

...the launcher is throwing a license error?

All the screenshots I've seen of license errors being thrown are in the game's interface. Is this something new, or has it always been like this and I didn't realise?

It's always been like that. There are two checks, one in the launcher and one in the client itself. I only ever hit the in-game one once, I think when I was still forcing libcef in the 32-bit launcher.

Proton 4.11-2 broke the sound in ffxiv causing it to disappear and system wide the audio was broken like it was too loud(?). If i mute ffxiv in pavucontrol the problem would go away unless I unmute then it would return. Restarting also fixes it.

This happened a few hours after playing.

Audio did not dramatically change between 4.11-1 and 4.11-2. The change was basically FAudio 19.07 to 19.08, which had essentially no functional changes:

https://github.com/FNA-XNA/FAudio/compare/19.07...19.08

EDIT: It also didn’t change much between the last 4.2 release and 4.11:

https://github.com/FNA-XNA/FAudio/compare/19.06.07...19.07

So just a random problem?

Probably, though I would be interested in knowing why system-wide audio was affected. FAudio is just a single connection made through SDL audio, nothing invasive that I'm aware of.

The only issue I have with the game is that I can't have a video playing on my second monitor otherwise the game doesn't register a lot of my inputs and it feels unresponsive. Anyone got a fix?

Running the game with proton 4.11 does not work, it throws a java script error.

You've got to press enter after you type your password instead of clicking on the Log In button.

The only issue I have with the game is that I can't have a video playing on my second monitor otherwise the game doesn't register a lot of my inputs and it feels unresponsive.

Just a shot in the dark, but (1) are you using a gamepad and (2) have you updated SDL recently? There's a bug introduced in SDL 2.0.10 that causes it to drop a lot of joystick inputs: https://bugzilla.libsdl.org/show_bug.cgi?id=4750
That wouldn't have anything to do with video playback, but I suspected a lot of different things on my own system before finally finding that bug.

The only issue I have with the game is that I can't have a video playing on my second monitor otherwise the game doesn't register a lot of my inputs and it feels unresponsive.

Just a shot in the dark, but (1) are you using a gamepad and (2) have you updated SDL recently? There's a bug introduced in SDL 2.0.10 that causes it to drop a lot of joystick inputs: https://bugzilla.libsdl.org/show_bug.cgi?id=4750
That wouldn't have anything to do with video playback, but I suspected a lot of different things on my own system before finally finding that bug.

No, I'm not using a gamepad. I'm using a keyboard and mouse. Seems like I'll have to wait for a fix.

@GhostEther I watch video almost constantly while playing and have no issues, so it's definitely possible. Make sure you're using the latest versions of proton/dxvk and your video card drivers are up to date, slowness/input dropping sounds like some of the bugs from months ago.

Anyone else having the problem that the launcher suddenly claims that their subscription has expired or the service account has not yet been registered? Was working fine yesterday, so might be related to the 5.08 patch :/

Anyone else having the problem that the launcher suddenly claims that their subscription has expired or the service account has not yet been registered? Was working fine yesterday, so might be related to the 5.08 patch :/

They started enforcing that accounts using "Windows" keys must use the launcher outside of Steam and those with "Steam" keys must launch using steam. Either way this is just determined by whether or not the argument "-issteam" is passed to ffxivboot.exe

So, you just need to make sure it is run with that argument if you are using an account with a Steam key or that it is not there if you are using an account with a Windows key.

@Equivocal90 I see, thanks. I'm running a Windows License from within Steam's Proton... so I'll have to figure out a way of preventing stream from passing -issteam.

@Equivocal90 I see, thanks. I'm running a Windows License from within Steam's Proton... so I'll have to figure out a way of preventing stream from passing -issteam.

I'm doing the same thing. I've had to just run it manually with something like the following:
STEAM_COMPAT_DATA_PATH=~/.local/share/Steam/steamapps/compatdata/39210/ python3 "~/.local/share/Steam/steamapps/common/Proton 4.11/proton" waitforexitandrun "~/.local/share/Steam/steamapps/common/FINAL FANTASY XIV Online/boot/ffxivboot.exe"

I just had to expand ~ to the actual folder for some reason that may be specific to python that I'm not familiar with.

Well that didn't work in my case, for some reason wine kept crashing with a vulkan error.

In the end I just patched the proton python wrapper script to drop the -issteam argument before launching the game :)

If anyone is having weird artifacting after game updates, make sure to clear out your shader cache.

For me I got a trippy technicolor character portrait and random objects being replaced with white blur as if my game was corrupted with light aether until I nuked my shader cache.

@jbal91 by shader cache, you mean the one created by the driver? Are you on Nvidia?

Every time i launch the game FFXIV,cfg gets re-written, so it doesn't save my resolution and graphics settings, any ideas?
Swapping to proton-ge-custom/releases/tag/4.15-GE-1 (or above) fixes this issue, but i see it with standard proton 4.11.3
and custom/releases/tag/4.10-GE-3

Sounds like a permissions issue. Make sure the config files are writable?
Unless this is that old bug proton bug.

ons. 11. sep. 2019, 23:53 skrev asim-vax notifications@github.com:

Every time i launch the game FFXIV,cfg gets re-written, so it doesn't save
my resolution and graphics settings, any ideas?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKDV7DJ64ZP5T75ISHTQJFSDZA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6QAMUY#issuecomment-530581075,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4BBKHX7MAHDM3F7PXUAMDQJFSDZANCNFSM4FRR7KYQ
.

So I tried all the suggested fixes (CutsceneMovieOpening 1, BrowserType 2, using Proton-4.15-GE-4 but am getting this error when starting the game via the launcher:

An unexpected error has occurred. Exiting FINAL FANTASY XIV.

ffxiv_dx11.exe+1120F78
...
ntdll.dll+B314D

I am using the ffxivboot.exe, not ffxivboot64.exe since logging in via ffxivboot64.exe says I dont have a valid FFXIV license assigned to my SQEX account (the error you'd usually get when trying to use an account with a Steam-key in the non-Steam launcher), using a 64-bit wineprefix.

Does or did anyone else experience this? Is there another fix i can try?

The game worked perfectly fine with proton 4.11-3, but with 4.11-4 after starting the game from the launcher all I get is a black screen.

At the moment, I have no fix for running a windows-key under Steam. Unfortunately it looks like the -issteam flag lives inside of ~/.steam/root/appcache/appinfo.vdf. While it seems possible to edit the file directly, it's a binary format and... it's probably an ugly fix that I'm not looking to delve too deep into myself. Windows users are using SteamEdit to update the file and bypass the check, but I'm not looking to mess with that, personally.
Hopefully someone smarter than me has a better answer to this. Maybe there's some way to strip the check out at runtime via the Set Launch Options -- but I don't know it.

@HereInPlainSight I've had success setting Set Launch Options to
echo %command%; "/home/XXX/.local/share/Steam/steamapps/common/Proton 4.11/proton" waitforexitandrun "/home/XXX/.local/share/Steam/steamapps/common/FINAL FANTASY XIV Online/boot/ffxivboot.exe, which essentially replaces the original command with a noop and then runs the actual command with no -issteam afterwards.

@HereInPlainSight I've had success setting Set Launch Options to
echo %command%; "/home/XXX/.local/share/Steam/steamapps/common/Proton 4.11/proton" waitforexitandrun "/home/XXX/.local/share/Steam/steamapps/common/FINAL FANTASY XIV Online/boot/ffxivboot.exe, which essentially replaces the original command with a noop and then runs the actual command with no -issteam afterwards.

Behold -- the aforementioned Someone Smarter Than Me. Makes sense as soon as I read it, not sure why I didn't think to just rebuild the command. Thanks!

@HereInPlainSight I've had success setting Set Launch Options to
echo %command%; "/home/XXX/.local/share/Steam/steamapps/common/Proton 4.11/proton" waitforexitandrun "/home/XXX/.local/share/Steam/steamapps/common/FINAL FANTASY XIV Online/boot/ffxivboot.exe, which essentially replaces the original command with a noop and then runs the actual command with no -issteam afterwards.

This is really smart! It actually makes certain types of ports much smoother without the need for a whole compatibilitytool (ignoring the redist installs, anyway): https://github.com/ValveSoftware/Proton/issues/1783

So I tried all the suggested fixes (CutsceneMovieOpening 1, BrowserType 2, using Proton-4.15-GE-4 but am getting this error when starting the game via the launcher:

An unexpected error has occurred. Exiting FINAL FANTASY XIV.

ffxiv_dx11.exe+1120F78
...
ntdll.dll+B314D

I am using the ffxivboot.exe, not ffxivboot64.exe since logging in via ffxivboot64.exe says I dont have a valid FFXIV license assigned to my SQEX account (the error you'd usually get when trying to use an account with a Steam-key in the non-Steam launcher), using a 64-bit wineprefix.

Does or did anyone else experience this? Is there another fix i can try?

Actually, i turns out that im having this error on Windows as well. So probably my files are just corrupt. But anyway, its not proton-reloated.

The game is now playable for me with the proton 4.11-5 update as it was not with 4.11-4 and I had to revert to 4.11-2.

update on prerendered cutscenes:

with winetricks directshow i managed to get it past the first "no class object" error, following a hint from https://forum.winehq.org/viewtopic.php?t=688
i'm now encountering the same error but with a different clsid but i don't know what dll is meant to provide that. the clsid is 2eeb4adf-4578-4d10-bca7-bb955f56320a if anyone knows how to follow that lead?

edit: apparently this is from wmadmod.dll. however, copying that dll from a windows installation doesn't seem to help as it is never loaded. not sure what i need to do for that

I used Tesu's excellent suggestion for getting getting past the -issteam problem, however now, when I log into a data server, nothing loads. I just get that spinning pinwheel thing in the bottom right-hand corner.

PROTON_LOG out put
Steam - System Information

I used Tesu's excellent suggestion for getting getting past the -issteam problem, however now, when I log into a data server, nothing loads. I just get that spinning pinwheel thing in the bottom right-hand corner.

PROTON_LOG out put
Steam - System Information

thats because the initial cutscene of the game cannot be played, you can change the setting in the CutsceneMovieOpening entry in the FFXIV.cfg file, which is in Documents/My Games/Final Fantasy XIV - A Realm Reborn by default, to 1

that will skip the cutscene and you should be able to get to the character selection screen

I used Tesu's excellent suggestion for getting getting past the -issteam problem, however now, when I log into a data server, nothing loads. I just get that spinning pinwheel thing in the bottom right-hand corner.
PROTON_LOG out put
Steam - System Information

thats because the initial cutscene of the game cannot be played, you can change the setting in the CutsceneMovieOpening entry in the FFXIV.cfg file, which is in Documents/My Games/Final Fantasy XIV - A Realm Reborn by default, to 1

that will skip the cutscene and you should be able to get to the character selection screen

This worked, however when I tried changing the graphics settings in game it locked up my system and I have to SysRq REI (but not SUB) to recover.

This worked, however when I tried changing the graphics settings in game it locked up my system and I have to SysRq REI (but not SUB) to recover.

That can occur on certain configurations involving AMD GPUs, the "Real-Time Reflections" option, and outdated versions of LLVM/Mesa.

Leave "Real-Time Reflections" off and you should be fine. I've heard that upgrading to LLVM 7+/Mesa 18.2+ fixes the issue, and for the most part it does, but personally even with those I've still come across the odd rare situation (in the Azim Steppe) where video lockups still occur.

I'd just suggest leaving the option off permanently.

This worked, however when I tried changing the graphics settings in game it locked up my system and I have to SysRq REI (but not SUB) to recover.

That can occur on certain configurations involving AMD GPUs, the "Real-Time Reflections" option, and outdated versions of LLVM/Mesa.

Leave "Real-Time Reflections" off and you should be fine. I've heard that upgrading to LLVM 7+/Mesa 18.2+ fixes the issue, and for the most part it does, but personally even with those I've still come across the odd rare situation (in the Azim Steppe) where video lockups still occur.

I'd just suggest leaving the option off permanently.

I have an nVidia 950, and as I'm using Arch, I'm pretty sure my LLVM is up-to-date. Also, I was turning the graphics settings down, not up. The game had it set at "high-end laptop" and I reduced that to "standard desktop".

Welp, there's a new launcher. It stinks. It doesn't render the login fields and a bunch of other things on Linux. On windows you can go to config and go back to the old launcher but apparently that won't be around forever. It seems like the new one heavily relies on IE11, anyone have any insights?

OK if you want to log in on Linux, click the gear icon then scroll down and click the last grey box, that's the option to go back to the old layout. It has scrollbars now but it works, at least it gets me to the "unavailable during maintenance" screen.

Do you have the config line corresponding to that option? I can't even get the settings view to scroll.

there appears to be a new option in FFXIV_BOOT.cfg called Browser where 1 is the old launcher and 2 is the new one

the new launcher design isn't coming to macos yet, right? it may be worth waiting a bit to see how they make it work on there

fwiw I was able to log in using the new launcher - scrolled all the way to the bottom and the login form was rendered there for whatever reason.

for me the new client doesnt even go further than this screen

disclaimer that im using not proton, but wine 4.16
edit: can confirm other people have this problem with vanilla wine here

I'm on lutris using the tkg-ffxiv-feffe-4.6-1.8-x86_64 runner still, the new launcher loads fine for me, but I can't scroll down, or really interact with it at all, without it freezing. I had it freeze on that display only when server load was high.

for me the new client doesnt even go further than this screen

disclaimer that im using not proton, but wine 4.16
edit: can confirm other people have this problem with vanilla wine here

with the patched version provided in the thread here, the launcher will start and work somewhat properly, with the login prompt rendering at the bottom of the page, and no titlebar showing

Works functionally without a hitch on ge-protonified-4.10, but there are some graphical problems like header transparency being bork. Haven't really compared it to the version running on windows though.

I was able to load the old launcher by setting Browser 1 in FFXIV_BOOT.cfg as @ashkitten suggested. In case it also matters, BrowserType is set to 0.

There is a nice little warning in the launcher config warning that this isn't going to last. I'm guessing when W7 support ends?

New launcher loaded for me without a hitch. Pop!_OS + patched Proton.

@aberardinelli which patch are you referring to?

@aberardinelli which patch are you referring to?

Ahh I was afraid someone was going to ask this. Going back to sift through old comments in this thread to find the right one...
Version shows in steam as Proton-4.10-GE-3
Posted by @GloriousEggroll on 6/22 in this comment: https://github.com/ValveSoftware/Proton/issues/580#issuecomment-504688485

Works on both my laptop & my desktop.

It's probably IsTransgaming that makes it work.Probably forces CEF like it does in the old launcher.

It'd be nice if we could get it working with Wine MSHTML like we did the old launcher, though.

Does anyone else experience random crashes while workspace switching since today?

EDIT: It also seems to happen in window mode & while the game is not focused
EDIT2: The crashes went away after restarting Xorg for some reason.

Does anyone else experience random crashes while workspace switching since today?

EDIT: It also seems to happen in window mode & while the game is not focused

I haven't had this issue. Which DE are you using? I'm using Gnome Shell.

Works functionally without a hitch on ge-protonified-4.10, but there are some graphical problems like header transparency being bork. Haven't really compared it to the version running on windows though.

I went ahead and gave ge-protonified-4.10 a shot as per your suggestion and indeed the new launcher seems to work fine, though it renders the login form below the rest of the content and is a bit inconsistent. I think it runs a bit better than the 4.8 I was using too but that could be psychosomatic, I'm just always hesitant to update because if it ain't broke.... 😄

I just tried the Proton-4.19-GE-1 release and the new login works + the title screen to character selections transition animation seems to run way smoother now. Also the old bug where you need to choose "data center" instead of "start" has been fixed....I havent played (enough) yet, so I can't say anything about gameplay fps improvements (but I did seem to get ~30fps on 4k with my old gtx 970, using "laptop high" pre- graphics settings)

system spec:

inxi -bxx
System:    Host: linux Kernel: 5.3.7-1-default x86_64 bits: 64 compiler: gcc v: 9.2.1 Console: tty 1 dm: SDDM 
           Distro: openSUSE Tumbleweed 20191101 
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: 4391 MHz min/max: 800/4400 MHz 
Graphics:  Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: eVga.com. driver: nvidia v: 440.26 bus ID: 01:00.0 
           chip ID: 10de:13c2 
           Display: server: X.org 1.20.5 driver: nvidia compositor: kwin_x11 tty: 273x33 
           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: 34.23 TiB used: 33.34 TiB (97.4%) 
Info:      Processes: 380 Uptime: 1h 05m Memory: 15.57 GiB used: 7.20 GiB (46.2%) Init: systemd v: 243 runlevel: 5 
           target: graphical.target Compilers: gcc: 9.2.1 alt: 9 clang: 8.0.1 Shell: bash v: 5.0.11 running in: tty 1 
           inxi: 3.0.32 

I've tried Proton 4.2-9, 4.11-9, and 4.21-GE-1 and all three show the same splash screen:

The results are the same with Browser 1 and Browser 0. Currently running Fedora 30 + KDE 5

@Romdeau4 i have the same problem, i have tried Proton-4.21-GE-1 and gallium9, can't scroll, i have also tired browsertype 2

@Romdeau4 @tuxutku This probably isn't your issue but I had the same issue until I remembered that I had set the launch option that was posted earlier in this thread to remove the -issteam argument. I needed to update that launch option to use the GE custom Proton.

I have only been able to get the new launcher to work with ge-protonofied-4.10, it seems like later versions just get that solid screen with the FFXIV logo on the launcher and never let you access the rest of it.

Hi everyone,
I think I've managed to resolve the issue, at least within my custom version. I simply replaced ffxivboot.exe with ffxivboot64.exe, and the launcher worked. If you are using my custom build, please try opening the following:

FFXIV Official:
Proton-4.21-GE-1/protonfixes/gamefixes/312060.py

FFXIV Trial:
Proton-4.21-GE-1/protonfixes/gamefixes/39210.py

and replace the contents with the following:

""" Game fix for FFXIV Trial
"""
#pylint: disable=C0103

from protonfixes import util
import os

def main():
    """ for FFXIV skip intro cutscene to allow game to work.
    """
    # Fixes the startup process.
    util.replace_command('ffxivboot.exe', 'ffxivboot64.exe')

    # disable new character intro cutscene to prevent black screen loop
    configpath = os.path.join(util.protonprefix(), 'drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn')
    if not os.path.exists(configpath):
        os.makedirs(configpath)
    configgame = os.path.join(configpath, 'FFXIV.cfg')
    if not os.path.isfile(configgame):
        f = open(configgame,"w+")
        f.write("<FINAL FANTASY XIV Config File>\n\n<Cutscene Settings>\nCutsceneMovieOpening 1")
        f.close

I have -not- tried to log in game yet, as I own a standalone account and am not sure if the license differs from steam licenses.

Edit: New launcher does not render, but at least it doesn't crash. Old launcher still works. Need to set Browser 1 in FFXIV_BOOT.cfg

There's no difference between the Windows licences. It's just if you're
trying to use a Steam licence in standalone, you need to append -issteam

Idk why Square did it that way lol
Seems kinda lazy to me, if the goal was to make a distinction. Better than
maintaining two builds, I guess.

On Sat, 7 Dec 2019, 05:39 Thomas Crider, notifications@github.com wrote:

Hi everyone,
I think I've managed to resolve the issue, at least within my custom
version. I simply replaced ffxivboot.exe with ffxivboot64.exe, and the
launcher worked. If you are using my custom build, please try opening the
following:

FFXIV Official:
Proton-4.21-GE-1/protonfixes/gamefixes/312060.py

FFXIV Trial:
Proton-4.21-GE-1/protonfixes/gamefixes/39210.py

and replace the contents with the following:

""" Game fix for FFXIV Trial
"""

pylint: disable=C0103

from protonfixes import util
import os

def main():
""" for FFXIV skip intro cutscene to allow game to work.
"""
# Fixes the startup process.
util.replace_command('ffxivboot.exe', 'ffxivboot64.exe')

# disable new character intro cutscene to prevent black screen loop
configpath = os.path.join(util.protonprefix(), 'drive_c/users/steamuser/My Documents/My Games/FINAL FANTASY XIV - A Realm Reborn')
if not os.path.exists(configpath):
    os.makedirs(configpath)
configgame = os.path.join(configpath, 'FFXIV.cfg')
if not os.path.isfile(configgame):
    f = open(configgame,"w+")
    f.write("<FINAL FANTASY XIV Config File>\n\n<Cutscene Settings>\nCutsceneMovieOpening 1")
    f.close

I have -not- tried to log in game yet, as I own a standalone account and
am not sure if the license differs from steam licenses.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AD4BBKBULR6DO6265I5LSHLQXMSGHA5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGF5U6I#issuecomment-562813561,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4BBKCPUADHYVFBK4ECPX3QXMSGHANCNFSM4FRR7KYQ
.

Edit: New launcher does not render, but at least it doesn't crash. Old launcher still works. Need to set Browser 1 in FFXIV_BOOT.cfg

Setting Browser 1 in FFXIV_BOOT.cfg did fixed my roblem :)

I updated the python script as per GE's instruction, set Browser 1 in FFXIV_BOOT.cfg, and added the flag -issteam and it looks like we're installing!

So pumped to get back into FFXIV. Thanks for all your help everyone

directx 9.0c mode doesn't work (at least with gallium9). I did installed dxwebsetup.exe to suppress the error message The latest version of DirectX is required to play FINAL FANTASY XIV, Please download and install the DirectX End-User Runtime, then restart the game,----(0) , game did launched after that but it's crashed after about 10 seconds while using about %50 cpu. From terminal it didn't reported that Gallium nine was being used anytime (However there were d3d9 related debug messages).

However DXVK performance is pretty good for amd a10-9620p.

P.S: I have used run file method since steam disables gallium9

@GloriousEggroll your 4.10 build works on the new launcher, even if it renders funny. the old launcher interface is slated to be removed/depreciated so it'd be much better to ensure that the new one at least works than relying on being able to set it to use the old one, do you have any insight as to why it regressed in more recent builds?

@GloriousEggroll your 4.10 build works on the new launcher, even if it renders funny. the old launcher interface is slated to be removed/depreciated so it'd be much better to ensure that the new one at least works than relying on being able to set it to use the old one, do you have any insight as to why it regressed in more recent builds?

Can you double check that? I had someone test, where it worked for them, then they removed the prefix, and upon making a clean prefix it did not work.

And to be clear: The intent is not to permanently rely on the old launcher. Ultimately it will need to be fixed. The intent of my original comments was to get the game working for people who want to play.

I've managed to get the game installed under Proton 4.21-GE-1 and using the new launcher, but it looks like I have a DirectX issue now.

System:    Host: localhost.localdomain Kernel: 5.3.14-200.fc30.x86_64 x86_64 bits: 64 compiler: gcc 
           v: 9.2.1 Desktop: KDE Plasma 5.15.5 tk: Qt 5.12.5 wm: kwin_x11 dm: SDDM 
           Distro: Fedora release 30 (Thirty) 
Machine:   Type: Desktop Mobo: Gigabyte model: H81M-S1 v: x.x serial: <root required> 
           BIOS: American Megatrends v: FF date: 06/20/2014 
CPU:       Quad Core: Intel Core i5-4460 type: MCP arch: Haswell speed: 3389 MHz min/max: 800/3400 MHz 
Graphics:  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics vendor: Gigabyte 
           driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:0412 
           Device-2: AMD Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X] vendor: PC Partner Limited 
           driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6810 
           Display: x11 server: Fedora Project X.org 1.20.5 driver: modesetting,radeon FAILED: ati 
           unloaded: fbdev,vesa compositor: kwin_x11 resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: renderer: AMD PITCAIRN (DRM 2.50.0 5.3.14-200.fc30.x86_64 LLVM 8.0.0) v: 4.5 Mesa 19.1.8 
           direct render: Yes 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Gigabyte driver: r8169 
           v: kernel port: d000 bus ID: 03:00.0 chip ID: 10ec:8168 
Drives:    Local Storage: total: 1.13 TiB used: 156.92 GiB (13.6%) 
Info:      Processes: 236 Uptime: 1h 13m Memory: 7.65 GiB used: 3.09 GiB (40.4%) Init: systemd v: 241 
           runlevel: 5 target: graphical.target Compilers: gcc: 9.2.1 Shell: bash v: 5.0.7 
           running in: konsole inxi: 3.0.37 

Hello @Romdeau4, Intel/Haswell has an experimental vulkan implementation and linux uses the radeon kernel module by default with your Southern Island (SI) generation AMD chipset. The radeon kernel module is not compatible with Vulkan.

Please give https://github.com/ValveSoftware/Proton/wiki/For-AMD-users-having-issues-with-non-OpenGL-games a read.

@kisak-valve Thank you so much, that helped and the game is running buttery smooth.
For visibility and other Fedora 30 users that may have not been aware:

Edit /etc/default/grub and add radeon.si_support=0 amdgpu.si_support=1 and radeon.cik_support=0 amdgpu.cik_support=1 to the option GRUB_CMDLINE_LINUX_DEFAULT

Afterwards, update your grub config with either sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg for UEFI systems or sudo grub2-mkconfig -o /boot/grub2/grub.cfg for BIOS systems.

Reboot your system and confirm you're running amdgpu kernel driver with lspci -k.

The new launcher still does not work. It is just the final fantasy xiv logo and I can either press minimise or quit.

Stupid question maybe, but could you set the file as read only?

On Tue, Dec 17, 2019, 6:57 PM zangoku notifications@github.com wrote:

It keeps overwriting my value of 1 by the value of 2 in ffxiv_boot.cfg.
Therefore I am unable to play the game.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/580?email_source=notifications&email_token=AGC7S2Z6X67GRZ27I6BM2UDQZFRP5A5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHELVPA#issuecomment-566803132,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGC7S25WEM5ZYUU2V4UISMTQZFRP5ANCNFSM4FRR7KYQ
.

Stupid question maybe, but could you set the file as read only?
…
On Tue, Dec 17, 2019, 6:57 PM zangoku @.*> wrote: It keeps overwriting my value of 1 by the value of 2 in ffxiv_boot.cfg. Therefore I am unable to play the game. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#580?email_source=notifications&email_token=AGC7S2Z6X67GRZ27I6BM2UDQZFRP5A5CNFSM4FRR7KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHELVPA#issuecomment-566803132>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGC7S25WEM5ZYUU2V4UISMTQZFRP5ANCNFSM4FRR7KYQ .

Steam said it had to restart to update, so I did that and then the issue was fixed.

@GloriousEggroll your 4.10 build works on the new launcher, even if it renders funny. the old launcher interface is slated to be removed/depreciated so it'd be much better to ensure that the new one at least works than relying on being able to set it to use the old one, do you have any insight as to why it regressed in more recent builds?

Can you double check that? I had someone test, where it worked for them, then they removed the prefix, and upon making a clean prefix it did not work.

And to be clear: The intent is not to permanently rely on the old launcher. Ultimately it will need to be fixed. The intent of my original comments was to get the game working for people who want to play.

I tried that, and it didn't work for me. The launcher is stuck on title screen. I also tried a bunch of stuff that was suggested here, but nothing helped. I tried switching launcher to the old one, but it makes me go through registration process or something. When I log into my account, launcher asks me to enter my game key, and when I do, it tells me that it is already registered and doesn't let me go forward. I have already played with this account on windows with full game activated.

That's... kinda weird. Are you trying to install through Steam when you have a standalone key, or vice versa? I'm not sure exactly what's happening there, last time I reinstalled I'm pretty sure I said I had an existing account, signed in, and it skipped past that screen. But if it's looking for a steam / non-steam key when you don't have that particular brand of key, maybe that's confusing it?

You could try setting StartupCompleted to 1 in FFXIV_BOOT.cfg, maybe? At best that'll get you past that particular screen.

@GloriousEggroll your 4.10 build works on the new launcher, even if it renders funny. the old launcher interface is slated to be removed/depreciated so it'd be much better to ensure that the new one at least works than relying on being able to set it to use the old one, do you have any insight as to why it regressed in more recent builds?

Can you double check that? I had someone test, where it worked for them, then they removed the prefix, and upon making a clean prefix it did not work.

And to be clear: The intent is not to permanently rely on the old launcher. Ultimately it will need to be fixed. The intent of my original comments was to get the game working for people who want to play.

To follow up on this, it just kind of suddenly stopped working :( Is there a way to change a config file to show the old launcher?

To follow up on this, it just kind of suddenly stopped working :( Is there a way to change a config file to show the old launcher?

In FFXIV_BOOT.cfg, set Browser to 1.