![]() |
Datendateien (util.dat)
|
Zusätzlich zu den normalen Result-Dateien erstellt PHost noch für jede Spieler eine utilX.dat. Diese Dateien vereinfachen die Anzeige der Informationen für Spieler.
Traditionell lesen Programme die Subraumnachrichten, die der Host sendet, um Informationen wie die Positionen von Minenfeldern, Ergebnisse von Sensorabtastungen usw. zu erhalten. Dies ist schwierig und fehleranfällig, und verträgt sich nicht damit, dass PHost Nachrichten in mehreren Sprachen erzeugen kann. Um dieses Problem zu lösen, sendet PHost die meisten Nachrichten noch einmal in einem maschinenlesbaren Format, in der Datei utilX.dat. Idealerweise enthält utilX.dat alle wichtigen Informationen, falls dir also etwas fehlt, sag es uns ruhig.
Die utilX.dat wird auch benutzt, um Spielern Dateien zu senden, die diese (mit dem send-Befehl) angefordert haben.
Dieses Dokument beschreibt das Format der Datendateien. Es ist daher nur für Entwickler von Host- oder Client-Programmen interessant. Hosts sollten allerdings sicherstellen, dass ihre Spieler die utilX.dat zusammen mit ihrem Result erhalten.
Dieses Dokument beschreibt auch andere Aspekte der Kommunikation des Hosts mit den Clients, nämlich Subraumnachrichten (messages) und Ufos. Die bevorzugte Methode der Kommunikation der Clients mit PHost sind Befehlsnachrichten, die auf ihrer eigenen Seite beschrieben sind.
Dieser Abschnitt wird aus der Sicht eines Spielers bzw. dessen Programm geschrieben, der die Datei lesen will. Informationen für die Host-Seite finden sich weiter unten.
Die Datei wird im DOS-Format gespeichert. Alle Einträge mit mehr als einem Byte sind daher Little-Endian, Zweierkomplement. Die folgenden Datentypen werden verwendet:
byte | ein 8-Bit Byte (0..255) |
char | ein 8-Bit ASCII-Zeichen |
word | ein 16-Bit Wort (-32768..32767) |
long | ein 32-Bit Wort (-2147483648..2147483647) |
typ[NN] | ein Feld mit Elementen des angegebenen typs, üblicherweise von 1 an indiziert |
Jede utilX.dat besteht aus einer Anzahl Datensätze (records). Jeder Datensatz beginnt mit einem Header der Form:
word Record Type word Record Size |
Der Record Type gibt an, was für Daten der Eintrag enthält. Der Header wird vom eigentlichen Inhalt des Datensatzes gefolgt, die Länge dieser Daten ist mit Record Size angegeben. Alle Typen, die PHost verwendet, sind unten beschrieben.
Die maximale Größe eines Eintrages inklusive Header beträgt 32k, um Probleme mit Programmen zu vermeiden, die die Record Size als vorzeichenbehafteten Wert interpretieren (in Programmiersprachen wie Java oder BASIC gibt es keine vorzeichenlosen Datentypen).
Im Allgemeinen werden Zeichenfolgen (strings) im BASIC-Format
abgespeichert, also mit Leerzeichen auf die Feldbreite aufgefüllt
werden. Da PHost aus der C-Ecke stammt, erzeugen manche
Versionen versehentlich C-Strings (mit Nullbyte abgeschlossen),
einige Addons ebenfalls. Daher sollten deine Programme beide
Formate unterstützen. In der
Dateiformatliste gibt es weitere Hinweise.
Programme sollten das Record Size Feld
auswerten, um zu ermitteln, wieviele Daten nach dem Header folgen,
anstelle feste Werte zu verwenden. Damit kann das Programm neu
eingeführte oder erweiterte Datensätze korrekt überspringen. Einige
Datensätze wurden bereits erweitert und waren in älteren
PHost-Versionen kürzer. Soweit bekannt werden solche
Versionsabhängigkeiten hier erwähnt.
Record Size kann 0 sein, dann folgt der nächste
Datensatz direkt darauf, ohne Daten zu dem aktuellen Datensatz.
Die Reihenfolge der Einträge entspricht im Groben dem Hostablauf. Wenn Informationen über ein Objekt mehrmals hintereinander folgen, steht die aktuellste Information also ganz hinten. Die Typnummern der Einträge haben mit der Reihenfolge in der Datei nichts zu tun.
Jede utilX.dat beginnt mit einem Steuer-Datensatz (control record).
Datensatz 0 - Minenfeld-Scan | Seit: PHost 1.0 |
word Minefield Id word X Location word Y Location word Owner (1..11) long Mine Units word Type (0=normal, 1=web) --- PHost 2.0: --- word FCode Planet Id --- PHost 2.6d: --- word Scan Type (0=lay, 1=sweep, 2=scan) |
Gesendet, wenn: Minenfeld gelegt/geräumt/gescannt
Gesendet an: Besitzer des legenden/scannenden Schiffes, und Verbündete mit Vision-Privileg
Diese Nachricht berichtet über eins von drei Ereignissen:
Ein Minenfeld kann mehr als einmal aufgelistet sein. Es wird einmal berichtet, wenn es gescannt wurde, und einmal für jedes Schiff das Minen hinzufügt oder räumt. Die letzte Nachricht über ein Minenfeld ist die, die die endgültige Größe des Minenfeldes (nach dem Legen und Räumen) enthält.
Das Feld FCode Planet Id gibt den Planeten an, der den Kommandocode für das Minenfeld zur Verfügung stellt: der Minenfeld-Code ist der gleiche wie der des angegebenen Planeten. Dieses Feld ist nur für eigene Minenfelder und die deiner Verbündetetn, die dir Minen-Privileg bieten, gültig. Für andere Minenfelder steht hier 0.
Das Feld Scan Type gibt an, woher dieser Eintrag stammt. Wurde ein Minenfeld gelegt, ist dieses Feld 0. Wurde ein gegnerisches Minenfeld (teilweise) geräumt, ist es 1. Handelt es sich um die abschließende Zusammenfassung aller Scans (für eigene und gegnerische Minenfelder), steht hier eine 2. Normalerweise kommen alle Typ-0-Einträge vor den Typ-1-Einträgen (da das Minenlegen vor dem Minenräumen kommt), welche wiederum vor den Typ-2-Einträgen stehen (da alle Minenfeld-Aktionen zum Schluss zusammengefasst werden).
Wenn ein Spieler Winplan benutzt, sieht er seine Minenfelder automatisch auf diese Weise, auch ohne ausdrücklich danach zu suchen. Wenn du also Winplan benutzt und eins deiner Minenfelder nicht siehst, kannst du davon ausgehen, dass das Minenfeld nicht mehr existiert.
Wenn ein Spieler AllowMoreThan500Minefields eingeschaltet hat, werden alle Minenfelder mit diesem Datensatz gemeldet. Wenn AllowMoreThan500Minefields ausgeschaltet ist, werden Minenfelder mit Id-Nummern über 500 stattdessen mit Datensatz 46 gemeldet.
Datensatz 1 - Explosion | Seit: PHost 1.0 |
word X Location word Y Location word Ship Id --- PHost 3.4: --- char[20] Ship Name |
Gesendet, wenn: Schiff explodiert im Kampf
Gesendet an: alle Spieler
Datensatz 2 - Minentreffer | Seit: PHost 1.0 |
word Ship Id word X Location word Y Location word Damage --- PHost 3.4b: --- char[20] Name |
Gesendet, wenn: Schiff läuft auf eine Mine (Fangmine oder normal)
Gesendet an: Besitzer des Minenfeldes und des Schiffes
Die angegebene Positio ist die des Minentreffers. Der angegebene Schaden ist der Gesamtschaden nach dem Treffer. Insbesondere bedeutet das, wenn das Schiff 99% Schaden (bzw. 150% bei Lizards) überschreitet, explodiert das Schiff.
Datensatz 3 - Dark Sense | Seit: PHost 1.0 |
word Planet Id word Owner (1..11) long Neutronium long Tritanium long Duranium long Molybdenum long Megacredits word Starbase Flag (0=no, 1=yes) |
Gesendet, wenn: Schiff scannt einen Planeten mittels Dark Sense
Gesendet an: Besitzer des Schiffes, sowie alle, denen er eine Vision-Allianz bietet.
Datensatz 4 - Super Spy | Seit: PHost 1.0 |
word Planet Id word Mines word Factories word Defense char[3] Friendly Code long Neutronium long Tritanium long Duranium long Molybdenum long Megacredits --- PHost 3.0: --- long Supplies |
Gesendet, wenn: Schiff scannt einen Planeten mittels Super Spy (der Teil der Mission, der im Schritt SuperSpyMission passiert)
Gesendet an: Besitzer des Schiffes, das spioniert, sowie alle, denen er eine Vision-Allianz bietet.
Zusätzlich zu den Super-Spy-Informationen erhältst du noch einen Exploration-Datensatz.
Datensatz 5 - Forschungsbericht | Seit: PHost 1.0 |
word Planet Id word Temperature word Owner (1..11) long Colonists word Starbase Flag (0=nein, 1=ja) |
Gesendet, wenn: Schiff mit Treibstoff umkreist einen fremden Planeten
Gesendet an: Besitzer des Schiffes, das den Planeten scannt, sowie alle, denen er eine Vision-Allianz bietet.
Colonists ist eine Anzahl Kolonisten, nicht
Clans. Temperature ist die Temperatur in Grad-Fahrenheit,
nicht der Temperaturcode aus der pdata.dat.
Datensatz 6 - Sensorenbericht | Seit: PHost 1.0 |
word Planet Id word Owner (1..11) word Activity (0..5) |
Gesendet, wenn: Schiff scannt einen Planeten mittels Sensor Sweep
Gesendet an: Besitzer des Schiffes, das den Planeten scannt, sowie alle, denen er eine Vision-Allianz bietet.
Das Feld Activity enthält die Stärke der industriellen Aktivität auf dem Planet. Es entspricht den Werten aus der Nachricht folgendermaßen:
Activität | Name | Minen + Fabriken |
---|---|---|
0 | minimal | < 30 |
1 | light (leicht) | 30 to 59 |
2 | moderate (mäßig) | 60 to 89 |
3 | substantial (bedeutend) | 90 to 119 |
4 | heavy (stark) | 120 to 149 |
5 | heavy (stark) | > 149 |
Datensatz 7 - Kampfergebnis | Seit: PHost 1.0 |
word[2] Id Numbers word Planet Flag word[2] Owners (1..12) word[2] Damage word[2] Torps word[2] Fighters word[2] Outcome --- PHost 1.3+ --- word X Location word Y Location --- PHost 3.4b+ --- word Random Seed |
Gesendet, wenn: Kampf ausgetragen. Dieser Datensatz ist eine Ergänzung zum normalen vcr.dat-Eintrag.
Gesendet an: Teilnehmer des Kampfes und Verbündete, denen sie die Kampf-, Schiffs- und Vision-Privilegien geboten haben.
Jeder Kampf wird zwischen zwei Einheiten ausgetragen, für die dieser Eintrag das Ergebnis angibt (der Anfangszustand steht in der VCR-Datei). Wenn das Planet Flag null ist, sind beide Einheiten Schiffe; steht dort der Wert eins, ist die zweite Einheit ein Planet und die zweite Id-Nummer ist eine Planeten-Id.
Das Feld Outcome beschreibt den Ausgang des Kampfes aus Sicht dieser Einheit:
0 | Sieger: diese Einheit hat den Kampf gewonnen |
1 | Gekapert: diese Einheit wurde gekapert (trifft niemals für Planeten zu) |
2 | Zerstört: diese Einheit wurde zerstört (bei Planeten wurde die komplette Verteidigung zerstört und der Planet gekapert) |
3 | Kampfunfähig: diese Einheit hatte kein weiteres Offensivpotenzial mehr |
In PHost können Schiffe Planeten kapern. Ergebnis 3 (No Ammo, kampfunfähig) entsteht, wenn eine Einheit am Ende des Kampfes keine Geschütze und auch keine Torpedos oder Raumjäger mehr hat. Dieses Ergebnis tritt nur bei Schiffen ohne wirksame Geschütze auf. Da Todesstrahlen gegen Planeten nicht wirken, kann solch ein Kampf ebenfalls mit diesem Ergebnis beendet werden.
Das Feld Seed enthält den selben Wert wie in dem VCR-Datensatz. Zusammen mit den Id-Nummern kann somit der util.dat-Eintrag einem VCR-Datensatzu zugeordnet werden.
Datensatz 8 - Meteor-Einschlag | Seit: PHost 1.0 |
word Planet Id long Neutronium long Tritanium long Duranium long Molybdenum |
Gesendet, wenn: ein großer Meteor schlägt auf einem Planeten ein
Gesendet an: alle Spieler
Die Nachricht enthält den Inhalt des Meteors, der zum Planetenkern (nicht zu den bereits abgebauten Mineralien) hinzugefügt wurde.
Die Mineralien in einem großen Meteor werden mit LargeMeteorOreRanges eingestellt.
Datensatz 9 - Meteoriten-Hagel | Seit: PHost 1.0 |
word Planet Id long Neutronium long Tritanium long Duranium long Molybdenum |
Gesendet, wenn: Meteoritenhagel auf einem Planeten
Gesendet an: Besitzer des Planeten
Die Nachricht enthält den Inhalt des Meteoritenhagels, der zum Planetenkern (nicht zu den bereits abgebauten Mineralien) hinzugefügt wurde.
Die Mineralien in einem Meteoritenhagel werden mit MeteorShowerOreRanges eingestellt.
Dieser Datensatz hat das gleiche Format wie Datensatz 8.
Datensatz 10 - Schiff (Target) | Seit: PHost 1.0 |
word Ship Id word Owner (1..12) word Speed (0..9) word Location X word Location Y word Hull Number (1..105) word Heading (-1..359) char[20] Name |
Gesendet, wenn: AllowMoreThan50Targets ist deaktiviert, aber es wurden mehr als 50 Schiffe gescannt, und der Spieler erhält ein RST im DOS-Format.
Dieser Datensatz hat das gleiche Format wie ein Eintrag in targetX.dat. Die ersten 50 Schiffe sind im Result enthalten. Weitere Schiffe werden mit diesem Eintrag übertragen; falls der Spieler Winplan benutzt, stehen sie in einem besonderen Bereich des Results.
Die meisten Elemente dieses Datensatzes sind selbsterklärend. Das Feld Heading enthält die Richtung, in die sich das Objekt bewegt (0 bis 359 Grad, dabei ist 0 im Norden und der Winkel wird im Uhrzeigersinn gemessen). Der Wert -1 (0xFFFF) gibt eine unbekannte Richtung an.
Name ist ein 20-Byte-Feld mit dem Schiffsnamen.
Target-Einträge unterscheiden sich von dem echten Schiff wie folgt:
Datensatz 11 - Sternenbasis | Seit: PHost 1.0 |
word Base Id word Base Owner (1..11) |
Gesendet an: Verbündete, denen du die Planeten-Allianz anbietest
Dieser Datensatz berichtet, dass der angegebene Spieler an dem angegebenen Planeten eine Sternenbasis hat.
Datensatz 12 - Planet | Seit: PHost 1.0 |
word Planet Id word Owner (1..11) word Temperature (0..100) word Native Race (0..9) word Native Government (0..9) long Native Population long Neutronium long Tritanium long Duranium long Molybdenum long Colonist Population long Supplies long Megacredits |
Gesendet an: Verbündete, denen du die Planeten-Allianz anbietest
Dieser Datensatz enthält Informationen über verbündete Planeten.
Die Felder Native Government und Native Race können die folgenden Werte annehmen:
Index | Volk | Regierung |
---|---|---|
0 | keine Eingeborenen | - |
1 | Humanoid | Anarchy |
2 | Bovinoid | Pre-Tribal |
3 | Reptilian | Early Tribal |
4 | Avian | Tribal |
5 | Amorphous | Feudal |
6 | Insectoid | Monarchy |
7 | Amphibian | Representative |
8 | Ghipsoldal | Participatory |
9 | Siliconoid | Unity |
Die vier Mineralien-Einträge enthalten die Menge der Mineralien an der Planetenoberfläche, nicht die im Planetenkern.
Für die Bevölkerung wird eine Menge Personen angegeben,
nicht Clans. Temperature ist die Temperatur in
Grad-Fahrenheit, nicht der Temperaturcode wie in
pdata.dat.
Datensatz 13 - Steuerdatensatz (Control Record) | Seit: PHost 1.0 |
char[18] Host Run Time (Timestamp) word Turn Number word Player Number (1..11) byte PHost Version: Major (e.g. 4) byte PHost Version: Minor (e.g. 0) long HULLSPEC.DAT Digest long ENGSPEC.DAT Digest long BEAMSPEC.DAT Digest long TORPSPEC.DAT Digest long TRUEHULL.DAT Digest long XYPLAN.DAT Digest long Configuration Digest long RACE.NM Digest char[32] Game Name --- PHost 2.11h: --- byte PHost Version: Release (e.g. 'a') |
Gesendet, wenn: Dieser Datensatz steht immer am Anfang der util.dat. Er dient zur Identifikation der Datei und assoziiert sie mit einem Result.
Im Feld Host Run Time steht der gleiche Zeitstempel wie in der Resultdatei. Damit kann ein Programm sicherstellen, dass eine util.dat tatsächlich zu einem Result gehört, indem es dieses Feld, Turn Number und Player Number vergleicht.
Die drei PHost Version-Felder geben an, welche PHost-Version die Datei erstellt hat. Bei PHost 3.4c wären die Felder beispielsweise Major=3, Minor=4 und Release='c'. Das Feld Release kann auch leer (Leerzeichen) sein.
Die acht 32-Bit-Digest-Werte sollen es Programmen ermöglichen, zu überprüfen, ob die Schiffsliste auf Spieler-Seite die gleiche ist wie auf Host-Seite. Details sind auf Anfrage verfügbar.
Das Feld Game Name enthält den Wert der GameName-Option.
Datensatz 14 - Wurmloch-Scan | Seit: PHost 1.0 |
word Location X word Location Y word Mass (0..32767) word Stability Code (0..5) word Id --- PHost 3.4h/4.0e: --- word Ufo Id word Bidirectional (0 or 1) |
Gesendet, wenn: ein Wurmloch wurde gescannt
Gesendet an: Besitzer des Schiffes, das das Wurmloch scannt, sowie alle, denen er eine Vision-Allianz bietet.
Dieser Datensatz beschreibt einen Wurmloch-Endpunkt, inklusive seiner Masse und einer Angabe der Stabilität.
Code | Stabilität | Ungefähre Fehlschlags-Wahrscheinlichkeit |
---|---|---|
0 | very stable (sehr stabil) | 5% |
1 | stable (stabil) | 15% |
2 | mostly stable (fast stabil) | 30% |
3 | unstable (instabil) | 50% |
4 | very unstable (sehr instabil) | 80% |
5 | completely unstable (ein Schwarzes Loch) | > 80% |
Das Feld Id gibt die Wurmloch-Id an. Wurmloch-Ids sind geradzahlig, wenn es sich um einen Wurmloch-Eingang handelt, und ungerade, wenn es sich um den "Ausgang" eines bidirektionalen Wurmloches handelt. Der Ausgang hat immer eine Id-Nummer, die um eins größer ist als der Eingang. Nicht alle Id-Nummern müssen belegt sein, falls ein Wurmloch beispielsweise kollabiert ist, oder falls es sich um ein unidirektionales Wurmloch handelt (der Ausgang mit der ungeradzahligen Nummer ist für unidirektionale Wurmlöcher nicht sichtbar).
Datensatz 15 - Wurmloch durchquert | Seit: PHost 1.0 |
word Ship Id word Location X word Location Y word New Damage word Total Damage word Wormhole Id |
Gesendet, wenn: Schiff durchquert ein Wurmloch
Gesendet an: Besitzer des Schiffes
Mit Location und Wormhole Id wird der Ausgangspunkt der Reise angegeben. New Damage ist der Schaden, der durch die Reise angerichtet wurde, Total Damage der neue Gesamt-Schaden. Wenn der Gesamt-Schaden 100 oder mehr enthält, wurde das Schiff zerstört.
Datensatz 16 - Schiff recycelt | Seit: PHost 1.0 |
word Ship Id word Base Id |
Gesendet, wenn: Schiff an Sternenbasis recycelt
Gesendet an: Besitzer der Sternenbasis
Datensatz 17 - Ionensturm | Seit: PHost 1.3 |
word Storm Id (1..50) word Location X word Location Y word Voltage word Heading (0..359) word Speed (0..15) word Radius word Class (1..5) word Growth Flag (0=weakening, 1=growing) |
Dieser Datensatz wird von PHost momentan nicht verwendet. Er kann von Addons benutzt werden, die Ionenstürme simulieren. Zukünftige PHost-Versionen, die Ionenstürme unterstützen, werden diesen Eintrag nutzen.
Datensatz 18 - Schiff kolonisiert | Seit: PHost 1.3 |
word Ship Id word Planet Id |
Gesendet, wenn: ein Schiff wurde mittels Colonize verschrottet
Gesendet an: Besitzer des Schiffes
Dieser Datensatz wird nur gesendet, wenn das
Schiff mittels Colonize gelandet wurde. Wenn
der Planet normal durch Abladen von Kolonisten eingenommen wurde, wird
er nicht gesendet (siehe aber Datensatz 28, Bodenkampf).
Datensatz 19 - Schiff übernommen | Seit: PHost 1.4 |
word Ship Id word Original Ship Owner (1..11) word Base Id word Base Owner (1..11) |
Gesendet, wenn: Schiff ergibt sich an einer Sternenbasis (Force surrender)
Gesendet an: ehemaliger Besitzer des Schiffes, Besitzer der Sternenbasis
In PHost 1.3 ist Datensatz 19 ein Schiff, das vom Feind
übernommen wurde, und hat das folgende Format:
word Ship Id word Base Id word Enemy Race Id (1..11) |
Datensatz 20 - Schiff gebaut | Seit: PHost 1.4 |
word Ship Id word Base Id word Clone flag (0=no, 1=yes) |
Gesendet, wenn: neues Schiff gebaut
Gesendet an: Besitzer des Schiffes
Das Clone flag gibt an, ob es sich um einen normalen Bauauftrag oder um ein zu klonendes Schiff handelt.
In PHost 1.3 ist Datensatz 20 ein Schiff, das wir vom
Feind übernommen haben, und hat das folgende Format:
word Ship Id word Base Id word Enemy Race Id (1..11) |
Datensatz 21 - Schiff übergeben | Seit: PHost 1.3c |
word Ship Id word Old Owner (1..11) word New Owner (1..11) |
Gesendet, wenn: Schiff wurde mit dem Kommandocode gsX oder dem Befehl give übergeben.
Gesendet an: alter und neuer Besitzer
Datensatz 22 - Allianzen-Status | Seit: PHost 1.4b |
byte[11] Offered to... byte[11] Offers from... --- PHost 2.6: --- byte[11] Conditional offers to... byte[11] Conditional offers from... |
Gesendet an: alle Spieler, die in eine Allianz involviert sind
Die vier Komponenten dieses Eintrages werden mit einer Spielernummer indiziert.
Das erste Feld gibt an, welche Allianz-Privilegien (alliance levels) der Spieler den andern Spielern bietet. Das zweite Feld enthält entsprechend die Angebote der anderen Spieler an den Empfänger dieses Datensatzes. Beispielsweise enthält das fünfte Element von Offered To die Allianz-Angebote dieses Spielers an die Privateers; das fünfte Element von Offers From enthält die Allianz-Angebote der Privateers an diesen Spieler.
Jedes Element ist ein Bitfeld, welches folgendermaßen aufgebaut ist:
Bit | Bedeutung |
---|---|
0 (value 1) | Schiffe (Ship Level) |
1 (value 2) | Planeten (Planet Level) |
2 (value 4) | Minenfelder (Minefield Level) |
3 (value 8) | Kampf (Combat Level) |
4 (value 16) | Vision Level |
5 (value 32) | Aktiv? |
Zuerst ist Bit 5 (Wertigkeit 32): dieses Bit entscheidet, ob das Angebot überhaupt gültig ist (also der Spieler den Befehl allies add benutzt hat). Wenn das der Fall ist, stehen in den unteren 5 Bits die angebotenen Privilegien (siehe allies config).
Die beiden höchstwertigen Bits sind reserviert und werden von PHost auf 0 gesetzt.
Wenn beispielsweise das fünfte Offered To-Feld von Spieler 3 den Wert 00101010 (binär) hat, bedeutet das, dass Spieler 3 dem Spieler 5 ein Bündnis angeboten hat und die Privilegien "Planet" und "Kampf" anbietet.
Für jeden Spieler N sollten die Felder, Offered To[N] und Offers From[N] den Wert 0 haben (man kann keine Allianz mit sich selbst eingehen).
Die letzten beiden Felder dieses Datensatzes geben an, welche Allianz-Privilegien nur bedingt angeboten werden. Analog zu den Feldern Offered To und Offers From werden diese Felder mit einer Spielernummer indiziert. Ein gesetztes Bit markiert ein bedingtes Angebot, das nur aktiv wird, wenn der andere Spieler das gleiche Privileg ebenfalls (möglicherweise ebenfalls bedingt) anbietet.
Die Codierung ist die gleiche wie für die ersten beiden Felder, allerdings ist das Active bit immer 0. Wenn ein Allianz-Privileg nicht angeboten wird, ist das entsprechende "Conditional"-Bit immer 0.
Datensatz 23 - Bioscanner | Seit: PHost 2.6 |
word Planet Id word Native Race (0..9) long Native Population word Temperature |
Gesendet, wenn: Planet wurde von Bioscanner erfasst
Gesendet an: Besitzer des Schiffes, das den Planeten scannt, sowie alle, denen er eine Vision-Allianz bietet.
Siehe den Planeten-Datensatz für eine Beschreibung der Felder. Die Eingeborenen-Population (und -Rasse) kann 0 sein, wenn der Planet keine Eingeborenen hat.
Datensatz 24 - Glory Device Explodiert | Seit: PHost 2.6 |
word Ship Id word Location X word Location Y |
Gesendet, wenn: Glory Device wurde ausgelöst (mit trg oder pop)
Gesendet an: Besitzer des Schiffes
Dieser Eintrag wird nur für das Glory-Device-Schiff generiert, für alle anderen davon betroffenen Schiffe gibt es einen Datensatz 25.
Datensatz 25 - Schaden von Glory Device | Seit: PHost 2.6 |
word Ship Id word Location X word Location Y word New Damage word Ship Owner (1..11) --- PHost 3.4b: --- word Hull Number (1..105) char[20] Name |
Gesendet, wenn: Schiff wird von der Schockwelle eines Glory Device betroffen
Gesendet an: Besitzer des Schiffes, und Besitzer des Glory Device
Dieser Datensatz enthält ein Schiff, welches von einem Glory Device beschädigt wurde. Die Daten beschreiben das beschädigte Schiff, nicht das Glory Device. Das Feld New Damage enthält den neuen Schaden, nach der Explosion. Bei einem Wert von 100 oder mehr ist das Schiff explodiert.
Datensatz 26 - Schiff geentert | Seit: PHost 2.6 |
word Ship Id word Old Owner (1..11) word New Owner (1..11) --- PHost 2.9e: --- word Boarding Ship Id |
Gesendet, wenn: Schiff wird geentert und übernommen (tow capture, siehe Mission Tow)
Gesendet an: alter und neuer Besitzer des Schiffes
Das Feld Ship Id enthält die Id des Schiffes, welches den Besitzer gewechselt hat; Boarding Ship Id ist die Id des Schiffes, welches das andere Schiff geentert hat.
Datensatz 27 - Konfigurationsdatei | Seit: PHost 2.6 |
Dieser Eintrag enthält eine Kopie von pconfig.src, ohne weitere Header.
Seit PHost 2.10 wird dieser Datensatz nicht mehr
verwendet, stattdessen wird der
allgemeine Dateitransfer genutzt.
Datensatz 28 - Bodenangriff | Seit: PHost 2.6 |
word Planet Id word Owner Race (1..11) word Attacker Race (1..11) word Outcome (0..2) |
Gesendet, wenn: Planet wird mit dem normalen Bodenkampf (Kolonisten abladen) oder Imperial Assault angegriffen
Gesendet an: Besitzer des Planeten und Angreifer
Das Feld Outcome kann die folgenden Werte annehmen:
0 | Angriff fehlgeschlagen, der Spieler Owner Race ist immer noch Besitzer des Planeten |
1 | Angriff erfolgreich, Spieler Attacker Race besitzt nun den Planeten |
2 | Alle Kolonisten haben sich gegenseitig getötet, der Planet ist nun unbesetzt |
Datensatz 29 - Minenfelder explodieren | Seit: PHost 2.6d |
word Minefield 1 Center X word Minefield 1 Center Y word Minefield 1 Id word Minefield 2 Center X word Minefield 2 Center Y word Minefield 2 Id long Minefield Units Lost |
Gesendet, wenn: zwei Minenfelder explodieren, weil sie überlappen
Gesendet an: alle Spieler
Dieser Eintrag enthält die Id-Nummern und Positionen der beiden Minenfelder, sowie die Anzahl Minen-Einheiten, die aus beiden Minenfeldern entfernt wurden.
Dieser Datensatz wird verwendet, wenn die Verluste symmetrisch sind: wenn zwei Minenfelder überlappen, verlieren beide die selbe Menge. In einigen Fällen sind die Verluste nicht symmetrisch, dann sendet PHost einen Datensatz vom Typ 53 für alle betroffenen Felder.
Datensatz 30 - Ende der Informationen von PHost | Seit: PHost 2.7a |
Dieser Datensatz ist der letzte in util.dat, der von PHost erzeugt wird. Der einzige Grund ist zu markieren, dass die folgenden Einträge von anderen Programmen oder Addons erzeugt wurden. Der Datensatz enthält keine Daten.
Datensatz 31 - Minenfeld aufgesammelt (scoop) | Seit: PHost 2.9d |
word Ship Id word Minefield Id word Torps Converted long Units Scooped --- PHost 2.11h: --- long Units Before Scoop |
Gesendet, wenn: Schiff sammelt Minen aus einem Minenfeld auf und stellt Torpedos her
Gesendet an: Besitzer des Schiffes
Das Feld Torps Converted gibt die Anzahl umgewandelter Torpedos an. In Units Scooped befindet sich die Anzahl dafür aufgesammelter Minen-Einheiten.
Datensatz 32 - Pillage | Seit: PHost 2.9d |
word Planet Id long Colonist Clans long Native Clans --- PHost 3.4g/4.0c: --- word Ship Owner |
Gesendet, wenn: Planet wird geplündert
Gesendet an: Besitzer des Planeten, und Besitzer des Schiffes, das den Planeten plündert
Im Gegensatz zu den anderen Datensätzen wird hier
tatsächlich eine Clan-Anzahl berichtet.
Datensatz 33 - Objekt | Seit: PHost 2.10 |
word Object Id word Position X word Position Y word Color (1..15) word Radius word Speed (0..15) word Heading (-1..359) char[20] Name char[20] Info Field 1 char[20] Info Field 2 word Utility Code ...weitere Daten können folgen. |
Dieser Datensatz ist als Vorlage für Addons gedacht, die Objekte an Client-Programme melden wollen, ähnlich der ufo.hst von HOST. PHost selbst erzeugt diesen Datensatz nicht. Wir empfehlen allen Addon-Autoren, die neue Objekte im Universum erzeugen, diesen Datensatz zu nutzen.
Dieser Eintrag kann in drei Abschnitte aufgeteilt werden:
Dieser Datensatz vereinfacht einem Client-Programm, Addon-Objekte darzustellen. Daher empfehlen wir allen Addon-Entwicklern, diesen Datensatz zu nutzen, um Objektpositionen zu übermitteln. Mindestens die folgenden Programme werten General-Object-Einträge aus:
Es gibt eine Konvention bezüglich des Feldes Object Id: wenn das Objekt auch in der ufo.hst enthalten ist, sollte das Feld Object Id der Ufo-Id entsprechen. Damit können Client-Programme erkennen, dass es sich um das selbe Objekt handelt. Entsprechend sollten also Objekte, die nicht in der ufo.hst stehen, eine Object Id größer als 1000 haben (das ist die maximale Anzahl Objekte in ufo.hst).
Siehe auch: General Object Destruction (Datensatz 42), die Datei UFO.HST
Datensatz 34 - Datei-Übertragung | Seit: PHost 2.9d |
char[12] File Name byte Flags char[...] File Data |
Gesendet, wenn: Spieler hat eine Datei vom Host angefordert (mit dem Befehl send), möglicherweise auch in anderen Fällen
Gesendet an: betreffenden Spieler
Mit diesem Datensatz kann eine Datei vom Host zum Spieler übertragen werden. Er enthält einen 13 Byte großen Header gefolgt vom Inhalt der Datei.
Der File Name enthält den Dateinamen, falls nötig mit einem Nullbyte am Ende. Es sind nur 8.3-Dateinamen (DOS) zulässig, die maximal 12 Zeichen haben. Die Flags enthalten zusätzliche Informationen, die die Datei beschreiben. Momentan wird nur das niederwertigste Bit benutzt, alle anderen sind 0 (für spätere Verwendung reserviert).
Dateien größer als 32k können hiermit nicht gesendet
werden. Wir planen eine Möglichkeit, das in naher Zukunft doch
zuzulassen. Wenn du diese Funktionalität jetzt benötigst, nerv uns
:-)
Momentan wird dieser Datensatz für folgende Funktionen benutzt:
Addon-Programme können diesen Datensatz für ähnliche Zwecke nutzen.
Datensatz 35 - Tarnung versagt | Seit: PHost 2.10b |
word Ship Id word Reason (0..5) |
Gesendet, wenn: Tarnung versagt auf einem Schiff
Gesendet an: Besitzer des Schiffes
Dieser Datensatz berichtet über versagte Tarnung. Bis auf Berichte von Tachyonen-Pulsen wird dieser Eintrag nur gesendet, wenn AllowCloakFailMessages aktiviert ist.
Dieser Datensatz wurde durch die allgemeine Fehlermeldung ersetzt, siehe dort für eine Beschreibung des Feldes Reason. Dieser Datensatz wird der Kompatibilität wegen immer noch gesendet.
Datensatz 36 - Anti Cloak | Seit: PHost 2.11g |
word Ship Id word Location X word Location Y word Owner --- PHost 3.4e/4.0a: --- word Before Movement |
Gesendet, wenn: Loki enttarnt ein Schiff. In PHost 4.0/3.4d und eher wird dieser Datensatz nur gesendet, wenn das enttarnte Schiff einen Planeten orbitiert.
Gesendet an: Besitzer des Loki
Das Feld Before Movement gibt an, ob die angegebene Position vor (1) oder nach (0) der Bewegung gescannt wurde. Wenn dieses Feld fehlt, kannst du die relative Position des Datensatzes in der Datei als Hinweis nutzen.
Datensatz 37 - Remote Control | Seit: PHost 3.0 |
word Ship Id 1 word Remote Control Flag 1 word Ship Id 2 word Remote Control Flag 2 ...and so on |
Mit diesem Datensatz werden die ursprünglichen Besitzer von ferngesteuerten Schiffen übertragen, die der Spieler diesen Zug sieht. Dieser Datensatz enthält ebenfalls Informationen über Schiffe des Spielers, die nicht für die Fernsteuerung freigegeben sind. Dieser Datensatz hat eine variable Größe, die von der Anzahl Schiffe abhängt. Wenn der Datensatz die Länge 4*N Bytes hat, enthält er N Einträge, die jeweils eine Schiffs-Id und den Status des Schiffes enthalten.
Datensatz 38 - Activity Levels | Seit: PHost 3.0 |
long Old Level long Decay Points long New Points long New Level |
Gesendet, wenn: immer
Gesendet an: jeder Spieler
Dieser Datensatz enthält die Aktivitätspunkte (PAL) eines Spielers, sowie die Punkte, die diesen Zug dazugewonnen bzw. verfallen sind.
PBPs: In PHost 4.0f/3.4i und neuer kann die Menge verbrauchter PBPs berechnet werden als
Used_PBPs = Old_Level - Decay_Points - New_Points - New_Level |
In vorigen PHost-Versionen ist Old Level der Stand nach dem Verbrauch der PBPs. Damit ergibt die Gleichung Null. In diesem Fall können die verbrauchten PBPs als Differenz zwischen dem New Level des letzten Zuges und dem Old Level dieses Zuges ermittelt werden.
Wenn keine PBPs verwendet werden, ergeben beide Methoden einen PBP-Verbrauch von 0. Siehe Details zu Baupunkten für mehr Informationen.
Datensatz 39 - Bauliste | Seit: PHost 3.0 |
word Base Id word Hull Type (1..105) word Position long Priority (...für alle Bauaufträge wiederholt) |
Gesendet, wenn: Spieler hat wartende Bauaufträge
Gesendet an: jeder Spieler
Dieser Datensatz enthält die Baulisten-Eintrage eines Spielers. Die Länge des Datensatzes hängt von der Anzahl Bauaufträge ab, pro Bauauftrag ist ein Eintrag von 10 Bytes enthalten.
Die Base Id ist die Sternenbasis, die das Schiff baut. Position ist die Position in der globalen Bauliste, an Position 1 steht das Schiff, das als nächstes gebaut wird. Priority ist die Priorität des Schiffes, die höchste Priorität wird zuerst gebaut.
Bauaufträge können ihre Position von Zug zu Zug ändern, entsprechend ihrer Prioritäten. Ein Bauauftrag rutscht nicht zwingend ständig in der Liste vorwärts.
Datensatz 40 - Web Drain Complete | Seit: PHost 3.0 |
word Ship Id --- PHost 3.4d --- word Player Id char[20] Ship Name |
Gesendet, wenn: Schiff innerhalb eines Fangminenfeldes hat keinen Treibstoff mehr
Gesendet an: Besitzer des Minenfeldes
Schiffe können leerlaufen, wenn sie eine Fangmine treffen, oder wenn sie Treibstoff verlieren, weil sie einfach nur in dem Minenfeld stehen. Letzteres passiert nur bei Fangminenfeldern, die den Crystals gehören, ersteres passiert bei allen Fangminen.
Datensatz 41 - Rebel Ground Attack | Seit: PHost 3.3c |
word Planet Id word Native Flag (0=no, 1=yes) --- PHost 3.4g/4.0d: --- word Rebel Player |
Gesendet, wenn: Schiff führt Rebel Ground Attack aus
Gesendet an: Besitzer des Schiffes, und Besitzer des Planeten
Dieser Datensatz enthält nur die Information, ob der Planet Eingeborene hat oder nicht. Die Rasse der Eingeborenen wird nicht übertragen. Das Feld Rebel Player enthält den Besitzer des angreifenden Schiffes, falls mehrere Spieler die Rebels spielen.
Datensatz 42 - General Object zerstört | Seit: PHost 3.3c |
word Object Id word Utility Code ...weitere Daten können folgen |
Gesendet, wenn: ein General Object wurde zerstört
Dieser Datensatz kann von Addon-Programmen genutzt werden, um die Zerstörung eines General Object zu melden. PHost selbst erzeugt diesen Eintrag nicht.
Hiermit soll das Verwalten von Informationen durch Clients vereinfacht werden. Clients können somit veraltete Objekte automatisch verwerfen. Die utilX.dat sollte bezüglich dieses Eintrags in chronologischer Reihenfolge verarbeitet werden: ein General-Object-Eintrag, der direkt oder indirekt von diesem Eintrag (für das gleiche Objekt) gefolgt wird, berichtet von einem neuen Objekt, welches sofort wieder zerstört wurde. Folgt zuerst ein Bericht über eine Zerstörung und dann ein neues Objekt mit den selben Id/UtilCode, so wurde das Objekt zerstört und ein neues erschaffen.
Nach den beiden hier definierten Feldern können Programm weitere Daten ablegen, zum Beispiel den Grund für die Zerstörung.
Siehe auch: General Object (Datensatz 33)
Datensatz 43 - Minenfeld-Status | Seit: PHost 3.3c |
word[11] Allowed word[11] Laid |
Gesendet, wenn: Minenfeld-Restriktionen sind aktiv (MaximumMinefieldsPerPlayer)
Gesendet an: alle Spieler
Dieser Datensatz ist veraltet und wird möglicherweise in
Zukunft entfernt. Die selben Informationen werden seit PHost 3.4d in
Datensatz 51 übertragen.
Dieser Eitnrag wird gesendet, wenn Minenfeld-Limits aktiv sind. Das Feld Allowed enthält für jeden Spieler die erlaubte Anzahl Minenfelder (MaximumMinefieldsPerPlayer). Das Feld Laid enthält die Anzahl Minenfelder für jeden Spieler: du erfährst die Anzahlen deiner Verbündeten, die dir das Minenfeld-Privileg bieten. Positionen von Spielern, die du nicht sehen sollst, sind 0xFFFF (all bits 1).
Datensatz 44 - Fehlschlag-Meldung | Seit: PHost 3.4 |
word Action that Failed word Ship Id (0 wenn nicht zutreffend) word Planet Id (0 wenn nicht zutreffend) word Cause ...optional weitere Daten |
Gesendet, wenn: eine Aktion schlägt fehl
Gesendet an: Besitzer der Einheit, die die Aktion ausführen wollte
Dieser Datensatz ist als eine allgemeine Möglichkeit zum Melden von Fehlern gedacht, damit man nicht so viel raten muss, wenn etwas schiefgelaufen ist.
Das Feld Action identifiziert die fehlgeschlagene Aktion; per Konvention ist das eine utilX.dat-Datensatznummer, oder eine größere Zahl, falls kein dazugehöriger Datensatz existiert. Das Feld Cause gibt an, warum die Aktion fehlgeschlagen ist. Der Datensatz lässt Raum für zusätzliche Informationen, was momentan nicht genutzt wird.
Fehlercodes: Die folgenden Werte für Cause sind momentan definiert. Noch nicht alle werden bereits verwendet.
Code | Bedeutung |
---|---|
0 | Zufall |
1 | zu wenig Sprit |
2 | zu stark beschädigt |
3 | Ionenpuls |
4 | Wurmloch durchquert |
5 | Tachyonenpuls |
10 | fehlende Ressourcen |
11 | fehlende Techlevels |
12 | Empfänger nicht anwesend |
13 | Funktion vom Host deaktiviert |
14 | Aktion ist lt. Regeln nicht erlaubt |
15 | Aktion ist wird vom Partner nicht genehmigt |
16 | Globales Limit überschritten |
17 | Limit für dein Volk überschritten |
18 | benötigte Fähigkeit nicht verfügbar |
19 | Zielobjekt existiert nicht |
Momentan benutzte Codes: Es folgen alle Konbinationen aus Action und Cause, die PHost momentan erzeugt.
Datensatz 45 - Planet übergeben | Seit: PHost 3.4b |
word Planet Id word Old Owner (1..11) word New Owner (1..11) |
Gesendet, wenn: Planet wurde mittels des Befehles give übergeben.
Gesendet an: alter und neuer Besitzer
Dieser Datensatz hat das gleiche Format wie der Bericht über Schiffshandel.
Datensatz 46 - Minenfeld-Scan (hohe Id) | Seit: PHost 3.4b |
Dieser Datensatz hat das selbe Format und die selbe Bedeutung wie Datensatz 0, siehe dort für mehr Informationen. Mit diesem Datensatz werden Minenfelder mit Id-Nummern über 500 übermittelt.
Wenn ein Spieler AllowMoreThan500Minefields ausgeschaltet hat, aber ein Minenfeld mit einer Id größer 500 zu melden ist, nutzt PHost diesen Datensatz. Wenn AllowMoreThan500Minefields eingeschaltet ist, werden alle Minenfelder mit Datensatz 0 gemeldet.
Datensatz 47 - Nicht-existierende Planeten | Seit: PHost 3.4c |
word[...] Planet Id |
Gesendet, wenn: es gibt nicht belegte Planeten-Ids, du spielst also auf einer Karte mit weniger als 500 Planeten.
Gesendet an: alle Spieler
Dieser Datensatz listet alle Planeten-Ids, die nicht existieren. Clients können diese Informationen nutzen, um ihre Sternenkarte zu aktualisieren.
Datensatz 48 - PAL-Übersicht | Seit: PHost 3.4c |
long[11] PAL Scores |
Gesendet, wenn: immer
Gesendet an: jeder Spieler
Dieser Datensatz ist veraltet und wird durch
Datensatz 51 ersetzt, der verschiedene
Punktestände berichten kann.
Dieser Datensatz enthält die PAL-Werte aller Spieler. Die Option BuildPointReport definiert, welche Einträge enthalten sind. Werte, die du nicht wissen sollst, sind -1 (0xFFFFFFFF).
Im Gegensatz zu der Subraumnachricht, die nur gesendet wird, wenn Daten von mehr als einem Spieler vorhanden sind, wird dieser Datensatz immer gesendet.
Datensatz 49 - Punktestand für Schiffe | Seit: PHost 3.4d / 4.0 |
char[50] Name word Score Type word Score Limit word Ship Id 1 word Score 1 word Ship Id 2 word Score 2 ...für alle relevanten Schiffe wiederholt |
Dies ist eine Möglichkeit, allgemeine schiffsbezogene Punktestände zu melden. Der Name enthält einen menschenlesbaren Namen des Punktestands, der Score Type enthält eine Bezeichnung für den Punktestand, die von Programmen ausgewertet werden kann. Das Score Limit gibt eine wichtige Grenze für den Punktestand an (kein hartes Limit: Punktestände können höher werden, aber wenn das Limit erreicht wird, passiert etwas "interessantes"). Die Bedeutung dieses Feldes hängt von der Art des Punktestandes ab. Das Feld kann auch -1 (=65535) sein, wenn es kein Limit gibt.
Programme können, dank des Name-Feldes, alle Punktestände sinnvoll bezeichnen. Wenn ein Programm nach einem bestimmten Punktestand sucht, kann es das Score Type-Feld nutzen.
Die drei Steuer-Felder werden von einer Folge aus Schiffs-Ids und Schiffs-Punktestand gefolgt. Die Anzahl solcher Felder kann aus der Größe des Datensatzes ermittelt werden.
Punktestände:
1 |
(v4.0:) Erfahrungsstufen. Die Obergrenze ist NumExperienceLevels, Punktestände laufen von 0 bis zu diesem Limit. Jeder Spieler bekommt Berichte über die Erfahrung seiner Schiffe und der Schiffe seiner Verbündeten. |
2 .. 99 | für zukünftige Verwendung reserviert |
100 .. 32767 | für Addon-Entwickler reserviert |
Dieser Datensatz hat das gleiche Format wie der Datensatz mit den Planeten-Punkteständen. Wenn möglich haben die Bezeichner der Punktestände die gleichen Werte.
Datensatz 50 - Punktestand für Planeten | Seit: PHost 3.4d / 4.0 |
char[50] Name word Score Type word Score Limit word Planet Id 1 word Score 1 word Planet Id 2 word Score 2 ...für alle relevanten Planeten wiederholt |
Dies ist eine Möglichkeit, allgemeine planetenbezogene Punktestände zu melden. Dieser Datensatz hat das selbe Format wie Datensatz 49 (Schiffs-Punktestand).
Die drei Steuer-Felder werden von einer Folge aus Planeten-Ids und Planeten-Punktestand gefolgt. Die Anzahl solcher Felder kann aus der Größe des Datensatzes ermittelt werden.
Punktestände:
1 |
(v4.0:) Erfahrungsstufen. Die Obergrenze ist NumExperienceLevels, Punktestände laufen von 0 bis zu diesem Limit. Jeder Spieler bekommt Berichte über die Erfahrung seiner Planeten und der Planeten seiner Verbündeten. |
2 .. 99 | für zukünftige Verwendung reserviert |
100 .. 32767 | für Addon-Entwickler reserviert |
Datensatz 51 - Punktestand | Seit: PHost 3.4d / 4.0 |
char[50] Name word Score Type word Turn Limit long Win Limit long[11] Scores |
Dieser Datensatz ist eine allgemeine Möglichkeit, Punktestände zu übermitteln. Der Name ist der Name dieser Punktetabelle in menschenlesbarer Form. Der Score Type enthält eine Bezeichnung der Punktetabelle, die von Programmen benutzt werden kann. Das Win Limit gibt an, wie viele Punkte ein Spieler erreichen muss, um das Spiel zu gewinnen, das Turn Limit gibt an, wie lange er diesen Punktestand halten muss. Beide Werte können -1 sein, wenn es kein solches Limit gibt. Das Feld Scores enthält schließlich die Punktestände aller 11 Spieler. Wenn der Empfänger des Datensatzes einen Wert nicht sehen darf, steht in dem entsprechenden Feld eine -1 (=0xFFFFFFFF).
Programme können, dank des Name-Feldes, alle Punktestände sinnvoll bezeichnen. Wenn ein Programm nach einem bestimmten Punktestand sucht, kann es das Score Type-Feld nutzen.
Punktestände:
1 | "Der Punktestand". Dieser Eintrag wird von PHost nicht benutzt. Wir empfehlen, dass Programme, die eigene Punktestände berechnen (scoring systems) diesen Datensatz benutzen, um die Punktestände zu übertragen. Damit können Programme wie EchoView den Verlauf automatisch darstellen. |
2 | Baupunkte. Dieser Eintrag enthält alle Baupunkte, und ist als Ersatz zu Datensatz 48 gedacht. |
3 | Erlaubte Minenfelder. Dieser Eintrag wird gesendet, wenn Minenfeld-Limits aktiv sind, und enthält den Wert der Konfigurationsoption MaximumMinefieldsPerPlayer. Dieser Eintrag ist als Ersatz zu Datensatz 43 gedacht. |
4 | Gelegte Minenfelder. Dieser Eintrag wird gesendet, wenn Minenfeld-Limits aktiv sind, und enthält die aktuelle Minenfeld-Anzahl für dich und deine Verbündeten. Dieser Eintrag ist als Ersatz zu Datensatz 43 gedacht. |
5 .. 99 | für zukünftige Verwendung reserviert |
100 .. 32767 | für Addon-Entwickler reserviert |
Datensatz 52 - Schiffsfunktionen | Seit: PHost 4.0a |
word Ship Id word[N] Ship Abilities |
Gesendet an: jeden, der das Schiff sieht
Dieser Datensatz enthält die schiffsspezifischen Funktionen für ein Schiff (siehe AssignTo=Ship). Jeder Datensatz kann mehrere Funktionen enthalten, es können aber auch mehrere Datensatz für ein Schiff auftreten.
Funktionsnummern sind ganze Zahlen, die folgende Werte annehmen können:
0 bis 37 | Standard-Schiffsfunktionen |
38 bis 999 | reserviert für zukünftige Benutzung durch PHost. Momentan legt PHost die Pseudo-Funktions-Nummern für Stufen-beschränkte Funktionen aus diesem Bereich, siehe Eintrag 57. |
1000 bis 32767 | reserviert für Addons. Kontaktiere die PHost-Gruppe, um einen Bereich für dich reserviert zu bekommen. |
Dieser Eintrag enthält nur Funktionen, die dem Schiff direkt zugewiesen wurden (AssignTo=Ship). Funktionen, die einem bestimmten Schiffstyp zugewiesen wurden (AssignTo=Hull) werden nicht so übermittelt, dafür muss hullfunc.txt gelesen werden.
Datensatz 53 - Minenfelder explodieren | Seit: PHost 3.4f / 4.0b |
word Minefield Center X word Minefield Center Y word Minefield Id long Minefield Units Lost |
Gesendet, wenn: zwei Minenfelder explodieren, weil sie überlappen
Gesendet an: alle Spieler
Dieser Datensatz wird momentan nicht von PHost erzeugt. Er wurde von einem Prototyp für den Host-Schritt MinesDestroyMines benutzt, hat sich aber später als nicht nötig herausgestellt. Es schadet aber nicht, diesen Datensatz definiert zu haben.
Wenn zwei Minenfelder überlappen, verlieren sie normalerweise die gleiche Anzahl Mineneinheiten. Das wird mit einem Datensatz 29 berichtet. Mit diesem Eintrag können asymmetrische Verluste gemeldet werden. Wenn zwei Minenfelder verschiedene Mengen verlieren, wird das mit zwei Einträgen vom Typ 53 gemeldet. Dieser Datensatz wird mit Typ-29-Datensätzen gemischt, wie es gerade passt.
Datensatz 54 - Feindbild | Seit: PHost 4.0h |
word Bitfeld |
Gesendet an: alle Spieler, die jemanden zum Feind deklariert haben
Dieser Datensatz wird an jeden Spieler gesendet, der mit dem Befehl enemies add andere Spieler als seine Feinde deklariert hat. Mit diesem Eintrag wird der aktuelle Zustand übermittelt, als Erinnerung für den Spieler. Der Datensatz besteht aus einem Wort, welches pro Spieler ein Bit enthält:
bit 0 (1) | unbenutzt |
bit 1 (2) | Spieler 1 |
bit 2 (4) | Spieler 2 |
... | ... |
bit 11 (2048) | Spieler 11 |
Jedes Bit ist 1, wenn du mit den entsprechenden Spieler als Gegner definiert hast. Das niederwertigste Bit und die Bits 12 bis 15 sind unbenutzt und haben den Wert 0.
Datensatz 55 - Produktionsbericht | Seit: PHost 3.4k / 4.0i |
word Ship Id word Cargo Type (0-7) word How Produced (0-3) word Amount Produced |
Gesendet, wenn: ein Schiff hat etwas produziert
Gesendet an: Besitzer des Schiffes, sowie Remote-Control-Besitzer
Es gibt eine Anzahl Schiffsfunktionen, Missionen und Kommandocode-Aktionen, mit denen ein Schiff Dinge produziert. Mit diesem Eintrag wird der Erfolg gemeldet.
Das Feld Cargo Type enthält die Art des produzierten Materials:
0 | Neutronium. Neutronium wird von Ramscoop- und Raffinerie-Schiffen produziert. |
1 | Tritanium. Tritanium wird von Alchemieschiffen produziert. |
2 | Duranium. Duranium wird von Alchemieschiffen produziert. |
3 | Molybdenum. Molybdenum wird von Alchemieschiffen produziert. |
4 | Kolonisten. Momentan nicht verwendet. |
5 | Supplies. Momentan nicht verwendet. |
6 | Geld. Geld entsteht auf Spielschiffen. |
7 | Torpedos/Raumjäger. Diese werden mit den Kommandocodes lfm und mkt sowie den Missionen Gather-build fighters, Build fighters, Gather-build torpedoes und Build torpedoes from cargo hergestellt; außerdem bauen Rebel-Schiffe automatisch Raumjäger. |
Das Feld How Produced erläutert, was zur Produktion verbraucht wurde:
0 | Die produzierten Dinge waren gratis (Ramscoop). |
1 | Das Schiff hat Ressourcen aus seinem Frachtraum verbraucht (z.B. Alchemie). |
2 | Das Schiff hat Ressourcen des Planeten, den es umkreist, verbraucht (z.B. Gather-build torps). |
3 | Das Schiff hat sowohl Ressourcen aus seinem Frachtraum, als auch Ressourcen des Planeten verbraucht (z.B. lfm). |
Datensatz 56 - Reparatur-Bericht | Seit: PHost 3.4k / 4.0i |
word Ship Id word Reason (0-4) word Repair Unit Id word Damage Repaired word Crew Given |
Gesendet, wenn: ein Schiff wurde repariert
Gesendet an: Besitzer des Schiffes, sowie Remote-Control-Besitzer
Dieser Datensatz wird gesendet, wenn ein Schiff irgendwie repariert wurde. Er beschreibt den Umfang der Reparaturen. Wenn eine andere Einheit an der Reparatur beteiligt war, wird sie hier ebenfalls identifiziert.
Reason | Repair Unit Id | Aktion |
0 | 0 | Reparatur mittels Vorräten (Supplies) |
1 | Planeten-Id | "Fix"-Anweisung einer Sternenbasis |
2 | 0 | Mission Self Repair |
3 | Planeten-Id | Mission Super Refit |
4 | Schiffs-Id | Mission Repair Ship |
Datensatz 57 - Schiffsfunktionen | Seit: PHost 3.4k / 4.0i |
word Function Id word Basic Function word Experience Level Mask |
Gesendet, wenn: es gibt stufenbegrenzte Schiffsfunktionen
Gesendet an: alle Spieler
Dieser Eintrag gibt die Nummern an, die PHost für modifizierte Schiffsfunktionen in Eintrag 52 verwendet. Das Feld Function Id enthält die Nummer, die in Eintrag 52 auftaucht 52 (z.B. 65). Das Feld Basic Function ist die zugrundeliegende Schiffsfunktion, zum Beispiel 10 für AntiCloak. Das Feld Experience Level Mask enthält ein Bitfeld mit all den Erfahrungsstufen, auf denen das Gerät funktioniert. Bit 0 bezeichnet dabei die Basis-Stufe, Bit 1 bezeichnet Stufe 1, und so weiter.
Jeden Zug werden die Zuordnungen an alle Spieler gemeldet. Während eines Zuges sind die Zuordnungen konstant, können sich aber zwischen Zügen ändern.
Falls ein künftiger PHost neue Modifikatoren einführt, wird dieser Datensatz erweitert um auch die neuen Definitionen zu übermitteln.
Dieser Abschnitt enthält Informationen für Entwickler von Programmen, die Daten vom Host an die Spieler senden wollen.
Addon-Programme können ihre eigenen Daten in utilX.dat schreiben. Es ist dem Programm freigestellt, welche Informationen es schreibt, du kannst neue Datensätze einführen, wenn du magst. Um Kollisionen zu vermeiden, kannst du die einen Bereich Datensatz-Nummern reservieren. Kontaktiere dazu die PHost-Gruppe. Momentan sind folgende Bereiche reserviert:
Bereich | Zugewiesen an |
---|---|
0 - 16383 (0x0000-0x3FFF) | PHost |
16384 - 16399 (0x4000-0x400F) | Torsten Czerny |
16400 - 16431 (0x4010-0x402F) | Jens Hofbauer |
16432 - 16447 (0x4030-0x403F) | Rafael Alvarez |
16448 - 16479 (0x4040-0x405F) | Sven Bursch |
16480 - 16511 (0x4060-0x407F) | Ingo Korb |
16512 - 16639 (0x4080-0x40FF) | Stefan Reuther |
16512 - 32767 (0x4100-0x7FFF) | frei |
32768 - 65535 (0x8000-0xFFFF) | reserviert -- nicht verfügbar |
Um Daten in eine utilX.dat aufzunehmen, schreibe sie einfach in utilX.ext. Wenn PHost die endgültige utilX.dat erstellt, hängt er die utilX.ext automatisch an. Dies passiert in Phase 3 des Hostlaufes (während der Erzeugung der utilX.dat). Beispielsweise hängt PHost den Inhalt der util1.ext, falls diese im Spielverzeichnis existiert, an die util1.dat an, nachdem er seine eigenen Daten geschrieben hat. Danach wird die util1.ext gelöscht.
Es ist deine Aufgabe, beim Schreiben der utilX.ext auf
Plattformunabhängigkeit (Datenfeld-Größen, Endianness) zu achten.
Versuche nicht, Clients durcheinander zu bringen, erzeuge keine
Datensätze größer als 32k, und verwende die PHost-Einträge nicht für
Dinge, für die sie nicht zuständig sind. PHost überprüft den
Inhalt der utilX.ext nicht.
Der Inhalt von utilX.ext kommt immer nach den normalen PHost-Meldungen. Das ist nicht immer erwünscht, insbesondere, wenn du einen Host-Schritt ersetzt. Wenn du beispielsweise den Befehl give extern behandelst, sollten die Einträge zu Schiffsübergaben vor den Einträgen zu Kämpfen kommen, um Programme, die Protokoll über die Besitzer eines Schiffes führen, nicht durcheinander zu bringen.
Um dies zu erreichen, kannst du auch in util.tmp statt utilX.ext schreiben. PHost sammelt Einträge in util.tmp, bevor die endgültigen utilX.dat erstellt werden.
Jeder Eintrag in util.tmp hat folgendes Format:
word Receiver (1..11) word Record Type word Data Size byte[N] Data |
Hierbei ist Receiver der Empfänger des Datensatzes, der Rest entspricht den Informationen aus utilX.dat.
Zusätzlich zu den General Object-Datensätzen gibt es eine weitere Möglichkeit namens Ufos, mit der man Spielern Objekte anzeigen kann.
Diese Methode wurde mit HOST 3.20 und Winplan 3.5 eingeführt. PHost unterstützt diese Ufos ebenfalls.
Um den Spielern ein Objekt anzuzeigen, schreibst du es einfach in ufo.hst, PHost erledigt den Rest.
ufo.hst besteht aus 100 oder 1000 Einträgen des folgenden Formats:
word Color (0..15) char[20] Name char[20] Info Text 1 char[20] Info Text 2 word Location X word Location Y word Speed (0..15) word Heading (-1..359) word Planet Scan Range (1..5000) word Ship Scan Range (1..5000) word Radius word Object Type |
Das Feld Color ist von Null verschieden, wenn dieser Ufo-Eintrag verwendet wird. Es gibt die Farbe an, in der das Ufo auf der Sternkarte angezeigt wird. Dabei werden die normalen VGA-Farben verwendet:
Nummer | Farbe | Nummer | Farbe |
---|---|---|---|
0 | Schwarz #000000 | 8 | Hellgrau #555555 |
1 | Blau #0000AA | 9 | Hellblau #5555FF |
2 | Grün #00AA00 | 10 | Hellgrün #55FF55 |
3 | Türkis #00AAAA | 11 | Helltürkis #55FFFF |
4 | Rot #AA0000 | 12 | Hellrot #FF5555 |
5 | Magenta #AA00AA | 13 | Rosa #FF55FF |
6 | Braun #AAAA00 | 14 | Gelb #FFFF55 |
7 | Hellgrau #AAAAAA | 15 | Weiß #FFFFFF |
Die Scan Range-Felder geben an, aus welcher Entfernung ein Planet bzw. Schiff dieses Objekt sehen kann. Der Host wertet diese Felder aus und filtert die Datei entsprechend.
Der Object Type gibt den Typ des Objektes an. Deine Programme sollten nur Einträge nutzen, die sie kennen, oder die noch frei sind.
PHost sendet Spielern auch Ufos mit Wurmlöchern, mit Id-Nummern beginnend bei WormholeUFOsStartAt. Alle Ufos in diesem Bereich werden dadurch ausgeblendet.
Vorteile: Ufos funktionieren mit HOST und PHost. Viele Client-Programme unterstützen Ufos. Bekannte Programme sind unter anderem EchoView, PCC, VPA, sowie natürlich Winplan. Ufos sind einfach zu handhaben.
Nachteile: General Objects sind flexibler, da hier der Addon-Autor entscheiden kann, wer das Objekt sieht. Außerdem können mit diesen Objekten zusätzliche Informationen übertragen werden.
utilX.dat wird Subraumnachrichten nicht ersetzen, Spieler wollen immer noch lesen. Damit Client-Programme Nachrichten mit Sternkarten-Positionen in Verbindung bringen können, sind sie seit HOST 3.20 mit Kennungen (message tags) versehen. PHost benutzt diese teilweise seit Version 2.6, und verwendet sie durchgehend seit 3.3b.
Die Kennung steht am Anfang der ersten Zeile der Nachricht und sieht so aus:
(-pc086)<<< Distress Call >>> |
Das Minuszeichen gibt an, dass die Nachricht aktuell ist. Dort könnte auch ein o für eine Nachricht aus einem früheren Zug stehen (vgl. DeleteOldMessages, von PHost noch nicht unterstützt).
Der erste Buchstabe (p) enthält die Art der Nachricht. In diesem Fall ist es eine Planeten-Nachricht.
Die zweite Stelle enthält eine Zahl oder einen Buchstaben, der weitere Informationen enthält.
Die letzten Ziffern geben die Id-Nummer des Objektes an, auf das Bezug genommen wird. Üblicherweise sind das drei Ziffern, es können aber auch mehr oder weniger sein.
Hier sind alle bekannten Nachrichten-Kennungen:
Kennzeichnung | Bedeutung |
---|---|
(-90xxx) | Rassenspezifische Mission. Hiss, Dark Sense: xxx ist eine Planeten-Id. Rob: xxx ist eine Schiffs-Id. |
(-a0xxx) | Nachricht von Addon. xxx ist die Kennung des Addons. Wird von PHost nicht verwendet, jedoch von einigen Addons. |
(-c0xxx) | Das Tim Continuum greift Planet #xxx an, oder Nachricht über PBPs. Wird von PHost nicht verwendet, PHost nutzt dafür (-h). |
(-dRxxx) | Nachricht von Sternenbasis #xxx (Basis gebaut, Schiff gebaut oder verschrottet). Wenn ein Schiff übernommen wird, ist R dessen originaler Besitzer (1..9, a, b), sonst ist R 0. |
(-e0xxx) | Notruf von Schiff #xxx. |
(-f0xxx) | Schiff oder Planet #xxx zerstört oder gekapert. In PHost ist xxx immer eine Schiffs-Id. |
(-g0000) | HConfig. Von PHost nicht verwendet. |
(-h0000) | Nachricht vom Host. |
(-i0xxx) | Ionensturm #xxx. Von PHost nicht verwendet. |
(-l0xxx) | Minenfeld #xxx gelegt. |
(-m0xxx) | Minenfeld #xxx gescannt/geräumt. |
(-n0xxx) | Abgefangene Nachricht vom Gegner: Schiff #xxx hat eine Mine getroffen, oder Planet #xxx wird mittels Pillage/RGA bearbeitet. |
(-pRxxx) | Nachricht von Planet #xxx. R kann das Volk der Eingeborenen (1..9) enthalten, wenn die Nachricht dieses betrifft, c, wenn die Nachricht Kolonisten betrifft, ansonsten Null. |
(-rX000) | Nachricht von Spieler X (1..9, a, b). X kann fehlen oder 0 sein, wenn die Nachricht anonym gesendet wurde. |
(-s0xxx) | Nachricht von Schiff #xxx. #xxx ist 0 wenn das Schiff nicht länger existiert (Glory Device). |
(-t0xxx) | Terraforming-Status für Planet #xxx. |
(-uxxxx) | Nachricht über Ufo #xxxx. Wird von PHost 4.0e und neuer für Wurmloch-Scans benutzt. Wird nicht von allen Clients unterstützt. |
(-w0xxx) | Fangminen haben Schiff #xxx leergesaugt. |
(-x0xxx) | Explosion auf den Langstreckensensoren (#xxx = laufende Nummer der Explosion). |
(-y0xxx) | Meteor auf Planet #xxx. |
(-z0xxx) | Scannerbericht für Planet #xxx. |
Letzte Aktualisierung 23 January 2005.