Talk:Guild Wars on Wine

From Guild Wars Wiki

Contents 1 Blue Screen 2 Broken 3 Not Broken 4 Wine 1.1.24 5 Wine bottle/box 6 Instalation notes - Fedora 11 7 Wine 1.1.27 8 Wine 1.1.28 9 Cannot see main Window

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)