I've been working on solving this for probably over a month all included but really the last 3 weeks I ramped up the complexity of the efforts, including reformatting my hard drive to include some extra "test bed" partitions for experimenting with different linux installations.

I'm on an Athlon II 635 and a GTX460 here. Other hardware configurations may require different considerations.

Here's the summation of what I can remember and various thoughts on each issue... Keep in mind that I am for all intents and purposes a linux novice. I just kept trying stuff until something worked.

Starting from a fresh install of 32 bit linux mint 9 LTS... (I created a ~32GB partition for this test bed).

Why an older 32 bit OS?: because solving the dependencies to compile wine in a late generation multiarch OS becomes problematic and messy. Beyond my expertise. Furthermore, installing .net 3.5 is more likely to succeed here (I haven't succeeded yet but that doesn't mean it can't be done).

Why Mint? Debian based distros are easier for newbs like me to deal with. The "Minty" offshoots of Ubuntu have, in my personal experience, been more stable and less buggy than the buntu's they are "based" on. Feel free to try to replicate this in any distro, but be warned, I already wasted many hours trying in OpenSuse 12 32 and 64 bit, Mint 13 32 and 64 bit, Mint 14 64 bit.

tip: the linux program "unetbootin" is the only GUI way I have found to somewhat easily and quickly create a bootable USB flash drive from iso's that were originally written for use on optical media.

Go ahead and snag all the security/stability updates for the OS before you get started. I restart after this step for good measure.

Download your binary video driver. I am running the latest beta from nvidia for this (313) and it seems to be working fine for what I want to do. I would have to guess that just about any driver version that will recognize your hardware will probably work for this. The latest stable is probably the best choice. You can install this now if you want but don't be surprised if you have to re-install it later on in this procedure.

If you have tried running DAOC in linux (via wine), then you may already be familiar with wine bug 6955. Some games call upon a rare openGL ARB something vertex blend yada yada whatever.... It's a problem that will probably never be solved in any final stable releases of wine because it only effects a few "unimportant" games of old. You may also be familiar with the reality that you can run DAOC via wine with either the pixel shader or the vertex shader disabled. (control over these options dries up from wine version 1.4 and up in winecfg but the settings can still be changed in the prefix registry). Running the game with the pixel shader disabled removes access to CAT models and ANT terrain trees and various other graphical options but the game will run. Running the game with the pixel shader enabled but the vertex shader disabled will give you access to the CAT models and many of the fancier graphical options (water etc), however, they will not display correctly. In either case, the game will not run correctly. From my personal experience, the game will run in a sort of software-only rendering mode and the performance will suffer in areas where certain graphical effects are present or when too many models (textures) are in view all at once. My goal was to find a way to run the game in linux smoothly (with hardware acceleration).

Head over to winehq and look up bug #6955. While you're on that page, click the link to the patch for wine version 1.3.23, copy/paste that into text editor and save the file as <whatever>.patch

Download wine 1.3.23 sourcecode. There are links to the sourceforge hosted files on winehq.

You may be able to use other versions of wine for this, however, I tried several and this was the only version for which there was a patch available that wound up working for ME in the end.

unpack the wine source.

Use package manager to install "patch."

copy the .patch file you created to the wine source folder.

from a terminal, cd to the wine source folder:

patch -p1 -i <whatever>.patch

./configure

This will start spitting out dependencies/warnings. Plan on a few hours of tracking down and installing the dependencies via the package manager to get everything resolved. Keep running the "./configure" script to reveal and resolve out the list as you go. You'll need gcc, flex, and bison installed to get things going. There are some things that can probably go unresolved with no consequence but make sure anything related to a graphical library is solved. You can probably skip things like "ISDN" support. I don't want to get into all the finer details about every package but I will share a few tips... The names in the package manager won't always match the output of ./configure. Use google to figure out what the dev files might actually be named where you run into snags. Try partial search terms in the package manager. There are some guides out there for buntu based distros that have lists of the packages that you need but none of the ones I have found are complete for good reason.. Chances are, they were written by people like me who don't know what they are doing and don't really know everything they needed or installed. I'm not even going to bother trying to make a list You will probably "break" your openGL libraries in the process of trying to fulfill the dependencies, this is where you will re-install your video driver to "fix" that. Save the re-installation of the video driver until all other dependencies are resolved. When you are satisfied, you can build wine.

make -j6

The -j option specifies the maximum number of threads the compiler can spawn. Setting this option around or slightly over the number of "cores" in your machine is probably a good idea. Compiling takes a few minutes on my propus.

sudo make install

You may or may not need to install the distro's wine development stuff and gecko. I was able to compile and install wine without it, but ended up running into some odd snags when trying to run msi installers. I found that using the package manager to install wine-dev and gecko (it installs wine 1.2 and some other stuff) followed by installing the patched compiled version of wine worked for me but I'm betting there is a cleaner way about this.

--------------

EDIT: the remainder of this guide was originally written to give some insight into procedures that gave me a patched (uthgard patches) copy of daoc that I could connect to via daocportal 2.8 with mono210 installed in a wine prefix and mono-complete installed by my package manager to handle getting over a few update hurdles... Since the time of writing that (just a few weeks after writing it) there have been a couple updates to daocportal and a serverside change that makes all of that information pretty useless. At this time I don't have any properly working way to play uth on linux. I still recommend resolving bug 6955 as a starting point for good performance in game but that becomes a rather moot point if you can't patch a game client and connect to the server properly.

My recommendation for getting dacportal to work would be to apply steady pressure with a 2x4 to your skull until you have lost your desire to play daoc.

-----------------

Best of luck,
Eric

I've been playing for a few days with only a few minor tips to add to the above...

Reflective water still doesn't work but SI and classic both work fine.

Turn off any compositing or other opengl functions in your xwindow system/manager. Running for instance, a transparent "desktop cube" in gnome 2 with the game running does work- but will cause a reduction in performance. Though it was kind of neat to see the game running on the face of a transparent rotating cube.

Performance is still probably not as good as it could be but at least this places a load on the GPU for some of the functions. The game is still primarily CPU bound and can get glitchy at times (relog to solve most issues). Running old-school models and terrain improves performance a bit and might be worth considering.

well done! I enjoy seeing windows free things work

or just buy an used windows license for 10 bucks....

hehe, nm, good work!

To get dotnet35 running you have to use a 32bit winepreifx, just do "export WINEARCH=win32" before youre create your prefix.

Testing atm your winetricks settings, cause I wasn't able to use portal or the connect.exe with just dotnet35, everytime a critical error...

Hello Geriain,

If someone is following through with the plan to compile a patched wine in a 32 bit OS, then there is no need to create a 32 bit wine prefix manually for the use of .net instead of mono, the prefix will be created that way by default in a 32 bit environment. I suspect if someone has the skills to fulfill the dependencies to compile wine in a late generation 64 bit linux install, then they probably already know how to manage their wine prefixes like a ninja

I have since also experimented with .net and had the same problems with connect.exe causing the whole thing to crash.... HOWEVER.... The latest version of connect.exe no longer works with uth (probably temporary).

----------

The recent server update that caused a compatibility problem with the latest version of the connect.exe program got most of us tinkering again...

Daocportal works pretty good with .net2.0 in wine if you DON'T allow it to update itself I didn't even bother updating to .net 3.0 or 3.5 and just ran it under .net 2.0 SP2 as installed by winetricks. I suspect other versions of .net wold also work with older versions of the connect.exe.

The idea to NOT update portal never occurred to me. (or try other versions of connect.exe).. I suspect you could run the updater and install the older version of connect.exe for the same results.

As it turns out... the older versions of connect.exe ONLY work in wine with .net installed, and the latest version of connect.exe ONLY works with mono support. All these little details are a pain, but it's nice to be back up and running again after the hiccup this evening.

Best of luck,
Eric

I wrote a little script which should install DAoC on linux, and do most of the work for you. It works fine for me on Ubuntu 12.10 64-bit with both wine 1.4.1. and 1.5.19.

Either download it manually, or execute this in a shell:

Code: Select all

wget matthiaslinder.com/gosh/installDAoC.sh && chmod +x installDAoC.sh && ./installDAoC.sh


Portal.exe won't work that well, so I recommend using connect.exe right away ('wine connect.exe [..]').

Hello Kroko,

Does that script install a patched [compiled] version of wine with vertex blend support?

Without this key element, the game will run poorly on lots of hardware.

----------------

Since throwing together the very rough guide above, I have now had server side changes put me back to the drawing board twice. I would say at this point that writing the guide was rather pointless other than to point out how to get vertex blending in wine working, beyond that the method to connect to uth will break about once a week and you'll be scrounging around looking for a workable solution (hunting down different versions of the game client, or different versions of the different pieces of daocportal, or wiping your wine prefix and switching from .net installations to mono installations.

I have found that the best way to run the modmanager (to apply the .dmm files) is in a wine prefix with .net 3.5 installed by winetricks. This seems to produce the best results. Unfortunately, the later versions of portal will work to apply the mods, but will crash in a .net 3.5 install when trying to connect. plan on reverting either the daocportal version or the .net version or switching to a mono compatible prefix instead. In any case, expect the solution to have a relatively short lifespan.

interestingly enough, since I started trying to make this work, there have been a couple updates to daocportal. In each update, the release notes claim improvements in linux support. In each case, the support has gotten worse. I have my suspicions that the program is reporting my crash logs to daocportal devs, they are trying to then solve the issues, and are inadvertently making things worse.

At this time, I am back to not being able to connect again because uth is demanding the use of a daocportal version that is not working in linux in any way that I have tried. Don't fall in love with the idea of playing uthgard from linux.

Regards,
Eric

.NET 3.5 is absolutely required. Else you will get a lot of problems.

Eric, I'm actually the one making the changes for running connect.exe on Linux, and I am using linux primarily myself. It is true that the script I provided won't compile a custom wine version -- but it will definitely allow you to connect to Uthgard and have a non-crashing game.

The setup of software required for running all of this on linux is very fragile - true. But that lies in the nature of things: connect.exe needs to do memory patching of a native wine process in order to allow the client to connect. It can't do that under mono because all win32 P/Invokes will fail due to missing libraries, but it will run fine under wine as wine can emulate those.
The huge difference between Portal 2.6 and 2.8 is that Portal 2.6 used the now outdated dolloader.exe, which as written in C++ a long time ago, whereas newer portal versions use a .NET implementation. Unfortunately for you dolloader.exe won't support v1.110 and higher, and won't have all those fancy things like autopatch, and won't be supported by Uthgard at all for much longer.

As the main connect flow using wine w/ winetricks mono210 installed is already working just fine, the 'improved linux support' has mostly focused on additional features like the ModMgr & autopatching, and hasn't touched the original connect code in a while. Apparently running mono210 using wine is a bit flaky, and the ModMgr does not quite like this, which means that connect.exe will have to launch the modmgr with mono instead of wine. Since wine converts paths to windows paths ("Z:\media\foo"), all of this gets some hassle.

If you, however, keep things simple and follow a few rules, all of this should work without much of a hassle:
* Create a clean wine prefix for all of this
* Mono has to be installed in /usr/bin/mono
* Use the script I provided above to get a _clean_ DAoC client. Make sure to put the connect.exe in your game directory to avoid some weird path issues.
* Using a stock Ubuntu 12.10 w/ 64bit everything should work fine -- at least it does on both my notebook and my PC

And no, connect.exe actually does not send any stacktraces to us, so I'm making all those changes blind/based on my own tests. If you have any stacktraces/crashdumps, just send them to me and I'll see what I can do.

Cheers!
- M

Hey Kroko!

I didn't realize you were the one working on the project Thankyou for sharing your knowledge on the issues here.

It's interesting to me that nothing changed regarding the instruction flow for connection, and yet, I was able to get 2.8 to work and was actually using that as my connection method for several weeks via mono 210 installed into the prefix. The change to 2.8B busted it. (I can't recall if it was 2.8 or 2.8A that was working before, I just know for sure that 2.8B no longer works for me in wine with mono 210 installed).

I just compiled 1.4RC5 with vertex blending and have a prefix setup with .net 3.5 SP1.

"Failed to launch client" "The game client could not be started."

I have tried running connect.exe like this:

"wine connect.exe . server.uthgard.net:10300 <login> <password>
with connect.exe located in the game folder. (hence <.>), giving the full path doesn't change anything, still can not start game client. The error occurs if I try to launch from daocportal.

I'll keep tinkering I suppose. You're absolutely right that this whole thing is very fragile. Seems like if you look at it wrong everything will crumble, I have grown very weary of running scripts and commands that I find posted to the web unless it is in a test bed environment since 99% of them break more than they fix in my experience. I'll save your script there as a last resort. I suspect since i have already got wine compiled with vertex blending I could probably install it to any OS now so I may consider that option. At this time I no longer consider this installation a test bed since I have been successfully using it for daoc for several weeks.

Best Regards,
Eric

I just cranked up another fresh prefix with mono210 and a pile of other winetricky stuff just for good measure and ran connect.exe direct from the game clients folder with all the proper syntax and BLAM, the patcher ran and the game loaded... (I saw something i had never seen before )

Terminal output: "Search for frontiers/frontiers.mpk:numkeeps failed"

client gives "the destination zone could not be loaded."

Then it crashes out.

Going to snag a fresh copy of daoc and see if that works, I suspect the patcher patching an already patched client may have busted it.

Nope. Fresh install updated, patcher runs automatically when connect.exe is run from terminal with proper syntax, patching downloads and appears to patch all *4* patches properly. Game launches, but regardless of which toon I try to play I always get the ""the destination zone could not be loaded." error and "pretty ESC to exit" or something like that.

This is hugely disappointing because it seems so close to working. My guess is that the patcher is breaking something in the installation.

--------------

EDIT: SYNTAX ERROR!

My fault!

I didn't realize that the syntax absolutely requires a character name (or possibly some empty quotes?) and realm, it was launching to the char selection screen without it so i figured it was unnecessary. Things are working now, I think*

--------------

I would appear that the connect.exe HAS been modified for the better for us linux users after-all (thanks M!!), but if you had it working already then the way in which you will have to use it has now changed a bit, and it's probably important to get a semi-fresh start to get it up and running again...

Go through your hidden files in the home directory (check in folder .config) and remove anything having to do with daocportal. Seems that if you have used mono in the past to run the patcher or the updater or the portal then it will have created various files that may prevent connect.exe from invoking the patching process in mono automatically. I could be wrong about this but this seems to have been one of the big hangups for me. Installing daocportal directly to the game folder also seems to be helpful as suggested, and finally, plan on doing a dance back and forth from mono to wine to get the updater to complete (you'll have to run this manually both with mono and with wine to get all the files updated, you may also have to manually adjust file permissions of the update. files to executable.

cd to game directory, then:
wine connect.exe . server.uthgard.net:10300 <login> <password> <character> <realm>

Glad that it finally seems to be working

As for launching the game / "the destination zone could not be launched": I'm running the game with these args:

Code: Select all

#!/bin/sh
cd /media/Data/DAoC
wine connect.exe ./ server.uthgard.net $1 $2

So just account name and password works fine; no quicklogin character is required.