Final Fantasy 14 (39210)

[nstgc]

Final Fantasy 14's installer (after Steam does it's own installing) doesn't have any fonts its seems, favoring [] over actual characters. Even the numbers, so its not that its trying to display Japanese characters and my system is missing them (which is not the case since I occasionally use them myself). Potential UTF-8 problem?

[witcheslive]

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.

[HereInPlainSight]

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.

[karlsbjorn]

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

[ghost]

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)

[witcheslive]

@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

[greydmiyu]

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.

[witcheslive]

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!

[e3b0c442]

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

[Mushoz]

@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.

[greydmiyu]

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.

[Mushoz]

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]

@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.

[witcheslive]

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

[fosspill]

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..)

[dlove67]

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

[fosspill]

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

[TenaarFeiri]

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...

[fosspill]

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

[TenaarFeiri]

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

[fosspill]

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

[fosspill]

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.

[madipietro]

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!

[TenaarFeiri]

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.

[fosspill]

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.

[kisak-valve]

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.

[TenaarFeiri]

PROTON_LOG=1 %command%

Absolutely! steam-39210.log

[TenaarFeiri]

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.

[exolyte]

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.

[fosspill]

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?

[nourez]

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?

[fosspill]

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?

[TenaarFeiri]

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.

[nourez]

@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?

[fosspill]

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.

[TenaarFeiri]

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.

[fosspill]

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

[jbalme]

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

[ashkitten]

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

[witcheslive]

@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?

[fosspill]

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?

[exolyte]

@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.

[ashkitten]

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

[Equivocal90]

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.

[witcheslive]

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

[ashkitten]

@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

[nourez]

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

[witcheslive]

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.

[ashkitten]

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

[fosspill]

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

[TenaarFeiri]

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.