Linux notes

English version

Problem: Maus zieht nach oben / Spiel friert nach ein paar Sekunden ein

In manchen Spielen, die die Unity-4-Engine nutzen, gibt es Probleme mit der Maus: typisch sind ein ständig nach oben flüchtender Mauszeiger und ein nach wenigen Sekunden einfrierendes Bild. Wenn man mit Alt + Tab aus dem Spiel heraus- und wieder hineinwechselt (in machen Umgebungen genügt es auch schon, im Spiel eine Maustaste zu drücken), dann funktionieren Bild / Maus wieder für wenige Sekunden. Betroffen sind davon besonders Spiele, die aus der Egoperspektive gespielt werden.

Bekannte Workarounds

Workaround Option 1
Spiele das Spiel im Fenstermodus und setze eine Auflösung, die der Auflösung des Desktops minus der Breite der Fensterdekoration entspricht (z.B. 1912×1072 statt 1920×1080) - weniger geht natürlich auch. Die Konfigurationdatei des Spiels, in der diese Einstellungen angepasst werden können, findet sich in einer Datei namens ~/.config/unity3d/<Entwicklername>/<Spielename>/prefs.

Workaround Option 2
Verwende einen anderen Fenstermanger (z.B. openbox, fluxbox, blackbox, wmaker, fvwm2, twm).

Weitere Workarounds
KDE-Nutzer können auch folgendes versuchen: http://steamcommunit … #c846965882766096888

Betroffene Spiele

Folgende noch betroffene Spiele sind mir derzeit bekannt, die Liste ist aber ziemlich sicher nicht vollständig. Ob das Problem tatsächlich auftritt hängt wohl auch von der Abtastrate der Maus und dem verwendeten Fenstermanager ab - nur weil ein Spiel in dieser Liste auftaucht heißt nicht unbedingt, dass das Problem auch überall auftritt.

• Doorways
• Surgeon Simulator 2013
• Gone Home
• Ravensword
• MirrorMoon EP
• Jazzpunk
• Galak-Z
• Nimble Quest

Problem: Im Spiel passieren seltsame Dinge

Manche Unity-4-Spiele kommen nicht mit nicht-englischen Spracheinstellungen zurecht. Typische Symptome sind Ereignisse, die nicht oder erst nach sehr langer Verzögerung ausgelöst werden, sich überlagernde Grafiken in der Benutzeroberfläche oder ein schwarzer Bildschirm nach dem Laden.

Oder in anderen Worten: Wenn ein Unity-Spiel nicht wie erwartet funktioniert, dann versuch’s einfach mal mit diesem Workaround :-)

Workaround

Starte das Spiel z.B. von der Kommandozeile mit den Variablen LC_ALL=C LANG=C, für Ravensword beispielsweise mit

LC_ALL=C LANG=C ./rs2.x86

Problem: Das Spiel startet nicht mit xxx is corrupted

Falls das Spiel nicht startet (typischerweise stürzt es einfach ab oder es wird nur ein Mauszeiger auf einem schwarzen Bildschirm angezeigt) und in der Logdatei unter ~/.config/unity3d/<Entwicklername>/<Spielename>/Player.log Einträge der Art

Error (8/12/2017 6:10:57 PM) - The file '<Installationsverzeichnis>/<Spielename>/<Spielename>_Data/resources.assets' is corrupted! Remove it and launch unity again!
[Position out of bounds! 875850853 > 69016]

zu finden sind, dann muss lsb_release installiert werden, um das Programm zum Laufen zu bewegen.

Bekannte betroffene Spiele

• Caravan
• The Raven: Legacy of a Master Thief

Es gibt ja immer mal wieder das Problem, dass ALSA Soundkarten in der falschen Reihenfolge erkennt - dann wird statt der eigentlichen Soundkarte auf einmal der Eingang der TV-Karte oder der HDMI-Ausgang vom Monitor als primäre Soundkarte verwendet. Auch neuere Sounddaemons wie Pulseaudio helfen nur dann, wenn alle verwendeten Programme denselben auch unterstützen.

Workarounds gibt es mehrere, die vom Blacklisting der Kernelmodule über die Priorisierung der Ladereihenfolge gehen. Den schönsten und einfachsten Weg finde ich aber, einfach eine Datei /etc/modprobe.d/alsa.conf mit einer Liste der Module anzulegen, die man nicht haben will.

Bei mir sieht die Datei beispielsweise so aus:

options snd slots=,cx88_alsa,snd_hda_codec_nvhdmi

Wichtig ist das Komma direkt nach dem Istgleich: Damit sage ich, dass alles vor den beiden von mir unerwünschten Modulen kommen soll.

——

Leider kommen Programme, die fmod verwenden, nicht damit zurecht - hier muss weiterhin eine Standard-Soundkarte festgelegt werden:

cat /proc/asound/cards

listet die verfügbaren Karten auf, die Standardkarte lässt sich dann in der Datei /etc/asound.conf (systemweit) oder ~/.asoundrc (für den Benutzer) festlegen, indem man dort folgenden Eintrag hinzufügt:

pcm.!default {
    type hw
    card <Name der Karte>
    hint.description "default"
}
ctl.!default {
    type hw
    card <Name der Karte>
    hint.description "default"
}

Für den hint.description-Eintrag siehe auch https://qa.fmod.com/ … s-the-back-end/20188.

Wer gerne ältere Spiele mit DOSBox spielt stößt vielleicht auf das Problem, dass bei CUE-Images statt des tollen Audio-Soundtracks nur statisches Rauschen abgespielt wird. Wer seine CDs nicht noch einmal sichern will, den bringt das nachfolgende Programm zum Ziel:

http://www.ssokolow.com/scripts/index.html#swab.py

Um in Spielen wie Sacred oder anderen auf OpenAL-basierenden Spielen Surround-Ton zu bekommen, muß das Feature explizit aktiviert werden. Dazu gibt es in der Datei /etc/openal/alsoft.conf die Option format. Setzt man diese beispielsweise auf

format = AL_FORMAT_51CHN32

erhält hat man nun endlich auch in Sacred Raumklang.

Das Problem ist unter Linux- und UNIX-Benutzern altbekannt: Irgendein Prozess blockiert mal wieder das DVD-Laufwerk, den USB-Stick oder sonst ein Medium, welches man gerade unmounten möchte, und sabotiert den Versuch mit einer Meldung wie umount: /media/cdrom0: device is busy.

Klassischerweise greift man hier zum Befehl fuser:

fuser -m /dev/sr0

beispielsweise sucht Anwendungen, die auf das das CD-ROM-Laufwerk /dev/sr0 zugreifen (-m nicht vergessen, sonst werden nur Anwendungen gefunden, die genau diese Datei geöffnet haben; die Option bewirkt, dass auch der Mountpunkt inklusive allen Unterverzeichnissen überprüft wird). Hier haben wir einen Schuldigen gefunden:

/dev/sr0:             5841

Der Prozeß mit der Nummer 5841 blockiert also unser Laufwerk.

Deutlich komfortabler ist der Befehl lsof:

lsof /dev/sr0

liefert uns standardmäßig gleich ein paar mehr Infos:

COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dosbox  5841 ignaz   14r   REG   11,0 50942045 1371 /media/cdrom0/ressci.001
dosbox  5841 ignaz   16r   REG   11,0 18623497 1368 /media/cdrom0/resource.sfx
dosbox  5841 ignaz   17r   REG   11,0 23470911 1365 /media/cdrom0/resource.aud

Jetzt wissen wir, dass der schuldige Prozess das Programm dosbox ist, ohne erst in der Prozessliste nachschauen zu müssen, und sehen ganz nebenbei auch gleich die fraglichen Dateien, die das Laufwerk blockieren.

Sowohl fuser als auch lsof beziehen ihre Daten aus dem /proc-Dateisystem, wir können hier also auch selbst einen Blick riskieren:

ls -l /proc/5841/fd

zeigt uns die Liste der von DOSBox geöffneten Dateien - hier finden wir auch unsere drei Dateien von eben wieder.

lrwx------ 1 ignaz users 64 2010-09-11 16:38 0 -> /dev/pts/1
lrwx------ 1 ignaz users 64 2010-09-11 16:38 1 -> /dev/pts/1
lrwx------ 1 ignaz users 64 2010-09-11 16:38 10 -> /dev/nvidia1
l-wx------ 1 ignaz users 64 2010-09-11 16:38 11 -> /dev/sequencer
lrwx------ 1 ignaz users 64 2010-09-11 16:38 12 -> /dev/snd/pcmC0D0p
lr-x------ 1 ignaz users 64 2010-09-11 16:38 13 -> /dev/input/event5
lr-x------ 1 ignaz users 64 2010-09-11 16:38 14 -> /media/cdrom0/ressci.001
lr-x------ 1 ignaz users 64 2010-09-11 16:38 15 -> /home/ignaz/c/SIERRA/GK2DOS/RESSCI.PAT
lr-x------ 1 ignaz users 64 2010-09-11 16:38 16 -> /media/cdrom0/resource.sfx
lr-x------ 1 ignaz users 64 2010-09-11 16:38 17 -> /media/cdrom0/resource.aud
lrwx------ 1 ignaz users 64 2010-09-11 16:38 2 -> /dev/pts/1
lrwx------ 1 ignaz users 64 2010-09-11 16:38 3 -> socket:[45729]
lrwx------ 1 ignaz users 64 2010-09-11 16:38 4 -> socket:[45731]
lrwx------ 1 ignaz users 64 2010-09-11 16:38 5 -> /dev/nvidiactl
lrwx------ 1 ignaz users 64 2010-09-11 16:38 6 -> /dev/nvidia1
lrwx------ 1 ignaz users 64 2010-09-11 16:38 7 -> /dev/nvidia1
lrwx------ 1 ignaz users 64 2010-09-11 16:38 8 -> /dev/nvidia0
lrwx------ 1 ignaz users 64 2010-09-11 16:38 9 -> /dev/nvidia1