Nachdem mit “Star Wars: Empire At War” seit langer Zeit endlich wieder ein konkurrenzfähiges Spiel aus George Lucas’ Universum für kleines Geld zu haben ist, bietet es sich an, statt dem Basisspiel + Erweiterungspack gleich in den “Gold Pack” zu investieren, der beide Komponenten enthält und kaum mehr kostet als eine der Einzelkomponenten.

Wer allerdings so wie ich vorher schon “Empire At War” installiert hatte und seine Spielstände übernehmen will, wird sich trotz der Tatsache, daß er bei der Deinstallation des Basisspiels auf das Löschen der Spielstände verzichtet hat, vor einer leeren “Load Game”-Auswahl wiederfinden.

Ursache des Bugs (oder Features?) ist die Tatsache, daß Petroglyph eine neue Dateiendung für die Spielstände eingeführt hat und das Spiel somit die ursprünglichen Dateien nicht mehr findet.

Als Notlösung bietet sich an, in das Spielstand-Verzeichnis zu wechseln und dort mittels ‘ren’-Kommando die Dateien in einem Rutsch umzubenennen:

cd %APPDATA%\Petroglyph\Empire At War\Save
ren *.sav *.PetroglyphEaWSave

Anschließend sind die Spielstände wieder zum Laden im Spiel vorhanden, wenn auch leider nur mit so sprechenden Namen wie “slot7” oder “slot20”.

Die ActivePerl-Distribution kommt zwar schon mit einer Menge Module daher, aber ein paar wichtige wie z.B. das Modul zur Ansteuerung der GD Graphics Library sind nicht im Lieferumfang enthalten und fehlen auch im online Repository von ActiveState.

Glücklicherweise gibt es noch ein paar recht gut sortierte Repositories wie z.B. das der University Of Winnipeg, die sich darauf spezialisiert haben, die Lücken aufzufüllen.

Um nun das GD-Modul zu installieren, fügt man am sinnvollsten das passende Repository mittes “Edit” / “Preferences” dem Perl Package Manager hinzu:

Nach dem Synchonisieren der Paket-Datenbank kann dann unter “View all packages” das GD-Paket ausgewählt und installiert werden.

Ähnlich zu den automatischen Updates unter Windows gibt es auch unter Debian-basierten Systemen die Aktualisierungsverwaltung, die mittels Icon in der Taskleiste darauf aufmerksam macht, daß Updates für das System verfügbar sind.

Bei Rechnern, die aber hauptsächlich “in der Ecke” stehen und ohne menschliche Interaktion auskommen sollen, hat dies den Nachteil, daß Updates nur sehr unregelmäßig durchgeführt werden, wenn sich mal wieder jemand aus anderen Gründen am System anmeldet.

Da die Aktualisierungsverwaltung im Westentlichen auch nichts anderes macht, als auf “apt-get” zuzugreifen, könnte ein möglicher Lösungsansatz in einer Automatisierung dieses Vorganges mittels “cron” bestehen - während dessen Realisierung man hoffentlich über das Paket “cron-apt” stolpert, das exakt für diese Aufgabe geschaffen wurde.

Nach der Installation mittels

apt-get install cron-apt

stehen die entsprechenden Konfigurationsdateien im Verzeichnis “/etc/cron-apt” zur Verfügung, wobei in einem ersten Schritt nur die Parameter der Datei “config” an die eigenen Wünsche angepasst werden müssen.

Standardmäßig lädt cron-apt die Pakete nur vom Server herunter und verschickt - je nach Konfiguration - eine entsprechende Mail an den zuständigen Administrator. Soll cron-apt die Pakete auch gleich installieren, so ist die Datei “/etc/cron-apt/action.d/3-download” durch Entfernen des Parameters “-d” anzupassen.

Wer vor dem Produktiveinsatz gerne einen Testlauf unter menschlicher Aufsicht durchführen möchte, kann dies mittels “cron-apt -s” tun.

So sinnvoll die automatischen Updates auch sind, so nervig ist das “Soll der Computer jetzt neu gestartet weden?"-Fenster, das in schöner Regelmäßigkeit sich immer genau dann in den Vordergrund drängt, wenn man es am wenigsten gebrauchen kann.

Leider bietet Microsoft keine auf den ersten Blick erkenn- und benutzbare Lösung (z.B. auf dem Konfigurationsdialog in der Systemsteuerung), so daß man die Hilfe des Gruppenrichtlinien-Editors in Anspruch nehmen muß:

• Unter “Start” / “Ausführen” “gpedit.msc” eingetippt und mit “Ok” bestätigt.

• Anschließend zu “Computerkonfiguration” / “Administrative Vorlagen” / “Windows-Komponenten” / “Windows Update” navigieren und dort die Richtlinie “Erneut zu einem Neustart für geplante Installationen auffordern” bearbeiten

• Hierzu die Richtlinie auf “Aktiviert” stellen und einen beliebigen Zeitraum (z.B. 999 Minuten) angeben.

• Mit “OK” bestätigen

Will man aus Perl PDFs erstellen, so gibt es das vorzügliche PDF::API2-Modul, das aber einen entscheidenden Nachteil hat: man wird von Optionen und Möglichkeiten dermaßen erschlagen, daß es schwer ist, überhaupt am Ziel anzukommen.

Als einfachen Ausweg gibt es das Modul PDF::API2::SIMPLE, ein “simplistic wrapper for the excellent PDF::API2 modules”, mit dem man sich auf’s Wesentliche konzentrieren kann.

Leider kann das Modul in seiner aktuellen Version (1.1.4) Bilder nur aus Dateien (JPG, TIFF, PNM, PNG oder GIF, die im Dateisystem vorliegen müssen) einbinden, ein extrem umständlicher Weg, falls diese z.B. in einer Datenbank vorliegen.

Eine entsprechende Erweiterung ist aber schnell - und einfach - gemacht, verhält sich analog zur ursprünglichen image-Methode und kann mit einem GD-Objekt genutzt werden:

sub gdimage {

    my ($self, $src, %opts) = @_;
    my $x = $opts{'x'} || $self->x;
    my $y = $opts{'y'} || $self->y;
    my $width = $opts{'width'} || 100;
    my $height = $opts{'height'} || 100;
    my $scale = $opts{'scale'} || 1;
    my $image = $self->current_page->gfx;

    my $data = $self->pdf->image_gd($src);

    $image->image($data, $x, $y, $width, $height);

    $self->x( $x + $width );
    $self->y( $y );
}

Der Erweiterungsvorschlag ist auch an die Entwickler raus, vielleicht wird er ja integriert …