Für Fans von Schleich-Strategie ala Commandos: Robin Hood – Die Legende von Sherwood. Macht irre Spaß den Helden in Strumpfhosen Mauern rauf kraxeln zu lassen, Wachen niederschlagen und ein wenig mit dem Bogen anzugeben 🥰

Ich habe das Spiel in der Windows-Version schon seit Jahren im Regal stehen und schon ein paar mal durchgespielt. Dazu gesellt sich nun auch die native Linux-Version, welche von RuneSoft portiert wurde. Leider gibt es die native Version nicht für 10 EUR vom Grabbeltisch aber dafür wird RuneSoft direkt unterstützt und kann weitere Spiele portieren 😉

PowerPC User kommen ebenfalls auf ihre Kosten, da eine offizielle PPC Version zum Download steht, mit der man seine x86 Version für den PowerPC aufwerten kann.

Der Absatz für Wine ist noch nicht fertig. Ich bin für heute zu müde und hole das die nächsten Tage nach. Es sei nur gesagt dass es bereits vor Jahren mit Wine lief und auch heute noch nach Schema F laufen sollte.

Heute mal wieder was aus meiner Klassiker Kiste: Albion. Der Artikel setzt dosemu korrekt für z.B. freedos und mit CD-Rom Unterstützung konfiguriert voraus. Einen Artikel über dosemu für die Wissensdatenbank werde ich die nächsten Tage schreiben.

Die Vorgehensweise sollte auch mit DOSbox funktionieren! Würde das bitte jemand ausprobieren? Die Demo ist verlinkt und da BlueByte und Ubisoft ihre Webseite wirklich vorbildlich pflegen ist sogar der letzte Patch noch verfügbar 👍

Seit einigen Updates konnte ich kein Unreal Tournament 2003 mehr starten. Mit dem neuen X-Server verschwanden auch einige Zusatzprogramme aus dem Paketbaum meiner Distribution. Nachdem sich heute eine weitere Fehlermeldung dazu gesellte habe bin ich der Sache einmal auf den Grund gegangen. Hier die Fehlermeldung, die mich beim Starten von ut2003 nun schon seit Monaten heim suchte:

Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 135 (XFree86-VidModeExtension)
Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
Value in failed request: 0xb6
Serial number of failed request: 203
Current serial number in output stream: 205

Mich verwunderte dies sehr, da ich doch das Paket “libXxf86vm”, welches die Funktion VidModeExtension zur Verfügung stellt, installiert hatte. Im Internet stieß ich dann auf folgende Erkenntnis: Viele Spiele nutzen das veraltete Programm “xvidmode” um die Auflösung im Vollbild zu setzen. Dafür wird heutzutage aber nur noch “xrandr” genutzt. Demnach müsste der Befehl “ut2003 –windowed” funktionieren. Klasse, es läuft also im Fenster, aber nicht im Vollbild. Nun habe ich drei Lösungen dafür konzipiert:

1. Quick’n’Dirty

 ln -s /usr/bin/xrandr /usr/bin/xvidmode

Als root ausführen. Dabei wird eine symbolische Verknüpfung von xrandr auf xvidmode erstellt. Die Befehlssyntax ist zwar leicht unterschiedlich aber für ut2003 scheint es zu reichen 🙂

2. Richtig

xvidmode zum Beispiel von ToCows herunter laden, kompilieren und unter /usr/bin installieren

3. Hack

Dabei editiert man das UT2003 startup script im Spielverzeichnis und fügt folgende Zeilen vor “# Let’s boogie!” ein:

#set proper screenresolution
utINI="$HOME/.ut2003/System/UT2003.ini"
if [ -r "$utINI" ]; then
    xwidth=`grep -m 2 FullscreenViewportX $utINI | cut -f2 -d'=' | tail -1`
    xheight=`grep -m 2 FullscreenViewportY $utINI | cut -f2 -d'=' | tail -1`
    echo "Read $xwidth x $xheight from UT2003.ini"
    xrandr `echo "-s "$xwidth"x"$xheight""`
fi


Hier ziehe ich mir die gewünschte Auflösung aus der UT2003.ini im Heimatverzeichnis und setze die Auflösung vor dem Spielstart manuell. Existiert noch keine UT2003.ini kann man das Spiel in dem Fall einmal mit “–windowed” starten. Dabei wird die INI dann erstellt und die Auflösung nach dem Einstellen im Menü unter Settings geschrieben. Ein optionales “xrandr -s 0” (oder andere gewünschte Auflösung) am Ende des Skripts setzt die Auflösung nach dem Spielen wieder zurück.

..aus diesem xvidmode/xrandr Grund setzt übrigens auch Quake3 und Enemy Territory die Auflösung nach dem Start nicht mehr richtig 🙂

Es gibt noch ein weiteres Problem, welches mit einem neueren X-Server aufzutreten scheint. Dabei kommt folgende oder ähnliche Fehlermeldung zusätzlich zum Spielstart:

ut2003-bin: xcb_lock.c:70: _XGetXCBBuffer: Assertion `((int) ((xcb_req) – (dpy-> request)) >= 0)’ failed.

Das kann man beheben indem man die systemeigene Bibliothek von libSDL nutzt. Dazu muss man erst die libSDL im Systemordner von ut2003 verschwinden lassen:

cd /usr/local/games/ut2003/System
mv libSDL-1.2.so.0 libSDL-1.2.so.0.contrib
ln -s /usr/lib/libSDL-1.2.so.0

Happy fragging 🙂

BioSys

BioSys ist eine “Survival Adventure Simulation” von JumpStart und Take2 in klassischer voll drehbarer 360 Grad Bilder-Manier. Nach dem Spielstart schlüpft man in die Rolle des Wissenschaftlers “Russel”, der jedoch nach einer schweren Katastrophe sein Gedächtnis verloren hat. Bei der Katastrophe sind alle anderen Menschen in der Biossphere4 ums Leben gekommen. Die Biossphere4 setzt sich aus vier voneinander abgeriegelten Biomen zusammen. Das hermetisch abgeriegelte Natur-Experiment ist komplett computergesteuert und sehr empfindlich. Durch die Katastrophe ist das Gleichgewicht massiv gestört und Russel muss schnell Initiative ergreifen, um sich selbst und seinen Mikrokosmos am Leben zu erhalten. Denn stirbt die Pflanzenwelt der einzelnen Biome stirbt auch er. Zu allem Überfluss scheint Russel nicht ganz alleine in der Biosphäre zu sein. Eines seiner Experimente hat sich selbstständig gemacht und neben den Gefahren von Flora und Fauna muss man sich auch noch vor diesen in Acht nehmen. Darüber hinaus muss für beständigen Nachschub an Nahrungsmitteln und Trinkwasser gesorgt werden, damit Russel nicht verhungert oder vor Erschöpfung umkippt. Den eigenen Gesundheit-Zustand darf man dabei ebenfalls nicht außer Acht lassen, während man alle vier Biome wieder funktionstüchtig bekommen muss. Die Hintergrundstory ist sehr Hollywood und kann getrost ignoriert werden. Wer an den Intrigen und Machtkämpfen hinter dem Projekt interessiert ist kann natürlich fleißig die Informationsfetzen im Spiel zusammen suchen und sich ein eigenes Bild machen.

Installation

Leider meinte Jumpstart wirklich nur Win95/Win98, als man das auf die Verpackung drucken ließ. Ab NT ist bereits Schluss. Zum Glück gibt es Wine. So konnte ich BioSys problemlos unter Linux installieren und starten:

InstallationsCD:

mount /media/cdrom
wine /media/cdrom/setup.exe
umount /media/cdrom

Nun muss Wine noch gesagt werden dass es für BioSys ein Win95 vorgaukeln soll:

wine winecfg

Unter Anwendungen fügen wir eine neue Anwendung hinzu und navigieren im Menü in den neu erstellen BioSys Ordner (C:/Program Files/Biosys) wo wir BioSys.exe auswählen. Als Windowsversion für diese Anwendung wählen wir Win95. Fertig.

SpielCD (wird zum Spielen benötigt):

mount /media/cdrom
cd /pad/zur/wineinstallation/drive_c/Program\ Files/Biosys/
wine BioSys.exe
umount /media/cdrom

Für häufiges Spielen kann man sich z.b. mit k3b komfortabel ein ISO (Imagedatei) der SpielCD erstellen lassen, welches man dann statt der CD über das Loopback Device mounten kann. So muss man nicht immer die CD griffbereit halten.

BioSys ist stellenweise sehr knifflig und kann durchaus frustrierend sein, wenn man das Spiel falsch gestartet hat. Spätestens wenn zum Beispiel das dritte Set Sicherungen durchgebrannt ist macht es einfach keinen Spaß mehr. Wer also wirklich nicht weiter kommt kann einen Blick in Steffen Geislers Walkthrough werfen. Der ist zwar nicht komplett und fehlerfrei aber genügt völlig um weiter zu helfen falls man in einer Sackgasse gelandet ist.

Mit der neusten Patch 1.15.2 von Blizzard ist es nun erstmals offiziell möglich StarCraft ohne CD zu spielen. Mangels Wintendo spiele ich StarCraft mit Wine unter Linux. Und so gehts:

Starcraft neuste Version 1.15.2:

Ich habe mir die neuste Patchversion Version 1.15.2 für StarCraft Deutsch ohne Expansion Set “Brood War” über http://ftp.blizzard.com/pub/starcraft/patches/PC/SC-1152.exe geholt und anschließend mit wine erfolgreich installiert:

wget http://ftp.blizzard.com/pub/starcraft/patches/PC/SC-1152.exe
wine SC-1152.exe

In der beliegenden ReadMe steht zum Spielen ohne CD folgende Information:

If you own only StarCraft, copy “INSTALL.EXE” from the StarCraft CD to
your StarCraft folder and rename it to “StarCraft.mpq”.

Die fragliche Datei befindet sich auf meiner “CD-Rom” unter /media/cdrom klein geschrieben und ist 605MB groß:

-r-xr-xr-x 1 root root 605M 3. Apr 1998 /media/cdrom/install.exe

Ich kopiere die install.exe wie im Patch-ReadMe beschrieben in mein StarCraft Installationsverzeichnis:

mount /media/cdrom
cp /media/cdrom/install.exe ~/.wine/drive_c/Programme/Starcraft/StarCraft.mpq
umount /media/cdrom
cd ~/.wine/drive_c/Programme/Starcraft
wine StarCraft.exe

Oder im virtuellen Desktop:

wine explorer /desktop=name,640x480 StarCraft.exe

Die neuste Version scheint anstandslos auch ohne CD zu laufen 🙂

StarCraft alte Version 1.14:

Bisher habe ich StarCraft immer über mein (quick’n dirty) Skript “starcraft.sh” gestartet, welches eine ISO anstelle der Spiele-CD für mich über das loop-device gemountet hat.

#!/bin/sh
#----------------------------------------

if [ -f /media/cdrom/sc.ico ]; then
    echo Game-CD already mounted
else
    echo Mounting Game-CD
    mount /home/beko/iso/starcraft.iso
fi

wine ./starcraft.exe $@

umount /home/beko/iso/starcraft.iso

DIe ISO habe ich vorher zusammen mit einigen anderen Spiele-ISOs, mit denen ich ähnlich verfahre, in meiner fstab definiert:

/home/beko/iso/starcraft.iso /media/cdrom iso9660 ro,noauto,user,exec,loop 0 0

Zum Vergleich:

  • 623M starcraft.iso
  • 605M StarCraft.mpq

Ich spare mir mit der neusten Patch also ganze 18 MB und ein paar Zeilen in meinem Startup Skript. Danke Blizzard…

Wer von euch zockt nur unter Linux? by GregorGregor (LinuxGaming)
So als Zusatzfrage an die Linux Only Gamer, die von Windows weggekommen sind: Habt ihr bemerkt, dass ihr weniger zockt als vorher? Also, denkt ihr, das lag am OS, oder einfach an weniger Zeit?

Ich daddle nur unter Linux.

Ich daddle weniger, als vor 10 Jahren. Das stimmt. Vor 10 Jahren hatte ich aber auch noch keinen Job, die Wohnung und ein paar Mäuler/Tanks zu stopfen/füllen 😉 Das liegt also wohl eher an der mangelnden Zeit.

Wenn ich ganz lustig bin spiele ich mit Linux. Ganz ehrlich so ein General-Update auf einem sourcen-basierenden System kann verflixt frustrierend werden bis das alles wieder so läuft wie man will. Dafür läuft es dann aber auch bis ich wieder damit spielen mag 🥰

Glest Hauptmenü Glest ist ein Strategiespiel, dass stark an Warcraft 3 erinnert. Seit einiger Zeit wird das freie OpenSource Spiel auch unter Linux unterstützt. Um es aber zu installieren benötigt es selbst für Linux eine gute Portion Hirnschmalz, wenn man nicht auf den fertigen Loki Installer zurückgreifen mag und das Spiel aus den Quelldateien heraus erstellen möchte. Auf Sourceforge gibt es dazu die benötigten Dateien glest_data und glest_source für Spiel- und Quelldateien.

Nach dem Entpacken wechselt man nun im Sourcenverzeichnis nach mk/linux. Nun fängt der Spaß erst richtig an. Als erstes sind alle Dateien mit dem DOS Zeilenumbruch kodiert. Abhilfe schafft zum Beispiel das Werkzeug hd2u (Hany’s Dos <-> Unix convertor). Hinweis: Es gibt mehrere Programme/Skripte mit dem Namen dos2unix (zum Beispiel aus dem Paket Recode) und die Befehlssyntax kann weitere Parameter erfordern.

cd mk/linux
for i in $(find ./); do dos2unix $i; done

Nun fehlt noch die korrekte Rechtevergabe, um die Skriptdateien auch ausführen zu können. Anschließend kann autogen und configure gestartet werden. Das Projekt selbst lässt sich dann mit jam (anstatt dem üblichen make) bauen.


chmod a+x *.sh
./autogen.sh
./configure
jam

Glest Spiel Magierseite Nach erfolgreicher Übersetzung kann nun die entstandene Binärdatei “glest” zu den restlichen Spieldateien unter glest_game kopiert werden. Nun habe ich noch die (unvollständige) Übersetzung deutsch 2.0.1.zip herunter geladen und die entpackte lng-Datei unter glest_game/data/lang abgespeichert.

Nun folgt der zweite Akt. Glest ließ sich wegen verschiedener Probleme nicht starten. Ein Blick in die glest.ini schafft hoffentlich Abhilfe. Ich habe folgende Probleme gehabt:

Exception: Couldn't set video mode 1024x768 (32bpp 0 stencil 32 depth-buffer). SDL Error is: Couldn't find matching GLX visualglest.ini => DepthBits=24

Exception: Font not found. glest.ini => FontConsole=-adobe-helvetica-medium-r-normal–12-120-75-75-p-67-iso8859-15
glest.ini => FontDisplay=–adobe-helvetica-medium-r-normal–12-120-75-75-p-67-iso8859-15
glest.ini => FontMenu=-adobe-helvetica-medium-r-normal–12-120-75-75-p-67-iso8859-15
(xlsfonts zeigt verfügbare Fonts auf dem System an)

Exception: Unknown sound factory: DirectSound8 glest.ini => FactorySound=OpenAL

KDEVELOP and SVN at workIch war am Wochenende fleissig und habe einen kleinen Server für die Deutsche M.A.X. Community zusammen gebaut und darauf Lunar Linux installiert. Seine Hauptaufgabe ist die Bereitstellung von “SVN” oder auch “subversion”. Dabei handelt es sich um eine Versionsverwaltung für die Quelldateien des Projekts. Jeder Entwickler kann dabei über seinen eigenen Zugang ständig mit dem Projekt synchronisieren. Dabei wird vermieden, dass ausversehen zwei Dateien gleichzeitig verändert werden, ohne dass die Autoren darüber in Kenntnis gesetzt werden. Darüber hinaus kann man zu jeder beliebigen älteren Version im SVN zurück kehren, falls man mit seinen Änderungen im Code in einer Sackgasse gelandet ist. Das beste: SVN ist es völlig egal welcher Programmierer mit was für einem Betriebssystem und was für einer Entwicklungsumgebung arbeitet.

Nach der Suche nach einer Einführung für SVN und KDEVELOP (Entwicklungsumgebung für KDE – siehe Bild) konnte ich einfach nichts verständliches finden. Klar war, dass KDEVELOP inzwischen scheinbar SVN unterstützt. Was ich verzweifelt suchte, war eine Möglichkeit mich an das bereits bestehende Projekt ran zu hängen. So entstand dieser neue Artikel, der genau das bietet, in meiner Linuxkategorie: SVN für KDEVELOP mit KDESVN.

Tja – und das passierte nach einem Update von XOrg:


X.Org X Server 1.4.0
[...]
(II) Module nvidia: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.0ServerCmd=/usr/bin/X -br

Module class: X.Org Video Driver
(EE) NVIDIA(0): ============= WARNING WARNING WARNING WARNING =============
(EE) NVIDIA(0): This server has a video driver ABI version of 2.0 but this
(EE) NVIDIA(0): driver is designed to work with versions before 2.0.
(EE) NVIDIA(0): Please check http://www.nvidia.com/ for driver updates or
(EE) NVIDIA(0): downgrade to an X server with a supported driver ABI.
(EE) NVIDIA(0): ===========================================================

Abhilfe schafft entweder ein Update der NVIDIA Treiber von 100.14.11 auf 100.14.19 oder den X mit -ignoreABI starten. Das sieht dann manuell so aus: “startx — -ignoreABI” oder zum Beispiel über KDM in $KDEDIR/share/config/kdm/kdmrc die Zeile ServerCMD anpassen: “ServerCmd=/usr/bin/X -br -ignoreABI”