Spartac V2.1: Format der Karten-Dateien

© Axel Rogat, 24-Jul-2009

Dieses Dokument ist gedacht für Spartac-Benutzer, die eigene Karten zu Spartac erstellen möchten. Die Kenntnis des Datenformats ist für die reine Anwendung des Programms mit fertigen Karten nicht notwendig.

• 0 Einleitung
  • 0.1 Koordinatensystem
  • 0.2 Koordinaten-Verschlüsselung
  • 0.3 Kochrezept
  • 0.4 Beispiele
• 1 Grundsätzliches
  • 1.1 Dateikopf
  • 1.2 Tags
  • 1.3 Unterelemente vs. Attribute
  • 1.4 Attribut-Typen
  • 1.5 Konventionen
• 2 Kartendateien
  • 2.1 <prmap>
  • 2.2 Allgemeine Objekte
    • 2.2.1 <comment>
  • 2.3 Marker
  • 2.4 <system>
    • 2.4.1 <sun>
    • 2.4.2 <planet>, <moon>
  • 2.5 <galaxy>
  • 2.6 <ellipsoid>, <sphere>
  • 2.7 <line>
  • 2.8 <phase>
  • 2.9 <scenery>
  • 2.10 <clusters>
  • 2.11 <label>
  • 2.12 <script>
• 3 Bibliotheken, <library>
  • 3.1 Anlegen einer Bibliothek
  • 3.2 Ansprechen einer Bibliothek in der Kartendatei
  • 3.3 Referenzieren von Objekten aus Bibliotheken
  • 3.4 Systeme aus .prsys-Dateien
• A Anhang: Farbnamen

Die eigentliche Programmdokumentation befindet sich in Manual.html.

Wenn ihr interessante eigene Karten erstellt habt, bitte schickt sie mir doch zu (Adresse ganz am Ende des Dokuments)!

Vorausgesetzt werden grundlegendste Kenntnisse in 3D-Geometrie und im Verfassen von Texten mit einem Texteditor ;-)   HTML-Kenntnisse helfen, sind aber nicht erforderlich.

Das verwendete 3D-Koordinatensystem ist ein (orthogonales) Rechts-System. Bei Galaxienkarten sollte der Mittelpunkt im Ursprung, bei Karten zu Spiralgalaxien die Galaxis-Ebene (in etwa) in der x/y-Ebene liegen. Normalerweise wird als Einheit das Lichtjahr verwendet, und das Programm gibt alle Distanzen in Lichtjahren aus. Wenn eine andere Einheit (z.B. Parsec oder AU) verwendet wird, kann mit dem <prmap>-Attribut scale eine automatische Umrechnung vorgenommen werden (siehe Abschnitt 2.1).

In der Milchstraßenkarte hat Dengejaa Uveso (das Schwarze Loch im Zentrum) die Koordinaten (0,0,0). Das Koordinatensystem ist so gewählt, dass die positive x-Achse genau durch Sol verläuft. In der PR-Serie wird der Einfachheit halber angenommen, dass Sol exakt in der Milchstraßenebene liegt, so dass diese mit der x/y-Ebene (z=0) zusammenfallen kann. Terra hat exakt die Koordinaten (30000,0,0), obwohl neuere Messungen in der Realität eher einen kleineren Abstand zum Zentrum finden (ca. 28000).

Die West-Richtung ist per Definition die positive x-Richtung (Richtung Sol/Terra), Osten die negative x-Richtung (in etwa Richtung Verth/Gatas). Norden ist in positive y-Richtung, Süden in negativer. Die Ebene ist in Quadranten nach Himmelsrichtungen aufgeteilt (Überlappung auf Grenzlinien):

Arkon mit den Koordinaten (16728, -23632, 20528) liegt mithin über dem Nordwesten der Milchstraße, über der Northside. (Am Rande: Im arkonidischen Koordinatensystem verläuft die positive x-Achse durch Arkon, der Ursprung ist ebenfalls im Milchstraßenzentrum, so dass die Milchstraßenebene »schräg« im System liegt.)

Die Positionen von stellaren Objekten sind in den Dateien immer als Koordinaten-Tripel x,y,z mit Komma getrennt anzugeben, z.B. position="16728,-23632,20528", Leerraum erlaubt. Es muss immer ein Dezimal-Punkt (kein -Komma) verwendet werden.

Winkel (Kamerawinkel, Drehwinkel von Ellipsoiden etc.) können in Grad (mit nachgestelltem °) oder normalerweise im Bogenmaß (Radian) angegeben werden, also 360° = 2π (Pi, mit π = 3.14159265358...).

Die meisten Koordinaten sind geistiges Eigentum und © Rainer Castor, und Rainer möchte momentan noch nicht, dass sie im Klartext veröffentlicht werden. Sie erscheinen daher in den Karten-Dateien verschlüsselt, etwa als Attribut wie folgt:

Ich bitte ausdrücklich darum, nicht zu versuchen, diesen Code zu entschlüsseln! Koordinaten eigener Objekte stehen in eigenen Dateien natürlich im Klartext.

Wenn bekannte Systeme in eigenen Karten verwendet werden sollen, kann man das durch eine Inkludierung aus einer Bibliothek erledigen. Die kodierten Koordinaten (und andere Angaben) brauchen also nicht in die eigene Karte kopiert zu werden (siehe die Beispiele in Abschnitt 0.4 und Abschnitt 3).

Dieser Abschnitt ist für alle Leute gedacht, die sich (zunächst) nicht mit den Details der Karten-Definitionen herumschlagen möchten. Die beste Methode ist da (wie so oft): abgucken. Am besten eine kleine Karten-Datei kopieren, fast alles herauslöschen und den eigenen Wünschen anpassen, was übrigbleibt.

Eine Karten- bzw. Bibliotheksdatei ist eine XML-Datei, besteht also im Wesentlichen aus verschachtelten Elementen, die durch »Tags« begrenzt werden, wie sie vielleicht schon aus HTML bekannt sind (<B>fetter Text</B> etc.). Die Namen der Tags und Attribute sind englisch gewählt (sorry, Gewohnheit), die Bedeutung sollte sich in fast allen Fällen von selbst erschließen.

• Jede Datei beginnt mit einer Header-Zeile (<?xml ...), die zwar entfallen kann, wodurch die Datei dann aber von anderen Programmen möglicherweise nicht mehr als XML akzeptiert wird. Also: stehenlassen.
   
• Danach kommt ein XML-Kommentar (<!-- ... -->) mit Dateiname und Kurzbeschreibung. Hieraus holt sich z.B. das Lade-Display den Text für die zweite Spalte der Dateiliste. Also: geeignet ersetzen.
   
• Danach kommt der eigentliche Karteninhalt zwischen <prmap> und </prmap>. Diese Tags stehenlassen. Als Attribute sind dort z.B. Zentrum der Karte, Radius des darzustellenden Bereichs, etc. angegeben (diese natürlich den eigenen Vorstellungen anpassen). Die meisten Attribute sind optional und werden mit Standardwerten belegt, wenn man sie nicht angibt.
   
• Zwischen diese beiden Tags gehört der eigentliche Inhalt, hauptsächlich eine Folge von <system>- und <galaxy>-Tags. Innerhalb eines <system>-Tags werden Sonnen und Planeten mit <sun>- bzw. <planet>-Tags definiert, innerhalb eines <planet>-Tags Monde mit dem <moon>-Tag. Am besten ein Element (z.B. aus Milchstraße.prlib) übernehmen, das möglichst viele Angaben realisiert, und mit diesen experimentieren.
   

• Um bekannte Systeme aus Bibliotheken zu übernehmen, reicht die Angabe <system lookup="Systemname" /> bzw. <galaxy lookup="Galaxienname" />. Systeme werden hier auch über Planeten- oder Mond-Namen und Galaxien über Katalognamen wie »M 13« gefunden. Die Bibliothek, in der die eigentlichen Daten stehen, muss weiter oben mit der Angabe <library file="Bibliotheksname.prlib" /> geöffnet worden sein.

  Die Daten aus der Bibliothek können durch eigene Angaben »überschrieben« werden. Beispielsweise erscheint mit <system lookup="Blaues System" color="red" /> das Blaue System nicht mehr blau, sondern rot. Genauso kann man mit comment eigene Kommentare hinzufügen, etc.

  Beachte: Die Systeme Sol und Arkon sind in eigenen Dateien definiert und werden mit <system file="Sol.prsys" /> etc. eingebunden.

(Fast) überall sind XML-Kommentare <!-- ... --> zur eigenen Orientierung erlaubt, die Spartac ignoriert.

Die XML-Korrektheit einer Karte kann man z.B. überprüfen, indem man sie in den Internet Explorer zieht, der bei syntaktischen Fehlern abbricht und eine entsprechende Meldung an den Schluss setzt.

Beispiel 1: Wir definieren eine Karte mit einem einzigen neuen System.

Wenn die Karte noch Syntax-Fehler enthält (falsche Verschachtelung, Kommentar nicht geschlossen) oder andere Fehler auftreten (System in keiner Bibliothek gefunden), meldet Spartac dies in einem Fenster. Die Zeilenangabe bezieht sich dabei immer auf die Zeile, in der das Tag beginnt, das den Fehler enthält. Dann editiert man die Karten-Datei und versucht es erneut; Spartac braucht dazu natürlich nicht verlassen zu werden.

Beispiel 2: Die folgende kleine Karten-Datei stellt die wichtigsten Blues-Systeme in der Westside dar.

Beispiel 3: Mit <line>-Tags definiert man Linien (z.B. für Reiserouten), mit <sphere>-Tags Kugeln (z.B. für Einflussbereiche von Kosmonukleotiden) und mit <ellipsoid>-Tags Ellipsoide (z.B. zum Herumlegen um Spiralgalaxien).

Das folgende kurze Beispiel zeichnet die vier großen Galaxien der Lokalen Gruppe als Objekte, mit umschließenden Volumina und allen 6 Verbindungslinien in verschiedenen Farben. Die Farbnamen sind genau die, die auch die meisten Web-Browser akzeptieren (Liste im Anhang).

Das sollte schon für erste Experimente reichen. Im Rest des Dokuments ist der Aufbau der Dateien in allen Einzelheiten beschrieben.

Mit Spartac Version 2.0 wurden die Karten-Dateien vom internen Binärformat auf ein XML-ähnliches Format umgestellt. XML ist sehr gut dafür geeignet, Daten, die hierarchisch verschachtelten Datentypen entsprechen, systemunabhängig darzustellen. Es wird so allen Benutzern ermöglicht, mit einem einfachen Texteditor (oder auch XML-Editor) eigene Karten zu erstellen. Außerdem lassen sich so die Daten bei Bedarf besser in andere Programme (und sogar auf anderen Systemen) importieren.

Um Karten zu erstellen, sind keinerlei Vorkenntnisse in XML notwendig. Dieses Dokument ist auch keine formale Einführung in XML, sondern beschreibt nur informell den Dateiaufbau, soweit es zur Erstellung eigener Karten notwendig ist. XML-Dateien sind reine Textdateien. Die Syntax von XML ist HTML-ähnlich und sollte jedem bekannt vorkommen, der einmal »zu Fuß« ein Web-Dokument erstellt hat.

Bemerkung: Spartac-Dateien (Karten-Dateien, Bibliotheken und die Konfigurationsdatei spartac.prcfg) sind »well-formed XML documents« im Sinne der XML-Definition (siehe bei www.w3.org). Die Dokumente sind für sich aber nicht »valid«, da keine DTD (document type declaration, eine Art Grammatik zur Interpretation des Inhalts) mitgeliefert wird, sondern die entsprechende Interpretation fest in Spartac eincodiert ist. Spartac verspricht nicht, beliebige XML-Dateien verarbeiten zu können, nur solche, die den weiteren Beschreibungen in diesem Dokument genügen! Insbesondere werden keine DTD-Deklarationen wie <!ELEMENT>, <!ATTLIST>, <!DOCTYPE> und keine <![CDATA[...]]>-Sektionen unterstützt.

Die Dateien haben nicht die Endung .xml, da sie bei Spartac in unterschiedlichen Zusammenhängen verwendet werden und die Art der Datei bereits am Namen ablesbar sein soll, ohne dass in die Datei hineingeschaut werden muss. Die Endungen sind .prmap für die eigentlichen Karten-Dateien (die einzigen Dateien, die Spartac momentan direkt lädt), .prlib für Bibliotheken (eine Art Include-Dateien), .prsys für Beschreibungen eines einzelnen Systems (gesondertes Format, gedacht für spätere Spartac-Erweiterungen) und .prcfg für die Konfigurationsdatei spartac.prcfg. Wenn man eine Datei z.B. in einen Browser wie Firefox oder den Internet Explorer zieht, erkennt dieser aber die Datei trotz Endung als XML und zeigt sie entsprechend formatiert als Quelltext an.

Zu Beginn jeder Spartac-Datei erscheint ein XML-Prolog, der die verwendete XML-Version und die Zeichencodierung enthält, und der am besten in jeder Datei so übernommen wird. Erlaubt sind momentan ISO-8859-1 (alte mitteleuropäische Kodierung, also mit Vokalen mit Akzenten etc.) und ISO-8859-15 (dasselbe mit Euro-Zeichen), also z.B. nicht UTF-8.

Danach folgt per Spartac-Konvention ein Kommentar, der in der ersten Zeile den Namen der Datei wiederholt und danach eine Kurzbeschreibung enthält. Diese Beschreibung erscheint dann z.B. im Lade-Display von Spartac als zweite Zeile hinter dem Dateinamen. Damit beim Anzeigen dieses Displays nicht eine komplette XML-Interpretation aller Dateien durchgeführt werden muss, ist diese Beschreibung hier zu Beginn vor der eigentlichen XML-Struktur untergebracht. XML-Kommentare sind wie die typischen HTML-Kommentare aufgebaut; beispielsweise steht in Thatrix.prmap dort dies:

Der Kommentar darf durchaus länger sein, aber nur seine zweite Zeile erscheint im Lade-Display.

Daten im XML-Format bestehen aus verschachtelten Definitionen von »Elementen«. Wie in HTML wird die Definition eines Elements mit dem Namen name begonnen mit einem »Start-Tag« der Form <name> und beendet mit einem »End-Tag« der Form </name>. Anders als in HTML darf das End-Tag nicht entfallen, so dass eine korrekte Verschachtelung von Elementen immer gewährleistet ist. Wenn ein Element keine weiteren Elemente enthalten soll, können Start-Tag und End-Tag zusammengefasst werden in der Form <name/>. Groß- und Kleinschreibung ist signifikant, standardmäßig werden nur Kleinbuchstaben verwendet.

Alle momentan in Spartac-Dateien verwendeten Tags sind folgende:

<area>, <clusters>, <comment>, <config>, <continent>, <continents>, <ellipsoid>, <galaxy>, <issue>, <issues>, <keyword>, <keywords>, <library>, <line>, <moon>, <phase>, <planet>, <prmap>, <race>, <races>, <scenery>, <sphere>, <sun>, <system>, <systems>.

Im Start-Tag kann dem Element ein Satz von »Attributen« mitgegeben werden. Jedes Attribut besteht aus einer Zuweisung der Form attributname="wert". Anders als in HTML dürfen die Anführungszeichen nicht entfallen. Mehrere Attribut-Zuweisungen werden durch Leerraum getrennt. Auch hier ist Groß- und Kleinschreibung signifikant, zum Trennen von Wortbestandteilen verwendet Spartac hier gelegentlich einige Großbuchstaben, z.B. playSounds="true". Die Reihenfolge der Attribute ist völlig gleichgültig (auch bei Attributen wie lookup und file in Spartac), und jedes Attribut darf maximal einmal verwendet werden.

Wenn das Element einen Inhalt hat, steht zwischen Start-Tag und End-Tag eine Zeichenfolge, die eine Sequenz von Textstücken und weiteren Element-Definitionen ist, beispielsweise:  <tag1> text1 bla bla <tag2> text2 etc. </tag2> <tag3/> </tag1>

Zwischen den Tags ist beliebiger Leerraum (auch Zeilenumbrüche, Kommentare) erlaubt, je nach interpretierendem Programm kann dieser Leerraum dann aber im Ergebnis erscheinen. Spartac ignoriert momentan diese Leerräume. Besser lesbar (weil die Hierarchie widerspiegelnd) sieht obiges Beispiel also wie folgt aus:

Wenn im Text zwischen den Tags die Zeichen < > & vorkommen sollen, müssen sie als XML-Entities &lt; &gt; &amp; (less-than, greater-than, ampersand) geschrieben werden; das abschließende Semikolon ist erforderlich. Zusätzlich versteht Spartac auch (ohne XML-Deklaration) die Entities &laquo; («) und &raquo; (»), obwohl die Zeichen keine XML-Bedeutung haben und im ISO-Code direkt in der Datei erscheinen können.

Jede XML-Datei enthält genau eine äußere Element-Definition, niemals eine Folge mehrerer Elemente. Dieses äußere Element wird Root-Element genannt. Hinter seinem End-Tag sind noch Kommentare und einige XML-Definitionen erlaubt. Beachte: Spartac hört nach diesem End-Tag (nicht ganz XML-konform) auf, die Datei zu lesen. Dadurch kann man Teile einer Karte austesten, indem man das End-Tag mitten in die Datei schreibt und somit den Rest der Datei »ausblendet«

Jede der vier Datei-Arten von Spartac muss ein fest vorgegebenes Root-Element definieren:

Zwischen Start- und End-Tag des Root-Elements spielt sich also die eigentliche Definition der Daten ab.

Bei der Entwicklung des Formats erwies es sich als lesbarer, einige Dinge als Attribute statt als Unter-Elemente zu implementieren. Die Verschachtelung von Elementen entspricht nun fast immer der Verschachtelung physischer Objekte. Beispielsweise sind in die Karte Systeme eingeschachtelt, die Sonnen und Planeten einschachteln und Planeten Monde. Dagegen sind Eigenschaften wie Name, Atmosphäre, Gravitation etc. üblicherweise als Attribute abgebildet. Wir haben also NICHT

sondern mit Attributen Folgendes:

Möglicherweise wird in späteren Versionen die Tag-Version aber zusätzlich erlaubt werden.

Sowohl als Attribut wie auch als Unter-Element gibt es:

Genauso verhalten sich die geografischen Angaben cities, continents, mountains, streams und oceans bei Planeten. Alle Tags werden in den weiteren Abschnitten genauer beschrieben. Außer <comment> gibt es hier alle in Einzahl- und Mehrzahl-Version. Nach reiner XML-Philosophie sollte man nur die Einzahl-Versionen verwenden, was die Dateien aber sehr länglich macht. In den Mehrzahl-Versionen werden die Einzelteile durch Kommas getrennt; bei den Einzahl-Versionen ist es möglich, Kommas in den jeweiligen Begriff einzubauen. Kommentartexte, die HTML-Formatangaben wie Fettschrift enthalten, müssen immer als Elemente geschrieben werden!

In den folgenden Tabellen zu den jeweils erlaubten Attributen gibt es eine Spalte »Typ«, in der der Typ der Werte für das Attribut angegeben sind. Dabei bedeutet:

Ein Stern ^* hinter einem Argumentnamen bedeutet, dass die Angabe dieses Arguments für das jeweilige Tag zwingend erforderlich ist. Wenn nicht erforderliche Attribute nicht angegeben werden, erhält die Eigenschaft intern einen Standardwert oder wird als »nicht definiert« markiert.

Für die meisten astrophysikalischen Größen (Sonnenmasse, Umlaufzeit, Planeten-Durchmesser etc.) ist bei Spartac eine Default-Einheit festgelegt (Masse von Sol, Tage, Kilometer). Diese Einheit braucht in den Attribut-Werten nicht mit angegeben zu werden, d.h. dort erscheint eine einheitenlose Zahl. Es sind aber an allen sinnvollen Stellen die gängigen physikalischen Einheiten erlaubt:

An allen Stellen, an denen stellare Objekte angesprochen werden (z.B. home="Terra" im <prmap>-tag), werden sie über irgendeinen der beteiligten Namen gefunden, also Sonnensysteme über den Systemnamen oder über den Namen einer Sonne, eines Planeten oder eines Monds, Galaxien über den Eigennamen oder über eine Katalognummer wie »M 87« oder »NGC 3190«.

In Listen (in Attribut-Werten oder im Text zwischen Tags) werden die Einzelteile (»Wörter«) mit Kommas getrennt. Zu Beginn, am Ende und vor und nach den Kommas ist Leerraum erlaubt (zwischen Tags inklusive Zeilenumbrüche) und wird von Spartac ignoriert. Leerraum innerhalb eines Worts ist erlaubt und wird zu einem einzigen Leerzeichen zusammengezogen. Beispiele:

Die Wörter werden auch intern nicht alphabetisch sortiert und erscheinen ggf. in der angegeben Reihenfolge in der Ausgabe. Werden mehrere Listen zusammengehängt (z.B. bei mehrere keywords-Angaben), erscheinen die Listenteile in Reihenfolge der Tags bzw. der Bibliotheksangaben in der Datei.

Eine Kartendatei definiert nach dem Prolog genau ein <prmap>-Tag.

Als Attribute werden Eigenschaften wie Name und Copyright angegeben, ebenso Einstellungen (wie »Raster einzeichnen«), die dann die entsprechenden Einstellungen aus der Konfigurationsdatei überschreiben. Zu den Typen siehe Abschnitt 1.4.

Karten zu einer Galaxie (type="galaxy") und zu größeren Universums-Ausschnitten (type="universe") unterscheiden sich darin, dass im ersten Fall Objekte je nach Detailstufe und ihrer Priorität eingezeichnet werden oder nicht, während im zweiten Fall immer alle Objekte gezeichnet werden. Welche Objekte beschriftet werden, hängt dagegen in beiden Fällen von Priorität und Kamera-Abstand ab. Die Erweiterungen .spiral und .elliptic haben momentan keine Bedeutung; sie dienten in älteren Versionen zur Bestimmung der Art der zu zeichnenden Szenerie.

Als Unter-Elemente sind physische Unter-Strukturen implementiert, die wichtigsten sind sicher <system> und <galaxy>, die beliebig gemischt vorkommen dürfen. Alle Elemente sind in späteren Abschnitten ausführlich beschrieben.

Alle Elemente einer Karte sind als Datentypen intern in einer Klassenhierarchie implementiert, d.h. Unterklassen übernehmen Attribute und mögliche Unter-Tags von ihrer Oberklasse und fügen ggf. eigene hinzu.

Beispielsweise sind »Marker« Objekte, die in der Karte mit einer optischen Markierung dargestellt werden, spezielle Marker sind Sonnensysteme und Galaxien. Marker haben als Attribute Position, Farbe, etc., darin unterscheiden sich Systeme und Galaxien nicht. Wohl unterscheiden sie sich in anderen Attributen und Unter-Tags.

Die alleroberste Klasse überhaupt ist das allgemeine Spartac-Objekt. Auf dieser Ebene gibt es die folgenden möglichen Attribute bzw. Unter-Elemente:

In den Kommentaren sind folgende HTML-ähnliche Formatierungs-Angaben erlaubt:

Beim Info-Display kann im Kommentartext bei Leerraum, - und / ein automatischer Zeilenumbruch erfolgen.

Bei den Tag-Namen ist auch Großschreibung erlaubt; Start- und End-Tag müssen wegen der XML-Struktur aber gleich geschrieben werden. Die <b>- und <i>-Tags müssen geschlossen werden. Sie dürfen beliebig ineinander geschachtelt sein; fette Schrägschrift ist möglich. Der Inhalt des <comment>-Elements ist der einzige Ort in Spartac-Dateien, an dem diese Formatierungs-Tags erlaubt sind!

Kommentare sind erlaubt in <system>, <planet>, <moon>, <galaxy>; Bei anderen Objekten werden sie momentan mit einem Fehler abgewiesen.

Marker sind Objekte, die in den Karten als Symbole erscheinen, momentan (Sonnen-)Systeme (<system>) und Galaxien (<galaxy>). Ihre gemeinsamen Attribute und Unter-Tags werden hier aufgeführt.

Bemerkungen:

goto

In die Karten sind mittlerweile einige Galaxien aufgenommen, zu denen noch keine Positionsangabe vorliegt, die aber doch so wichtig sind, dass sie zumindest beim Suchen über das Suchfenster gefunden werden sollten. Ihr Info-Fenster erscheint dann in der linken oberen Bildschirmecke. Mit goto kann ein Ersatz-Objekt angegeben werden, zu dem eine Kamerafahrt erfolgt. Beispielsweise kennt man noch nicht die Position der Seth-Apophis-Galaxis Wethromoon, anstatt dessen wird in die (vermutlich nahe) Galaxis Sethdropoon geflogen. Dagegen kann bei Vayquost leider nirgendwohin geflogen werden, weil die Position "im Limbus zwischen ES und Seth-Apophis" zu vage ist.
 

image

Normalerweise wird bei der Anzeige des Info-Displays nach einer Datei gesucht, die so heißt wie das markierte Objekt (oder einer seiner Katalog-Namen). Hier kann ein Alternativ-Name angegeben werden, z.B. DaGlausch bei Salmenghest, da das Bild zu DaGlausch ohnehin beide Whirlpool-Galaxien darstellt.
 

marker

Mit dem Attribut marker gibt man ein ein- oder zweibuchstabiges Kürzel an, das Größe und Farbe der optischen Markierung bestimmt. Mit sizefactor und color können diese Werte bei Bedarf überschrieben werden (z.B. bei importierten Objekten). Beachte, dass in Universumskarten (z.B. mit Zugehörigkeiten zu Mächtigkeitsballungen) die Farben stattdessen aus der Liste des colors-Attributs des <prmap>-Tags übernommen werden! Wenn bei einem Sonnensystem marker und color nicht angegeben werden, wird die Farbe ggf. aus der Spektralklasse der ersten Sonne rekonstruiert (type-Attribut des ersten <sun>-Tags).
 
marker beeinflusst außerdem Typangabe im Info-Display und den Halo: Wird kein Type (type) angegeben, wird im Info-Display ein generischer Eintrag (»Spiralgalaxis« etc.) abhängig vom Marker angezeigt. Black Holes und Kosmonukleotide haben zusätzlich spezielle Halos mit Farbwechseln.
 

erlaubte Werte für das Attribut  marker
Kürzel	Bedeutung	Form	Farbe	Größe
?	unbekannt	Kugel	grau	normal
X	groß (Kugelsternhaufen in Galaxis)	Kugel	weiß	groß
*	kein System (Raumstation etc.)	Kugel	grau	klein
.	Dummy, Wegpunkt etc.	Kugel	grau	sehr klein
R	rote Sonne	Kugel	rot	normal
Gr	grüne Sonne	Kugel	grün	normal
B, Bl	blaue Sonne	Kugel	blau	normal
Y, Ge	gelbe Sonne	Kugel	gelb	normal
W, Wh	weiße Sonne	Kugel	weiß	normal
Or	orangerote Sonne	Kugel	orange	normal
BH	Black Hole	Kugel	schwarz	normal
E0, Sph	kugelförmige Galaxis	Kugel	weiß	normal
E*, Ell	elliptische Galaxis	Ellipsoid	weiß	normal
S	spiralförmige Galaxis	flacher Ellipsoid	weiß	normal
SB	Balkenspiralgalaxis	flacher Ellipsoid	weiß	normal
Ir	irregulärer Sternhaufen	unregelmäßig	weiß	normal
CN, KN	Kosmonukleotid	Kugel	weiß	normal
So	Sombrero (Gruelfin)	Ellipsoid + Ring	weiß	normal

 

priority

Ein Objekt mit Priorität n wird in Galaxienkarten (z.B. Milchstraße) von der Detailstufe n an aufwärts angezeigt (in Universumskarten werden immer alle Objekte angezeigt). Die Priorität beeinflusst in beiden Fällen, ab welcher Nähe zur Kamera das Objekt beschriftet wird. Die Start-Priorität beim Anzeigen einer Karte wird mit dem <prmap>-Attribut priority festgelegt (siehe Abschnitt 2.1).
 

rotate

Spiralgalaxien werden durch Ellipsoide angezeigt, die aus ästhetischen Gründen normalerweise etwas schräg zum Koordinatensystem rotiert dargestellt werden. Da die Milchstraße aber nun per Definition gerade genau in der x/y-Ebene liegt. Für solche Fälle setzt man rotate auf false.

 

upline

Auch zu den normalen (nicht-Fake-) Objekten sollen manchmal die Auflinien unterdrückt werden, wenn sie optisch mit Spezial-Linien »clashen«. Das geschieht z.B. in der Sonnentransmitter-Karte (Verbindungslinien) mit den besonders weit entfernten Objekten der Lokalen Gruppe.

Bemerkung:

issues

Die Einträge haben momentan noch kein vorgeschriebenes Format und werden unverändert in das Info-Display übernommen (im Abschnitt »siehe:« ganz am Ende). Man kann momentan nicht über Heftnummern nach Objekten suchen. Im Hinblick auf Kompatibilität mit späteren Versionen sollte man sich am besten in etwa an die folgenden Muster halten:

PR 1000, PR 1001-1099, PR 1100ff, PR 1105/06, AT 2, TB 415

Für die einzelnen Atlan-Miniserien sollte man Atlan-Centauri etc. schreiben - ich gebe aber die Hoffnung nicht auf, dass die alte Nummerierung wieder auflebt, spätestens kurz vor Atlan 1000 ;-)   Seitenzahlen sind im Moment noch nicht vorgesehen (vielleicht mit Klammern?).

Ein Sonnensystem wird durch das Tag <system> definiert. Es erscheint als Unter-Tag von <prmap> in Kartendateien oder von <library> in Bibliotheksdateien.

Da bei Mehrfach-Sternsystemen eventuell keine eindeutige Zuordnung eines Planeten zu einer der Sonnen besteht, werden die Planeten nicht der Sonne untergeordnet. Ein System braucht aber weder Sonnen, noch Planeten zu enthalten. Beispielsweise sind die beiden Quinto-Centers als <system> definiert, und die Hundertsonnenwelt enthält keine (!) Sonne, nur einen Planeten. (Wer gerne 100 <sun>-Tags einfügen möchte, nur zu!)

Dieses Element definiert eine Sonne im System und kann nur innerhalb eines <system>-Elements verwendet werden. Wenn nur die Anzahl der Sonnen, weitere Daten aber nicht bekannt sind, kann man entsprechend viele leere <sun>-Tags verwenden.

zu colorStr:

Nicht zu verwechseln mit dem RGB-Farbcode des Markers! Die Angabe ist nur notwendig, wenn type nicht angegeben wurde oder die Farbbeschreibung vom Standard abweicht (z.B. »grün« oder »lachsrot«). Die erste Angabe ist das nicht flektierte Adjektiv (»grün«), die zweite die geschlechts-, typischerweise auf »Sonne« bezogene Form (»grüne« für »grüne Sonne«). Wird die zweite Angabe ausgelassen, wird im Display die erste verwendet, was zu Grammatikfehlern führen kann.

zu type und colStr:

Im Info-Display wird der erste Großbuchstabe der Spektralklasse wie folgt zusätzlich in eine Farbbeschreibung umgewandelt (DWRNS werden nicht unterstützt):

O	blau	B	weißblau	A	weiß	F	weißgelb
G	gelb	K	orange	M	rot

Wenn eine genauere Farbbeschreibung gewünscht ist, kann sie in colorStr angegeben werden und hat dann Vorrang. Führende Kleinbuchstaben in type werden wie folgt umgesetzt:

g	Riesensonne (giant)
d	Zwergstern (dwarf)
sd	Unterzwerg (subdwarf)

Kleinbuchstaben am Schluss (sollten das Spektrum noch genauer beschreiben) werden ignoriert. Wenn type keiner Spektralklasse zu entsprechen scheint, wird der angegebene Text ohne Interpretation übernommen.

Wenn die Farbe des Markers eines Sonnensystems nicht durch marker oder color festgelegt wird, wird ggf. die Farbe aus den (angegebenen) Spektralklassen der Sonne im System rekonstruiert (momentan gleich gewichtet zusammengemischt).

Das <planet>-Element ist ebenfalls nur im Inneren eines <system>-Elements zu verwenden und definiert einen Planeten. Mögliche Monde erscheinen als Unter-Elemente <moon> in seinem Inneren.

Monde von Monden werden momentan nicht unterstützt: Sie können zwar so verschachtelt definiert werden, erscheinen aber nicht im ausführlichen Info-Display und werden nicht über das Such-Display oder beim Importieren aus Bibliotheken gefunden!

<moon> und <planet> haben identische Attribute und Unter-Elemente. Lediglich die Interpretation des Werts von distance (Abstand von der Sonne bzw. Abstand vom Planeten, mit anderen Einheiten) ist unterschiedlich!

Die Temperaturangaben können (wie die Oberflächentemperatur bei <sun>) die Suffizes "C", "°C" (Celsius) und "K" (Kelvin) besitzen; Default ist Celsius.

Beachte: Es brauchen nicht alle astronomischen Daten angegeben zu werden. Viele werden vom Programm aus physikalischen Zusammenhängen (näherungsweise) rekonstruiert, beispielsweise:

• mittlerer Abstand und Bahnexzentrizität aus Aphel und Perihel (1. Keplersches Gesetz, Ellipsen-Beziehungen)
• oder andersherum Aphel und Perihel aus Abstand und Exzentrizität
• Masse aus Durchmesser und Oberflächen-Gravitation (Gravitationsgesetz)
• oder andersherum Gravitation aus Masse und Durchmesser
• Umlaufzeit aus Abstand und Masse des Zentralkörpers (3. Keplersches Gesetz)
• oder andersherum Abstand aus Umlaufzeit und Masse des Zentralkörpers

Ebenso wird in einem Ein-Sonnen-System die Masse der Sonne aus den Distanzen und Umlaufzeiten der Planeten berechnet, sofern die Planetendaten einigermaßen dem 3. Keplerschen Gesetz gehorchen.

Als Unter-Tags werden geografische Details definiert, die im erweiterten Info-Display und im Such-Display erscheinen:

Beachte^*: Bei den beiden Listen zu <continents> und <oceans> darf das erste Wort eine positive ganze Zahl sein, die dann die Gesamtanzahl der Kontinente bzw. Ozeane angibt (sinnvoll, wenn nicht all deren Namen bekannt sind), etwa continents="6, Pront" (bei Gäa).

Mit dem <galaxy>-Tag werden Sternhaufen diverser Größen und Formen definiert. Enthaltene Systeme können nur dem Namen nach angegeben werden; weitere Details sind auf dieser Stufe nicht vorgesehen - dafür würde dann eine eigene Karte fällig. Wenn man einige Systeme genauer beschreiben will, hält einen aber nichts davon ab, gesonderte <system>-Elemente anzufügen, die dann aber keine interne Zugehörigkeit zum <galaxy>-Element besitzen.

Für das Attribut type werden folgende Werte automatisch erkannt und in der ausführlicheren Textform im Info-Display ausgegeben (nicht erkannte werden unverändert übernommen):

Mit den (gegenüber Marker neuen) Unter-Elementen werden in Kurzform namentlich Sonnen und Planeten angegeben, die dann im Info-Display aufgeführt werden. Im Such-Display kann die Galaxie über sie gefunden werden.

In einem Datensatz wird ein Name vor einem Schrägstrich als Systemname, einer nach einem Schrägstrich als Planet interpretiert (Monde können nur als Planeten angegeben werden). Sternhaufen, Wolken, etc. werden als Systeme angegeben. Jeder Satz hat eines der Formate

Leerraum vor und nach den Schrägstrichen ist erlaubt. Ein Satz darf auf einen Schrägstrich enden, z.B. um für den menschlichen Leser der Karten-Datei eine Sonne definitiv als solche zu kennzeichnen.

Beispiele: Point Ultra Kugelsternhaufen, Kimb/, Truhterflieng/Pröhndome, Thorrtimer/Thorrim/Cletternam, /Chircool

<sphere>, subdivisions=1

<sphere>, subdivisions=2

Ellipsoide sind - grob gesprochen - Kugeln, die in die 3 Koordinatenrichtungen unterschiedlich stark gestreckt oder gestaucht (und anschließend gedreht) sein können. Mit dem <ellipsoid>-Tag kann ein allgemeiner Ellipsoid, mit dem <sphere>-Tag als Abkürzung eine Kugel definiert werden, jeweils als Unter-Element des <prmap>-Elements.

Ellipsoide dienen zur Darstellung von Raumbereichen, etwa um in Universumskarten die Umrisse von Spiralgalaxien (flacher Ellipsoid) anzudeuten, oder um die Einflussbereiche von Kosmonukleotiden oder Superintelligenzen (Mächtigkeitsballungen) zu markieren.

Die Darstellung von Ellipsoiden kann per Menü bzw. mit dem <prmap>-Attribut showVolumes abgeschaltet werden. Die Ellipsoide werden als Drahtmodelle gezeichnet. Wenn ein Ellipsoid keinen anderen schneidet, wird zusätzlich seine Oberfläche halbdurchsichtig dargestellt (abstellbar per Menü bzw. mit dem <prmap>-Attribut showFilledVolumes). Die Feinheit der Unterteilung der Fläche in Dreiecke wird nicht im Ellipsoiden, sondern im <prmap>-Tag der jeweiligen Karte für alle Ellipsoide in der Karte festgelegt. In der Unterteilungsstufe 0 wird ein Ikosaeder gezeichnet (20 Dreiecke), für Stufe 1 wird jedes Dreieck in vier Unterdreiecke zerlegt, etc. bis maximal Stufe 5 (20480 Dreiecke), Default ist Stufe 3 (1280 Dreiecke).

<ellipsoid>, axes="3,2,1", rotation="0,0,0.78"

Zur Lage der Ellipsoiden:

Das Zentrum wird mit dem Attribut center definiert, die halben Achsenlängen (analog zu Radius = halber Durchmesser) mit dem Vektor axes (bzw. dem einem Wert radius bei der Kugel).

Außerdem kann ein Ellipsoid beliebig im Raum gedreht sein. Mit rotation werden 3 Winkel für die Rotation um die x-, y- und z-Achse angegeben. Es wird im mathematisch positiven Sinn (gegen den Uhrzeigersinn) gedreht, wenn man auf die positive Achse schaut.

Die richtigen Winkel zu bestimmen, kann manchmal etwas mühsam sein. Meistens sind die Ellipsoide aber sehr einfach ausgerichtet, etwa zigarrenförmig entlang einer bestimmten Raumrichtung. Daher kann man alternativ mit dem Vektor orientation eine solche Ausrichtung definieren: Die x-Achse wird in die durch orientation angegebene Richtung hineingehoben.

Beispiel: Wenn ein langer schmaler Ellipsoid die Punkte A und B »verbinden« soll, ist center der Mittelpunkt zwischen A und B, die x-Halbachse der halbe Abstand zwischen A und B, die anderen Halbachsen sind viel kürzer zu setzen. Als Orientierung nimmt man den Differenzvektor der Positionen von A und B.

Die Standard-Orientierung ist (1,0,0). Damit ergibt z.B. axes=(5,5,1) einen flachen Diskus in der x/y-Ebene, axes=(5,1,1) eine Zigarre entlang der x-Achse, etc.

Normalerweise wird entweder nur orientation oder nur rotation angegeben, die beiden können aber kombiniert werden; es wird dann zuerst rotation, dann orientation angewendet.

In der Legende für Volumina erscheint als Beschriftung der Name; mit dem Attribut label kann eine Alternativ-Beschriftung angegeben werden. So enden die Namen der Volumina in den Bibliotheken meist auf "Vol", um sie von sonst gleichnamigen Objekten zu unterscheiden (z.B. <galaxy> "Milchstraße" vs. <ellipsoid> "Milchstraße Vol").

Außerdem wird bei Universumskarten im Info-Display eines Systems, das innerhalb eines Ellipsoiden liegt, der Name bzw. das Label des Ellipsoiden als »Einflussbereich« aufgeführt (abstellbar in der Kartendatei mit infoInfluence="off"). Wenn ein System in mehreren Ellipsoiden gleichzeitig liegt, wird der Name des Ellipsoiden mit dem kürzeren Mittelpunkts-Abstand angezeigt. Außerdem lassen sich Ellipsoide über den Namen aus Bibliotheken importieren.

Bei Bedarf kann man Ellipsoide nur in bestimmten Phasen sichtbar werden lassen, siehe dazu Abschnitt 2.8.

In den Standard-Bibliotheken werden die Volumen-Objekte von gleichnamigen stellaren Objekten durch ein Anhängsel "Vol" unterschieden.

Das <line>-Tag (als Unter-Tag von <prmap>) dient zum Einzeichnen einzelner Linien in die Karte, beispielsweise als Reiseroute, Transmitterverbindung, etc.

Diese Art von Linien lässt sich in Spartac momentan nie abstellen. Man kann aber wie bei Ellipsoiden festlegen, dass eine Linie nur in einer bestimmten Phase erscheint (siehe Abschnitt 2.8) - so ist beispielsweise in PR-Universum.prmap die Verbindung Mahlstrom-Erranternohre-Milchstraße-Algstogermaht auf Phase 2 beschränkt (durch F9 ein/ausschaltbar).

Die Linien werden von der Engine momentan nicht am vorderen Ende des Sichtbereichs geclippt, d.h. bei sehr langen Linien kann es passieren, dass DirectX sie nicht mehr zeichnet, wenn einer der beiden Endpunkte zu weit hinter dem Beobachter liegt. Mit dem Attribut subdivisions wird dafür einfach die Linie in Teilstücke zerlegt. (Mag in zukünftigen Versionen von Spartac überflüssig werden.)

from und to sind natürlich vollständig austauschbar. name kann vergeben werden, wird aber nicht verwendet (insbesondere sind Linien nicht aus Bibliotheken importierbar.)

Eine Karte kann einen zeitlichen Ablauf in mehreren Phasen darstellen, zwischen denen mit F9 (eine Phase vorwärts) und Shift-F9 (rückwärts) hin- und hergeschaltet werden kann. Der Ablauf kommt dadurch zustande, dass einige Objekte nur in bestimmten Phasen sichtbar sind; es gibt also keine wirkliche Bewegung.

Die Anzahl der Phasen wird im <prmap>-Attribut phases festgelegt, die Phasen sind von 1 bis phases nummeriert. Auf die obige Art schaltbare Objekte heißen Phasenobjekte; momentan sind das genau <ellipsoid> (und <sphere>) und <line>. Sie geben in ihrem Attribut phase eine Liste von den Phasen an, in denen sie sichtbar sein sollen: Ein Eintrag in der Liste ist eine einzelne Phasennummer oder ein Bereich phase₁-phase₂, beispielsweise:

Objekte ohne phase-Definition sind in allen Phasen sichtbar.

Die Szenerie (der »Sternenstaub« und die »Sternwolken«) werden über <scenery>-Objekte definiert. Im Objekte wird das Zentrum eines Sternenstaub-Bereichs, seine Form, Größe und Dichte (gestaffelt in drei Bereichen) definiert. Die eigentlichen Sterne und Wolken werden während des Programmablaufs zufällig und von der momentanen Szeneriestufe abhängig erzeugt.

Es gibt vier Formen von Szenerie-Objekten:

Die Szenerie-Objekte der Typen disk, ellipsoid und sphere dürfen keine Unter-Elemente haben. Bei der Szenerie ohne Typ-Angabe steht zwischen Start- und End-Tag eine Liste von x/y/z-Koordinaten von kleinen Sternenballungen - und zwar ausnahmsweise ohne trennende Kommas.

Bei discrete werden immer kleine achsenparallele Ellipsoide gefüllt, deren Halbachsen mit variation festgelegt werden.

Beispiele (bis auf die Koordinatenliste aus Milchstraße.prlib):

In den Standard-Bibliotheken werden die Szenerie-Objekte von gleichnamigen stellaren Objekten durch ein Anhängsel "Sz", bzw. "Sz2" etc. unterschieden.

Das <clusters>-Tag existiert im Moment allein für die Dommrath-Karte, kann aber natürlich bei Bedarf auch in anderen Karten verwendet werden. Wie beim normalen Raster wird der Kreis in der x/y-Ebene um den Mittelpunkt und mit dem Radius der Karte in Quadrate unterteilt; der Linienabstand wird dem <prmap>-Attribut rasterWidth entnommen. Es wird aber zusätzlich ein Cluster-Würfel der Kantenlänge rasterWidth oberhalb der Ebene über das Quadrat gezeichnet, über dem sich der Mauszeiger befindet. (Praktischerweise liegen alle bekannten Systeme Dommraths in diesem Bereich der »Cluster-Ebene 1«.)

Beachte:

• Das <clusters>-Tag ist optional; fehlt es, werden die Cluster von 0 aufsteigend (zeilenweise in der obigen Orientierung) nummeriert, zeilenweise von Süden nach Norden, innerhalb einer Zeile von Osten nach Westen (diese Nummerierung stammt so aus den Dommrath-Daten, sorry).
   
• Es sind momentan nur (nicht-negative ganze) Zahlen, keine beliebigen Beschriftungen der Cluster-Würfel möglich. Die Beschriftung ist immer vierstellig mit führenden Nullen (es sei denn, die Cluster-Nummer hat mehr als vier Stellen),

Die Anzahl Quadrate in einer Richtung ergibt sich automatisch als 2*radius/rasterWidth, sie muss aber zum Einzeichnen von Clustern erneut als <prmap>-Attribut clusters angegeben werden. In Dommrath haben wir beispielsweise clusters = 2 * 38125,548 / 3177,129 = 24. Bei nicht zusammenpassenden Angaben ist das Verhalten undefiniert.

Im Innern des <clusters>-Elements folgt dann eine Liste von clusters*clusters Integer-Zahlen, die als Cluster-Nummern oberhalb des Cluster-Würfels erscheinen. Die Zeilenstruktur ist gleichgültig; in der Dommrath-Karte stehen aber der Übersicht halber immer 24 Zahlen pro Zeile. Die Nummern erscheinen wiederum von Norden nach Süden zeilenweise, in jeder Zeile von Osten nach Westen, d.h. Süden (positive y-Achse) ist oben in der Mitte, Westen (positive x-Achse) rechts, etc.

Quadrate, die außerhalb des Kreises liegen, sollten mit 0 markiert werden; dort erscheint dann kein Cluster-Würfel. Solche Löcher können aber auch mitten in der Karte platziert werden.

Mit diesem Tag positioniert man eine Beschriftung in die Szenerie, die nicht an ein physisches Objekt wie ein Sonnensystem oder eine Galaxie gebunden ist, z.B. können damit Raumbereiche beschrieben werden.

Achtung: Dieses Feature befindet sich noch im frühen Experimentalstadium. Die Syntax könnte sich in zukünftigen Versionen noch ändern!

Ein Skript ist eine lineare Abfolge von einfachen Anweisungen, die Kamera, Einstellungen und die Anzeige von Overlays steuern. Variablen und Schleifen sind momentan nicht implementiert. Das Skript erscheint unter seinem Namen am Schluss des Menüs Aktionen und kann von dort gestartet und über den Menüpunkt "Skript anhalten" vorzeitig beendet werden.

Wenn sich Skript-Befehle auf Objekte beziehen, müssen diese vorher in der Karte definiert worden sein. Typischerweise stehen Skripte daher am Ende der Kartendatei (oder werden dort importiert).

Jedes Unter-Element entspricht einem Befehl in der Sequenz. Keines der Elemente außer <text> hat Unter-Elemente.

Bemerkungen:

• Wenn bei <move> kein Blickpunkt angegeben ist, bleibt der alte Blickpunkt erhalten; die Kamera kann sich bewegen. Wenn keine Kamera angegeben wird, bleibt die Kamera an der alten Position; der Blick kann schwenken. Die Angabe camera="*" fliegt das bei lookat angegebene Objekt wie bei einem Doppelklick sehr nah an.
• Das bei <text> angezeigte Overlay bleibt angezeigt, bis die bei period angegebene Zeit verstrichen ist oder der Benutzer das Overlay mit Escape oder dem Schließknopf schließt. Danach wird der Rest des Skripts ausgeführt.
• Die Vektoren camTrans und lookTrans werden auf Kamera bzw, Blickpunkt addiert. Wenn mit camera="*" eine Standardkamera gewählt wird, wird camTrans ignoriert.

Bibliotheken sind Spartac-Dateien mit der Endung .prlib, die das Root-Tag <library> definieren. Sie enthalten im Innern Definitionen von Elementen der Arten <system>, <galaxy>, <ellipsoid>, <sphere>, <scenery> und <script>. Andere (z.B. Linien) sind momentan noch nicht vorgesehen.

Der Vorteil von Bibliotheken ist erstens, dass jede Information möglichst nur an einer Stelle gespeichert sein soll, damit nicht mögliche Änderungen an mehreren Stellen durchzuführen sind. Zweitens lassen sich so auf einfachste Art und Weise Detailkarten oder aus mehreren Datenbereichen zusammengestellte Karten erstellen, ohne Daten irgendwoher einkopieren zu müssen.

Angesprochen werden die Objekte in einer Bibliothek über einen Namen - neben dem direkt vergebenen Namen ist bei Systemen möglich ein Sonnen- oder ein Planeten- oder Mondname, bei Galaxien der Messier-, NGC- oder ein anderweitiger Katalogname. Am besten hängt man an die Namen von Volumina immer ein "Vol" und an die von Szenerie-Objekten ein "Sz" an, zur Unterscheidung von korrespondierenden stellaren Objekten ansonsten gleichen Namens.

Eine .prlib-Datei hat denselben Kopf wie eine .prmap-Datei; das Root-Tag ist allerdings <library>. Als Attribute erlaubt sind name, version und date, die momentan allerdings vollständig ignoriert werden. Es ist also z.B. nicht möglich, eine Bibliothek in mehreren Versionen vorliegen zu haben und in der Karte dann eine Version auszuwählen, etc.!

Zwischen Start-Tag und End-Tag müssen die eigentlichen Objekte platziert werden. Objekte ohne Namensangabe werden beim Einlesen ignoriert!

Eine Bibliothek wird mit einem <library>-Tag mit dem Attribut file (im Innern des <prmap>-Elements) eingebunden. Diese Angabe muss vor jeder Bezugnahme in einem Objekt in der Datei stehen. In Bibliotheken kann keine weitere Einbindung (geschachtelt) erfolgen.

Beispiel:

Bemerkungen:

• Es können beliebig viele Bibliotheken hintereinander eingebunden werden. Bei einer lookup-Angabe wird immer in allen vorher angegebenen Bibliotheken gesucht. Es gibt nur einen internen »Namensraum«; wenn ein Name ein zweites Mal auftaucht, überschreibt er das erste Vorkommen, und eine Warnung wird ausgegeben. Wenn man gleich benannte Objekte aus unterschiedlichen Bibliotheken einbinden möchte, muss man zunächst die eine Bibliothek einbinden, die Objekte referenzieren, dann die zweite Bibliothek mit clear="true" einbinden und die anderen Objekte referenzieren. Objekte aus der ersten Bibliothek werden danach aber nie mehr gefunden.
   
• Beim Einbinden wird die komplette Bibliotheks-Datei eingelesen, auf XML-Korrektheit überprüft, und eine Namensliste enthaltener Objekte wird angelegt. Weitere Interpretationen finden erst später Objekt für Objekte statt, wenn Objekte referenziert werden. (Aus diesem Grund kann man beliebige Tags in Bibliotheken hineinschreiben, nur später nicht referenzieren!) Dennoch kann natürlich das Einlesen einer sehr großen Datei seine Zeit dauern, weswegen die Milchstraßen-Daten auch auf mehrere Bibliotheksdateien verteilt sind.
   
• Die Koordinaten aus Bibliotheken können translatiert (verschoben) werden; der zu subtrahierende Vektor wird mit dem Attribut translate angegeben. Das Objekt, das vorher diesen Vektor als Positionsvektor hatte, hat danach die Koordinaten (0,0,0). Beispielsweise translatiert die Mahlstrom-Karte die Position des Mahlstroms in den Ursprung des Koordinatensystems. Alle direkt in der Karte angegebenen Koordinaten werden dadurch einfach kürzer, insbesondere die Ellipsoiden der Nabelschnur. Ebenso bindet Andromeda.prmap die Koordinaten von Andro-Alpha etc. aus der Bibliothek Lokale Gruppe.prlib ein, die Positionen der Systeme in Andromeda sind aber auf (0,0,0) im Zentrum Andromedas bezogen.
   
• Objekte müssen mit demselben Tag referenziert werden, mit dem sie in die Bibliothek eingetragen sind, also <system> als <system>, <galaxy> als <galaxy>, etc., ansonsten wird ein Typkonflikt gemeldet.

Objekte, die aus irgendeiner vorher eingebundenen Bibliothek übernommen werden sollen, erhalten das Attribut lookup, das das Attribut name ersetzt. Andere Attribute im Objekt-Tag überschreiben die Angaben aus der Bibliothek. Die Platzierung des lookup-Attributs im Tags ist dabei gleichgültig, auch davor stehende Attribute überschreiben alte. Beispiele:

Zu beachten ist, dass an Listen wie issues, keywords und races (siehe Abschnitt 2.3) immer angehängt wird. Wenn man die Liste aus dem Bibliotheks-Objekt ganz ignorieren möchte, muss man zunächst als Attribut issues="" etc. verwenden! Beispiel:

Ohne das races="" erscheinen als Völker im Info-Display Cappins, Ganjasen und diverse andere, und die Wuppertaler am Schluss. So wie oben angegeben erscheinen nur noch die Wuppertaler. Die neuen Einträge müssen als Unter-Tags angegeben werden, da kein Attribut doppelt auftauchen darf.

Analog kann man mit dem Attribut comment="" den Kommentar aus der Bibliothek löschen. Das ist nur sinnvoll, wenn man wirklich gar keinen Kommentar haben möchte. Wenn man mit <comment> einen neuen angibt, überschreibt er den alten ohnehin. Aber beachte: So löscht man bei <system> nur den Kommentar zum System, nicht die aus Sonnen und Planeten, die ggf. weiterhin im Info-Display erscheinen.

Ein zweiter Mechanismus zur Datenübernahme ist der der Einbindung einer .prsys-Datei. Darin wird genau ein Sonnensystem sehr detailliert definiert; entsprechend funktioniert das Ganze nur mit <system>-Objekten. Gedacht ist dies für die spätere Darstellung von Planetenbahnen und Planetenoberflächen, -Karten etc. Momentan gibt es diese Dateien für Sol und Arkon.

Diese Art von Referenzierung arbeitet mit dem file-Attribut, beispielsweise

Der Mechanismus des Überschreibens von Eigenschaften funktioniert hier genauso wie beim lookup. So wie oben wird Sol lila eingefärbt und erhält einen Black-Hole-Halo mit Farbwechseln.

Hier werden aus Platzgründen nur die für den Typ color verwendbaren Farbnamen aufgeführt, nicht deren RGB-Entsprechung (dazu siehe z.B. SelfHTML o.ä.). Die Namen mit gray sind in beiden Schreibweisen (also auch grey) erlaubt.

Spartac und die Kartendateien sind © 2003-2006 Axel Rogat. Die den beigelegten Karten zugrundeliegenden Koordinaten und viele andere Daten sind © 2000-2006 Rainer Castor. Perry Rhodan ist © 1961-2006 Pabel-Moewig Verlag KG, Rastatt

http://www.axelrogat.de
mailto:Axel.Rogat@arcor.de