Der xml Traum

[botffan]

Puste
PS:
offtopic: Mein Traum wäre, wenn die ganzen *.data Dateien irgendwann mal *.xml wären. Dann könnte man diese viel einfacher editieren und prüfen ob sie auch valide sind. Aber anno 2004 hatte ich davon noch keine Ahnung .

Hab mich da ma bsel schlau gemacht (weil bis jetzt keine Ahnung ).

Fragen haben sich da aufgetürmt.

Gibt's da schon ne Überlegung wie das Implementiert werden sollte.

Stichworte MSXML, freie XML-Bibliothek, Parser, .Net Framwork, Strukturen .

Nur mal so in den Raum geworfen.

[RedAdder]

Ich habe mich gestern auch für .xml geäußert.

Ich kann sowas, also Konverter und Leseroutinen, prinzipiell auch in Java oder C programmieren.
Ich habe bisher erfolgreich scew+expat dafür benutzt.
Vielleicht gibt es in boost was dafür?

Das Stichwort .NET mag i net, da mein System zu alt ist, dass das läuft, und eine gewisse Abhängigkeit von der MS-Schiene erzeugt.

[Sir Pustekuchen]

Ich kenne mich nicht mit xml-Bibliotheken aus. Es sollte halt eine sein, die "einfaches" XML versteht und parsen bzw. schreiben kann.
Das Schreiben ist nicht so wichtig, solange der Konverter funktioniert und die Dateien der Editoren direkt konvertiert. Später wäre es natürlich besser, wenn alle Editoren auch XML lesen und direkt schreiben könnten.

In BotE müsste XML nur gelesen werden. Das was dort an Infos steht, müsste den Attributen der jeweiligen Objekte zugeordnet werden. Das ist jetzt auch nicht anders, nur das die Infos aus einem eigenem ASCII Format kommen. Ich denke das anzupassen ist nicht schwer, sofern man einmal eine leicht zu verwendende, performante XML-Reader Klasse für C/C++ hat.

Der Einfachheit halber könnte man das Lesen und Schreiben z.B. erst einmal mit dem Gebäudeeditor testen bzw. dort implementieren. Das Lesen in BotE direkt ist danach nicht anders. Wenn es im Editor mit Schreiben und Lesen einmal klappt, dann funktioniert es auch in BotE.

[RedAdder]

Wer ist denn am ehesten der technische Ansprechpartner für den Gebäudeeditor?

[Sir Pustekuchen]

Ich

[botffan]

Ja genau das war mein Ansatz.

Festlegen welche Software wir nutzen sollen!

expat Scheint aus meiner Sicht geeignet, ist halt in c (c++ Wrapper sind ja vorhanden).
Die Bibliotheken stehen unter "MIT License", bin noch nicht sicher was das genau heißt.
@RedAdder
Da villeicht noch Infos bezüglich der Lizenz.!?

Sollen wir noch weitere Alternativen sammeln z.b. C++ Basierend?

In wie Weit müssen wir auf eventuell zukünftige Bedürfnisse achten?

[botffan]

@ Puste
Was verstehst du unter einfachem xml?

[RedAdder]

Also MIT Lizenz heißt im Wesentlichen Du musst irgendwo angeben, wer der AUthor ist.
Also nichts schlimmes.

Ich habe noch das hier gefunden, das wurde auch sehr gelobt, auch bzgl. Unicode:
http://pugixml.googlecode.com/svn/tags/ ... start.html

Ich bin nicht auf scew/expat festgelgt, habe es halt einfach nur schonmal verwendet.
Nachteilig ist sicher, dass es zwei Bibliotheken sind.

[botffan]

Sooooooooooo

hab mal so aus Jux ma was erstellt.

Beim suchen nachnem xml Editor viel mir auf, das VB schon einen hat.

Da ich mich da grad einarbeite (also xml) hab ich mal n bischen mit der shiplist rumgespielt.

Shiplist.xsd Datei (XML Schema) ->Struktur und Validierung

Shiplist.xml Datei (Basierend auf Shiplist.xsd) ->Die Eigentlichen Daten

Ich hab die mal Hier angehängt und zum lesen reingestellt.

Ist das die Richtung in die wir gehen wollen?

[Sir Pustekuchen]

Ja, genau so sollte es ausschauen. Mir wäre eigentlich nur wichtig, dass wir die deutschen und englischen Listen mergen. Das heißt, dass da mal ein <DescriptionDE>, <DescriptionEN> und zukünftig vielleicht auch ein <DescriptionFR> usw. drin stehen kann. Lediglich die Namen und Beschreibungen sind ja sprachabhängig. Später vielleicht auch mal die Beamwaffen sowie Torpedowerfer. Also für die Verwendung verschiedener Sprachen bräuchten wir noch ein Konzept.

Z.B könnte man sich da an Civilization 4 orientieren. Da sind auch alle Informationen in XML Dateien abgespeichert. Hier ist ein Beispiel, wie die Städtenamen sprachabhängig sind:

Code: Alles auswählen

<TEXT>
	<Tag>TXT_KEY_CITY_NAME_VIENNA</Tag>
	<English>Vienna</English>
	<French>Vienne</French>
	<German>Wien</German>
	<Italian>Vienna</Italian>
	<Spanish>Viena</Spanish>
</TEXT>

Als XML Parser kann ich TinyXML empfehlen. Dieser ist OpenSource, es braucht keine Bibliotheken, lediglich ein paar Quellcodedateien. Ich finde der lässt sich richtig gut verwenden. Wie der Name schon sagt, er ist nicht überfrachtet mit Features sondern konzentriert sich auf das Wesentliche, nämlich XML zu parsen. Das verstehe ich unter einem "einfachen XML". Hier der Eintrag zu TinyXML bei Wikipedia: http://en.wikipedia.org/wiki/TinyXML

@RedAdder
@botffan
Es wäre schön, wenn ihr euch zusammen schließt bzw. absprecht. Es wäre nicht gut, wenn Arbeit doppelt gemacht wird. Schlussendlich können wir ja nur einen XML Parser verwenden.

PS:

Ich habe noch das hier gefunden, das wurde auch sehr gelobt, auch bzgl. Unicode:
http://pugixml.googlecode.com/svn/tags/ ... start.html

Nachdem ich mir das auch mal kurz angeschaut habe, dann scheint es auch sehr gut zu sein. Könnte man wahrscheinlich auch verwenden.

[botffan]

hmmmmmmmmm
Erstma Gutes neues an alle(Schande über mich ich hab das nicht so auf'm Schirm gehabt ).

@ Puste
Die Abstimmung und Festlegung, Was-Wie-Wo, scheint für mich das Schwierige zu sein.
Welche Konzepte wollen wir da anwenden? XML ist da sehr Frei und man kann das nach belieben Gestallten.
z.b. Validierung -> soll der Parser das beherschen (kann man auch selber coden!?, sollen wir XMLSchema nutzen (hab mich da grad n bischen verliebt . Ist aus meiner Sicht nicht mehr "einfaches" xml )

Ums nochmal klar zu machen : ich bin da ein NOOB und bräuchte da feedback ob das erstrebenswert ist.(@RedAdder )
Ich seh in diesem Konzept eine sehr Mod-Freundliche Umgebung.

[RedAdder]

pugixml 0.9 schneidet in den benchmarks sehr gut ab, andererseits: der Autor von tinyxml verspricht mit TinyXML2 auch effizienter zu sein als mit TinyXML.

http://www.grinninglizard.com/tinyxml2/index.html

Im Übrigen habe ich gemerkt, dass ich bzgl. der Programmierung (des Buildingeditors) passen muss, da ich nur die Express-Version von VC installiert habe und mir die MFC fehlen.

@botffan:

Also Schema-Validierung finde ich jetzt nicht so wichtig. Man könnte es sogar als ein Feature betrachten, dass wenn sich das Schema ändert, alte XML-Dateien durch defaultwerte ergänzt werden. Ich vermute alle besonders schnellen XML-Parser machen keine Schema-Validierung.

Zum Validieren eignet sich glaube ich der IE ganz gut, da der einen sehr guten Ansichtsmodus für XML hat (man kann ja sonst von dem Browser halten was man will).

Wenn Du sagst Du bist ein Noob, dann können wir uns gerne kurzschließen. Du hast nicht zufällig xfire in Benutzung?

Bzgl. des Designs des XML: man kann auch Attribute nutzen z.B. statt

Code: Alles auswählen

<Texts>
    <Deutsch>Text</Deutsch> 
</Texts>

Code: Alles auswählen

<Texts>
    <Text lang="de">Text</Text>
</Texts>

Dann muss man das Schema nicht ändern, wenn eine neue Sprache hinzukommt.

[botffan]

@RedAdder

No (Peanut voice on)-> soooryy <-(Peanut voice off) xfire hab isch nisch (das ganze Messengerglumb mag ich net. Bin da ein wenig eigen; um nicht paranoid zu sagen).

@ alle
Legen wir doch mal die Grundvoraussetzungen fest.

Wo sollen wir die Entscheidungen sammeln und koordinieren (codplex? wobei da ja auch über Alternativen nachgedacht wird)

Das wir mal einen Rahmen festlegen. Welche übersichten gibt es den bis jetzt vom/fürs gesamte Projekt.(ich zieh mir meine Infos unter anderem aus dem quellcode -> eher mühsam)

[rainer]

was verstehst Du denn unter Grundvoraussetzungen?

Die wichtigste Basis ist der Quellcode, denn alles was außenherum aufgeschrieben ist, hängt davon ab, ob es (noch) dem Quellcode entspricht.

Am Beispiel der Buildings.data ist im Wiki ein bißchen was aufgeschrieben http://birth-of-the-empires.de/wiki/ind ... dings.data (dort kann man gerne z.B. die Datentypen ergänzen), ansonsten hilft mir die dort verlinkte Excel-Datei oft, um zu sehen, welche Daten(typen) beinhaltet sind.

Ansonsten gilt das, was Puste hier schon früher geschrieben hat: Es sollte wohl kein "High-End"-xml sein, das kaum ein (OpenSource)-Programm und kaum ein Mensch versteht, keine Sackgasse werden (z.B. Spracherweiterung oder auch am XML-Standard bleiben) und ansonsten halt einfach funktionieren für das, was wir so brauchen => momentan liest der Code halt die data=Textdateien aus und verwendet die Werte.

Dabei bedenken, dass ich (oder auch Puste) mich nicht in xml auskennen...da seid Ihr, die sich damit beschäftigen, mehr die Experten , die sich besser auskennen, was wie zu tun wäre => darum einfach mal ausprobieren...und wenn's funktioniert...

PS: es kann sein, dass Puste frühestens erst am WE wieder online ist, und ich auch

PS2: habe im Wiki eine Kategorie Data-Files (wo was zur Struktur und zum Content drinsteht) http://birth-of-the-empires.de/wiki/ind ... Data-Files angelegt, die mir das Navigieren leichter macht...es sind aber noch nicht alle Data-Files verlinkt

[chrisfirefox]

Möchte mich da kurz einbringen, weil ich grad selber viel mit XML mache, damit mein neues Game einigermaßen Modfähig ist .

1) XML lässt extrem viele Freiheiten zu, allerdings habe ich die Erfahrung gemacht, dass in Parsing und Programmierung "flache" Strukturen (also Attribute im Stile "<lang text='de'>wert</lang>" statt Subelemente im Stile "<lang><de>text</de></lang>") zumindest mit den .NET-Bordmitteln um einiges leichter programmatisch zu verarbeiten sind - dürfte aber auch viel auf den Parser ankommen. Natürlich gehts da auch etwas um die "menschliche" Lesbarkeit, sprich mehr als 10 Attribute sollte ein Element wohl nicht haben. Kürzer werden die XMLs durch Attribute auf jeden Fall, und damit in jedem Fall leichter lesbar. Als Faustregel würde ich einfach Text und Zahlen möglichst in Attribute packen bzw. in Elementen zusammenfassen (zB Tech als Sammelelement mit Attributen wie 'bio="0" energy="2" computer="3" oder so), und komplexere Strukturen bzw. solche, die mehrfach vorkommen können, in Subelemente packen. So entsteht ein kompaktes, lesbares XML, das keine (plakativen) 5 Bildschirmseiten für ein Schiff braucht, und dennoch voll XML-Kompatibel ist.

2) Wichtig ist wie RedAdder schon angemerkt hat die Erweiterbarkeit, also "feste" Elementnamen für multiple Einträge wie "<nameDE>" oder so sollten zugunsten von Einträgen im Stile von "<name lang="de">" nicht verwendet werden, um sowohl im Schema als auch in den Editoren leicht erweiterbar zu sein, ohne jetzt an 17 Stellen etwas hinzufügen zu müssen.

3) Schema ja oder nein ist wirklich Geschmackssache, es kommt ganz darauf an, welche Tools man verwendet - wenn fürs Bearbeiten des XML nur ein Texteditor zum Einsatz kommt, ist das XML-Schema einfach nur Ballast. Ein Schema erlaubt es hingegen einem XML-Editor theoretisch, Formulare für die einzelnen Elemente automatisiert aufzubauen, je genauer das Schema, desto besser das Formular, bis hin zu einem "Generalisierten Editor", der nicht mehr getrennt gewartet werden muss. Allerdings kenne ich bisher keine so guten XML-Editoren, ich sage nur dass es technisch denkbar wäre, einen solchen "General-Editor" mithilfe von XML-Schemata umzusetzen.