Schlagwort-Archive: Fehler

Tja, da geht sie hin, meine schöne alte WordPress-Theme, die ich damals mühsam zusammengefrickelt habe. Damals, 2010. Mit dem neuesten WordPress-Update hatte die Theme leider plötzlich einige schwerwiegende Probleme verursacht, wodurch Kommentare und diverse andere Dinge nicht mehr angezeigt wurden. Den oder die Fehler zu beheben hätte wahrscheinlich sehr lange gedauert, wenn ich es überhaupt irgendwie hinbekommen hätte. Also musste ich schnell improvisieren und eine neue Standardtheme einstellen, damit die Seite überhaupt wieder funktioniert.

Die alte Theme war ursprünglich für WordPress 3 erstellt worden, seitdem unverändert geblieben, und daher auch nicht mehr an die neuen Funktionen angepasst worden. Mit jedem weiteren Update und größeren Versionssprung stieg die Gefahr, dass früher oder später etwas an meiner Theme kaputtgehen würde. Insofern ist es ein Wunder, dass das Ding überhaupt so lange gehalten hat. Leider hatte ich heute Mittag dann wohl doch kein Glück mehr, und daher sieht meine Webseite jetzt eben so komisch aus.

Ich kann im Moment leider nicht viel machen, allerhöchstens Kleinigkeiten, mir fehlt auch meistens die Zeit, um mich wieder ins Themeing einzuarbeiten und Grafiken zu bearbeiten, insofern wird es jetzt wohl erstmal so bleiben, bis mir etwas einfällt. Die Umstände beim Lesen bitte ich zu entschuldigen.

Vielleicht sehe ich es einfach positiv: Jetzt muss ich tatsächlich mal wieder was machen, und kann die Gelegenheit für eine Generalüberholung meiner Webseite nutzen. Wer weiß schon was dabei rauskommt.

Ende der 90er Jahre war es leicht, ein Bullfrog- und Peter Molyneux-Fan zu sein. Die britische Spielefirma kannte ich bereits seit meiner Kindheit von Powermonger und Populous auf dem Atari ST, später spielte ich auch Theme Park und Hi-Octane, und auch in Syndicate Wars investierte ich viel Zeit. Das Jahr 1997 brachte uns gleich zwei Kracher von der Insel: Dungeon Keeper und Theme Hospital. Ersteres räumte für seine innovative Spielidee und grandiose Umsetzung viele Preise ab, letzteres stand dagegen ein wenig in dessen Schatten. Es wurde zwar lobend und wohlmeinend beurteilt, es habe zwar nicht ganz die Klasse des wesentlich bekannteren Freizeitpark-Vorgängers von 1994, aber sei dennoch ein witziges und angenehm zu spielendes, solides Werk, vielleicht ein wenig verbuggt, aber doch insgesamt gut. Und schon nach kurzer Zeit geriet das Spiel in Vergessenheit.

Theme Hospital ist ein Krankenhaus-Aufbauspielchen mit isometrischer 2D-Comic-Grafik, witzigen Fantasiekrankheiten und schrägen Animationen. Wer als Kind eine Playmobil-Arztpraxis betrieben hat, wird Theme Hospital lieben. Zu knuffig sind die vielen kleinen Leute, die durch die Gänge tapsen, ihrer Arbeit nachgehen, sich behandeln lassen, oder die Toilette aufsuchen. Die Grafik ist farbenfroh und nach damaligen künstlerischen Maßstäben wunderbar gepixelt. Der Schwierigkeitsgrad lässt sich in drei Stufen einstellen, ist aber insgesamt höchstens moderat. Da die Windows 95-Version heute nicht mehr überall besonders gut läuft, und diese bei mir auch unter VirtualBox in einer XP-VM leider extreme Performance-Probleme hatte, musste ich zur DOS-Version (Gepatchte deutsche Version 1.0.0.1) in der Emulation via DOSBox greifen, was problemlos funktioniert hat.

Mein jüngeres, 15-jähriges Ich würde wohl ungläubig gucken, wenn ich ihm erzählte, dass er noch fast 20 Jahre braucht, bis er das Spiel tatsächlich durchspielt. Aber es ist endlich vollbracht. Und so wurde Theme Hospital hiermit zum allerersten Spiel, das ich komplett in DOSBox bis zum Ende gespielt habe. Nachdem ich die Demoversion nach 1997 schon gespielt hatte bis der Arzt kommt, enttäuschte mich die Vollversion, die ich mir nicht mehr als zwei Jahre später besorgte, zunächst maßlos. Der Grund war recht simpel: Die ersten paar Levels sind wunderbar zu spielen, und haben mich genauso sehr mitgerissen wie die Demo. Und dann kamen die Epidemien.

Epidemien sind Zufallsereignisse und im wahrsten Sinne des Wortes die Pest in Theme Hospital. Sie machen mir das Spiel zur Hölle, was mir auch Ende der 90er schon unangenehm aufgefallen ist, weshalb ich es frühzeitig aufgegeben habe. Wer von einer Epidemie heimgesucht wird, kann diese entweder pflichtbewusst freiwillig melden und zahlt pauschal 10.000 Dollar Strafe. Das ist schon nicht leicht zu stemmen, besonders weil Epidemien in den höheren Levels ständig auftreten, gerne auch gleich mehrmals hintereinander, und man dadurch ruckzuck pleite ist und den Level von vorne beginnen darf.

Sinnvoller ist es, die Epidemien zu vertuschen und heimlich zu bekämpfen. Dann muss man eigentlich nur die betroffenen Patienten suchen und händisch mit der Maus markieren. Die Krankenschwestern können dann die markierten Patienten impfen. Schließlich muss man nur noch dafür sorgen, dass die Epidemie-Patienten schnell geheilt werden, bevor das Gesundheitsamt Wind davon bekommt. Dumm nur, dass hier absolut nichts funktioniert: Die Krankenschwestern übersehen minutenlang einzelne markierte Patienten, selbst wenn sie direkt davorstehen, selbst wenn man zehn extra neu angestellte Krankenschwestern direkt neben ihnen abstellt. Im schlimmsten Fall ignorieren sie die Patienten bis zum bitteren Ende.

Und sogar wenn alle Patienten erfolgreich geimpft sind: Ob und wieso eine Epidemie vom Gesundheitsminister entdeckt wird, scheint reiner Zufall zu sein. Beim allerersten Fall zahlte ich astronomische 36.000 Dollar Strafe und war auf einen Schlag ruiniert – Level verloren, alles für die Katz. Ein anderes Mal sind es „nur“ 8000 oder gar 4000 Dollar Strafe, und hin und wieder gewinnt man und bekommt plötzlich 9000 Dollar Entschädigung für eine Epidemie. Oft reicht es, wenn man dieselbe Epidemie via Savegame ein zweites oder drittes Mal spielt, ohne dass man den Eindruck hat, weniger falsch gemacht zu haben, schon ändert sich das Ergebnis extrem. Die Epidemien scheinen komplett fehlerhaft zu sein, und machen das Spiel fast ungenießbar. Denn eigentlich will man bauen und verwalten, und sich nicht ständig davor fürchten müssen, dass die nächste Epidemie mir das Level ruiniert. Dass die Epidemien oftmals schon in der frühesten Spielphase fast ausschließlich Krankheiten betreffen, die man noch nicht einmal behandeln kann, ist nur ein weiteres der unzähligen Probleme des Spiels.

Doch zum Glück gibt es für diesen Bug auch gleich einen Konter-Bug. Wenn man das Spiel sofort speichert, bevor man eine Epidemie „angenommen“ hat, kann man durch geduldiges Neuladen und Epidemiewarnung wegklicken, die Epidemiewarnung irgendwann gänzlich verschwinden lassen. Wenn das passiert, taucht im gesamten restlichen Level keine weitere Epidemie mehr auf, denn der Epidemiestatus scheint dadurch im Nirvana zu hängen. Durch diesen kleinen Kniff wurde das Spiel für mich tatsächlich wieder spielbar. Ein wirtschaftlich rentables Krankenhaus mit einem guten Ruf aufzubauen, ist schließlich schon schwer genug. Und selbst wenn man den Bug nicht triggern kann, kann man durch das Zurückgehen auf ein älteres Savegame die kommende Epidemie oft noch vermeiden.

Auch wenn es grausam klingt: Patienten, deren Gesundheitszustand sich rapide verschlechtert (zu erkennen an dem traurigen Smiley, der sich Schritt für Schritt in einen Totenschädel verwandelt) sofort aus dem Krankenhaus schmeißen, wenn sie nicht offensichtlich kurz vor der Heilung stehen. Das Spiel bestraft Sterbefälle nämlich rigoros. Zum einen ist der Imageschaden pro verlorenem Patienten deutlich spürbar, zum anderen fehlt in der Jahresendabrechnung der großzügige Keine-Sterbefälle-Bonus von 10.000 Dollar, der gerade in höheren Levels über Sieg oder Pleite entscheidet. Des Krankenhauses verwiesene Patienten mindern den guten Ruf dagegen auch in größeren Zahlen kaum. Daher am besten knallhart bleiben und die schwerkranken Patienten konsequent vor die Tür setzen, bevor sie zum Problem werden. Bei längeren Warteschlangen kippen die Menschen garantiert früher oder später reihenweise um, und der Sensenmann freut sich über das gute Geschäft. Später habe ich dann zum Glück begriffen, dass das Spiel von mir erwartet, Räume mehrfach zu bauen. Am Ende ist es keine Seltenheit mehr, dass man fünf, sechs oder noch mehr Allgemeinmediziner gleichzeitig beschäftigt.

Achja, die Erdbeben, das nächste Ärgernis in dem Spiel. Wiederholt kam es vor, dass einwandfreie medizinische Räume, die erst Sekunden zuvor von einem Handwerker repariert worden waren, durch ein folgendes Erdbeben zerstört wurden, obwohl das gar nicht passieren dürfte. Und zerstörte Räume sind dann im Spiel auch noch unbenutzbarer Platz, der sich nicht für alles Geld der Welt renovieren lässt. Oft reicht gefühlt schon ein winziger Kratzer an einem Diagnose- oder Behandlungsgerät und beim nächsten Erdbeben fliegt einem alles um die Ohren. Es nervt wirklich sehr.

Weiter gehts mit den Notfällen: Am Anfang ist man meistens ganz froh, wenn man mit der Pharmatheke, dem Entlüfter, und der Polyklinik wenigstens ein paar einfache Basiskrankheiten heilen kann, um nicht sofort rote Zahlen schreiben zu müssen, und dann kommt ein Notfall rein: Vier Patienten mit außerirdischer DNA. Oder 13 Patienten mit Verstrahlung. Schön für euch, ich kann euch nicht helfen. Aber sobald man endlich alle Krankheiten diagnostizieren und behandeln kann, kommen keine Notfälle mehr rein. So ist Theme Hospital. Genauso albern wie seine Animationen.

Einmal war ein Arzt aus irgendeinem Grund unter einem Billardtisch im Personalraum gefangen. Bei einem angekündigten Notfall mit sechs Patienten sind vier erst gar nicht aufgetaucht. Ich habe die ganze Karte nach ihnen abgesucht. Entsprechend wurde mir der Bonus verwehrt, weil ich nur zwei retten konnte. Und das kam später mehrmals vor. Gleich mehrere Ärzte wollten ums Verrecken ihre endlose Ausbildung zum Berater nicht abschließen. Irgendwann war ich mir sicher, dass ich einen Bug gefunden hatte. Als ich schließlich aus Verzweiflung den Lehrer ausgewechselt habe, sind nur eine Sekunde später auf einen Schlag fast alle Ärzte gleichzeitig zu Beratern aufgestiegen.

Die deutschen Texte in dem Spiel sind leider voller Fehler, numerische Werte werden falsch eingesetzt oder falsch umgerechnet („Sie haben Diagnosegeräte von 100 2.121996e-314rforscht.“, „Melden Sie die Epidemie, müssen Sie eine Strafe von 1852392736 zahlen.“). Einige „Tipps“ sind komplett irreführend und wenig hilfreich („Ihre Empfangsdamen sind total erschöpft. Veranlassen Sie sofort, daß sie eine Pause einlegen.“). Eine meiner Krankenschwestern wollte ihren Behandlungsraum partout nicht mehr verlassen, litt dadurch am Ende unter einem Burnout, und verlangte schließlich eine Gehaltserhöhung nach der anderen. Die Liste der Fehler ließe sich vermutlich noch eine Weile fortsetzen.

Kann ich das Spiel unter den gegebenen Umständen und trotz seiner vielen Problemchen überhaupt noch empfehlen? Aber unbedingt! Theme Hospital mag ein bisschen sperrig sein, es mag verbuggt sein, aber es hat Charme, es hat Spielwitz, es ist spannend, fordernd, es ist nett anzusehen, und der Wuselfaktor ist relativ hoch. Man muss mit seinen Macken umgehen können, dann macht das Aufbauen auch heute noch gehörigen Spaß. Leider krankt die Einzelspieler-Kampagne an einem Problem, das viele vergleichbare Aufbauspiele haben: Es ist furchtbar repetitiv. Im Prinzip baut man 12 Krankenhäuser auf, bis man den Abspann sieht. Von der Rezeption bis zum allerletzten Behandlungsraum muss man jedes Krankenhaus immer wieder von vorne hochziehen und liebevoll einrichten. Und es ist oft frustrierend, wenn man wirklich viel Zeit und Mühe in den Aufbau eines Krankenhauses investiert hat, endlich alles perfekt und rund läuft, den Level-Ende-Bildschirm sieht, um dann gleich wieder bei Null anfangen zu müssen. Irgendwann war dann auch bei mir die Luft raus. Da war ich dann doch froh, dass das Spiel nicht 20 oder gar 30 Levels hat.

Auch wenn es mit Two Point Hospital seit kurzem einen offiziellen inoffiziellen 3D-Nachfolger von den Original-Designern gibt, ist das für mich kein Grund, Klassiker wie diesen aus meinem Kopf zu verdrängen, denn ich hatte an Theme Hospital in meiner Jugend eine Menge Freude, und nun habe ich dieses Kapitel für mich mit einem kleinen Sieg abgeschlossen. Außerdem gibts Theme Hospital noch gänzlich ohne Steam-Zwang, und das ist mir heutzutage sehr viel Wert.

Mein Projekt zum Umstieg von Windows 7 auf Linux Mint ist vorgestern offiziell gescheitert. Meine Linux-Installation hat nicht ganz zwei Monate gehalten, und nun ist sie hinüber. ‚Hinüber‘ vom Standpunkt eines durchschnittlichen Windows-Benutzers gesehen. Natürlich könnte ich jetzt noch alle Hebel in Bewegung setzen, stundenlang nachforschen und kryptische Recovery-Befehle ausführen, den Rechner dem einzigen Linux-Experten in meinem Bekanntenkreis zur Analyse übergeben, und am Ende würde es vermutlich irgendwann wieder laufen, aber das war von vornherein nicht die Intention des Experiments. Tja, und was war passiert?

Vorgestern wollte ich ein Unterverzeichnis auf einer meiner NTFS-Festplatten anlegen (und ich schätze das hat bis dahin immer geklappt), doch dann stürzte der Dateimanager plötzlich ab, als ich dem neuen Ordner einen Namen geben wollte und ENTER gedrückt habe. Tja … Linux … so wahnsinnig stabil. Ich entschied mich, es noch einmal zu versuchen, das war bestimmt nur ein Ausrutscher. Auch beim zweiten Mal stürzte der Dateimanager sofort ab, und diesmal verschwanden auch alle Desktopsymbole und tauchten leider nicht mehr auf. Reboot tut gut, so dachte ich, und startete die Kiste ganz naiv neu.

Leider kam Linux nicht mehr hoch und so starrte ich minutenlang auf zwei dunkle Monitore ohne Signal. Nach einem weiteren Reboot meldete sich wenigstens das Bootmenü, aus dem ich eine der wichtigsten Recovery-Funktionen von Linux endlich praktisch nutzen konnte: Ich wählte dort den letzten funktionierenden Linux-Kernel vor dem aktuellen aus und startete diesen: Die Erwartung war groß, die Enttäuschung noch größer. Leider kein Linux, nur schwarze Bildschirme. Ich wählte anschließend den vorletzten Linux-Kernel aus, doch auch dieser startete nicht. Hat sich absolut gelohnt, diese super Funktion.

Schließlich doch noch ein Hoffnungsschimmer: Ich konnte im Wiederherstellungsmodus hochfahren, und nach ein paar sperrigen Menüs erschien auch tatsächlich der Linux-Desktop – ohne Grafikkartentreiber, in niedriger Auflösung, und auch nur auf einem Bildschirm. Aha, es geht also doch, nur nicht wie ich will. Da ich mit dem Wiederherstellungsmodus so nicht viel anfangen konnte, und auch nicht wusste, welche gruseligen Kommandos ich diesmal auf der Konsole eingeben musste („autorepair -pls -kthx“ und „fix my linux immediately“ haben beide nicht funktioniert…), entschied ich mich, wieder im normalen Modus hochzufahren. Doch wie erwartet ging nichts.

Ich krabbelte unter den Tisch, öffnete kurzerhand den Rechner und schloss die Windows-Festplatte an. Windows 7 startete einige Sekunden später genauso wie ich es vor zwei Monaten verlassen hatte. Mein Linux-Schiff ist leider untergegangen, damit hat sich das Thema für mich erledigt. Warum Linux so schnell kaputtging? Keine Ahnung, vielleicht habe ich den einen oder anderen bekackten Befehl aus dem Internet zuviel in die Konsole kopiert, und mir das blöde Betriebssystem so zerschossen ohne es zu wollen. Ist mir inzwischen auch egal. Das Ergebnis des Projekts ist für mich klar: Linux im Desktopbereich fängt hoffnungsvoll und beeindruckend an, zeigt dann nach und nach immer mehr fragwürdige Designentscheidungen, Macken, Probleme und Fehler, bis sich irgendwann die Update-Funktion verabschiedet, und kurz darauf das ganze System nicht mehr startet. Ob es sein kann, dass Linux unschuldig ist, und ich vielleicht einfach nur zu blöd war, damit umzugehen? Jeder darf sich selbst eine Meinung darüber bilden, welche der von mir gemeldeten Probleme allein auf meine Unfähigkeit zurückzuführen sind, und welche nicht. Im Grunde war das herauszufinden genau der Zweck der Übung: Wie weit komme ich als (beinahe) kompletter Linux-Anfänger? Leider nicht sehr weit, und damit ist Linux im Desktopbereich aus meiner Sicht disqualifiziert, denn das war die Anforderung.

Oh, doch, ich habe Windows-Installationen zerschossen. Einige! Windows 95 ging mir desöfteren kaputt, Windows 98 noch öfter. Windows ME war bei mir sofort nach der Installation kaputt, und wurde sofort von mir gemieden. Windows 2000 und XP waren endlich WESENTLICH stabiler, und seitdem sind die Ansprüche gestiegen. Damit war es dann auch nicht mehr so leicht, durch Bedienfehler das System zu ruinieren. Gerade Windows 2000 hat einige meiner übelsten Optimierungsversuche unbeschadet überstanden. Und Windows 7 hat die Wiederherstellungspunkte, die bei mir schon mehrmals funktioniert haben: Windows defekt – Wiederherstellungspunkt geladen – alles wieder gut.

Danke Linux, es waren spannende sieben Wochen mit dir, aber wir passen leider nicht zueinander. Du bist mir zu sehr „high maintenance“, dauernd muss ich mich um DEINE Probleme kümmern, so dass ich immer weniger dazu komme, mich den eigenen Dingen zu widmen. Ich hoffe wir können Freunde bleiben, dann sehe ich dich alle paar Monate mal, wenn auf irgendeinem Rechner Linux läuft. Bei mir zuhause eher nicht mehr. Aber wir sehen mal, wie sich die Dinge in den nächsten zehn Jahren entwickeln, vielleicht bist du bis dahin reifer geworden und endlich beziehungsfähig. Und tschüss.

Da mir im Moment der Sinn nicht ganz nach irgendeinem Politikum steht, worüber ich meinen Senf ausgießen müsste, werde ich vorerst noch mehr Softwareentwickler-Kram posten, mit dem ich die geneigten, aber uninteressierten Leser erfolgreich abschrecken kann. Wir danken für Ihr Verständnis.

Wer sich im Internet gezielt über aktives Rendering mittels Canvas in Java informiert, also etwas, das direkt im Zusammenhang mit Java-Spieleentwicklung steht, der wird wahrscheinlich irgendwann über die Methode sync() in java.awt.Toolkit stolpern, also meistens in der Form Toolkit.getDefaultToolkit().sync(). Nun gehe ich stark davon aus, dass die meisten Entwickler diese Codeschnipsel als gegeben ansehen und 1:1 in ihre eigene Klasse einfügen, da sie wahrscheinlich vielfach erprobt sind. So war das bei mir anfangs leider auch. In einem eigenen Render-Thread habe ich Bilder gerendert und anschließend brav das Toolkit „synchronisiert“, was laut Dokumentation irgendwie „gut für Animationen“ ist.

Seit der Umstellung auf aktives Rendering jedoch hatte ich plötzlich Schwierigkeiten damit, den Render-Thread mittels interrupt() vorzeitig zu stoppen, also etwa wenn der Nutzer das Rendering über das Menü beendet oder wenn ein bestimmtes Ereignis auftritt. Zuvor war das nie ein Problem gewesen. Neuerdings läuft der Thread in drei von vier Fällen einfach weiter, sobald ich ihn gezielt unterbrechen will. Das war eine mittlere Katastrophe, denn ich konnte mich jetzt nicht mehr darauf verlassen, dass das Programm das macht, was ich davon erwartete. Mein Programm funktionierte so nicht mehr, und ich wusste nicht, was ich falsch gemacht haben könnte.

Etwa einen halben Tag hat es gedauert, bis ich den Fehler gefunden hatte: java.awt.Toolkit.sync() verschluckt ganz frech das Interrupted-Flag. Es scheint leider wirklich so zu sein. Die Implementation der Java Virtual Machine von Oracle ist hier offenbar fehlerhaft, denn alles funktioniert einwandfrei wenn ich auf sync() verzichte. Sobald ich die Zeile verwende, klappt das Unterbrechen des Threads nicht mehr. Meine Vermutung ist daher, dass das blockierende sync() das Interrupted-Flag mittels interrupted() abfragt (und dadurch löscht!), und dann leider nicht mehr setzt und leider auch keine Exception wirft. Es verschluckt die Thread-Unterbrechung völlig. So wird dieser Mechanismus sogar ganz offiziell in der Java-Doku erklärt:

if (Thread.interrupted()) // Clears interrupted status!

Nun hält sich Oracle selbst nicht daran. Ich habe anschließend in meinem Code keine Möglichkeit mehr, diese Unterbrechung zu erkennen und gegebenenfalls selbst eine InterruptedException auszulösen. Oracle hat hier eindeutig Scheiße gebaut, denn eigentlich ist das Konsens, das Interrupted-Flag nach dem Löschen erneut zu setzen, damit die Unterbrechung nach oben eskaliert werden kann, so dass auch andere Programmteile auf die Unterbrechung korrekt reagieren können. Hier wurde ganz einfach geschlampt.

Und was macht sync() eigentlich? Tja, keine Ahnung. So ganz scheint das nämlich niemand zu wissen. Ich liebe es, wenn die Java-Dokumentation von Oracle so explizit ist, dass man trotzdem keine Ahnung hat, was genau vor sich geht. So auch zur Methode sync() der Klasse Toolkit:

void java.awt.Toolkit.sync()

Synchronizes this toolkit’s graphics state. Some window systems may do buffering of graphics events.

This method ensures that the display is up-to-date. It is useful for animation.

Wenn jemand mal im Internet in einschlägigen Entwicklerforen versucht danach zu fragen, was das genau bedeutet, wird die Frage mit „synchronizes the graphics state“ „beantwortet“, und anschließend als Off-Topic geschlossen. Zurecht wurde wenigstens noch darauf hingewiesen, dass das die Frage kaum beantwortet.

Da ich weder sagen kann, was die Methode macht, in welchen Fällen ich sie brauchen könnte, und welche Vorteile oder Nachteile damit zusammenhängen, werde ich auf sync() gerne verzichten, schon da ich mit dem Interrupt-Problem einen ziemlich schwerwiegenden Fehler entdeckt habe, den ich nicht bereit bin zu akzeptieren – ganz egal wie toll die Funktion ansonsten arbeiten möge.