![]() |
Technische Informationen
|
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.
Wenn du ein Host-Addon für PHost schreibst, solltest du definitiv einen Blick auf das PHost Development Kit (PDK) 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.
In jedem Fall solltest du einen Blick in die Dateiformat-Liste 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 ;-)
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.
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.
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.
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.
Im Gegensatz zu HOST versucht PHost nicht, Übertragungsfehler durch das Xmodem-Protokoll zu beheben.
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.
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.
Da VPA VCR.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.
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.
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.
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".
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".
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.
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.
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.
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 (like in UTILx.DAT) +4 WORD Record Length +6 n BYTEs Data |
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 |
Aus historischen Gründen ist diese Datei verschlüsselt. Ein Grund ist vermutlich, dass PHost abstürzen kann, wenn diese Datei beschädigt wird. Details liegen daher vorerst nicht offen.
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:
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%).
Letzte Aktualisierung 15 October 2005.