Stranger Than Usual

Seit ich 2012 mein altes Blog auf blogger.de verlassen habe und mein Blog auf meinem eigenen Server gehostet habe, hat sich dort nicht mehr viel verändert. Es läuft immer noch die gleiche alte Software (mit ein paar Patches), antville. Das letzte Mal, dass ich dort etwas gemacht habe war, als ich 2020 die Posts des alten Blogs in mein neues Blog importiert habe.

Dieser Import war mir wichtig, denn bei so einem alten System weiß man ja nie, wann der Betreiber vielleicht mal aufgibt. Aber jetzt, noch einmal fast sechs Jahre später, ist blogger.de immer noch da. Seit Jahren hält es sich, stabil und fast unverändert, während ringsherum Websites entstehen und wieder eingehen.

Und bei allem, was mir technisch an blogger.de nicht gefällt (Hallo? Nicht einmal UTF-8?), muss ich neidlos anerkennen, dass diese Stabilität eine schöne Sache ist. Und nicht nur das: Die Seite ist auch schnell. Gut, mein aktuelles Blog ist auch schnell. Mein aktuelles Blog ist aber auch ein Haufen statisch generierter HTML-Dateien. Wenn das nicht schnell ist, dann habe ich irgendetwas wirklich falsch gemacht.

Aber blogger.de ist ähnlich schnell. Und ich glaube, ein Hauptgrund dafür ist, dass es einfach viel weniger bloat gibt als auf vielen „modernen“ Websites. Das HTML wird serverseitig generiert, es gibt ein bisschen CSS und ein minimals Javascript-Script. Keine XHR-Requests. Kein langes Nachladen von nutzlosem Krams. Ich lade die Startseite meines alten Blogs und es sind 66 kiB. Bei viel zu vielen Websites heute kommt man nicht unter 1 MiB! Auch bei ebenso einfachen Blogs. Das ist nicht nötig! Wir kommen auch ohne den Bloat aus!

PS: Ich habe ein bisschen die Templates des alten Blogs angepasst und ein bisschen in Richtung HTML-5 gearbeitet. Es ist nicht komplett gültig (z.B. ist es nicht UTF-8-codiert), aber daran kann ich nichts ändern, das Encoding kommt vom Server. Immerhin sollte die Seite jetzt auf Smartphones ein bisschen schöner angezeigt werden. Ansonsten sieht sie sehr ähnlich aus wie vorher. Warum habe ich das gemacht? Eine spontane Obsession, wie ich sie häufig habe, und die ich auch schon darin ausgelebt habe, die Website einer Freundin zu verbessern oder die Website von winkekatze24.de.

Der Adenauer SRP+ hat es in einen Artikel auf tagesschau.de geschafft. Der Bus des Zentrums für politische Schönheit, der Hauptsächlich für Demos gegen Rechts (insbesondere gegen die AfD) da ist, wird nämlich regelmäßig von der Polizei angehalten und wegen angeblicher Verkehrsuntauglichkeit festgesetzt. Und obwohl sich immer wieder ergibt, dass der Bus alle Regeln einhält, hält die Polizei an dieser Masche fest. Darüber wurde auch schon in Logbuch Netzpolitik berichtet.

Niemand kann mehr behaupten, dass es hier wirklich um Verkehrssicherheit geht. Es geht hier einfach darum, das ZfPS davon abzuhalten, zu Demos zu kommen. Dabei sollte die Polizei doch genau so gegen Rechts sein wie die Mehrheit in Deutschland. Ich kann ja verstehen, dass sie auch die Rechte der AfD schützen müssen (da sind sie immerhin zu Neutralität verpflichtet, schützen sie z.B. die Grünen nicht in diesem Maße). Aber eine rechtmäßige Demo gegen eine Verfassungsfeindliche Partei aktiv zu behindern, dass ist unserer Ordnungskräfte nicht würdig. Da frage ich mich nämlich, ob da nicht doch einige Beamte dabei sind, die lieber die AfD an der Macht sähen.

git.kernel.org hosted git-Repos für den Linux-Kernel, insbesondere auch das Repo des Linux-Kernels. Es gibt auch eine dynamisch gerenderte Website, die z.B. den Inhalt der commits in einem Repo anzeigen kann.

Und diese Seite hat jetzt ein Problem: Web-Crawler laden automatisch alle diese Seiten herunter, um damit LLMs zu trainieren. Das lastet im Schnitt 14 Prozessorkerne komplett aus. Das sind 20 % der Kapazität der Seite (über den Globus verteilt), aber im Durchschnitt. Die Anfragen kommen immer in Spikes. Und üblicherweise sind die Server auch nicht an der Belastungsgrenze, im Schnitt ist also mehr als die Hälfte der Last von Crawlern generiert.

Lest euch den Artikel durch, der ist interessant. Mir sind vor allem zwei Punkte aufgefallen:

1. Diese Crawler ignorieren die robots.txt. Früher haben sich praktisch alle größeren Crawler (von Suchmaschinen wie Google) an die Anweisungen darin gehalten. Das war so eine Art Abmachung: „Ihr lasst uns euch crawlen, wir nehmen euch dafür in unseren Suchindex auf und versprechen, nicht zu viel Last zu erzeugen.“. Die Crawler für LLMs halten sich nicht an die robots.txt und geben sich auch wirklich Mühe, alle anderen Schutzmaßnahmen zu umgehen. Ob das legal ist, ist fragwürdig.
2. Die Crawler erzeugen um Größenordnungen mehr Last als notwendig. Sie könnten effizient das git-Repo des Kernels und eventuell noch andere Repos klonen und dann offline durch die commits durchgehen. Das ist sowohl für git.kernel.org viel effizienter, wäre aber auch für die Crawler effizienter, insbesondere weil sie dann nicht mehr Rechenzeit darauf verschwenden müssten, ständig proof-of-work-captchas zu berechnen. Stattdessen werden Millionen bis potentiell Milliarden von HTML-Seiten gecrawled, die alle dynamisch gerendert werden müssen.

Und das ist nicht die einzige Seite, die dieses Problem hat, ich habe das schon von anderen Seiten gelesen. Das kostet alles Strom, Leistung, und geht am Ende auf die Kosten von uns allen, weil Seiten aufgeben, weil Geld in Infrastruktur investiert wird, das man sonst woanders für hätte verwenden können und weil normale Benutzer jetzt bei jedem Besuch von git.kernel.org ein paar Sekunden warten müssen, bis der Browser den proof-of-work erbracht hat, der die Bots abhalten soll.

Und für was? Damit ein paar milliardenschwere Konzerne uns ihre LLMs verkaufen können, die auf die Kosten von freien Projekten trainiert wurden. Ich sehe ja schon, dass LLMs eine Technologie ist, die nicht mehr verschwinden wird. Auf die eine oder andere Art wird diese Technologie bleiben. Die Frage ist nur: auf welche Art wollen wir, dass sie bleibt? Der bisherige Weg ist nicht nachhaltig, weder was das Sammeln von Trainingsdaten angeht, noch welche ökologischen Auswirkungen die Rechenzentren haben, die für den Betrieb gebaut werden, noch was das Geschäftsmodell der Betreiber angeht (die Momentan mit jeder Anfrage Verlust machen).

Momentan kann ich jedenfalls LLMs nicht reinen Gewissens benutzen.

Role playing scene. We are in the spirit realm, to save Rocket Mel (again). Rocket Mel's soul is in the process oof being devoured by a giant blob of Protoplasma in the middle of the marketplace of the village in the spirit world.

The blob gives us a stereotypical villain speech about whether we want it the easy way (it just eats our souls) or the hard way. Jacksnipe is having none of this. With an “Eat this!”, she commands her painted boar to charge the blob. The boar strikes, and the blob turns its attention to Jacksnipe. It turns out the entity is more than just the blob. Like an eldritch octopus, its arms are the branches of the market place, including market stands and everything. Jacksnipe, still blind, hears something coming but dodges the wrong way and gets buried under a market stall.

Rocket Mel on the other hand notices that her soul is not being feasted on anymore and sees an opening to break free of the entity:

I try to fight the market forces.

Meine Lieblingscomputerspiele in meiner späten Kindheit bzw. aus meinen frühen Teenager-Jahren war die „Siedler“-Reihe von Blue Byte. Ich habe damals mit Siedler II angefangen, das ich mir von einem Freund kopiert habe (jaja, nicht ganz legal). Dieses Aufbauen, besonders aber auch den kleinen Männchen dabei zuzusehen, wie sie Waren durch die Gegend tragen oder ihr Handwerk verrichteten (Bäumefällen, Bäume pflanzen, Bretter sägen, Steine schlagen Grundstücke planieren, Häuser bauen, etc) hat mich begeistert.

Mit Siedler III, das mir ein Schulfreund (noch in der Grundschule) vorgestellt hat, ging es dann weiter. Man musste keine Straßen mehr bauen (alte Fans haben sich beklagt, mir war das egal), die Siedler konnten sich innerhalb der Siedlung frei bewegen, aber das Grundprinzip war das Gleiche. Später ging es dann mit Siedler IV weiter, das an vielen Stellen Siedler III recht ähnlich war. Siedler IV habe ich dann als erstes Spiel mit Freunden über ein lokales Netzwerk gespielt (wir haben kleine LAN-Parties mit zwei bis fünf Teilnehmern veranstaltet). Manchmal haben wir uns bekämpft, manchmal aber einfach nur Siedlungen aufgebaut, die möglichst schön sein sollten.

Mit „Die Siedler – Das Erbe der Könige“ schlug die Reihe einen ganz anderen Weg ein. Weg von hunderten wuselnden Siedlern. Weg von langen Produktionsketten und dutzenden von Gütern. Weg vom hin- und hertransportieren von Sachen. Es war einfach nur noch ein generisches Strategiespiel, der Wuselfaktor, der eigentlich interessante Teil des Spiels, ging für mich verloren.

Ich glaube, was mich an der Siedler-Reihe so begeisterte war das Aufbauen einer großen Siedlung. Leider ging es am Ende in fast allen Missionen darum, am Ende effizient eine große Armee aufzustellen und in die Schlacht zu schicken. Und wenn man das geschafft hatte, war die Karte durch und man konnte auf der nächsten Karte wieder anfangen.

Ich glaube das ist es, was mich heute noch an Spielen wie Minecraft, Dwarf Fortress, Satisfactory usw. begeistert: Dort baut man sich Sachen um des Aufbauens willen auf und kann so lange Spielen, bis man keine Lust mehr hat. Trotzdem haben die Siedler immer einen Platz in meinem Herzen.

Wie komme ich jetzt darauf? Gestern habe ich diesen aktuellen Post gefunden, in dem jemand Die Siedler III lobt. Auch 28 Jahre nach Erscheinen dieses Spiels gibt es immer noch Leute, die sich mit Freude an dieses Spiel zurückerinnern.

Ich bin ja gerne mal im Fediverse unterwegs. Meist auf Mastodon, ich habe aber auch z.B. ein paar meiner Fordite-Bilder bei einer Pixelfed-Instanz hochgeladen und die feeling of being watched-Videos auf einer PeerTube-instanz. Und alle diese Fediverse-Server sind über das ActivityPub-Protokoll untereinander vernetzt.

Ich habe schon ein paar Mal mit dem Gedanken gespielt, für dieses Blog hier auch ActivityPub zu implementieren. Das größte Hindernis ist aber: Das hier ist eine Seite aus statischem HTML, eine Inbox für ActivityPub ist hier nicht möglich. Aber eine kleine ActivityPub-Instanz wäre schon ganz schön, irgendwie. Nur ist Mastodon eher ein Schwergewicht und ist vor allem in PHP geschrieben, und damit habe ich schon durch Nextcloud genug Probleme.

Aber hier hat jemand einen ActivityPub-Server auf einem Raspberry Pi Zero W laufen. Nun hat selbst ein Raspberry Pi Zero W schon ganz ordentlich Rechenleistung im Verhältnis zu Computern aus den 90ern (wo wir auch schon das Web hatten). Aber trotzdem eine nette Sache. Aber welche Software hat die Person den genutzt?

Das ist littleFedi, in Go geschrieben, im Minimalbetrieb braucht das keine anderen Dienste und bringt eine eigene Datenbank (keine Ahnung welche, vermutlich sqlite) mit. Optional kann man es auch aneine Postgres-Datenbank anschließen. Ich würde damit gerne mal herumspielen.

Was mich nur ein bisschen irritiert ist dieser Satz auf der littleFedi-Seite:

Beta software. The source is not published yet.

Das ist ungewöhnlich für freie Software. Üblicherweise wird da Code irgendwo veröffentlicht, lange bevor der Code auch nur Beta-Status erreicht hat. Es gibt eine Doku, aber keinen Code und auch kein Binary (letzteres wäre mir auch wirklich suspekt). Naja, ich schaue mal, wie sich das entwickelt.

Mir ist neulich aufgefallen, dass ich dieses Jahrzehnt noch nicht Dwarf Fortress gespielt habe. Überhaupt noch nicht. Und das Jahrzehnt ist schon wieder halb herum. Aber darum kümmere ich mich später, denn in diesem Zusammenhang ist mir ein altes Succession-Game eingefallen, das ich mit Arbeitskollegen gespielt habe, und dass es leider nur vier In-Game-Jahre geschafft hat, bevor uns die Spieler_innen ausgegangen sind. Dazu hat, dem Brauch eines Succession-Games, jeder einen Bericht geschrieben, was in dem entsprechenden Jahr in der Festung passiert ist (aus der Sicht eines Zwergs). Mit Screenshots.

Wer hier regelmäßig liest, weiß, dass ich eine Obsession für Bilddateigrößenoptimierung entwickelt habe. In diesem Post geht es nicht um Dwarf Fortress. Es geht um Bildgrößenkompression. Wer möchte, kann sich ja vorher noch meine kurze Einführung in verlustfreie und verlustbehaftete Kompression anschauen. Dort steht auch eine Faustformel, wann man welche Kompressionsvariante verwenden sollte.

Nun eignen sich Dwarf Fortress-Screenshots sehr gut für verlustfreie Kompression, zumindest mit der klassischen Grafik. Die ist nämlich nichts weiter als der ASCII-ähnliche (aber nicht kompatible) Zeichensatz CP437, eingefärbt in eine von 16 Farben, wobei der Hintergrund ebenfalls eine von 16 Farben haben kann, aber meisten grau ist. Die Darstellung der Zeichen hat keine Kantenglättung. Optimal für verlustfreie Kompression. Beispiel:

Oder, hereingezoomed, damit man die Pixel besser erkennen kann:

Lässt sich super komprimieren. Das obere Bild? 502×475 Pixel, nur 8,5 kiB groß als WebP. Insgesamt komme in einem Jahr auf 116 kiB an Bildern und in dem anderen Jahr auf 348 kiB. Der Kollege für Jahr zwei kommt auf 968 kiB, der Kollege für Jahr drei sogar auf 6,2 MiB. Und beide haben weniger Bilder als ich, in Jahr 4 habe ich sogar deutlich mehr Bilder. Wie kommt das?

Zum einen haben die Kollegen oft deutlich größere Bildausschnitte genommen. Das hätte man kleiner halten können, aber geschenkt. Der Kollege von Jahr 3 hat nicht die klassischen DF-Texturen genommen, sondern andere, mit mehr Details und Farben. Trotzdem noch relativ gut komprimierbar. Der Kollege von Jahr 2 hat aber die Standardtexturen. Allerdings hat er nicht aufgepasst und alle Screenshots als JPEG abgespeichert. Autsch.

Nun hängt diese Story momentan noch bei Github herum. Ich hatte mir überlegt, die mal auf meinen eigenen Server zu packen, als Teil meines digitalen Gartens. Aber dann muss ich irgendwas mit diesen übergroßen Screenshots machen. Und darum geht es in diesem Blogpost.

Bestandsaufnahme und Kompression in verschiedenen Formaten an einem Beispielbild

Als Basis für die Analyse nehme ich einen Screenshot eines fliehenden Kobolds. Der hat gewissen Ähnlichkkeit mit dem Screenshot oben, weil er auch draußen aufgenommen wurde. Die Auflösung ist ein bisschen kleiner (454×362), aber die Dateigröße als JPEG sind enorme 168 kiB. Ich werde hier erst einmal immer nur einen kleinen Ausschnitt des Bildes wiedergeben, dafür aber hereingezoomt, damit man sehen kann, was mit den einzelnen Pixeln passiert. Zunächst einmal habe ich verschiedene Bildformate mit verschiedenen Einstellungen ausprobiert:

Von oben nach unten:

1. Das Originalbild. In der Originalvariante (JPEG) 168 kiB groß, als verlustfreies WebP nur 126 kiB. Die Kompressionsartefakte machen verlustfreie Kompression deutlich schwieriger. Als verlustfreies AVIF übrigens 212 kiB groß. Ich habe noch keinen echten Anwendungsfall für verlustfreie AVIF-Dateien gefunden.
2. Verlustfreies WebP mit maximaler Qualität (100). Deutlich erkennbar: Die veränderten Rottöne. 81 kiB groß.
3. Verlustfreies WebP mit 75 % Qualität (Standardeinstellung von cwebp). Auch hier stark veränderte Rottöne. 33 kiB groß.
4. Verlustfreies Avif mit 50 % Qualität. Bild deutlich besser wiedergegeben als irgendein Webp. 25 kiB groß.
5. WebP mit der cwebp-Option -near-lossless 0. Diese Option macht ein verlustbehaftetes Farb-Preprocessing und wendet danach verlustfreie Kompression an. 0 bedeutet maximales Preprocessing. 57 kiB groß.
6. WebP mit -near-lossless 60, dem empfohlenen Wert. Kaum ein Unterschied zum Original erkennbar, 84 kiB groß.

Da die Bilder eh verlustbehaftet sind, hätte ich mich hier mit der Avif-Variante zufrieden geben und Schluss machen können. Was aber, wenn wir die Verluste irgendwie wieder rückgängig machen können?

Recovery von der verlustbehafteten Kompression

Nun, eigentlich kann man die Informationen, die beim Komprimieren verloren gehen, nicht zurückholen. Das ist Informationstheoretisch nicht möglich. Wir haben hier aber einen großen Vorteil: Wir haben Kontextwissen. Wir wissen, dass die Screenshots Zeichen im Raster zeigen. Wir wissen, dass sie nur eine begrenzte Farbpalette zu Verfügung hatten. Wir kennen alle möglichen Zeichen. Wir könnten die Bilder vermutlich also wirklich so wiederhestellen, wie sie waren (von ein paar Pixeln am Bildrand abgesehen, die sich vielleicht nicht mehr konkret einem Zeichen zuordnen lassen).

Aber das wäre mir dann doch zu viel Arbeit. Aber zumindest die Farbpalette zu reduzieren wäre schon cool. Deswegen habe ich aus verlustfreien DF-Screenshots die Farbpalette extrahiert:

Es gibt ein schönes Tutorial, wie man mit Imagemagick die Farben auf eine Palette reduziert. Ich habe mich, wie gesagt, auf eine vorgegebene Palette festgelegt, also habe ich folgenden Befehl genutzt:

magick 1-koboldThief.jpg +dither -remap palette.png 1-koboldThief_16_colors_remap.png

+dither deaktiviert hier Dithering, sonst hätte Imagemagick mir vermutlich noch ein paar falsche Pixel mehr reingedrückt. Das Ergebnis sieht so aus:

Perfekt ist es noch nicht. Gerade die helleren Zeichen haben immernoch einen Farbverlauf, weil es dunklere Farben gab, um den Verlauf darzustellen. Manche Pixel sind völlig falsch. Aber das Gesamtbild ist gut, und die Dateigröße kann sich sehen lassen: Sie ist von 168 kiB auf 7,8 kiB geschrumpft. Damit steht dem Ziel, den Bericht, in dem die Screenshots verwendet werden, auf meinem eigenen Server zu hosten, nichts mehr im Weg. Naja, außer einer Menge Arbeit. Aber der schwierige (andere sagen auch: der interessante) Teil ist geschafft.

Hier zum Abschluss noch einmal der „wiederhergestellte“ Screenshot:

Rollenspielszene. Wir wollen immer noch den Wald retten. Während Calum und Shane Flyer für eine Demo verteilen, fährt Siobhan in eine Nachbarstadt, um das Thema mit dem Wald an die Presse zu bringen. Siobhan hat dort einen Kontakt, ein Zeitungsredakteur namens Kevin.

Siobhan kennt Kevin nicht besonders gut. Sie weiß nicht genau, wie sie das Thema auf den Tisch bringen soll. Also fängt sie an:

Du kennst doch Bäume… und wenn sich viele Bäume mögen, dann ergibt sich ein Wald…

Ich brauche für ein kleines anderes Projekt (dazu in einem späteren Post mehr) eine Palette von allen Farben, die in einer Sammlung von Bildern vorkommen. Hier kann mal wieder das Schweizertaschenmesser der Bildverarbeitung glänzen: Imagemagick. Um eine Farbpalette aus einem Bild herauszukriegen, kann man folgenden Befehl ausführen:

magick bild.png -unique-colors palette.png

Das erstellt ein Bild mit einer Höhe von einem Pixel und so breit, wie die Anzahl der Farben ist. Jedes Pixel hat ein der Farben, die in dem Ursprungsbild vorkamen, alle Farben tauchen in dem Ausgabebild auf.

Man kann sich die Farben auch in einer Textdatei ausgeben lassen

magick all.png -unique-colors txt:palette.txt

Der halbe Weg ist also geschafft. Ich will aber nicht die Palette eines Bildes, sondern die Palette mehrerer Bilder zusammen. Wenn ich mehrere Eingabedateien angebe, erstellt mir Imagemagick hier aber einfach eine Palette pro Datei. Das reicht also nicht. Ich habe ein bisschen herumgesucht, und bin nur auf einen Workaround gekommen: Ich füge erst alle Bilder zu einer Bilddatei zusammen und nehme dann die Palette dieses Gesamtbildes. Das Zusammenfügen kann man z.B. so machen:

convert -append img/* all.png

Wobei in diesem Fall die Eingabedateien unter img liegen und all.png die Ausgabedatei ist. Eine wichtige Einschränkung: Wenn die Eingabebilder nicht alle gleich groß sind, wird es weiße Flächen in all.png geben. Das heißt, es wird eventuell weiß zur Palette hinzugefügt, obwohl das falsch wäre. In meinem Fall war aber weiß ohnehin Teil der Palette. Ansonsten kann man Imagemagick sicher auch irgendwie dazu bringen, den Hintergrund anders zu färben.

Damit jedenfalls habe ich meine Palette:

Oh, warte, das kann man kaum sehen. Also hier eine vergrößerte Variante:

Und hier die Textausgabe:

# ImageMagick pixel enumeration: 16,1,0,255,srgb
0,0: (0,0,0)  #000000  black
1,0: (128,0,0)  #800000  maroon
2,0: (255,0,0)  #FF0000  red
3,0: (0,128,0)  #008000  green
4,0: (0,255,0)  #00FF00  lime
5,0: (128,128,0)  #808000  olive
6,0: (255,255,0)  #FFFF00  yellow
7,0: (0,0,128)  #000080  navy
8,0: (0,0,255)  #0000FF  blue
9,0: (128,0,128)  #800080  purple
10,0: (255,0,255)  #FF00FF  magenta
11,0: (0,128,128)  #008080  teal
12,0: (0,255,255)  #00FFFF  cyan
13,0: (128,128,128)  #808080  fractal
14,0: (192,192,192)  #C0C0C0  silver
15,0: (255,255,255)  #FFFFFF  white

Rollenspielszene. Wir sind in der nächsten Stadt in Galt angekommen. Die Stadt wird größtenteils von Banden beherrscht, nachdem das Stadtviertel, in dem die herrschende Klasse wohnte, vor zwanzig bis dreißig Jahren mysteriöserweise explodiert ist. Eine Hinterlassenschaft dieser Klasse sind jedoch Metallkonstrukte von mäßiger Intelligenz und geringer Eigeninitiative, die versuchen, die Ordnung in der Stadt aufrecht zu erhalten.

Direkt am ersten Abend passiert in der Nähe unserer Unterkunft ein Mord. Vom Tatort weg (in Richtung eines Kanaldeckels) führen Spuren zweier kleiner Personen und einer menschengroßen Person. Thivuc fängt an zu spekulieren: Vielleicht gibt es hier Rattenmenschen? Gibt es wandelnde Pilze? Und wenn es große Wachkonstrukte gibt, die Gesetzesverstöße hart bestrafen, warum soll es dann nicht auch kleine Kriminalkonstrukte geben, die Verbrechen begehen? Fredegar ist nicht überzeugt: Warum sollte jemand viel Geld für Kriminalkonstrukte ausgeben? Viel wahrscheinlicher sind doch die Rattenmenschen, oder einfach kriminelle Halblinge oder Gnome, die die Kanalisation als Fluchtweg nutzen.

Am nächsten Tag haben wir dann ein Treffen mit einem Informanten, weil Dolgrim, Zwerg und Kopfgeldjäger, hofft, in dieser Stadt eine gesuchte Mörderin zu finden. Tatsächlich gibt es Hinweise auf die gesuchte Person: Sie hat sich einer Bande von Wyrwoods angeschlossen, die sich in der Kanalisation aufhält. Die Gruppe schaut fragend Julien, den Magier an. Der erklärt: Wyrwoods sind Holzkonstrukte mit freiem Willen, die von Magiern geschaffen wurden aber dann gegen sie rebellierten.

Thivuc lacht triumphierend:

Hah! Kriminalkonstrukte!