PHost - Technische Informationen

PHost 4.1h
Main
Articles
Download Index
Docs v3.x
Docs v4.x
 Technische Informationen
Links

Inhalt

Einleitung

Dieses Dokument ist für Programmierer gedacht. Hier sind technische Unterschiede zwischen HOST und PHost aufgeführt. Leute, die neue Client- oder Host-Programme entwickeln erhalten hier nützliche Hinweise, wie sie ihr Programm kompatibel zu PHost machen und PHost optimal nutzen. Für Spieler sind die Informationen hier eher weniger interessant.

Allgemeine Hinweise

Wenn du ein Host-Addon für PHost schreibst, solltest du definitiv einen Blick auf das PHost Development Kit (PDK)[Remote] werfen. Das PDK kümmert sich um die Dateizugriffe, so dass du dich direkt auf dein Addon konzentrieren kannst. Das Ziel des PDK ist, auch zu Tims Host kompatibel zu sein, 100%-Kompatibilität ist aber vermutlich noch nicht erreicht. Ein weiteres Ziel des PDK ist, Zugriff auf alle Möglichkeiten des PHost zu bieten; auch das ist sicherlich noch nicht vollständig erreicht.

In jedem Fall solltest du einen Blick in die Dateiformat-Liste[Remote] werfen. Diese Liste enthält eine vollständige Beschreibung fast aller in Planets verwendeten Dateiformate für HOST und PHost. Die Liste wurde von Stefan Reuther erstellt (inzwischen ein PHost-Autor), größtenteils durch Reverse-Engineering, und enthält daher auch oft eine kritischere Sicht der Dinge als offizielle PHost-Dokumente ;-)

Nach oben

Turn-Dateien

PHost und HOST unterscheiden sich leicht in der Behandlung von Turn-Dateien. Effektiv akzeptiert PHost alles, was maketurn.exe und Winplan erzeugen. Wenn dein Programm sich also genauso verhält, funktioniert es wie gewünscht.

TacCom

PHost unterstützt keine TacCom-Turns (Turns mit Dateianhängen). Dies sind in Wirklichkeit Turndateien, die neben TacComs Dateien in einen speziellen Container eingebettet sind. HOST entpackt dieses Format. PHost enthält keinen derartigen Entpacker, daher werden TacCom-Turns als veraltet (stale) oder beschädigt zurückgewiesen.

Anordnung der Befehle

PHost erwartet dicht gepackte Turns, ohne Lücken zwischen den Befehlen. Die Befehlszeiger aus dem Kopf der Datei werden ignoriert. Wenn du Lücken zwischen den Befehlen lässt, kommt PHost durcheinander. (Wir halten das nicht für optimal, vermutlich wird es irgendwann einmal geändert. Allerdings hat diese Änderung keine hohe Priorität, schließlich funktioniert es ja :-) Es gibt nur ein kleines Problem: der Befehl PlanetBuildBase (34) hat ein unregelmäßiges Format, und einige Entwickler vereinfachen ihre Maketurns, indem sie dem Befehl ein zusätzliches Datenwort beifügen. Das funktioniert mit HOST, aber nicht mit PHost!

PHost vor Version 3.3b konnte durcheinander kommen, wenn du die Turn-Befehle nicht in der normalen Reihenfolge sendest (Schiffe in Id-Reihenfolge, Planeten in Id-Reihenfolge, Sternenbasen in Id-Reihenfolge, Nachrichten, Passwort; Befehle für jede Einheit in Reihenfolge der Befehlscodes). Neuere PHost-Versionen behandeln dieses Problem korrekt, bis Version 3.4a können dabei aber versehentlich Nachrichten umsortiert werden. In PHost 3.4b funktioniert es richtig.

Bauaufträge

Normalerweise sendet Maketurn den Befehl BaseBuildShip (53), wenn ein Bauauftrag an einer Sternenbasis geändert wurde. Einige Versionen von Winplan senden den Befehl allerdings dann (und nur dann), wenn ein Bauauftrag vorhanden ist, egal, ob er geändert wurde; sie senden gar keinen Befehl, wenn der Spieler den Auftrag storniert.

PHost enthält einen Workaround für diesen Fehler: sobald ein registrierter Winplan-Client erkannt wird, und für eine Basis kein BaseBuildShip-Befehl erhalten wird, nimmt PHost an, dass der Bauauftrag an dieser Sternenbasis storniert wurde und löscht ihn auch in den Host-Daten (mit HOST können diese Winplan-Versionen keine Bauaufträge stornieren).

Dein Maketurn muss also, wenn es Turns im Winplan-Format erzeugt, für jeden aktiven Bauauftrag einen BaseBuildShip-Befehl senden, damit PHost den Auftrag nicht löscht. Die beste Lösung, die mit allen Hosts funktioniert, ist, für jeden aktiven und jeden geänderten (bzw. stornierten) Auftrag einen BaseBuildShip-Befehl zu senden.

Fehlerbehebung

Im Gegensatz zu HOST versucht PHost nicht, Übertragungsfehler durch das Xmodem-Protokoll zu beheben.

SendBack

PHost 4.0 enthält einen neuen Turn-Befehl SendBack (62).

 +0     WORD    Receiver race
 +2     WORD    Record Type
 +4     WORD    Data Size
 +6   n BYTEs   Data

Dieser Befehl kopiert die angegebenen Daten (einschließlich Datensatztyp und Datengröße) in deine util.dat. Als Empfänger muss momentan 0 bzw. die Nummer des Spielers, in dessen Turn sich der Befehl befindet, angegeben werden; bei beiden Angaben werden die Daten an den Sender zurückgeschickt. Eventuell wird diese Möglichkeit in Zukunft ausgebaut, um auch das Senden an andere Spieler zuzulassen. Der Hauptzweck dieser Funktion ist es, Client-Programmen zu ermöglichen, ihre zusätzlichen Dateien zu "speichern", indem sie Datentransfer-Einträge (Typ 34) verwenden. PHost interpretiert die Daten nicht weiter. Die obere Grenze für die Größe ist 32000.

Geänderte Kosten

PHost 4.0k und neuer erlauben Hosts, verschiedene Kosten zu verändern, die bisher fest vorgegeben waren (zum Beispiel StarbaseCost). Diese Kosten sind auch in aktuellen Planets-Clients fest vorgegeben. Um korrekte Turns einreichen zu können, müssen Clients mit den entsprechend geänderten Werten rechnen, wenn sie eine entsprechende Aktion durchführen.

PHost implementiert keine Fehlerbehandlung für diese Fälle. Wenn die konfigurierten Kosten für eine Sternenbasis höher als die Standardwerte 402T/120D/340M/900$ sind, erhalten Spieler einen roten Status, wenn sie ihren Zug einreichen. PHost versucht nicht, dieses Problem zu erkennen und zu beheben.

Dies entspricht in etwa dem Verhalten, wenn du eine modifizierte Schiffsliste einsetzt. Die Qualität des Problemes ist jedoch eine neue, da Spieler dieses Problem nicht einfach durch Installation der korrekten Datendateien beheben können, sondern ein aktualisiertes Client-Programm installieren müssen.

Zum Schutz haben wir die Option AllowIncompatibleConfiguration vorgesehen. Hosts müssen diese Option explizit einschalten, bevor sie ein inkompatibles Spiel konfigurieren können.

Nach oben

VCR-Dateien

Dieses Kapitel beschreibt die Unterschiede von VCR-Dateien des PHost zu denen des HOST. Grundlegende Kenntnisse des VCR-Dateiformates werden vorausgesetzt.

Die Dateien unterscheiden sich nicht nur im Inhalt, es wird zur Wiedergabe auch ein vollkommen anderer Algorithmus benötigt.

Identifizieren

Um VCR-Dateien von PHost und HOST auseinander zu halten, enthalten Dateien, die der PHost erzeugt, eine Codenummer. In HOST ist das erste Wort eines Kampf-Datensatzes der Startwert für den Zufallsgenerator (1..111), das zweite Wort ist 0. In PHost ist das erste Wort der Startwert (alle 64k Möglichkeiten erlaubt), die Summe des ersten und zweiten Wortes ist immer 48879 (mod 65536). Diese Eigenschaft wird als PHost-Signatur bezeichnet und gilt für mindestens den ersten Kampf der Datei.

Alle VCR-Dateien, die von PHost 1.x oder 2.x erzeugt wurden, enthalten einen Konfigurationsdatensatz. Das genaue Format ist in der Dokumentation dieser PHosts und in der Dateiformat-Liste aufgeführt. Programme sollten diesen Datensatz nicht als Kampf interpretieren. PHost 3.x und 4.x senden diesen Datensatz nicht.

Da VPA vcrX.dat-Dateien mit nur einem Kampf falsch interpretiert, gibt es ein Programm Corr, welches diese Situation korrigiert und einen Dummy-Kampf anhängt. Diese Situation solltest du ebenfalls erkennen.

  • Wenn der erste Kampf die PHost-Signatur nicht enthält, handelt es sich um HOST-Kampf.
  • Wenn die Datei nur einen Kampf enthält, stammt sie von PHost 3.x/4.x.
  • Wenn die Datei zwei Einträge enthält, wobei die "Owner"-Felder im zweiten Eintrag 0 sind, hat der Benutzer Corr verwendet. Die Datei enthält dann nur einen Kampf von PHost 3.x/4.x sowie einen Dummy-Eintrag.
  • Wenn die Datei mindestens zwei Einträge enthält und der letzte Eintrag die PHost-Signatur enthält:
    Wenn das Feld BattleType 0 oder 1 ist, handelt es sich um eine vcr.hst-Datei. Die Versionsnummer ist nicht erkennbar.
    Wenn das FeldBattleType größer als 1 ist, handelt es sich um eine vcrX.dat von PHost 1.x/2.x.
  • Der Rest ist PHost 3.x/4.x.

Der Aufwärtskompatibilität wegen enthalten Kämpfe ein Feld mit einer Liste für das Abspielen der Kämpfe nötiger Funktionen (Capabilities). Dieses Capability-Feld steht nur im ersten Eintrag der Kampf-Datei, in dem Feld, das üblicherweise als "planet temperature" bezeichnet wird und von PHost sonst nicht genutzt wird.

  • Bit 15 ist gesetzt, um zu signalisieren, dass dieses Feld gültig ist.
  • Bits 14..3 sind gelöscht. Wenn sie gesetzt sind, benötigt die Aufzeichnung eine bisher unbekannte Funktion und kann nicht abgespielt werden.
  • Bit 2 ist gesetzt, wenn das Spiel derart konfiguriert ist, dass es von PHost 4.0k und später anders wiedergegeben wird als von vorigen Versionen.
  • Bit 1 ist gesetzt, wenn die Aufzeichnung Unterstützung für das Erfahrungssystem benötigt.
  • Bit 0 ist gesetzt, wenn die Aufzeichnung Unterstützung für Todesstrahlen oder ShieldKillScaling benötigt.

Wenn Bit 15 gelöscht ist, wird dieser Wert behandelt, als wäre er komplett 0. Wenn keins der Bits 0 bis 14 gesetzt ist, ist der Datensatz 100% kompatibel zu PHost 3.x.

PlayerRace

In Spielen mit geänderter PlayerRace-Zuordnung enthält das Owner-Feld im höherwertigen Byte die Rassennummer, falls diese sich von der Spielernummer unterscheidet. Wenn Spieler 2 also Lizards spielt, steht hier normal der Wert "2"; spielt er jedoch Privateers, steht hier der Wert "0x502".

Schiffstypen

Ein Problem des VCR-Dateiformates ist, dass der Hüllentyp normalerweise nicht mit übertragen wird. Damit weißt du normalerweise, ob du gegen einen Merlin oder einen Super-Frachter kämpfst. PHost sendet die Hüllennummer im höherwertigen Byte des Feldes, in dem normalerweise die Bild-Nummer steht. Beispielsweise enthält dieses Feld für den Merlin (Hülle 105 = 0x69, Bild 33 = 0x21) den Wert "Bild 0x6921".

Erfahrung

Die Erfahrungsstufe eines Schiffes oder Planeten wird im höherwertigen Byte des beam count-Feldes übertragen. Mögliche Werte liegen zwischen 0 und NumExperienceLevels. Die Erfahrungsstufe aus der VCR-Datei kann sich von der in util.dat unterschieden, falls das Schiff nach dem Kampf aufgestiegen ist.

Zusammenfassung

Zusammengefasst sieht also ein VCR-Eintrag so aus:

WORD      Random number seed
WORD      PHost: signature; HOST: 0
WORD      PHost: capabilities; HOST: planet temperature
WORD      Battle type (0=s/s, 1=s/p)
WORD[2]   Left and right mass
OBJ[2]    Left and right object, see below
WORD[2]   Left and right shields

Jedes Objekt hat folgendes Format:

BYTE[20]  Name
WORD      Initial damage
WORD      Crew
WORD      Id
BYTE      Player number
BYTE      PHost: Race, 0 if same as player [*]
BYTE      Picture number
BYTE      PHost: Hull number [*]
WORD      Beam type
BYTE      Beam count
BYTE      PHost: experience level [*]
WORD      Fighter bays
WORD      Torpedo type
WORD      Torpedo/Fighter count [**]
BYTE      Torpedo launcher count
BYTE      PHost: Torpedo count [**]

[*] = Diese Felder sind 0, wenn HOST oder eine ältere PHost-Version benutzt wird.

[**] = Wenn dieses Objekt ein Planet ist, und PlanetsHaveTubes eingeschaltet ist, enthält das erste Feld die Anzahl Raumjäger und das zweite die Anzahl Torpedos. In allen anderen Fällen hat das Objekt nur ein Sekundärwaffensystem, so dass das erste Feld die Anzahl Torpedos/Raumjäger enthält und das zweite 0 ist.

Nach oben

Andere Dateien

utilx.dat

Zu dieser Datei gibt es eine eigene umfangreiche Dokumentation.

Neue Programme sollten auf jeden Fall util.dat unterstützen anstatt sich auf einen Message-Parser zu verlassen. util.dat ist zuverlässiger und flexibler.

util.tmp

Diese Datei existiert nur während des Hostlaufes. Sie enthält den neuen Inhalt der util.dat-Dateien, genau so, wie mess.tmp die Nachrichten für die neuen Results enthält.

Diese Datei ist, ähnlich wie util.dat, in Datensätze unterteilt. In PHost 3.4 ist das Format folgendes:

 +0     WORD    Player Id (wessen UTILx.DAT die Daten enthalten wird)
 +2     WORD    Record Type (wie in UTILx.DAT)
 +4     WORD    Record Length
 +6   n BYTEs   Data

tons.hst

In PHost 3.4b und neuer enthält diese Datei 4x11 Longs, nicht mehr nur 2x11 wie vorher.

 +0  11 DWORDs  Versenkte Tonnage, Summe
+44  11 DWORDs  Versenkte Tonnage, diesen Zug
+88  11 DWORDs  Verlorene Tonnage, Summe
+132 11 DWORDs  Verlorene Tonnage, diesen Zug

plang4.hst

Seit PHost 4.1/3.5 ist plang4.hst eine Datei im normalen ar(1)-Format. ar(1) ist das Unix-Bibliotheksprogramm, und wird normalerweise für Software-Bibliotheken benutzt, aber auch z.B. für Debian-Pakete. ar(1) wurde aufgrund seiner geringen Komplexität und seines geringen Platzbedarfs gewählt.

plang4.hst enthält Dateien mit Namen der Form language.phl. Der Teil language darf dabei bis zu 8 Zeichen haben, "NewEnglish" wird also in einer Datei newengli.phl gespeichert. PHost sucht zuerst im Spiel- und Hauptverzeichnis nach den Dateien, danach in plang4.hst.

Damit können einfach neue Sprachen hinzugefügt werden. Wenn jemand seine Sprache auf Kisuaheli einstellen möchte, sucht PHost nach einer Datei kisuahel.phl.

Der Rückwärtskompatibilität wegen akzeptiert PHost ein paar Abkürzungen für Sprachnamen. Die Liste der Abkürzungen ist jedoch fest, neue Sprachen können keine Abkürzungen haben. Siehe die Beschreibung des Befehls language für mehr Informationen.

Wenn du Plattenplatz sparen willst, kannst du die Sprachdateien, die du verwenden willst, extrahieren und plang4.hst löschen. Alternativ kannst du die unbenutzten Sprachen mit einem Befehl wie ar d aus der plang4.hst entfernen. Die englische Sprachdatei, english.phl, muss immer verfügbar sein, entweder in plang4.hst, oder als separate Datei.

==> Frühere PHost-Versionen suchen nach ihrer Sprachdatei auch mit den Namen plang.hst und plangeng.hst. PHost 4.1 sucht nur nach einem Dateinamen. Die alte Sprachdatei hatte auch ein komplett anderes, stark verschlüsseltes Format.

shipscan.ext

PHost 3 und danach erzeugen in Phase 3 eine Datei shipscan.ext. Diese Datei soll Add-on-Programmen helfen, zu erkennen, welche Schiffe im aktuellen Zug von wem gescannt wurden. Es handelt sich dabei um eine Textdatei folgenden Formats:

  • Die erste Zeile enthält die Zugnummer als Dezimalzahl, gefolgt von einem Leerzeichen und dem 18-stelligen Zeitstempel. Damit können Add-on-Programme prüfen, ob die Datei zum aktuellen Zug passt (Zeit und Zugnummer müssen mit lastturn.hst übereinstimmen).
    ==> PHost-Versionen vor 4.0k/3.4m schreiben die vorige Zugnummer und Zeitstempel in die Datei. Insbesondere der Zeitstempel ist nutzlos, da er zu diesem Zeitpunkt nirgendwo anders gespeichert ist. Seit 4.0k/3.4m nutzt PHost die Daten aus lastturn.hst. Außerdem aktualisieren PHosts vor 4.0 lastturn.hst zu früh, so dass die Zugnummer während des Hostlaufs sogar zwei daneben liegt.
  • Danach folgt eine Zeile pro Schiffsslot (also 999 für PHost 4, 500 für PHost 3, unabhängig von dem mit NumShips eingestellten Wert). Jede dieser Zeilen enthält zwei dezimale Zahlen, die mit einem Leerzeichen getrennt sind.
    • Die erste Zahl ist ein Bitfeld der Spieler, die das Schiff regulär über ScanRange oder über den Befehl show sehen.
    • Die zweite Zahl enthält alle Spieler, die das Schiff über eine Schiffsallianz sehen, die der Besitzer des Schiffes anbietet, sowie den Schiffsbesitzer selbst.
    In jedem Wert bedeutet Bit 1 Spieler 1, Bit 2 Spieler 2 usw. Bit 0 ist unbenutzt. Die beiden Bitfelder haben keine Werte gemeinsam. Wenn jemand das Schiff regulär und über eine Allianz sieht, ist nur das Allianzbit gesetzt.

Wenn ein Schiff nicht existiert, lautet seine Zeile 0 0. Kein existierendes Schiff kann in der zweiten Spalte eine 0 haben.

combat.log

Wenn die Kommandozeilen-Option -C angegeben wurde, erzeugt PHost eine Datei combat.log. Diese Datei ist für Kampfsimulator-Programme gedacht. Programme können ein Spieluniversum einrichten, PHost darauf laufen lassen, und in combat.log nützliche Informationen abholen.

Die Datei besteht aus drei Zeilen für jeden Kampf in vcr.hst. Zum Beispiel:

15 s 22
d 40 0 9 100 0 51 0 0.0 0.0 0.0 33.5 102.9 44.2 36.4 0.0 55.4 0 0
v 1300 84 6 0 0 255 0 0.0 0.0 0.0 0.0 4.9 0.0 0.0 11.1 0.0 0 0

Die erste Zeile beschreibt den Kampf; es werden die Id-Nummer des linken Objektes, der Typ des rechten Objektes (s=Schiff, p=Planet) und dessen Id-Nummer angegeben. Das linke Objekt ist immer ein Schiff.

Die folgenden beiden Zeilen enthalten nützliche Informationen über das linke und das rechte Objekt, in dieser Reihenfolge:

  • Status: v=victory (Sieg), c=captured (gekapert), d=destroyed (zerstört), n=out of ammo (kampfunfähig)
  • Mannschaft (am Ende des Kampfes)
  • Schilde (am Ende des Kampfes)
  • Ursprünglicher Besitzer
  • Schaden (am Ende des Kampfes)
  • Anzahl überlebender Raumjäger
  • Anzahl verbleibender Torpedos
  • Minimale Anzahl Raumjäger an Bord des Schiffes während des Kampfes
  • Drei gebrochene Zahlen: durch gegnerische Raumjäger getötete Mannschaft, Schild-Schaden, Hüllen-Schaden.
  • Drei gebrochene Zahlen: durch gegnerische Torpedos getötete Mannschaft, Schild-Schaden, Hüllen-Schaden.
  • Drei gebrochene Zahlen: durch gegnerische Geschütze getötete Mannschaft, Schild-Schaden, Hüllen-Schaden.
  • Anzahl durch gegnerische Raumjäger verlorene Raumjäger
  • Anzahl durch gegnerische Geschütze verlorene Raumjäger

Durch Rundungseffekte entspricht die Summe der Werte "Schaden durch..." nicht genau den angegebenen Endwerten. Im Beispiel bekam das linke Schiff 102.9% Schild-Schaden durch Torpedos (das entspricht 100% Schild-Schaden und etwas Hüllen-Schaden) sowie 44.2%+55.4% = 99.6% Hüllenschaden von Torpedos und Geschützen (gerundet 100%).

hullfunc.dat

Die Datei hullfunc.dat wird von PHost erzeugt, wenn du beim Aufruf die Option -l (Schiffsliste ausgeben) verwendest. Die Datei enthält die Zuordnungen der Schiffsfunktionen in einem einfach maschinenlesbaren Binärformat. Programme wie EchoView nutzen diese Datei, anstatt aufwändig die shiplist.txt bzw. hullfunc.txt interpretieren zu müssen.

Die Datei besteht aus folgenden Teilen:

  1. Header
  2. Schiffstypen zugeordnete Funktionen
  3. Stufen-limitierte Funktionen (optional)
  4. Schiffen zugeordnete Funktionen (optional)
  5. Trailer

Die Teile stehen lückenlos direkt hinter einander. Der Header enthält Zeiger auf die optionalen Teile, damit sie einfacher gefunden werden können. Bis PHost 4.0k wurden nur die drei Pflichtteile geschrieben. Künftige PHost-Versionen werden möglicherweise weitere Daten vor dem Trailer einfügen, du solltest die Position des Trailers daher aus der Dateigröße ermitteln.

Format des Headers: 

 +0     DWORD   Magic Number 0xB1297F35
 +4     BYTE    PHost Minor Version (e.g. 0)
 +5     BYTE    PHost Major Version (e.g. 4)
 +6  32 BYTEs   Game Name (mit Leerzeichen aufgefüllt)
+38     DWORD   Zeiger auf Stufenlimitierte Schiffsfunktionen
+42     DWORD   Zeiger auf Schiffen zugewiesene Funktionen
+46   8 BYTEs   Reserviert, immer 0

Die "Zeiger"-Felder sind 0, wenn die entsprechenden Bereiche nicht existieren. Das ist die Standardbelegung in PHost-Versionen vor 4.0l.

Format der den Schiffstypen zugewiesenen Funktionen: Dieser Bereich beschreibt die Funktionen, die Schiffstypen zugeordnet sind (AssignTo=Hull). Wenn beispielsweise für einen Schiffstyp gemeldet wird, dass er nur tarnt, wenn er den Lizards gehört, kann so ein Schiff auch nur getarnt werden, wenn es gerade den Lizards gehört, egal, wer es gebaut hat.

 +0     WORD    Anzahl Einträge, die folgen
 +2   n RECORDs variabler Länger:
                 +0     WORD    Hull Number
                 +2     WORD    Anzahl Schiffsfunktionen, die dieser Hülle
                                zugewiesen sind
                 +4   n RECORDs a 4 Bytes:
                                 +0     WORD    Schiffsfunktion.
                                 +2     WORD    Spieler-Bitfeld. Bits 1 bis 11
                                                entsprechen den Spielern, die
                                                diese Funktion nutzen können.
                                                Bits 0 und 12..15 sind
                                                undefiniert.

Das Feld Special Function kann die folgenden Werte annehmen:

  • eine Funktions-Nummer (Feld Numerischer Wert in der Beschreibung der Funktionen)
  • die Nummer einer stufen-limitierten Schiffsfunktion, wie im nächsten Abschnitt beschrieben
  • ein noch nicht spezifizierter Wert einer künftigen PHost-Version bzw. eines Add-On-Programms

Stufen-limitierte Funktionen: Dieser Bereich beschreibt Funktionen, die mit einer Level-Anweisung modifiziert sind.

 +0     WORD    Anzahl modifizierter Funktionen
 +2     WORD    Größe der Einträge
 +4   n RECORDs der angegebenen Größe:
                 +0     WORD    Function Id
                 +2     WORD    Basic Function
                 +4     WORD    Experience Level Mask

Das Format der Definitionen ist das gleiche wie util.dat Eintrag 57, siehe dort für mehr Informationen. In künftigen Versionen kann die Größe erhöht und neue Daten angefügt werden. Beachte, dass die Funktionsnummern, die in hullfunc.dat gemeldet werden, sich von denen in utilX.dat unterscheiden können, da hullfunc.dat üblicherweise nur einmal zu Beginn des Spiels erstellt wird, während utilX.dat den jeweiligen aktuellen Zustand meldet. Die hier gemeldeten Funktionsnummern können also nur dazu verwendet werden, um die Funktionsnummern der Bereiche zugeordnete Funktionen in dieser Datei zu interpretieren.

Schiffen zugewiesene Funktionen: Das Format dieses Abschnitts ist das gleiche wie das des Bereichs Schiffstypen zugewiesene Funktionen. Es beschreibt Funktionen, die Schiffen zugewiesen werden, wenn diese gebaut werden (AssignTo=Ship). Wenn beispielsweise ein Schiff als tarnbar berichtet wird, wenn es der Lizard baut, dann kann jedes dieser Schiffe tarnen, wenn es der Lizard gebaut hat, egal, wem es momentan gehört.

==> Dieses Feld dient nur dazu, vorherzusagen, welche Eigenschaften ein neu gebautes Schiff haben wird. Die derzeit aktiven Zuordnungen existierender Schiff werden in util.dat-Eintrag 52 gemeldet.

Format des Trailers: 

 +0     DWORD   Signatur 0x1F0C219A
 +4     DWORD   Prüfsumme

Die Prüfsumme ist die wortweise Summe (Worte haben 16 Bit, Little-Endian) aller Worte in der Datei, bis auf das Prüfsummen-Feld selbst. Beispielsweise hat das Feld "Magic Number" den Wert 0xB1297F35. Damit besteht es aus den Worten 0xB129 und 0x7F35 und ergibt die Prüfsumme 0x1305E.

Neue Dateien

Nicht benutzte Dateien

  • tons2.hst: eine Punktetabelle analog den Tons, wird von PHost nicht unterstützt.
  • hconfig.hst: PHost nutzt stattdessen pconfig.src für die Konfiguration. Einige Add-ons benötigen allerdings eine gültige hconfig.hst. Siehe diesen FAQ-Eintrag für mehr Informationen.
  • pconfig.hst: in PHost 3.0 und neuer muss die Konfigurationsdatei nicht mehr explizit compiliert werden.
  • leechX.dat: diese Datei gehört zu "TacCom". HOST sendet diese Datei in den Results, PHost unterstützt diese Funktion nicht.
  • auxbatt.ini: diese Datei wird vom PHost nicht verwendet. Wenn du die Kampfsequenz austauschen willst, nutze dazu PControl.
  • auxhostX.exe, auxhostX.bat: PHost verwendet nur auxhostX.ini. Wenn du eine .exe oder .bat auführen willst, musst du sie aus der entsprechenden auxhostX.ini explizit aufrufen.

Ein paar Worte über Dateinamen

VGA Planets lief ursprünglich unter MS-DOS, welches in Dateinamen nicht zwischen Groß- und Kleinbuchstaben unterscheidet. Wenn PHost auf Unix oder einer anderen Plattform, die Groß- und Kleinbuchstaben unterscheidet, läuft, muss eine Festlegung über die Form der Dateinamen getroffen werden.

PHost bevorzugt Dateinamen in Kleinbuchstaben. Er enthält zwar ein paar Vorrichtungen, um mit Namen in Großbuchstaben umgehen zu können, dies ist aber sehr unterentwickelt und wenig getestet. Insbesondere verhindert PHost nicht, dass ein Name in Kleinbuchstaben angelegt wird, wenn bereits ein Name in Großbuchstaben existiert. Namen mit gemischter Schreibung wie HullSpec.Dat werden nicht unterstützt.

Tipp: Selbst unter Unix-ähnlichen Betriebssystemen wie Linux verhält sich eine Partition mit FAT-Dateisystem oftmals wie unter DOS oder Windows und unterscheidet nicht zwischen Groß- und Kleinschreibung. Damit lassen sich Probleme mit der Schreibung von Dateinamen einfach umgehen, indem du deine Spielverzeichnisse auf einer FAT-Partition speicherst.

Der Kompatibilität zu allen Plattformen wegen nutzt PHost für Dateien, die er selbst liest oder erstellt nur 8.3-Dateinamen. An Stellen, wo du selbst einen Verzeichnis- oder Dateinamen angeben kannst (also bei der Übergabe eines Spielverzeichnisses, oder in einer Addon-Anweisung) kannst du auch längere Dateinamen benutzen, sofern deine Umgebung diese unterstützt. Allerdings enthält PHost keine besonderen Maßnahmen, um diese Dateinamen zu maskieren (quoten), wenn sie beim Aufruf eines Addons an die Shell übergeben werden (z.B. per %d-Platzhalter in einem PControl-Befehl). Es empfiehlt sich daher, Shell-Sonderzeichen und Leerzeichen in Dateinamen zu vermeiden.

Nach oben

Letzte Aktualisierung 31 May 2015.
 
Mail support@phost.de for support, ideas, bug reports, questions. Contact Details