Der xml Traum

[botffan]

uhhhh i frei mi so (diskussion start)

@ rainer
Genau das ist's. Jeder geht von ner anderen Grundlage aus.
Auf dem vorhandenen (z.B. Quellcode) aufbauen und xml hier anpassen,
oder Strukturen neu überdenken.

@ chrisfirefox
Das wollte ich wissen da, xml wie schon erwähnt, sehr flexible ist.
3. In die Richtung will ich!!!

@ alle

Hier ist jetzt meine Vorstellung.

So weit wie möglich Die Inhalte ohne Hardcoding editierbar und erweiterbar machen.
Extremes Beispiel -> grafische Oberfläche über einen Editor flexibel anpassbar
(z.B Positionierung von Grafiken und Schrift) .

Damit jetzt nimand einen Schreck kriegt. Ich möcht nicht alles umschmeißen, sondern die zukünftigen Möglichkeiten ausloten.
Dann die syntaktischen und konzeptionellen Bedingungen festlegen mit denen wir jetzt arbeiten können, und spätere Ansetzte auch noch abdeken.
Ist jetzt ein bischen Glaskugelschauen aber ist ja ein Traum.

[chrisfirefox]

Also ich würd jetzt mal ganz schnell "runter vom Gas" sagen .

Beim "XML-Traum" gehts rein um die Änderung des Formats für die Datendateien. Von einer Positionierung für Grafiken und Texte war nie die Rede und wird aus meiner Sicht auch nie die Rede sein, weil das im Endeffekt für den gesamten User-Interface-Code von BotE, der geschätzte 60% des Games ausmacht, "kübeln und neu machen" bedeuten würde.

Also: Datenfiles wie Buildings oder Language-Texte ja, aber sicher keine Grafikpositionen.

[Sir Pustekuchen]

Ja, es geht ausschließlich um die data-Dateien.

Ich schlage vor, den Start mit der MajorsRaces.data zu machen. Diese ist relativ klein, man kann sie schnell überblicken und die hat keine großen Unterstrukturen. Die Gebäude- und Schiffsliste ist später am kompliziertesten. Mit dieser muss man ja nicht anfangen.

@chrisfirefox
Möchtest du das "XML-Projekt" leiten/überwachen? Ich denke du steckst in dem Thema mehr drin als ich. Alles zu meiner Position und meinen Wünschen habe ich zuvor ja schon bekanntgegeben. Ich kann von daher auch wenig Tipps geben.

Schlussendlich brauchen wir einen Parser und im Code von BotE Funktionen, welche Infos aus der XML holen und daraus Objekte (z.B. CMajor für Hauptrasse) erstellen und initialisieren.

[botffan]

Ok schluß mit Größenwahn und Budder bei die Fische!!

Welches sind die nächsten Schritte?

Sollen wir die Editoren umbauen und die Dateien in xml Konvertieren, oder die xml's von Hand erstellen?

[Sir Pustekuchen]

Ich würde vorschlagen, erst einmal die MajorRaces.data Datei in XML konvertieren. Dafür braucht man ja den Parser, der müsste also programmiert werden. Wenn dann eine valide XML Datei rauskommt, können wir versuchen diese in BotE einzulesen. Danach gehts dann an die nächsten Data Dateien. Irgendwann sollten wir auch die Editoren anpassen, was aber keine so hohe Priorität hat, da man XML auch manuell gut bearbeiten kann.

Also wichtig wäre sich zu entscheiden, welches Framework / Bibliothek nun genommen werden soll. Und danach wie man generell vorgeht. Ich kenne mich da auch nicht aus, ob es besser ist Eigenschaften, Attribute usw. zu verwenden. Da müsste ich mich auch erst einlesen. Ich habe noch nie was mit XML gemacht (außer selbst mal paar Dateien modifiziert, aber noch nie ein Konzept erstellt)

[Nobody6]

Wäre es nicht Sinnvoll zunächst mal den Editor umzubauen, so dass er beides (altes Format und xml) verarbeiten kann?

[chrisfirefox]

@Puste, ich kann mit Rat zur Seite stehen, bei der Tat hapert es leider wie schon im internen Forum gesagt etwas, weil ich an einem beruflichen Projekt dran bin.

@Nobody, das ist wiederum Geschmackssache, ob man jetzt zuerst die Editoren angeht oder zuerst mal die Editoren quasi "invalidiert". Meiner Meinung nach würde grade ein Editor ein "abgeschlossenes Biotop" bieten, um die XMLs zu erstellen. Und ob man jetzt einen Konverter schreibt (nein, ich käme nichtmal auf die Idee, das von Hand zu machen ), oder gleich den Editor als Ausgang nimmt, um dann die Daten, die er ohnehin in interne Strukturen umwandelt (hoffe ich zumindest!), einmal als Data-File und einmal als XML-File schreibbar und in weiterer Folge lesbar zu machen, ist glaube ich "igel", der Editor würde halt schon die bessere Ausgangsbasis bieten. Vor allem aber würde dieses "Biotop" es erlauben, mehrere Ansätze zu testen.

Erfahrungsgemäß ist XML schreiben wesentlich einfacher als XML lesen, weil man im Zuge des Schreibens und der Schleifen ja ohnehin das Format festlegt - beim Lesen *muss* man eben auf einen Parser zurückgreifen, und da gibts komplizierte und einfache. Ich schau mir mal die Vorschläge an, evtl. kann ich da ja was rauslesen, welcher einfacher ist.

Wie gesagt, ich kann gerne beraten, aber vom "Senf dazugeben" wirds halt auch nicht umgesetzt - sorry .

EDIT: pugi und tiny angeschaut, beide schauen von der Syntax her recht passabel aus, Performance-Überlegungen würd ich jetzt grad für XML bei BotE nicht wirklich anstellen, weil das in sehr unkritischen Bereichen (Config) eingesetzt wird, und nicht bei jedem Klick oder so. Schreiben würde ich fast schon mit sprintf, weil das bei weitem am Schnellsten und unkompliziertesten funktioniert. Hat dann zwar kein automatisches "Tag-Closing" und Validierung und so, aber ist glaube ich am Leichtesten verständlich.

[botffan]

hi, ich bin's nur

Struktuleti (vererbt und abgeleitet von Diktatoleti->Kontroleti) is in the house.

hmmmmm die MajorRace.data Struktur Beschreibung ist für mich bisl verwirrend (Wikki)

<Grundsatzdiskussion>Tags in english oder deutsch<DebateOnPrinciples>


dann
z.B.

Code: Alles auswählen

First Line: Racial ID (eg "MAJOR1")

Second Line: Name of the home system (eg "Terra")

Third Line: Breed name (eg "people")

4th Line: article for breed name (eg, "the" people ...)

5th Line: prolonged empire name (eg "Terran Confederacy")

6th Line: article for breed name (eg "the" ... Terran Confederacy) 

Empire vs Race vs Breed tut das not?
DatenString Terran Confederacy (als Beispiel in wikki) vs Coalition of Planets als DatenString in Englischer MajorRace.data

und es gibt sehr viele daten die nicht Sprachabhängig sind, sollen wir das als Block (jede sprache mit allen daten) oder solls nur für sprachrelevante Daten gelten?

Hier ein Block Beispiel.

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>

<MajorRace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="MajorRace.xsd" 
          VERSION="0.81">

  <Race>
    <RacialIdDe>MAJOR1</RacialIdDe>
    <RacialIdEn>MAJOR1</RacialIdEn>
    <RacialIdFr>MAJOR1</RacialIdFr>
    <HomeSystemDe>Terra</HomeSystemDe>
    <HomeSystemEn>Terra</HomeSystemEn>
    <HomeSystemFr>Terra</HomeSystemFr>
    <BreedNameDe>Menschen</BreedNameDe>
    <BreedNameEn>Humans</BreedNameEn>
    <BreedNameFr>Gens</BreedNameFr>
    <ArticlBreedNameDe>die</ArticlBreedNameDe>
    <ArticlBreedNameEn>the</ArticlBreedNameEn>
    <ArticlBreedNameFr>ceux</ArticlBreedNameFr>
    <ProlongedEmpireNameDe>Terranische Konföderation</ProlongedEmpireNameDe>
    <ProlongedEmpireNameEn>Coalition of Planets</ProlongedEmpireNameEn>
    <ProlongedEmpireNameFr>Terrestre Confédération</ProlongedEmpireNameFr>
    <ArticlProlongedEmpireNameDe>die</ArticlProlongedEmpireNameDe>
    <ArticlProlongedEmpireNameEn>the</ArticlProlongedEmpireNameEn>
    <ArticlProlongedEmpireNameFr>ceux</ArticlProlongedEmpireNameFr>
    <DefiniteArticlProlongedEmpireNameDe>der</DefiniteArticlProlongedEmpireNameDe>
    <DefiniteArticlProlongedEmpireNameEn>the</DefiniteArticlProlongedEmpireNameEn>
    <DefiniteArticlProlongedEmpireNameFr>qui</DefiniteArticlProlongedEmpireNameFr>
    <RacePrefixDe>con_</RacePrefixDe>
    <RacePrefixEn>con_</RacePrefixEn>
    <RacePrefixFr>con_</RacePrefixFr>
    <BreedDescriptionDe>Die Menschen leben in einer Gesellschaft, .....</BreedDescriptionDe>
    <BreedDescriptionEn>Humans live in a society based .....</BreedDescriptionEn>
    <BreedDescriptionFr>Les humains vivent dans une ......</BreedDescriptionFr>
    <NumberAssignedToBuildingsDe>1</NumberAssignedToBuildingsDe>
    <NumberAssignedToBuildingsEn>1</NumberAssignedToBuildingsEn>
    <NumberAssignedToBuildingsFr>1</NumberAssignedToBuildingsFr>
    <NumberAssignedToShipsDe>1</NumberAssignedToShipsDe>
    <NumberAssignedToShipsEn>1</NumberAssignedToShipsEn>
    <NumberAssignedToShipsFr>1</NumberAssignedToShipsFr>    
  </Race>  
  
</MajorRace>

ps. Das französisch hab ich jetzt mit google & co gefummelt ich kanns nicht (obvie)

[RedAdder]

Wäre es nicht Sinnvoll zunächst mal den Editor umzubauen, so dass er beides (altes Format und xml) verarbeiten kann?

Ja, das wäre sinnvoll.

[RedAdder]

Hallo BotFFan,

grundsätzlich sollten Parameter wie die Sprache nicht in eine Datenstrukturdefinition in die Namen bzw. Schlüssel eingehen. Besser ist es, mit Attributen zu arbeiten, sodass dann eine neue Sprache hinzuzufügen einfach ist. Die RacialID sollte nicht übersetzt werden, meine ich.
IDs gehören vorzugsweise in Attribute.

Also mindestens so:

Code: Alles auswählen

<Race>
    <RacialId>MAJOR1</RacialId>
    <HomeSystem lang="de">Terra</HomeSystem>
    <HomeSystem lang="en">Terra</HomeSystem>
    <HomeSystem lang="fr">Terra</HomeSystem>
...

Vielleicht sogar so:

Code: Alles auswählen

<race id="MAJOR1">
   <!-- language independent data -->
   ..
   <!-- language dependent data -->
   <translations>
       <translation lang="de">
            <HomeSystem>Terra</HomeSystem>
            ..
       </translation>
      ..
   </translations>
</race>

Vorteil: beim Hinzufügen einer neuen Sprache wird einfach eine andere Sprache kopiert und als neuer Block in die Translations eingefügt, man muss nicht an zig-Stellen das XML ediitern.

[chrisfirefox]

ok, RedAdder war schneller, ich kann seinen Post aber vollauf bestätigen, höchstens etwas flachere Strukturen mit Attributen wären aus meiner Sicht noch wünschenswert.

[botffan]

jo

das gefällt mir sehr gut

Code: Alles auswählen

<race id="MAJOR1">
   <!-- language independent data -->
   ..
   <!-- language dependent data -->
   <translations>
       <translation lang="de">
            <HomeSystem>Terra</HomeSystem>
            ..
       </translation>
      ..
   </translations>
</race>

das währe auch simpler in nem (ich weiß brauchen wir jetzt nicht, und warscheinlich nie) xmlSchema.
Soweit ich das beurteilen kann, ist's auch besser beim Auslesen Später im Code.

[botffan]

Ich glaub da wird jetzt ein Schuh draus!!!!!

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>

<MajorRaceData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="MajorRace.xsd" 
          VERSION="0.81">
  
  <Race id="MAJOR1">
    
    <LanguageIndependetData>
      <NumberAssignedToBuildings>1</NumberAssignedToBuildings>
      <NumberAssignedToShips>1</NumberAssignedToShips>
    </LanguageIndependetData>
    
    <LanguageDependetData lang="de">
      <HomeSystem>Terra</HomeSystem>
      <BreedName>Menschen</BreedName>
    </LanguageDependetData>
    <LanguageDependetData lang="en">
      <HomeSystem>Terra</HomeSystem>
      <BreedName>Humans</BreedName>
    </LanguageDependetData>
    <LanguageDependetData lang="fr">
      <HomeSystem>Terre</HomeSystem>
      <BreedName>Gens</BreedName>
    </LanguageDependetData>
  
  </Race>
  
</MajorRaceData>

[RedAdder]

Auch nicht schlecht, eine Ebene weniger.

Aber bitte ohne Schreibfehler: (in)dependet=>(in)dependent (dependency=Abhängigkeit)

[RedAdder]

ok, RedAdder war schneller, ich kann seinen Post aber vollauf bestätigen, höchstens etwas flachere Strukturen mit Attributen wären aus meiner Sicht noch wünschenswert.

Das XML wird mit Daten in Attributen natürlich teilweise um den Faktor 0.5 kürzer, das sehe ich ein.

Da ich aber oft mit Datenbanken zu tun habe, finde ich es logischer, wenn in den Attributen hauptsächlich Schlüssel und Primärschlüsselkandidaten stehen, sowie Informationen die zum Auslesen der Daten nötig oder hilfreich sind wie Version, Zeichensatz und vielleicht Anzahl Datensätze.