Willkommen ~Gast!
Registrieren || Einloggen || Hilfe/FAQ || Staff
Probleme mit der Registrierung im Forum? Melde dich unter registerEin Bild.
Autor Beitrag
000
12.08.2004, 09:45
Nicemice
Moderator


Hi
Leute

Ich hab mir überlegt, daß ich vielleicht eine Doom3Guide machen werde. Zunächst mal nur für mich und wenns gut wird public.

Um das Ganze möglichst formatunabhängig zu machen, würde das gerne in XML schreiben. Mithilfe eines Parsers könnte man dann HTML Seiten, Latex Dokumente usw. generieren. Noch cooler wärs natürlich als Onlineprojekt, zum Beispiel mit CVS oder einfach nur als ein Wiki. Die XML Datei würde zum Beispiel dann unter der GPL veröffentlicht. Sowas fände ich richtig goil.

Sowas könnte ich mir auch für thewall.de vorstellen: Anstatt irgendeine Entity Database zu entwickeln, einfach das Ganze Zeugs in ein XML Dokument reinhauen.

So, nun zu meiner Frage:
Wie könnte ein XML Dokument aussehen ? Mein Problem ist immer, daß ich mir unklar bin was ich nun als neuen TAG bzw. als Attribut eines TAGS schreiben soll. Wie könnte zum Beispiel ein Konten für eine Entity Beschreibung aussehen ?

--

www.d3opencoop.com - A Doom3 Cooperative Mod


Dieser Beitrag wurde am 12.08.2004 um 09:50 von Nicemice bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
001
12.08.2004, 12:43
theDon



eine möglichkeit wäre XSLT. zumindest kann man damit recht leicht aus beliebigem XML HTML generieren. Für LaTeX etc bräuchte man natürlich immernoch einen parser.

--

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

zum Seitenanfang zum Seitenende Profil || Suche
002
12.08.2004, 14:22
Chronial



Die aktuelle entitiy-"database" als xml würde so aussehen:

Quellcode:<group name="Trigger">
   <entitie>
      <name>trigger_auto</name>
      <description>
         Mit dem trigger_auto ist es möglich ein anderes
         entity zu triggern sobald das level geladen wird. der
         delay sollte auf ca. 0,5 Sekunden gestellt werden.
         damit ist sichergestellt dass alle anderen entities
         die der trigger_entity betrifft auch sicherlich schon
         angesprochen werden können
      </description
   </entitie>
   <entitie>
      <name>trigger_push</name>
      <description>
         Mit dem trigger_push kann man den Spieler
         wegschieben. Dazu ein kleines Beispiel: Man will in
         einem Gang am Ende einen Ventilator plazieren. Wenn
         dieser eingeschaltet wird soll der Spieler vom
         Ventilator nach hinten gedrückt werden. Dazu muß in
         dem Gang ein Block, der so groß ist wie der Gang,
         plaziert werden. Aus diesem Block macht man einen
         trigger_push. Dann muß man noch die Richtung mittels
         dem oben liegenden Angle verändern. Einfach an den
         weißen Strich drehen.
      </description>
      <property name="name">
         um es triggern zu lassen Namen eingeben
      </property>
      <property name="delay before trigger">
         die Anzahl der Sek. bis man es wieder benutzen kann
      </property>
      <property name="speed of push">
         Die Geschwindigkeit mit der der Spieler weggedrückt
         wird
      </property>
      <property name="Angle">
         Damit kann man die Richtung einstellen; nach oben und
         unten ist auch möglich
      </property>
      <flag name="Once Only">
         Man kann es nur einmal benutzen
      </flag>
      <flag name="Start off">
         ist anfangs ausgeschaltet und muß erst getriggert
         werden um es einzuschalten
      </flag>
   </entitie>
</group>
<group name="Monster">
   <entitie>
      <name>monster_bigmomma</name>
      <description>
         Ziemlich großes Vieh dem man nicht zu nahe kommen
         sollte, sie spuckt Säure und wirft
         mit babycrabs um sich.
      </description>
      <image>
         images/monster_bigmomma.jpg
      </image>
   </entitie>
</group>
<group name="Func">...
Für richtiges XML müsste man aber aohl auch die Propertys und die Flags so aufbaun wie die entities. Dann wäre nämlich auch das hier möglich:

Quellcode:<group name="func">
   <entitie>
      <name>func_mortar_field</name>
      <description>
         Mit func_mortar_field werden Bereich für geziehlte
         Airstrikes definiert. Über dem Gebiet, in dem die
         Airstrikes niedergehen sollen, kreiert man - am
         besten direkt unter dem Himmel - einen Block mit eben
         dieser Größe.

         Wichtig ist, dass man die Balken zu Anfang am unteren
         und am linken Rand positioniert, wenn man Table zum
         zielen verwendet, denn der Ausgangspunkt der AS ist
         immer unten links, wenn man vor der Targetting-Map
         steht also in der süd-westlichen Ecke.
      </description>
      <property>
         <title>Name</title>
         <name>targetname</name>
         <description>
            Ein Name wird benötigt, denn schließlich muss man
            die Airstrikes mit einem Button auslösen.
         </description>
      </property>
      <property>
         <title>Spread Radius </title>
         <name>m_flSpread</name>
         <description>
            Hier kann man den Zerstörungsradius einstellen.
         </description>
      </property>
      <property>
         <title>Repeat Count</title>
         <name>m_iCount</name>
         <description>
            Das bestimmt die Anzahl der Bomben pro AS.
         </description>
      </property>
      <property>
         <title>Targeting</title>
         <name>m_fControl</name>
         <description>
            Hier wird die Art der Zielbestimmung festgelegt
         </description>
         <value>
            <title>Random</title>
            <description>
               Zufällig - man kann sowohl durch Table als auch
               durch Activator den AS auslösen
            </description>
         </value>
         <value>
            <title>Activator</title>
            <description>benutzung unbekannt</description>
         </value>
         <value>
            <title>Table</title>
            <description>
               Wenn man Table einstellt, dann kann man das
               Bombenziel durch Schieber auf einer Karte
               einstellen, wie im originalen HL als man den
               feuerspuckenden Gargantua wegbomben darf.
            </description>
         </value>
    ....
Auf jeden Fall ein interessanter Vorschlag - muss man nur Leute finden, die das machen.
Als Wiki wäre das aber wohl weniger der Hit - man bräuchte schon ein Script, das die xml-struktur dynamisch bearbeitet.

--

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren


Dieser Beitrag wurde am 12.08.2004 um 14:28 von Chronial bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
003
12.08.2004, 14:43
K-Putt



Wie thedon schon sagte, XSLT wäre optimal, um aus dem XML Quelltext eine schöne HTML-Seite zu zaubern.

Seh ich als Prima vorschlag für Künftige Tutorials oder als Entity-Bibliothek, werd mich mal mit dem Thema auseinandersetzen.

--

Rambo Engineer @ Drippy's 2fort - finest TFC 1.5 || Bild Upload || The world's most advanced open source database


Dieser Beitrag wurde am 12.08.2004 um 15:40 von K-Putt bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
004
12.08.2004, 15:31
theDon



mh, wenn da mal wer eine ordentliche formatdefinition aufstellt, dann kann ich mich mal an einem LaTeX - converter versuchen.

--

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

zum Seitenanfang zum Seitenende Profil || Suche
005
12.08.2004, 15:38
K-Putt



Wie wärs damit?

Quellcode:<?xml version="1.0" encoding="ISO-8859-1"?>
<bibliothek>
<group>
    <title>trigger_</title>
    <entity>
        <name>Name des Entity 1</name>
            <description>
            Beschreibung des Entity
            </description>
        <property>
            <title>Name der Eigenschaft 1</title>
            <description>
            Beschreibung der Eigenschaft 1
            </description>
        </property>
        <property>
            <title>Name der Eigenschaft n</title>
            <description>
            Beschreibung der Eigenschaft n
            </description>
        </property>
        <flag>
            <title>Name des Flags 1</title>
            <description>
            Beschreibung des Flags 1
            </description>
        </flag>
        <flag>
            <title>Name des Flags n</title>
            <description>
            Beschreibung des Flags n
            </description>
        </flag>
    </entity>
    <entity>
        <name>Name des Entity n</name>
            <description>
            Beschreibung des Entity
            </description>
        <property>
            <title>Name der Eigenschaft 1</title>
            <description>
            Beschreibung der Eigenschaft 1
            </description>
        </property>
        <property>
            <title>Name der Eigenschaft n</title>
            <description>
            Beschreibung der Eigenschaft n
            </description>
        </property>
        <flag>
            <title>Name des Flags 1</title>
            <description>
            Beschreibung des Flags 1
            </description>
        </flag>
        <flag>
            <title>Name des Flags n</title>
            <description>
            Beschreibung des Flags n
            </description>
        </flag>
    </entity>
</group>
</bibliothek>
[edit]
Beispiel:
XML: http://www.sro.at/xml_test/bibliothek.xml
Dazugehöriges XSL-Stylesheet: http://www.sro.at/xml_test/style.xsl

Quick & Dirty, aber zeigt wie einfach sowas machbar ist.

[edit2]
Warum sollt ein entity zu mehren Gruppen gehören? Also wenn dann kann ein Entity doch nur in einer Gruppe sein, sei es jetzt env_, func_, trigger_, oder sonst was.

[edit3]
@Nicemice Stimmt, am besten für jeweils Key & Value einen Titel & Beschreibung festlegen, aber natürlich nur bei den Properties, die Flags kennen ja nur an/aus Status.
Werd mich dem heut abend widmen, falls niemand was dagegen hat, jetzt mangelts mir leider an Zeit..

--

Rambo Engineer @ Drippy's 2fort - finest TFC 1.5 || Bild Upload || The world's most advanced open source database


Dieser Beitrag wurde am 12.08.2004 um 15:53 von K-Putt bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
006
12.08.2004, 15:38
Nicemice
Moderator


@chronical: So ist das schon recht gut.

Das mit dem Group könnte man ja auch in <entity> reinziehen zum Beispiel:
Quellcode:<entity>
      <group>trigger</group>
      <group>wall</group>
      <name>trigger_wall</name>
      <description>
        ...
      </description>
   </entity>
So, könnte ein Entity zu mehreren Gruppen gehören. Es wäre natürlich auch cool, wenn es der Klassenhierachrie im SDK entspricht. Also der Ansatz ist schon nicht schlecht. Man muß halt von Anfang an eine gute Strukur bauen (mit möglichst wenig Tags), die aber alle Bedingungen erfüllt.

@K-Putt: Dann noch gleich in Key/Value Pairs unterteilen, damit man gleich weiss wo man was eintragen muss.

--

www.d3opencoop.com - A Doom3 Cooperative Mod


Dieser Beitrag wurde am 12.08.2004 um 15:42 von Nicemice bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
007
12.08.2004, 16:48
dp
Administrator


Zu den Entityproperties - Viele davon (name, target, delay before trigger, usw.) sind in vielen Entities verwendet, man also eine n:m relation Entity:Property. Wie würde man das mit XML machen? Wenn man wie oben, für jedes Entity das "name"-Property definiert hat man ja eine riesig große Redundanz.

--


Dieser Beitrag wurde am 12.08.2004 um 16:51 von dp bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
008
12.08.2004, 20:33
Chronial



nicemice - die gruppe nach innen will gut überlegt sein - "besser" ist das nicht, sondern eben anders. Damit änderst du die Struktur, und die Bedeutung von Gruppen.
Die Änderung wäre eventuel sinnvoll, vieleicht aber auch nicht. Die aktuelle Datenbank ist jedenfalls meiner Struktur enstprechend aufgebaut.

dp - sowas ist von xml her nicht möglich.
Was man jedoch machen könnte, ist ein <commonproperty> element.
Das könnte man dann folgendermasen einsetzten:
Quellcode:<group name="func">
   <entity>
      <name>func_wall>
      <commonproperty name="name" />
   </entity>
</group>
aber auch so:

Quellcode:<group name="func">
   <entity>
      <name>func_wall>
      <commonproperty name="name">
         <description>
            Andere Beschreibung als normal
         </description>
      </commoproperty>
   </entity>
</group>

--

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren

zum Seitenanfang zum Seitenende Profil || Suche
009
13.08.2004, 23:24
CN



das wäre ja (fast) noch länger

--

zum Seitenanfang zum Seitenende Profil || Suche
010
14.08.2004, 01:11
Chronial



mh?

aus
Quellcode:.     <property>
         <title>Name</title>
         <name>targetname</name>
         <description>
            Ein Name wird benötigt, denn schließlich muss man
            die Airstrikes mit einem Button auslösen.
         </description>
      </property>
wird
Quellcode:.     <commonproperty name="name">
         <description>
            Ein Name wird benötigt, denn schließlich muss man
            die Airstrikes mit einem Button auslösen.
         </description>
      </commonproperty>
und aus
Quellcode:.     <property>
         <title>Name</title>
         <name>targetname</name>
         <description>
            Name, mit dem das entity angesteuert werden kann
         </description>
      </property>
wird
Quellcode:.     <commonproperty name="name" />
was ist da länger?

--

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren


Dieser Beitrag wurde am 14.08.2004 um 01:12 von Chronial bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
011
15.08.2004, 18:21
dp
Administrator


Zitat:
dp postete
Zu den Entityproperties - Viele davon (name, target, delay before trigger, usw.) sind in vielen Entities verwendet, man also eine n:m relation Entity:Property. Wie würde man das mit XML machen? Wenn man wie oben, für jedes Entity das "name"-Property definiert hat man ja eine riesig große Redundanz.
Damit ist das für ne Ent Bibliothek bisschen hinfällig oder?

--

zum Seitenanfang zum Seitenende Profil || Suche