I wonder if anyone has managed to get the new client working under Wine? In my Linux setup, the current client crashes straight after Launchpad when the game tries to construct character selection screen. The pre-f2p VGClient.exe did run the game just fine with exactly the same Wine version and configuration. Wine itself doesn't give any extra errors compared to previous client. I have also tried to trace Wine's internals, but didn't catch anything suspicious. I am using 32-bit wine (ver 1.5.9 and 1.5.10) with Fedora 17 x86_64. Windows compatibility is set to Windows XP. Here is the vgclient.log from fresh installation of the game: http://pastebay.net/1070638 The client dies with "Critical: Couldn't load HLSL shader header 'VS_UIRectangle.fx'". This error seems to be related to detected base directory "Init: Base directory: ... Installed Games\Vanguard\bin\.", which does have a trailing dot in the path. If I create directory "bin\.Caches" the game manages to create file "bin\.Caches\CompiledShaders.shd", but dies with the same error. If I create "bin\.Caches" as symbolic link to "bin\Caches" the game proceeds further until dies with "Critical: Couldn't load HLSL shader header 'PS_UberShader.fx'". Extra dot in the base directory path might be Wine specific bug, but it would be nice to know how the implementation has changed from pre-f2p client (so Wine could be fixed). There is some reports on the forum about crash with 'PS_UberShader.fx', but suggested fix of cleaning Caches directory does not work at least here.
I was able to get the game working, minus the interface before the f2p launch - however now I cannot get LaunchPad4 to do anything but show a black screen. (This is for all SOE games) If you can give me some advice to fix this, I'll be more then willing to troubleshoot through this.
I'm personally a big linux fan. When we get some of these current bugs worked out; I'd be happy to try and help ya'll get VG to work in wine. For right now, lemme throw you a bone, the way that the path works is the startup code sequence discovers the local directory that VG is run from. http://msdn.microsoft.com/en-us/lib...v=vs.71%29.aspx that's essentially the call that is used when compiled for windows. It then will add Caches\\NewCombinations\\ShaderCombinations as a final string in the shader batch compiler. I don't have a linux setup, it's obviously not supported; but lemme know if you get it to work or if you run into other issues. If you catch me when I'm not too terribly busy, we're all busy right now, I'll see if I can throw you some more bones. Also, launchpad is another team, so I can't help you much there in getting it working. However, launchpad is necessary for the correct running of Vanguard. It handles your ability to login to our servers and you MUST have a valid session to let VG run which Launchpad provides. It also handles patching in a known/safe way.
Darlim: I don't have any other SOE game than VG, but at least the version of Launchpad that got installed with Vanguard_setup.exe is working well here (and has been working well since spring). AppDb at winehq.org does have several reports similar to yours for other SOE games. What has worked for some people is reinstallation of the game to separate wineprefix. This is a good idea with Wine anyway. What platform and version of Wine you are using? There has been a lot of bug fixing in Wine recently and it is recommended to upgrade if you have anything older than version 1.4. gpx1000: thank you for the hint. I'm not exactly a C/C++ programmer, but managed to compile small windows program with _wgetcwd and some other file system calls that vgclient.exe seems to be using. I ran the tests with native Windows XP and Wine under Linux, but couldn't find any differences in results, at least for the test cases that were used. Here is some additional data about the problem, just in case someone is able to make sense out of it: http://pastebay.net/1073009 It's a small snippet from trace log created by "WINEDEBUG=+file wine Launchpad.exe". This is the first place in the log where that trouble making path with dot is found. Later on in the log, the path is used only to access files in Caches directory (like gpx1000 said). All other file access seems to be ok.
My "gut" feeling is that the bug doesn't have to do with the extra . I'm going to guess that what it has to do with is the default path that we give it to generate the new directory having the windows '\' in it. Try making certain that the directory structure looks like this: Vanguard/bin/Caches/NewCombinations Vanguard/bin/Caches/ProvidedShaders What I'm guessing this will do is allievate Wine from having to translate the path sent to the create directory C++ windows call; and thus allow the game to read/write to the shader cache so it can compile the HLSL. However, this is very much a guess and I'm probably wrong about it.
Those directories exists and are created correctly by launchpad and vgclient, if they are missing. Got the game sort of working with a workaround. If I create symbolic link (ln -s Caches .Caches) and dummy file (.PS_UberShader.fx) to the Vanguard\bin directory, the shader compiler complains loudly but does not crash the client. The drawback is that player characters and NPCs are not rendered properly and mostly invisible. However, other aspects of the game, like crafting or exchange, are working just fine without any visual problems. I am now really out of ideas what could cause different behavior in Wine compared to native Windows. It is related to some new logic in the client that went live with f2p. I doubt that the reason is simply buggy file-system calls in Wine though. After all those years of Wine development, one would expect them to be quite well tested by now.
zap wrote: The PS_UberShader.fx file is HLSL code. Wine doesn't handle shaders well yet. One of the things I fixed a while ago and went live in the F2P was to make the HLSL compiled shader code work in windows. Looks like wine is now starting to get a HLSL to GLSL converter going you might see if you have success with getting 1.5.6 or better working. http://www.winehq.org/announce/1.5.6 Very intresting that it needed .Caches, I have no idea where the '.' is coming from...
I'm on wine 1.5.11 and experiencing the same problem. I don't suppose anyone knows if there's any native Windows dlls that can be used to resolve this issue? I followed the development of Vanguard back in the day and I'd love to give it a try now. If I use the "balanced quality" settings I see only faces on player models, if I use the "highest performance" setting I see bodies but no faces. On the highest quality" settings I see nothing at all. ^^
What it sounds like is the HLSL code isn't working even in the (next to) very latest version of Wine. If I get some time I might do some research on if I translate the HLSL to GLSL by hand and provide both if Wine would be fine with that. In anycase, I don't know what else would help ya'll out. I'll see if there's some documentation that wine provides that might help out.
I had a thought. Try deleting all *.shd files within the Caches directory and the .uz2 inside of NewCombinations. You might have to do this after Launchpad has confirmed that all files are there to get the delte to take effect. What this should do is convince Vanguard to build the shaders from source instead of trying to use the compiled shaders. I'm imagining this to be easier on Wine than the alternative.
Removing contents of the bin/Caches/ causes the same error as in the first post ("Critical: Couldn't load HLSL shader header 'VS_UIRectangle.fx'"). The same happens if bUseProvidedShaders=False is set in vgclient.ini. I suppose that the HLSL compiler used is the one in d3dx9_31.dll. Wine does have it's own implementation of this dll and HLSL compiler, but I have verified that d3dx9_31.dll that is actually used, is loaded from Vanguard/bin directory, so there shouldn't be any incompatibility because of this. Some documentation about how HLSL shaders are handled in Wine can be found here. If I understand this right, Wine uses bytecode generated by HLSL compiler, but not HLSL code directly. I don't think Wine's problem is with HLSL or compiled bytecode. For example, using ProvidedShaders does work fine now (after fixing the path with symlink) and forcing recompile (with bUseProvidedShaders=False) has been working in the past. What is not working is shader compiling, but I guess that is just because call like D3DXCompileShaderFromFile() points to non-existing file. This could explain why creating empty file ".PS_UberShader.fx" allows the game continue. Shader compiler does not like empty file, but on the other hand it does not crash the client.
