Talk:Guild Wars on Wine/before 1.3.0
Blue Screen
I know its not possible to get the BSOD on Kubuntu, but whenever I try to start GWs it just shows a giant, blue screen on my desktop. I can switch to another desktop (Ctrl-Alt-<left/right arrow key>) and it switches to that desktop fine, but I still cannot get it to work. I am running Kubuntu 8.10 with KDE 4.1 and the latest GWs. ╙─ ╠Dogzrdogz╣ talk
- I had the same problem on my Ubuntu 9.04 with Wine 1.1.20. In Wine configuration under the Graphics tab, I unchecked "Allow Pixel Shader." This got rid of the blue screen for me. Tedium 09:08, 26 April 2009 (UTC)
Broken
Hewus has updated the article page to exclude the dev release of Wine, as it "has been seriously broken since 1.1.22" as he puts it. It's worth noting that the Update Manager on Ubuntu will update to the development (not stable) version! The break on my GW is that it has to repair the Data Archive each time it loads - I presume Hewus has the same problem? I have uninstalled GW, updated Wine to 1.1.23 and will reinstall GW later as I've been busy all day. I will let you know what happens when I reinstall. (I finally got rid of everything Microsoft and this happens so you can all blame me as the resident planet Earth jinx. What's worse is that Windows 7 - on a different machine - is working well!) LOL – josəph 18:13, 6 June 2009 (UTC)
- Update: It appears that v1.1.23 won't even install GW. It downloads the first bit but after that the process goes to sleep. I'm considering saving my pennies for Windows 7 now, rather than spend it on Crossover. Damn Microsoft's monopoly. – josəph 00:32, 8 June 2009 (UTC)
- Try installing from source, you get to install each version in it own concurent location. This allow you yo use any version no matter what the update manager push on you. And allow you yo go back previous version. 1.1.20 is what worst best for me now, ill try 1.1.23 as soon as compiling is over :X --Bob 17:20, 9 June 2009 (UTC)
- With 1.1.23, i got the same "repair the data archive" problem as in 1.1.22 that you describe. --Bob 05:45, 10 June 2009 (UTC)
Not Broken
Talking about 1.1.23, are we? There is no 1.2.23 on WineHQ AFAIK. 1.1.23 seems to work fine (my specs: Debian Lenny 32-bit, Nvidia, Gnome Desktop with compiz). Got no data archive corruption and best results ever (graphics and sound superb). So it might be a distro problem or maybe KDE 4? Have you tried turning off window manager control and decoration in winecfg? Korkman 02:35, 18 June 2009 (UTC)
- Just notice the typo. Yes, i mean 1.1.23, tho i cant wait to see how good will be 1.2 :P --Bob 09:44, 24 June 2009 (UTC)
Wine 1.1.24
I still get the repair-data-archive issue with 1.1.24. if i let it go thru, gw will eventualy start and no data is been corupted in the process. It will do that every time gw is started so ill stay with 1.1.20. Obviously, i didnt test how the FBO fix improve gw with this release. --Bob 09:42, 24 June 2009 (UTC)
Got the same problem now after upgrading 1.1.23 to 1.1.24. Not possible to start. Reverted to 1.1.23, same "corrupt" Gw.dat, no repair necessary on startup. Well, that's why it is called development release ... 1.1.25 should be packaged any day now, will try that again. Korkman 16:48, 5 July 2009 (UTC)
- Unfortunatly, 1.1.25 do the same thing. at last on my system. --Bob 21:28, 11 July 2009 (UTC)
- It's still an issue in 1.1.26. I added a note in the article about the problem. Hopefully this will get fixed soon.--Oln 14:15, 28 July 2009 (UTC)
- As the (inappropriately characterized) response from ArenaNet was (properly) pulled from the main page, I checked the WineHQ bugzilla myself. ArenaNet and NCSoft are indeed going to ignore this unless the issue is pursued. Having done QA kinds of things in the past, I suggest that the direct approach is not going to get the level attention it deserves. Instead, note that this is a PERFORMANCE issue and that, if some versions of Windows does indeed have a problem with 'reallocation' not copying content, that either the extra copying step be skipped on Windows versions where it is not a problem, or that the Windows' copying code be avoided by separating the allocation and de-allocation steps. Also note that they are relying on a corner case of the Windows' reallocation code that may bite them in the future (or may have caused unexplained problems in the past). The fact that this will fix the problem with Wine should be mentioned but not emphasized. As for wine, it might need a bug imitation flag in the registry to work around this particular problem. (As a guess, the de-allocation could be postponed until the next allocation/reallocation/de-allocation request is initiated, but that issue is for the wine maintainers to decide.) --Max 2 07:58, 5 August 2009 (UTC)
- I wonder why NCSoft wants to rely on this bug of Windows and does not want to fix it, it seems that they only rely on this Windows Bug in the Downloader Code and with the given description of the Bug, the culprit should be fairly easy to track in the source code ... . Especially since they should know quite good at which time they introduced it. Ps 15:21, 5 August 2009 (UTC)
- I'm not surprised NCSoft Support's response was dismissive. They are presumably trained to respond to tickets about Linux with a "We don't support that", for the very simple reason that they don't support it.
- I mentioned it to Joe. He says he'll look into it, but no promises. In the meantime, 1.1.20 and earlier work, and the Wine Bugzilla page has a workaround patch attached for newer versions (though I can't personally attest to if that works or not). - Tanetris 18:39, 5 August 2009 (UTC)
- Evidently the diagnosis of the error was wrong, and this is no bug of Windows after all. The wine developer already apologized for the diagnosis in the bug report and there already is a bugfix. See http://bugs.winehq.org/show_bug.cgi?id=18675#c30 Ps 18:42, 5 August 2009 (UTC)
- The issue is fixed in 1.1.27 --Oln 15:15, 8 August 2009 (UTC)
- Evidently the diagnosis of the error was wrong, and this is no bug of Windows after all. The wine developer already apologized for the diagnosis in the bug report and there already is a bugfix. See http://bugs.winehq.org/show_bug.cgi?id=18675#c30 Ps 18:42, 5 August 2009 (UTC)
- I wonder why NCSoft wants to rely on this bug of Windows and does not want to fix it, it seems that they only rely on this Windows Bug in the Downloader Code and with the given description of the Bug, the culprit should be fairly easy to track in the source code ... . Especially since they should know quite good at which time they introduced it. Ps 15:21, 5 August 2009 (UTC)
- As the (inappropriately characterized) response from ArenaNet was (properly) pulled from the main page, I checked the WineHQ bugzilla myself. ArenaNet and NCSoft are indeed going to ignore this unless the issue is pursued. Having done QA kinds of things in the past, I suggest that the direct approach is not going to get the level attention it deserves. Instead, note that this is a PERFORMANCE issue and that, if some versions of Windows does indeed have a problem with 'reallocation' not copying content, that either the extra copying step be skipped on Windows versions where it is not a problem, or that the Windows' copying code be avoided by separating the allocation and de-allocation steps. Also note that they are relying on a corner case of the Windows' reallocation code that may bite them in the future (or may have caused unexplained problems in the past). The fact that this will fix the problem with Wine should be mentioned but not emphasized. As for wine, it might need a bug imitation flag in the registry to work around this particular problem. (As a guess, the de-allocation could be postponed until the next allocation/reallocation/de-allocation request is initiated, but that issue is for the wine maintainers to decide.) --Max 2 07:58, 5 August 2009 (UTC)
- It's still an issue in 1.1.26. I added a note in the article about the problem. Hopefully this will get fixed soon.--Oln 14:15, 28 July 2009 (UTC)
Wine bottle/box
Ill leave this here with the hope it will be of some use to anyone. It a simple script i made to keep each windows apps installation in it own location. This simplify managing of multiple windows apps that like to spread and write bit of everythign everywhere. The script assume wine is installed as proposed in the Wine from source method. Config will go in ~/.winebox/NAME while actual program and data go in ~/Wine/NAME. This make managing files on each bottle/box easy with nautilus and other gui. eg: Link ~/Wine to your desktop or menu.
This is how it work...
Save this as winebox and chmod 755 it. Put some where in your $PATH. ~/bin is a good chose.
#!/bin/bash winever="1.1.20" #change to the version of wine you whant to use winebox="Default" application="" while [ $# != 0 ]; do flag="$1" case "$flag" in -c) DO_CREATE=1 ;; -b) if [ $# -gt 1 ]; then winebox="$2" shift else echo "Missing winebox name" fi ;; *) application="$@" break ;; esac shift done configpath="$HOME/.winebox/$winebox" drivespath="$HOME/Wine/$winebox" export PATH=/usr/local/wine-$winever/bin:$PATH export WINEPREFIX="$configpath" if [ $DO_CREATE ] then echo Creating winebox "$winebox" mkdir -p "$configpath/dosdevices" mkdir -p "$drivespath" ln -sf "$drivespath" "$configpath/dosdevices/c:" cd "$drivespath" wineboot fi if [ -d "$configpath" ] && [ -d "$drivespath" ] then if [ -n "$application" ] then echo "Wine $winever" echo "Run \"$application\" in \"$winebox\"" echo " \"$configpath\", \"$drivespath\"" cd "$drivespath" sleep 2 wine "$application" else echo Starting $shell in wine environement cd "$drivespath" export PS1="winebox:\w C:/>" bash --noprofile --norc fi else echo "No such winebox \"$winebox\"" exit 1 fi
To create a new box that will contain a Guildwars installation for example:
winebox -c -b "Guild Wars"
From there all your envoronement variable are set. you can wget the gwsetup.exe or install from cd.
Next to start gw:
winebox -b "Guild Wars" "C:\Program Files\Guild Wars\Gw.exe"
To edit winecfg:
winebox -b "Guild Wars" winecfg
Just to get a shell with the environement var set:
winebox -b "Guild Wars"
This is not flawless. It is not secure way to sand box windows apps, do not run viruss/trojen/crapware thinking you are safe. It has know bug too, it cant be use to pass argument to gw.exe for example. Feel free to improve or post your own script that you use. --Bob 10:22, 24 June 2009 (UTC)
Instalation notes - Fedora 11
I'm running on a Fedora 11 distro.
I was having trouble and spent some time resolving issues. These are notes on what I did and what happened...
- Which version of Wine?
- The version of Wine packaged with Fedora 11 is neither the latest Stable version nor the latest Development version. It is a development version that has had some testing and patching.
- I was having enough trouble with the normal package that I decided to install from source. The notes here warned that the latest Development version was 'unstable' (to put it politely), so I went with the Stable version (1.0.1). The build blew up.
- Problems with the NVidia OpenGL libraries
- Lots of unresolved symbols... I saved the old versions of /usr/lib/libGL.so... as ....oldnvidia and replaced them with symbolic links to the /usr/lib/nvidia/libGL.so...185... versions. I also noticed libGLcore had a similar structure and took the same action for it.
- Problems with freetype
- Something messed up in the headers. ./configure --without-truetype and rebuild.
- Result
- seems to be stable, with fewer graphic glitches. I'm not sure, but I think it handles line noise better as well.
--Max 2 15:17, 29 July 2009 (UTC)
- I got same trouble with truetype on ubuntu 9.04 amd64. Guildwars work just fine without the truetype support so it isent so bad. The lastest wine 1.1.27 work best. --Bob 21:27, 10 August 2009 (UTC)
Wine 1.1.27
So the good news is archive corruption for big gw.dat files is gone, but I crossed another issue that I could solve by tweaking some registry key:
If your GW screen turns black when post-process effects are enabled:
- Launch wine regedit
- Create key "HKEY_CURRENT_USER/Software/wine/Direct3D", create string "OffscreenRenderingMode", set value to "backbuffer"
Maybe we should create pages for specific wine versions to collect these hints in a more organized fashion?
Korkman 23:01, 12 August 2009 (UTC)
Another issue with 1.1.27: I built 1.1.27 from source on a Fedora 11 system, installed it and tried it. The action was horribly bursty. Run 3 or 4 steps, pause, run 3 or 4 steps, pause... Controls were very erratic. Re-installed 1.0.1 and the problem disappeared. The graphics seemed better but the game was unplayable with 1.1.27. --Max 2 15:48, 13 August 2009 (UTC)
Wine 1.1.28
This release work good using dx9 and high quality shaders. --Bob 01:42, 25 August 2009 (UTC)
Some post-process effect, like the water fall near Fenrir, are draw on top of everything. It look like depth test is disabled. --Bob 06:19, 25 August 2009 (UTC)
Wine 1.1.34
I'm using Ubuntu Jaunty, Catalyst 9.11 (8.671 fglrx release) on an ATI 4770 graphics card and Wine 1.1.34 directly from the (not so stable) "deb http://wine.budgetdedicated.com/apt jaunty main" repository.
This is quite bleeding edge but all works fine.
There are a few glitches:
- You may need the Direct3d registry entry: [HKEY_CURRENT_USER\Software\Wine\Direct3D] "OffscreenRenderingMode" = "backbuffer"
- Screen initialisation needs about 5 seconds longer than on the windows version.
- On 4770 graphics cards there is a serious bug in the ATI driver. It resets of the x.org engine whenever the total gamma values change in the game (like entering a cave). It is playable but anoying.
Wine 1.1.43
I am running Guild Wars on top of Fedora-12. As noted elsewhere, the version of 'wine' they provide is pretty old, so I pulled the 1.1.43 tarball and started working with it. There were problems associated with my hardware configuration:
- Many unresolved 'nvidia' symbols:
- Solution: Add LDFLAGS="-L/usr/lib/nvidia -L/usr/lib" to the configure command line.
(I'm not sure the second '-L' specification is needed.)
- Solution: Add LDFLAGS="-L/usr/lib/nvidia -L/usr/lib" to the configure command line.
- Poor performance
- Analysis: The poor thing thinks it has to deal with a 386. Telling it what it really has to deal with helps.
- Solution: Add CFLAGS="-march=core2" to the configure command line.
The difference is very noticeable.
You will almost certainly need to specify a different architecture than the 'core2' that I used.
The exact architecture of your machine is displayed during the system initialization dialog. You can review that at any time by piping the output of 'dmesg' to your favorite pager. There is a lot of junk you will have to wade through in order to find it. (There is likely a less difficult way to get the information, but I do not know of one off the top of my head.)
--Max 2 07:45, 29 April 2010 (UTC)
Cannot see main Window
Hi everyone. Up to now Guildwars has been running perfectly under wine on my box. But then i seem to have pressed some keys (most likely alt+<something>) and now i cannot see the game window. When i start Guild Wars i can see the updater window and after that i can here the backgroundmusic of the login. However the window is invisible. The problem doesnt get solved by rebooting the computer. I know that this problem has been discussed here before, but there was no solution. Consoleoutput and Infos from xwininfo can be found on my userpage. I really hope someone can tell me how i can get the window visible again CiaraAndraste 16:44, 27 September 2009 (UTC)
- Ok i have playing with wine settings and the problem doesnt get solved by using a virtual screen or disabling windows manager decorations and control. CiaraAndraste 17:19, 27 September 2009 (UTC)
- I was able to resolve the issue by reinstalling GW. It seems the problem was that the inital position of the main window was off screen. I would have prefered other solution like a registry key that holds the initial position but 'wine regedit' didnt have such a thing. Well now GW is back running to my liking and works better than it does on Windows (less texture mistakes on far objects - have had those ever since i was forced to use my backup graphics-card). If someone knows where the initial window position for GW is stored, i would still be happy to know that. CiaraAndraste 20:37, 27 September 2009 (UTC)
I am also getting this same behavior. It would be nice to not have to do the uninstall/install option. Any thoughts out there? WayneMesmer 17:01, 24 December 2009 (UTC)
- Have you tried "Alt+Space,m" then arrow keys to move the window in to view? --BlueNovember 17:32, 28 December 2009 (UTC)
- This doesn't work out because wine doesn't create a window at all in this state. Gw.exe is running but there is no window, even with emulated screen turned on. So nothing to move. Korkman 18:56, 1 January 2010 (UTC)
- Have you tried "Alt+Space,m" then arrow keys to move the window in to view? --BlueNovember 17:32, 28 December 2009 (UTC)
Ugly workaround: Start Gw.exe with an emulated screen and command line switch "-mce", which switches to fullscreen mode immediately. Change to desired resolution in game options. No way yet to restore the initial window position, tough, but it saves your Gw.dat. Korkman 18:56, 1 January 2010 (UTC)
If you share Gw.dat with a windows installation, you may be able to change the window position through launching the game in windows, then change back. Have not tried this yet. Korkman 18:56, 1 January 2010 (UTC)
This issue still exists on Ubuntu 10.04 using Wine 1.1.42. It seems to me to be caused by trying to start in Windowed mode. I "fixed" by transferring a .dat file from another machine that was set to start fullscreen. I had been hunting for a fullscreen switch but couldn't find one, will try the next time with the emulation and -mce. --Dyanarose 06:08, 19 July 2010 (UTC)
I have seen this before, though not as much lately. I always managed to trigger it when moving the window around, at which point it jumped in the same direction that it was moving until it was offscreen. I've managed to catch it while it's moving, and move it back up, but it sometimes keeps going after it's been dropped. If it's still moving, xwininfo might show it moving (position changes on consecutive runs) I found some utilities that could move arbitrary windows around, and so I could move them up into visible space, but it was temperamental and didn't always work. The position is stored in the Gw.dat somewhere. I just started taking backups of the dat file periodically. I didn't get a chance to do hexdumps to see if I could spot an offset for the window position. Perhaps some GW.dat hacker can help. 64.245.3.212 22:20, 28 July 2010 (UTC)
- Oh yea. If you, like me, have the window running off-screen, kill -9 the Gw.exe when it happens, (not after it's happened, and you've restarted) and the Gw.dat file isn't written out with the bogus position in it.
Distro Neutrality
Much of this text isn't very distro-neutral. With such diversity in Linux distros, an article such as this should be distro-neutral so that everyone can follow the directions as easily as possible. 96.42.232.4 07:25, 29 December 2009 (UTC)
- Really? At a glance, it seems pretty neutral to me. The only non-neutral requirement appears to be xorg, but that's reaching a bit, since that's standard on most graphical *nixes these days. That said, I'm not an expert, so if you have any specific ways to improve the article, feel free to discuss them here or just edit the article yourself. :) —Tanaric 09:45, 29 December 2009 (UTC)
- This is a talk page. I'm documenting what I have. I am not insisting anybody use the same distribution I do. I have neither the time nor resources to verify problems on other distributions. --Max 2 07:58, 29 April 2010 (UTC)
Anyone seen this solution?
It's a the regular GW client pre-wrapped in Wine via "WineBottler", to be used in Mac OS X. I'm kinda scared to use it. I've already downloaded it and opened the .app. It seems like it is what it says it is, website seems honest, the guy is Dutch so he can't really mean any harm :P, and the comments show no complaints of keyloggers, which is my main fear.
This isn't a hacked client, but rather the client put into Wine, so you don't have to install Wine and have all these hidden folders littering your HD, which is what's stopping me from using Wine instead. I'm just scared there's some kind of keylogger in it as well, so I first want to see if anyone else is using this.
It'd also be a shame if this guy would get a C&D from you guys if this in any way infringes on the EULA. If it's really legit, consider working together with this guy, ANet! Spore for Mac also uses a derivative of Wine (Cider) to run, and this solution (WineBottler) does the same thing, so this could be seen as a proof of concept to create a GW client for Macs!
Silva 16:04, 6 March 2010 (UTC)
- EULA are always full of crap, no one ever read this stuff, i did not, but i am pretty sure he can't redistribute Gw's executable even tho it is a "free" download... Also this is not a GW client for Macs. Macs and Linux should have there own native client. It is not that hard, many games developers support multiple platform. Wine is a hack and should not be use a permanent solution. And he wont recive C&D from us because wiki users are not anet's Lawyer Horror minions ;) You might have draw attention to him with your post tho.
- As for the security... It all come down to trust. Do you trust this Dutch guy? (Do it realy matter that he is Dutch?). Dont try to determine the safety of the code without proper expertise. Keylogger don't have to be in a hacked client, so you can not checksum it against official executable. Also the client get updated often with each new build so it a bad place to put a loger. A password loger could be put in any of the Wine subsystem that Gw will depend on. There is no way to test these with checksum because binary will vary from compiler version, flags, striping, .. Also comments prove noting; comment could be faked, or negative one could simply be deleted.
- To steal GW accounts it is best to put a loger in software that will be use by GW players. A specific to GW build is more suspicous then a general purpose build. I would go with a general build from a reliable source. It is not difficult to install Gw in wine. In fact, now, it is almost just like windows. Default setting work good enough.
- --Bob 21:13, 6 March 2010 (UTC)
- That's what I meant: keylogger inside of the package, not in the client.
- Anyway, I just finished installing Wine and Guild Wars, it runs great, though I have to download the entire gw.dat again, since I'm not sure I still have the DVD's. It runs quite smooth, but maybe I'll lower the shadows a bit or something, I already have no anti-alias since it makes my eyes hurt. It runs pretty well in deserted outposts, and I briefly walked around in Kamadan, and it didn't stop every few seconds, so that's a plus.
- The only problem I've noticed so far is that holding the right mouse button and moving the mouse is quite slow, I'd like to turn the camera a bit faster. Any way to change the mouse sensitivity in X11 or Wine?
- --Silva 13:55, 7 March 2010 (UTC)
- GW pointer match 1:1. In fact, the GW pointer is the X pointer, only the picture is changed. You could change the pointer sensitivity using the tool your distribution provide. On Ubuntu its from the System -> Preference -> Mouse. Using this method you will have to live with the setting every where, not just in Gw, not just when turning the camera. A other solution would be to launch GW from a script, call xset with your prefered gaming aceleration before gw.exe and then xset with the prefered desktop setting. Then the modified setting will only last during the Gw session. Tho they will be present if you change destop while Gw is running. It will take time to get the value right, maybe it is best to use the reverse direction key binding to do quick 180 turn. --Bob 21:35, 12 March 2010 (UTC)
This page is excellent.
My thanks to all those who contributed, this is quite the help. -- NilePenguin 15:14, 8 June 2010 (UTC)
Mouse disappearing
Does anyone know of a fix for the disappearing mouse cursor in GW ? This usually happens after a long period of playtime. I quickly scanned the talk archives and this issue supposedly was fixed in an earlier release, but I still get this problem. I'm using Wine 1.1.33 in Kubuntu (Karmic). Erszebet 10:17, 21 July 2010 (UTC)
- I get this problem too. I've just been quitting and restarting. I started logging how often it happened. My best guess is that it's after a certain number of cursor changes, as it's occurance seems at least somewhat based on how long the client has been running, and how much afk I've been doing. 64.245.3.212 22:16, 28 July 2010 (UTC)
- So far I can't see any pattern in this behaviour. All I know is that it happens after more than 2 hours of play. Below that it practically never occurs. And yes, the only 'solution' so far is restarting GW - very annoying in the middle of an Urgoz run :p Erszebet 15:45, 2 August 2010 (UTC)
- Update wine, latest stable release is 1.2. Let us know how it work. Also, if you need a quick fix, for most bug that happen over time, just kill -9 Gw.exe. Uppon restart you should have the option to reconnect. I did that when plusaudio was buggy and screwed gw's sound. --Bob 05:11, 5 August 2010 (UTC)
- Updated to Wine 1.2...well I haven't experienced this issue anymore...now I have GW crashing down instead >.< Guess I'll be looking into some tweaks again. Erszebet 16:33, 10 August 2010 (UTC)