Auto-Reconnect für DD-WRT

Aus irgendeinem, mir noch nicht ganz nachvollziehbaren Grund, erkennt der pppd manchmal nicht, dass das ppp-Interface down ist und keine Verbindung mehr besteht. Um das zu beheben muss man normalerweise das WebInterface aufrufen und „reconnect“ drücken. Das kann man auch automatisieren.

Als erstes erstellt man eine Datei unter /tmp/connection_tracker.sh

#!/bin/sh

if [ $(ping -c 1 $(nvram get wan_ipaddr)|grep -c from) -lt 1 ]; then 
  logger -t connectiontracker nvram get wan_ipaddr unreachable
  killall redial; 
  killall pppd; 
  sleep 5 
  pppd file /tmp/ppp/options.pppoe >/dev/null; 
  logger -t connectiontracker reconnect wan nvram get wan_ipaddr successfully 
fi

Was macht das Script? Es versucht die IP des WAN-Interfaces zu pingen. Ist das Down gibt es keinen Treffer. „grep“ wertet die Rückgabe des ping Befehls aus und zählt die Zeilen. Gibt es weniger als einen Treffer (also Null) wird der redial und pppd gestoppt und neu gestartet.

Anschließend fügt man eine NVRAM-Variable hinzu. Gibt es die Variable wird sie überschieben, Ansonsten wird sie angelegt.

nvram set rc_custom="$(cat /tmp/connection_tracker.sh)"
nvram commit

Über den Startup-Script/Command muss diese Datei nun immer angelegt werden.

nvram get rc_custom>/tmp/connection_tracker.sh

Über einen zusätzlichen Cron-Job die Überprüfung alle 15-Minuten durchführen.

*/15 * * * * root /tmp/connection_tracker.sh

Routing unter Ubuntu

Einen Text mit viel „Bla-Bla“ hatte ich heute schon, jetzt gibt es Technisches!

Will man unter Ubuntu einen „echten“ Router betreiben, also dynamisch auf die Netzwerkumgebung reagieren, stehen zwei Routing-Suites zur Verfügung: BIRD und Quagga. Beide unterstützen die wichtigsten Routing-Protokolle: BGP, RIP, OSPF

Wichtiger Hinweis vorweg: in Ubuntu 10.04 wird BIRD noch in Version 1.1.5 ausgeliefert. Die ist mal gut zwei Jahre alt und Unterstützt noch nicht alle Funktionen. Entweder akzeptiert man diese Schwächen oder nutzt das PPA des CZ.NIC Labs.

Die Quagga-Suite ist schon seit einiger Zeit am Markt. Sie bietet ein Config-Interface das einem CISCO Router gleicht. Man kann sowohl Config Files hinterlegen als auch „on the fly“ Config Befehle geben und die entsprechende Config dann raus schreiben (ganz wie bei CISCO Routern). Im Hintergrund werden bei Quagga für jedes Routing-Prokoll ein eigener Dienst gestartet und jeder dieser Dienste macht einen TELNET Port auf. Diesen kann man auf den Localhost beschränken oder so konfigurieren, dass er jede Anfrage ablehnt (kein Password angeben).

Bird befindet sich aktuell noch in der (Weiter-)Entwicklung. Zudem wirkt es auf mich schlanker. Es wird nur ein Dienst gestartet, die Config befindet sich in einer Datei und wirkt übersichtlicher. Neben diesen „Geschmacksfragen“ soll BIRD leistungsschonender sein.[1. Quelle: Vergleich BIRD/Quagga] Laut Wiki kommt er vor allem deswegen in den großen „Verteilerknoten“ zum Einsatz. [2. Quelle: Wikipedia] Dafür spricht auf jeden Fall, dass bei DD-WRT Firmwares für wenig Speicher der BIRD zum Einsatz kommt und bei viel Speicher die Quagga-Suite.

Ich habe beide Implementierungen gezwungenermaßen durch meine Routern im Einsatz. Beim Ubuntu-Router hatte ich die Wahl und mich nach einem kleinen Quagga Test für BIRD entschieden.

Wichtig: Die meisten Routing-Protokolle nutzten MultiCast-Addressen für ihre Kommunikation. Damit das funktioniert muss man eine entsprechende Route hinterlegen.

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

Beispiel – Konfiguration BIRD

Einfach über apt-get oder aptitude bird installieren und schon kann es losgehen.

aptitude install bird

Danach kann man die /etc/bird.conf bearbeiten.

log syslog all;
router id 10.1.0.1;

protocol kernel {
        export all;
        learn;
}

protocol device {
        scan time 60;
}

protocol ospf {
        debug { states, routes, interfaces };
        area 0 {
                interface "eth0" 10.1.0.0/16 {
                        cost 10;
                        stub;
                        check link;
                };
                interface "eth1" 10.2.0.0/16 {
                        priority 10;
                        cost 100;
                        type broadcast;
                        hello 30; retransmit 5; wait 10; dead 120;
                        authentication none;
                        check link;
                };
                interface "eth2" 10.3.0.0/16 {
                        priority 10;
                        cost 10;
                        type broadcast;
                        hello 30; retransmit 5; wait 10; dead 120;
                        authentication none;
                        check link;
                };
        };
}

Die Config dürfte selbsterklärend sein. Ein paar Hinweise zum Umgang mit BIRD:

  • Das Kernel-Protokoll wird gebraucht. Ohne die „export all;“ Regel werden keine Routen an das OS bekanntgegeben.
  • Hat man Default-Routen oder pflegt händisch welche über den „route“-Befehl nach, sollte die über das „learn“-Statement von BIRD ermittelt werden.
  • Alle lokalen Netze, die den Nachbarn mitgeteilt werden sollen, benötigen ein interface-Statement. Das stub-Statement markiert Interfaces die nur „announced“ werden sollen aber sonst keine Funktion haben.
  • Wenn man einen PPPoE-DSL-Uplink als Default-Route verwendet, sollte man das PPPoE Interface nicht als Area-Interface hinterlegen.
  • „check link“ funktioniert nur, wenn man neuerere BIRD-Versionen benutzt. BIRD 1.1.5 meckert einen Syntax-Fehler an.

 Beispiel – Konfiguration Quagga

Installation:

aptitude install quagga

Quagga ist anfangs etwas komplizierter. Anfangs muss man erst mal die benötigten Dienste unter /etc/quagga/daemons freischalten. Will man, dass diese Dienste per TelNet auch Remote konfigurierbar sind muss man noch in der /etc/quagga/debian.conf Anpassungen vornehmen.

Auf jeden Fall benötigt man den zebra-Dienst. Dieser ist das „protocol kernel“ Pendant. Zusätzlich muss man noch den Dienst für das gewünschte Protokoll aktivieren. Für den einfachen Einstieg findet man Beispiel-Konfigurationen unter /usr/share/doc/quagga/examples.

zebra.conf

hostname deadend-router

interface br0
  link-detect
interface ath1
   link-detect

in der zerba.conf werden die zu nutzenden interfaces angegeben.

ospf.conf

interface br0
  ip ospf cost 10
  ip ospf dead-interval 120
  ip ospf hello-interval 30
  ip ospf retransmit-interval 5
  ip ospf network broadcast
interface eth0
  ip ospf cost 10
  ip ospf dead-interval 120
  ip ospf hello-interval 30
  ip ospf retransmit-interval 5
  ip ospf network broadcast

router ospf
  ospf router-id 10.3.0.10
  network 10.3.0.0/16 area 0
  network 10.4.0.0/16 area 0
    redistribute kernel
    redistribute connected

In der ospf.conf wird diesen Interfaces erst Eigenschaften zugewiesen und anschließend das Protokoll zugeschaltet. Wichtig ist die Syntax. Das Einrücken dient nur zur Optik und hat kein Einfluss. Die Reihenfolge der Befehle hingegen hat Einfluss. Gewisse Befehle „öffnen“ eine SubConfig-Ebene. Ein „ip ospf cost“ ist nur gültig, wenn vorher eine interface-Direktive stand. Was bei den „interface“-Direktiven noch übersichtlich erscheint, kann bei den area-direktiven unübersichtlich werden, da diese ineinander geschachtelt sein können. Angenehm sind hingegen die redistribute -Direktiven. So muss man nur die Interfaces auflisten, auf den auch wirklich ein weiterer Router lauscht.

DD-WRT im Einsatz – ein Fazit

Vor gut einem Monat durfte ich meine lokale Netzwerkstruktur ein wenig wenig umbauen. Dabei habe ich meinen alten Netgear Router rausgeschmissen. Ich wollte ein bisschen was „professionelleres“. Nach kurzer Suche bin ich auf Geräte-Serien gestoßen, die nativ mit DD-WRT unterstützen (ein kommerzieller Ableger der OpenWRT-Firmware). Hängen geblieben bin ich bei zwei Buffalo-Geräten:

  • WHR-HP-G300N (400 MHz/32MB Ram)
  • WZR-HP-AG300H (680 MHz/128MB Ram)

Beide Geräte werden ab Werk mit DD-WRT ausgeliefert. Die Hardware-Ausstattung ist für meine Verhältnisse üppig und reicht für den Home und Medium-Office Bereich. Auch wenn beide „eigentlich“ DD-WRTv24Sp2 einsetzten unterscheiden sich die tatsächlich eingesetzten Firmwares doch stark. Sie unterscheiden sich vor allem im Release-Date und den verfügbaren Features. Der kleinere G300N vermisst zum Beispiel CIFS Support, OpenVPN, beschreibbaren Speicher (JFFS2) usw.  Dazu kommen Unterschiede in den ausgelieferten Software-Versionen. Beim G300N kommt BIRD als Routing-Daemon zum Einsatz, beim AG300H wird Quagga angeboten. Man könnte beide Geräte auch auf die offizielle DD-WRT Version zurück flashen, diese hingt der „Buffalo“ Version jedoch im Release hinterher (keine Ahnung was das für Auswirkungen hat). Leider bietet Buffalo die Sourcen der DD-WRT Software nicht zum download (oder ich hab den Link noch nicht gefunden) so muss man mit einigen „Eigenheiten“ leben. Dazu gleich mehr. Neben einem Farbbranding und ein paar Funktionseinschränkungen entspricht die Buffalo Version von DD-WRT der frei verfügbaren DD-WRT-Version.

Als erstes fällt beim Einsatz von DD-WRT auf, dass man nicht für einen Idioten gehalten wird. Man kann den Assistenten wegklicken! Nach der Änderung des Passwords  darf man auf Wunsch gleich loslegen ohne sich durch einen Nerf-Dialog zu klicken. Standardmäßig ist Telnet und HTTP als „Fernwartung“ aktiviert. Das kann man aber einfach umkonfigurieren. SSH und HTTPS werden angeboten. Beide Varianten haben kleine Haken. HTTPS verwendet „fest“ eingebrannte selbst signierte Zertifikate (und ich würde wetten, dass die priv Keys nur pro Version-Build unterschiedlich sind). Will man dieses austauschen muss man gleich eine eigene Firmware einspielen da der /etc Bereich read-only gemounted ist. SSH bietet hingegen die Möglichkeit die Zertifikate zu ändern. Standardmäßig logt man sich dort hingegen als root ein. Da ist Vorsicht bei den Passwörtern geboten!

Neben diesen beiden „Fehlern“ fällt nur noch der Umstand auf, dass die Konfigurationsoberfläche stark auf den Betrieb eines Gateway-Routers ausgelegt ist. Hat man sich damit einmal abgefunden und verstanden, dass das br0-Interface (intern werden Birdges verschaltet) immer „das Interne“-Interface ist, entfaltet sich eine Konfiguationsvielfalt, die man sonst nur bei hochpreisigen Konkurrenten findet. Ein Beispiel: um auf den WAN – Port (eth1) zwei VLANs zu konfigurieren braucht es 3 Klicks. Will man WAN-VLAN1 ins br0-Netz bridgen ist das ein weiterer Klick. Will man nun das WLAN aus dem br0 nehmen und auf WAN-VLAN2 bridgen geht das mit unter 5 Klicks. Ohne auch nur ein mal das SSH-Terminal zu nutzen. Auf diesem Niveau geht es weiter. Statische Routen, sehr detaillierte Interface-Konfigurationen, fast alle Services und diverse Hilfseinstellungen lassen sich über das WebInterface bequem und umfangreich konfigurieren.

Ich hab den SSH-Zugang dennoch häufig genutzt. Das hat drei Gründe:

  • Die Zeit die man zum Konfigurieren braucht: alle Einstellungen erfordern das Schreiben in den NVRam, das anschließende auslesen dieser Informationen und das durchstartet des betroffenen Dienstes. Da DD-WRT aber nicht „weiß“ welcher Dienst betroffen ist, wird alles durchgestartet. Beispiel: ändert man an der PPPoE Einstellung etwas, werden mal ebend alle Dienste durchgestartet auch der Routing-Dienst (BIRD/ZEBRA). Der Router ist erst mal eine Weile beschäftigt. Wird ein Routing-Dienst eingesetzt und befindet man sich außerhalb der direkten Router-Netze muss man erst mal warten, bis  die Routing-Tabellen wieder stehen. Wenn man weiß was mach macht, kann man auf der Konsole in aller Ruhe an der Config-File rum fuschen. nur den betroffenen Dienst durchstartet und wenn alles wie gewünscht funktioniert, alles in den NVRam speichern.
  • Einige exotische Einstellungen kann man „nur“ über die Konsole machen. Das WebInterface bietet zwar die Möglichkeit 3 Skriptes zu hinterlegen (StartUp, FirewallUp,ShutDown) und direkt Konsolen-Befehle auszuführen, mir fehlt hier aber das Feedback. Ich hab die Skriptes immer erst im Terminal ausprobiert und dann als Skript hinterlegt.
  • Einige Eingabemasken führen quasi eins zu eins auf ein Config-File für einen Dienst. Startet man dann durch und hat einen Syntax-Fehler bekommt man keine Rückmeldung. Auch hier gilt: erst auf der Konsole ausprobieren und dann hinterlegen.

Bei den ganzen Konfigurations-Möglichkeiten sollte noch erwähnt werden, dass alle Interfaces frei konfigurierbar sind. Selbst wenn das WebInterface dann ein wenig zickt. Es werden alle Ethernet und WLan Ports einzeln an das OS gemeldet. Im Falle des AG300H (DualBand) muss man den 2.4Ghz Adapter getrennt vom 5GHz konfigurieren (auch im WebInterface). Einzig die internen LAN-Ports werden durch eine nicht konfigurierbaren Hardware-Switch verschaltet. So muss man ein wenig aufpassen was man am eth0-Port macht.

Was bleibt abschließend zu sagen? Ich bin vom Funktionsumfang der Firmware sehr positiv überrascht. Es wird einem fast alles geboten, was man so braucht. Für alles andere gibt es das SSH-Terminal.  Der WNR3500 war wohl mein letzter nicht WRT Router gewesen sein.

ics dhcp hostname direktive wird ignoriert.

Ich hatte bei mir das Problem, dass bei aktiven DNS-Update durch den DHCP Server „illegale“ DNS-Namen in meine dynamische Zone eingetragen wurden. Irgendein Witzbold muss sich bei Google wohl gedacht haben, dass „android_{MAC}“ ein wunderbar einfacher Hostname ist und den ein User nie ändern will.

Dummerweise wird dieser von keinem DNS Server standardmäßig akzeptiert. Man muss zu mindestens das „Sperrverhalten“ abschalten. Ich entschied mich dafür im DHCP Server ein Hostname zu definieren. Der wurde aber geflissentlich ignoriert. Das Snippet das standardmäßig als „on-commit“ Hook hinterlegt ist greift auf „option host-name“ zu anstatt auf „config-option host-name“.

Ich hab es wie folgt angepasst und in meine dhcpd.conf eingefügt

on commit {
  option server.ddns-hostname =
        pick (config-option host-name,option fqdn.hostname, option host-name);
  option server.ddns-domainname = config-option domain-name;
  option server.ddns-rev-domainname = "in-addr.arpa.";
}

OutOfMemory – Exception die Zweite

Während des Feintunings an der GalDroid-App bin ich auf einen interessanten Unterschied zwischen der GridView und der Gallery Komponente gestoßen.

Erstere versorgt die Adapter-Implementierung mit einer Referenz auf vorher genutzte Elemente. Die Gallery Komponente macht dies nicht. Das ist dann blöd, wenn man sich darauf verlässt, dass man über diese Referenz alte Bitmaps aufräumt oder gar Hintergrund-Threads abbrechen kann/muss.

Wer also einen Adapter an die Gallery bindet, muss sich selbst um die „alten“ Referenzen  kümmern. In einem ersten Schritt hab ich dafür gesorgt, dass zu einem Zeitpunkt nur ein Bitmap dekodiert wird (syncronized-Block).  Das gibt dem GC genug Zeit, Platz zu schaffen wen möglich. Daneben nutze ich eine LinkedList/Queue von WeakReferences auf die AsyncTask für das Laden und Dekodieren der Bilder. Überschreitet die Länge dieser Queue einen Schwellwert, werden die ersten Threads abgebrochen.

Dadurch wird keine Bilder mehr unnötig geladen und es spart gleichzeitig Ram.

Sourcecode:

Android – BitmapFactory und OutOfMemory-Exception

OutOfMemory-Exceptions sind immer eine unangenehme Sache. Trehten sie einmal auf, kann man nicht mehr reagieren. Das Programm wird einfach vom Stack geworfen und dem User eine unschöne Fehlermeldung vorgesetzt. Für den Entwickler ist die Fehlersuche langwierig, da das vermeintliche „Opfer“ selten der Verursacher ist. Der produzierte StackTrace ist schlicht unbrauchbar.

Die OOM-Exceptions trehten gehäuft im zusammenhang mit der BitmapFactory auf. Der Grund ist einfach, Bilder brauchen viel Platz…

Wenn man im Web nach Beispielen  für eine Bilder-Galerie sucht, bekommt man eigentlich immer das gleiche Beispiel. Ein paar kleine Bilder, lokale Resourcen, werden über eine Klasse die von BaseAdapter abgeleitet an ein über-gelagertes UI-Element gereicht. um dort zur Anzeige gebracht zu werden.

Bringt man jedoch Bilder auf einem Tablet zur Anzeige, werden schon die Bild-Dimensionen größer, nicht nur die Auflösungen. Auf einem 10 Zoll Tablet mit 1280×800 und mehr Bildpunkten braucht ein Bild in VollBild-Auflösung oder mehr schon mehrere MegaByte Ram, alleine zum Vorhalten der Bildinformationen. Dank der komprimierung brauchen Bilder als File wesentlich weniger Speicher, als die dann Tatsächlich im Ram belegen. Ein JPEG in 1920*1080 Aufgelöst und 500KB Dateigröße braucht mehr als 6MB Ram. Ein paar solcher Bilder im Ram abgelegt und die Dalvik-VM grüßt mit einer OutOfMemory-Exception.

Dazu kommt Fall einer Web Galerie die Bilder nicht lokal vorhanden sind, sondern bei Bedarf von einem WebServer geladen werden. Was einfach klingt, stellte sich schnell als vermeintliches Memory-Leak heraus. Im Grunde dreht sich alles um folgende Methode:

public View getView(int position, View cachedView, ViewGroup parent);

Mit dieser Methode werden die Views/darzustellenden Bilder zur Laufzeit abgefragt. Im einfachsten Fall sind das ImageViews die ein Bitmap auf den Bildschirm zeichnen.

Der augenscheinlichste Ansatzpunkt zum Speicher sparen ist, dass man eine vorher benutze View zur „Wiederverwendung“ übergeben bekommt (cachedView). Die CachedView kann man auch benutzen, der Resourcengewinn ist bei großen Bildern aber nicht „von Interesse“. In Anbetracht der xMB pro Bild, kommt es auf die paar Byte für die ImageView Struktur kaum an. Kommt jedoch ein AsyncTask zum ein Einsatz, um die Bilddaten „im Hintergrund“ herunterzuladen und in ein Bitmap zu decodieren, dann ist diese cachedView immens wichtig. Slided der User schneller durch die Galerie, als die Bilder aus dem Netz herunter geladen werden können, werden AsyncTask erzeugt, die „sinnlos“ Bilder im Hintergrund herunter laden und decodieren. Bei kleinen Bildern und einem Lokalen Cache, ist das nicht mal schlecht. Einmal gecached, werden die Bilder das nächste mal aus der lokalen Quelle geladen. Bei den großen Bildern frisst das parallele Decodieren schlicht zu viel Speicher.

Bei der GalDroid-Entwicklung hat es sich nicht als sinnvoll herausgestellt, die Anzahl der Threads zu kontrollieren. Der overhead, die Downloads zu queuen, stand in keinem Verhältnis zum Nutzen oder der Wartezeit des Users. Ich hab mir in der CachedView einfach den Task gemerkt, der das Bild herunterlädt und diesen bei Bedarf abgebrochen. So sind bei einer VollBild-Anzeigen selten mehr als vier Bilder parallel in Bearbeitung.

Eine Ausnahme gibt es noch: Ist das Layout des UI-Elements nicht statisch fixiert, werden die Dimension geändert, oder hängen die Dimensionen gar von den darzustellenden Inhalt ab, wird das 0-te Element mehrfach abgefragt um die benötigten Dimension zu bestimmen. Das ist in sofern übel, da es 5-7 mal hinter einander passierte, ohne das jeweils eine cachedView übergeben wird. Wieder: bei kleinen Bildern unschön, bei großen Bildern grüßt die OutOfMemory-Exception.

Das Problem kann man umgehen, in dem man mehr speichert. Bei der GalDroid wird einfach ein Feld von WeakReferences angelegt, in dem jedes je angefragte ImageView gespeichert wird. Die Logik ist simpel – wird ein Element mehrfach kurz hinter einander abgefragt, sollte es in diesem Speicher zu finden sein. Wird es länger Zeit nicht genutzt, räumt der GC auf und die WeakReference zeigt auf NULL.

Sollte nach diesen Maßnahmen immer noch OOM-Exceptions auftreten, kann man noch Bitmap.recycle aufrufen, sobald eine ImageView aus dem Sichtbereich des Users verschwindet. Das ist aber „frickelig“, da nicht immer klar ist, wann etwas „nicht mehr gesehen werden kann“. Das Recycle gibt sofort den Speicher des Bitmaps wieder frei, ohne den GC aufzurufen. Allerdings muss man so jedes mal das Bitmap neu laden, wenn es wieder in den Sichtbereich kommt.

Sollte das alles nicht helfen, kann man auf den Allocation Tracker zurückgreifen. Dieses Tool ist in dem ADT für Eclipse enthalten und listet jedes erstellte Objekt zur Laufzeit auf.

GalDroid – Gallery 3 für Tablets

Da es mich ein wenig genervt hat, dass es keine einfach Anbindung der Gallery 3 für Android Honeycomb gibt, hab ich mich selber mal hingesetzt und was zusammen geschustert. Das ganze ist ab heute im Market verfügbar.


Available in Android Market

Die Entwicklung ging relativ einfach von der Hand jedoch bin ich über einige grundlegende Sachen gestolpert, die ich in einigen Beiträgen in den nächsten Tagen vertiefen werde.

Für alle interessierten, den SourceCode gibt es hier: https://github.com/raptor2101/GalDroid

Deus Ex – Human Revolution

Einleitung

Deus Ex – Elf Jahre ist es her. Elf Jahre die ich ab und an dieses Spiel (noch immer installiert) starte und eine kleine Runde durch NewYork, HongKong oder Vandenberg drehe. Elf lange Jahre, die ich nach einem würdigen Nachfolgen suche (es soll gerüchteweise einen zweiten Teil geben…). Nach dieser langen Zeit und leider viel zu wenigen Nachahmern schickt sich Eidos Montreal (ION-Storm gibt es nicht mehr) nun an, Deus Ex wieder zu beleben. Ich hab es seit letzter Woche in den Fingern und hab es wie im Rausch durchgespielt. Dies ist nun mein kleines persönliches Fazit dieser wirklich „illuminierten“ 30 Spielstunden. Eins vorweg: Das Spiel macht Spaß. Seit Mass Effect (1) und Dragon Age – Origins hat mich kein Spiel mehr so gefesselt. Aber ich gehöre zum schlag der Spieler die gemeinhin als „nicht casual“ bezeichnet werden (HardCore will ich mich selbst nicht nennen). Dieser Schlag von Spieler zeichnet sich durch das Seltsame verhalten aus, gewisse Aspekte, Fehler oder Eigenheiten eines Spiels komplett zu ignorieren und auf der anderen Seite ein Spiel an Kleinigkeiten zu Grunde zu richten. Beispiel: meist ist die Grafik uninteressant aber wehe ein Logikfehler hat sich in die Story eingeschlichen. Dies sollte beachtet werden wenn der folgende Erfahrungsbericht/Kritik gelesen wird.  Des weiteren poste ich keine Bilder. Diese sind entweder langweilig (Schleichshooter) oder Spoilern die Handlung.

WARNUNG: Am Ende des Artikel wird es einen Spoiler geben, da ich leider nur so meinen Hauptkritikpunkt erläutern kann. Bis zu dieser Passage spoiler ich nur das was eh offensichtlich ist und halte mich selbst mit Spoilern zurück, die aus den Trailern kommen (die mal eben alle Wendungen verraten). Einfach nicht zu weit runter scrollen…

Ein ganz schlechter Tag

So genug der einleitenden  Worte. Deus Ex – Human Revolution dreht sich, wie seine beiden Vorgänger, um Verschwörungen, Verrat und das „Zusammenleben“ von Menschen mit und ohne Augmentierungen allgemein. Da Deus Ex 2  die Geschichte nach Deus Ex erzählt (und  von den Fans zerrissen wurde), widmet sich HumanRevolution der Geschichte vor Deus Ex. Als Hauptfigur dient diesmal kein Denton sondern ein bis dato eher Unbekannter namens Adam Janson. Dieser ist Sicherheitschef bei Sarif Industries und Ex-Freund des dortigen Wissenschaftsgenies Megan Reed. Und wie es das Glück so will, just an dem Tag als sich der gute Adam wieder Hoffnung auf eine Beziehung mit Reed machen kann und diese der ganzen Welt ihren Durchbruch in der Augmentierungs-Technologie verkünden will geht alles schief. Es kommt „ganz zufällig“ zu einem Großangriff auf die Firmenlabore, die Sicherheitssysteme versagen und der Spieler in Jansons Person darf es richten. Das ist der recht theatralische Einstieg von Human Revolution. Am Ende (nach ca 10 min Spielzeit) wird Janson sterben. Nahkampferfahrung mit einem Voll-Augmentierten „Elite“-Soldaten, eine Kugel zwischen die Augen und schon ist der mieseste Tag im Leben eines angehenden Helden fast perfekt. Fast… Was noch fehlt, ist der super reiche, technikverliebte Boss des Unternehmens. Dieser packt Janson mal „kurz“ auf den OP-Tisch und spendiert ihm alles was die Technik so hergibt. Das ist die Ausgangslage für eine 30 Stunden Hatz auf die „Verursacher“ und deren Hintermänner, bei der Janson mehr aufdeckt, als ihm lieb und gesund ist.

Eine Welt von Morgen

Wo Deus Ex drauf steht müssen Rollenspielelemente, dystropische SciFi und Verschwörungen drin sein. Erste Entwarnung: ja es gibt ein Erfahrungssystem und Augmentierungen. Es gibt Waffenbasteleien. Die SciFi-Atmosphare ist beklemmend und intensiv und nunja die Verschwörung gibt es auch. Anders als in Deus Ex 1 fliest die Erfahrung jedoch direkt in die Augmentierungen (früher Implantate). Spieltechnisch wird das so erklärt: Janson hat schon alle Implantate intus, jedoch abgeschaltet, da das sein Körper nicht vertragen würde. Erst durch Übung und Erfahrung kann er weitere Implantate freischalten. Dabei unterteilen sich die Implantate in zwei Kategorien: Aktive und Passiv. Erstere braucht „Energie“ und muss aktiviert werden, letztere sind immer Scharf und ziehen keinen Strom. Erfreulicherweise gibt es gerade zu Anfang einen Haufen an sinnvollen Implantaten. So wird die ersten 5-10 Stunden die Spielweise durch die Wahl der Implantate definiert. Danach kristallisiert sich durch die Spielmechanik her raus, welche Implantate in die „Spielwelt“ passen und welche nicht. Am Ende des Spiels hatte ich 4 „Pratik-Punkte“, also aufrüstbare Implantate, übrig, dich ich nicht vergeben habe, weil es einfach Sinnlos war, bzw. deren Nutzen gen null ging! Und das auf dem höchsten Schwierigkeitsgrat (dazu später mehr). Das liegt daran, das einige Implantate für sehr dedizierte Situationen gedacht sind. Zum Beispiel „Durch die Wand schlagen“, „Hohe Stürze überleben“. Die Situationen an denen man das braucht, kann man an einer Hand abzählen. Dazu gesellen sich schlicht Sinnfreie Implantate. „Durch die Wand schauen“ wird z.B. durch den standardmäßig freigeschalteten Radar überflüssig gemacht. Und schließlich folgen dann noch die Implantate deren Nutzen eher zweifelhaft ist: „Besser Zielen“ – Machte die Eigenbewegung des Zielvisiers in Deus Ex 1 einen Treffer noch zur reinen Glückssache, ist sie im Human Revolution kaum spürbar. Drei Punkte in dieses Implantat und es bewegt sich gar nichts mehr.

Ein „Implantat“ hingegen ist definitiv zu stark geraten: der Nahkampf. Von Anfang an kann Janson im Nahkampf jeden Gegner mit einem „Knopfdruck“ ins Reich der Träume schicken oder gleich ganz in die Unterwelt. Wobei die Animationen für das „betäuben“ sehr drastisch ausfallen. Ich zweifle doch stark an, dass der geballte Einschlag einer Roboterfaust im Schädel „nur“ betäubt. Auch die anderen Animationen deuten eher auf schwere Knochenbrüche hin, denn auf Betäubung. Nur selten setzt Janson zum leisen Würgegriff an. Alternativ nutzt er seine Armklingen und macht Geschnetzeltes aus den Kontrahenten. Investiert man dann nochmal zwei Praxispunkte, kann man auch zwei Gegner gleichzeitig ausschalten. Das ganze Kostet zwar gleich eine ganze Energiezelle (davon hat man im Spiel am Ende fünf) aber diese lädt sich schnell wieder auf. Auch die Einschränkung das Jenson ohne Strom gar keine Nahkampfattacke ausführen kann, wirkt eher aufgesetzt, als das es dem Balancing gut tut.

Die eigentliche „Stärke“ dieser Attacke kommt nicht von der Einsatz-Häufigkeit sonder von dem Umstand, dass die Zeit im Spiel anhält, während die Animation läuft. Auf den ersten Blick erscheint das Logisch, die Animationen laufen teils länger als 30 Sekunden. Auf den zweiten Blick ist das die einzige Betäubungsmöglichkeit, die den Gegner sofort auf die Bretter schickt (ElektroShock/Betäubungsgewehr brauchen Zeit). Es gibt keinen Grund für den Spieler auf diese Attacke zu verzichten oder gar die tödliche Variante zu benutzen, sieht man vom „Style-Faktor“ mal ab. Ein Klick und die Gegner fallen um. Wird man eindeckt, ist man meistens schnell genug an der Wache dran um sie Umzuhauen, bevor sie Alarm schlägt. Nur Waffengänger haben das Nachsehen. Sie kommen selten dicht genug an den Gegner rann um diese mächtige Fähigkeit einzusetzen. Zusätzlich stellt sich schnell  her raus, dass die Entwickler klar den „schleichenden“ Janson übervorteilen. Wozu also Thermalpanzerung skillen, wenn es doch eh „Punktabzug“ gibt, wenn man von  Gegnern entdeckt wird.

Ein schleichender Janson, der seine Gegner mit gezielten Kopfschüssen aus dem Betäubungsgewehr ins reich der Träume schickt, bekommt 3 mal so viele Erfahrungs-Punkte wie ein Rambo-Janson. Dazu schießen die Gegner noch unglaubwürdig gut und treten meistens in größeren Rudeln auf. Das Leveldesign tut sein übriges. Dieses bietet häufig eine alternative Route an, die eine vor der Entdeckung durch die Wachen schützt. Im Gegenzug werden aber selten sinnvolle Deckungs- und Rückzugsmöglichkeiten angeboten. Da Janson selbst mit Panzerung (auf höchstem Schwierigkeitsgrad) wenig Treffer einsteckt, bleiben nur Angriff aus dem Hinterhalt, die wiederum schnell auffliegen. Diese Rahmenbedingung, gepaart mit der immer akuten Munitionsknappheit, zwingen dem Spieler eigentlich eine schleichende Spielweise auf. Hat man sich einmal darauf eingelassen, macht Human Revolution als Schleichschooter richtig Spaß. Es werden immer mindestens zwei Routen angeboten. Meist jedoch mehr. So hat man die Wahl, übers Dach, durch die Kanalisation oder schleichend durch den Haupteingang zum Ziel vorarbeiten. Diese Freiheit gilt auch in geschlossenen Gebäudelevels. Auch wenn die (schon aus Deus Ex bekannten) Lüftungsschächte aufgesetzt wirken, so sind sie doch immer genau dann da, wenn man eine Alternative braucht.

Die Entwickler drehen aber genau fünf mal den Spieß um. Drei mal muss man bei Bosskämpfen in den Nahkampf, in zwei weiteren Situation darf man in den offenen Kampf. Die Bosskämpfe nerven schlicht und ergreifend. Die Bosse setzten alle keine besondere Taktik vor raus , stecken viel ein (nach den Kämpfen leidet man immer unter Munitionsknappheit) und passen so gar nicht ins sonstige Spiel. Im alten Deus Ex hatte man, wenn man wollte, die Möglichkeit den Boss ohne eine einziges Gefecht ins Nirwana zu schicken. Das war zwar nicht sonderlich Herausfordernd aber passte ins Spiel. Hier ist der Spieler gezwungen gefühlte 20 Min im Kreis zu rennen und ab und an drauf zu halten. Oder man hat durch Zufall die richtigen Augmente geskillt (die man sonst nicht braucht) und putzt die Bosse im Handumdrehen weg. Wesentlich besser gefallen mir da die beiden „offenen“ Kämpfe in den Missionen. Bei beiden kann man sich für den Kampf entscheiden oder sich drum „drücken“. In einer Situation ist man gezwungen eine Stellung zu halten und muss sich derweil Wellen von Gegner erwehren. „Zufällig“ liegen ein Haufen Haftminen und ein Geschützturm rumm, der „umprogrammiert“ werden will. Die zweite Szene ist intensiver. Hier geht es um einen dem Spieler nahen NPC. Man hat die Wahl ob man sich den Kampf stellt oder der NPC stirbt. Stellt man sich, muss man alles raushauen was man an Munition, Augmenten und „Fähigkeiten“ hat. Der Gegner ist übermächtig, die Uhr tickt schnell. Man muss das einzige mal in Deus Ex unter Zeitdruck die Gegnerzahl rapide dezimieren. Eigentlich hat man als „Schleicher“ kaum eine Chance. Schafft man es doch, ist das Erfolgserlebnis um so größer.

Eine Technik von Gestern

Diese Nahkampf-passagen werden zusätzlich noch durch die Steuerung frustrierender. Während die Widrigkeiten beim Schleichen nicht auftreten, stört folgendes im schnellen Kampf doch extrem:

  • Der Automatische Waffenwechsel bei Munitionsmangel. Gerade in hitzigen Situationen ist es nervig wenn ein Waffenwechsel mehrere Sekunden braucht und dann noch auf die falsche Waffe geht.
  • Granaten: gerade in Bosskämpfen sind sie essentiell wichtig. Es braucht aber zwei Tasten um auf die richtige Granatenart zu wechseln und diese zu Werfen.
  • Das Deckungssystem: Mal verhakt sich Jenson, mal kann er sich nicht lehnen, Gewehre mit optischen Visiere kann man „zielen“ bei allen anderen nicht.

Auch das Kriechen,  Springen,  Schleichen und Ducken haben andere Spiele schon intuitiver gelöst, zum Beispiel über ein Mausrad. Auch so wirkt die Verwendete Technik nicht auf der Höhe der Zeit. Besonders, dass die Figuren nicht lippensynchron (weder im englischen noch im deutschen) sprechen, fällt als ersten negativ auf. Danach folgen die „hölzernen“ Animationen. Gerade in Gesichtsnahaufnahmen fällt es extrem auf,  dass es so gut wie keine Mimik gibt. Daneben fällt eigentlich nur noch die KI mit krassen Mängeln aus dem Rahmen. Die KI aus Human Revolution macht den Eindruck als hätten sie die aus Deus Ex 1 importiert oder zu mindestens eins zu eins nachgebaut. Und die KI war damals schon nicht die Cleverste. Mal abgesehen von ihren Schießkünsten hat die nicht sonderlich viel drauf. Erkennen das eine Leiche oder ein Betäubter herumliegt (samt aufwecken), bei Sichtkontakt Alarm schlagen und vorgegebene Wege abschreiten, dass war es dann auch schon. Was fehlt:

  • Kommt es mal zu einem offenen Gefecht, verhält sich die KI schlicht dämlich. Einkreise, übersetztes Vorrücken und Feuerschutz scheint die KI nicht zu kennen. Auch das gezielte Deckung suchen hab ich nur an Stellen gesehen, wo ich es für geskriptet halte.
  • Die KI reagiert nicht auf ihre Umgebung. Stellt eine Kamera, Roboter, Geschützturm den Dienst ein stört das die anwesenden Wachleute kein bisschen. Auch das der Kollege, mit dem man vor 30 Sekunden noch lustig einen Plausch gehalten hat, von seiner Runde (30 Sekunden) durch den (gut einsehbaren) Raum nicht zurückkehrt, scheint kein Misstrauen hervorzurufen. Offene Türen, Lüftungsschächte oder herumliegende Waffe (von verschleppten Wachen)… ach geschenkt.
  • Das ganze gipfelt in der Tatsache, dass man den NPC vor ihren Augen die Bude leerräumen kann, ohne dass diese Reagieren. Aber wehe man macht sich an Computer oder Schlössern zu schaffen!

Mir ist bewusst, dass eine bessere KI den Schwierigkeitsgrad massiv hochgezogen hätte, aber mal ehrlich, im höchsten Schwierigkeitsgrad erwarte ich mehr als nur stupide Statisten als Gegner. Obwohl alle Medien behaupten um die Grafik sei es nicht besser bestellt überzeugt mich diese wiederum. Die Engine unter der Haube ist Wirklich nicht mehr taufrisch. Es gibt zu wenig Charactermodelle was in vielen Clonen mündet und die Effekte sind nicht auf dem Level von Crysis. Das macht das Spiel aber durch seine Detailverliebtheit und Grafikstiel wett. Wenn man das erste mal das eigene Apartment betritt und das Licht und Farbenspiel betrachtet, das erste mal Upper-Hengshan erlebt, oder in eine (unlogisch) riesige geheime Vorschungsanlage einfährt verschwendet man keinen Gedanken an die GrafikEngine. Überhaupt sind die Orte grafisch sehr unterschiedlich und glaubwürdig (sieht man mal von den „Abkürzungen“ ab) gestaltet. Das Ambiente stimmt. Das Funktioniert sogar so gut, dass die gelegentlichen Zwischensequenzen einen sogar aus dem Spiel reißen, weil sie ein anderes/dunkleres Farbsetting haben. Ansonsten nimmt man Deus Ex die Welt ab, in die es einen hineinziehen möchte. Das liegt vor allem an den herumliegenden Objekten. An allen Ecken und Enden gibt es was zu entdecken, zu lesen oder zu benutzen. Das macht die so Welt glaubwürdig. An einigen Stellen hätte ich mir nur höher aufgelöste Texturen gewünscht. Wenn man in Jansons Apartment einige Briefe oder Baupläne herumliegen hat und diese nicht lesen kann weil die Buchstaben zu gering aufgelöst sind, ist das schade. Der Sound trägt einen großen Teil zur Atmosphäre bei. Die Waffeneffekte sind nicht übertrieben aber auch nicht zu schwach. Die Sprecher sind durch die Bank weg glaubwürdig. Gerade in den Wortduellen, wo eigentlich die Mimik Anhaltspunkte liefern sollte, ist die Betonung und Wortwahl das einzige Mittel um abzuschätzen ob man den Duellanten „erwischt“ hat oder eben nicht. Auch der Soundtrack weiß zu gefallen. Nicht mehr der Elektro/Synti-Stiel wie bei Deus Ex 1 aber doch sehr hörenswert. Er treibt die Situation immer passend an und ist das einzige was die Bosskämpfe erträglich macht.

Fazit

Alles bis hierher Genannte ist Kritik auf hohem Niveau. Einiges davon wird von  dem ein oder anderen nicht mal bemerkt. Andere dinge stoßen sauer auf. Dennoch ändert das nichts an der Tatsache das Deus Ex Human Revolution ein sehr guter Neustart der Serie ist. Es macht einfach Spaß Janson durch die futuristische Welt zu steuern und ihn wieder an meine „Wunschvorstellung“ anzupassen. Leider bleibt er meiner Meinung nach hinter Deus Ex 1 zurück und erfüllt auch die Erwartung nicht, die Eidos und Square Enix gesetzt haben (auch im Spiel). Das liegt vor allem an dem bisher nicht angesprochen Punkt: der Story – die lässt sich nicht Kritisieren ohne zu spoilern.

LETZE WARNUNG – MASSIVER SPOILERIm folgenden Absatz werde ich auf die Story eingehen, das geht leider einher mit Spoilern die die wichtigsten Wendungen verraten.

Eine lange Geschichte…

Wenn Deus Ex Human Revolution einen richtigen Schwachpunkt hat, dann die Story. Nicht das man mich falsch versteht. Einen Großteil der Spielzeit (bei mir 27 von 30 Spielstunden) ist diese Packend und unterhält glänzend. Abgesehen von ein paar sehr aufgesetzt wirkenden Schwächen (mal wieder eine Super KI/Sidekicks auf Deus Ex 1) ist die Handlung in sich (ab)geschlossen und Stimmig. Aber wie würde der Weinkenner sagen: Es hat einen miesen Abgang. Wenn man Eidos etwas bei Deus Ex Human Revolution vorwerfen möchte, dann das sie ausnahmslos die gesamte Handlung, samt aller Wendungen in ihren Trailern gespoilert haben. Das sie dabei wesentlich mehr Aktion und Theatralik rein gepackt haben als im realen Spiel vorhanden, kann man fast schon als böswillige Täuschung auslegen. Wie in den Trailern dargestellt ist der Spieler/Janson die meiste Zeit damit beschäftigt die Umstände um den Anschlag auf Sarif Industrie aufzuklären. Wie schön im Trailer betont, sind die Wissenschaftler gar nicht tot, das waren keine einfachen Terroristen und auch nicht die FEMA und Janson wird alles tun, was in seiner macht steht um seine Ex Freundin zu retten. Das passt ja alles so weit und motiviert. Auch im Spiel kommt das sehr gut rüber. Die Storywriter haben es verstanden, immer einen (und wenn noch so unsinnigen) CliffHanger einzubauen, der die Spielabschnitte verbinden und zum Weiterspielen verleitet. Es wird wohl keinen Überraschen, dass am Ende dieser Hatz ein Wiedersehen steht. Und genau an dieser Stelle fällt das Kartenhaus „Story“ in sich zusammen. In dem Momenten wo sich Janson und Reed nach „6 Monaten“ wieder gegenüberstehen, hätte das Spiel zu Ende sein sollen oder die „neue“ Story ordentlich einführen müssen. Was passiert? Die beiden stehen sich gegenüber. Janson  (zu recht) stinksauer auf seine Ex. Sie entsetzt das er noch lebt (sie hat ihn ja sterben sehen) aber doch Froh das er sie raus haut und bemüht um Erklärungen. Dann ein Schnitt, irgendwo anders in der Welt (Der Ort wird auch im Trailer gezeigt) passiert eine Katastrophe und sofort wird das Gespräch beenden. „Janson du musst dich darum kümmern, mach’s gut“. Das war der erste Moment im Spiel wo ich mir verschaukelt vorkam. Kein Wort der Erklärung, keine Überleitung, nichts. 10 Minuten später steht man im nächsten (letzten) Level und das war es. Ist den Entwickler plötzlich das Geld oder die Ideen ausgegangen oder gar Beides? So etwas unfertig wirkendes hab ich ja seit der „Wiedersehen“-Szene in MassEffect 2 nicht erlebt. Dazu kommt noch, dass der letzte Level einfach schlecht ist. Linear, ohne große Überraschung und mit Zombies gespickt.  Ja richtig gelesen, mit Zombies. Die Erklärung warum die Menschen durchdrehen ist zwar schlüssig, das ändert aber nichts daran, dass der spielerische Anspruch gen Null geht. Man kann sich dem Kampf nur noch selten entziehen und ist gezwungen auf alles drauf zuhalten was sich einem in den weg stellt. Stellenweise gibt es nicht mal, irgendwelche Alternativrouten. Nur der Bosskampf kann überzeugen. Es ist der erste bei dem es nicht auf reines Ballern ankommt. Die Krönung ist der dann der Spielabschluss. Deus Ex bietet vier enden zur Auswahl an, aber liebloser hätte man diese nicht präsentieren können. Erstens wirken von drei Parteien die zur „Auswahl“ stehen, zwei einfach nur Aufgesetzt und deplatziert, zweitens kann man die Folgen nicht wirklich abschätzen. Muss man aber auch nicht. Am ende Steht man in einem Raum vor drei Knöpfen (die Ansprache die dann folgt, wurde auch schon im Trailer gespoilert) und hat die Wahl, oder man geht in einen Nebenraum und drückt den vierten Knopf. Was für epische Entscheidung. Was bleibt danach zurück?

  • Sie hätten den letzten Level weglassen sollen.
  • Sie hätten die Story um die Iluminaten weglassen sollen. In Deus Ex 1 waren alle Parteien sauber erläutert und deren Ziele und Motivationen zu mindestens am Ende klar. In Human Revolution bleiben mehr Fragen offen als beantwortet werden.
  • Was sollte das mit der Nebenstory um Jansons Vergangenheit (die später eine Rolle spielt), wenn die eigentlichen fragen doch nicht beantwortet werden.
  • Die Sidekicks auf DeusEx wirken arg aufgesetzt. Nur TracerTong schafft es überhaupt ins Spiel (die Mission ist lächerlich). Der Rest wie Manderlay oder Bob Page finden nur in den Mails Erwähnung. Wo ist Navara und Hermann. Wenn das die Überleitung zu Deus Ex 1 sein soll, wo bleibt die Seuche, wo die NSF usw. Human Revolution spielt keine 25 Jahre vor Deus Ex 1

Bei der Story wäre weniger wesentlich mehr gewesen. So bleibt ein fader Beigeschmack an einem ansonsten sehr guten Spiel hängen

XBMC Mediathek Addon für XBox

Nach langem hin und her mit Andy haben wir den Fehler/Änderung in den Interfaces zwischen XBox und „normalem“ XBMC gefunden.

Ich hab ein Addon-Zip bereit gestellt: plugin.video.mediathek

 

Sollte sich was ändern werde ich es hier Veröffentlichen

Update – 19.09.2011 : BR Alpha hinzugefügt
Update – 20.09.2011: ARTE wieder ans Laufen gebracht.
Update – 30.09.2011: BayernFS wieder ans Laufen gebracht
Update – 18.10.2011: WDR gepatched
Update – 20.11.2011: WDR gepatched, ZDF HD Inhalte hinzugefügt, ORF aktualisiert
Update – 17.02.2012: KIKA (Without Kikaninchen) und NDR hinzugefügt. 3SAT gepatched
Update – 22.06.2012: XBOX Version auf Eden Niveau hochgezogen. (ARD läuft wieder)