Thread: [DSA Manager] Element-Klassen (Entwurf 1)
Status: Planning
Brought to you by:
alexnofftz
Menu
▾
▴
dsaman-list
|
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-14 12:35:29
|
Hi!
Ich habe mir mal Gedanken zu meiner Klassierungsidee gemacht. Wenn ich
jetzt hergehe, und teile jedes Element, das wir im DSA Manager verwenden
wollen, in eine hierarchische Klassenstruktur mit Mehrfachvererbung ein,
kann man sehr viele Konflikte, auf die wir bisher gestoßen sind, lösen:
DSA Manager
|
|--> Charakter-Daten
| |
| |--> Beschreibung (Name, Alter, Größe...)
| |
| |--> Meta-Eigenschaften (abgeleitete Werte)
| |
| |--> Eigenschaften
| | |
| | |--> Nicht steigerbar (AT, PA, MR, ST, SO...)
| | |
| | \--> Steigerbar
| | |
| | |--> Gute Eigenschaften (MU, KL...)
| | |
| | \--> Schlechte Eigenschaften
| |
| |--> Variablen (LeP, AsP, AP...)
| |
| |--> Vor- und Nachteile
| | |
| | |--> Nachteile
| | |
| | \--> Vorteile
| |
| |--> Sonderfertigkeiten und Manöver
| | |
| | |--> Sonderfertigkeiten
| | |
| | \--> Manöver
| |
| |--> Talente und Zauber
| | |
| | |--> Talente
| | | |
| | | |--> Kampftalente
| | | |
| | | |--> Körperliche Talente
| | | ...
| | |
| | \--> Zauber
| | |
| | |--> Antimagie
| | ...
| |
| \--> Herkunft
| |
| |--> Rasse
| |
| |--> Kultur
| |
| \--> Profession
|
|--> Ausrüstung
| |
| |--> Kampf
| | |
| | |--> Waffen
| | |
| | \--> Rüstungen
| | |
| | |--> Stoff
| | |
| | |--> Metall
| | |
| | |--> Leder
| | |
| | |--> Helme
| | |
| | |--> Torso
... ... ...
Wie man sehen kann, sind etwa die schlechten Eigenschaften gleichzeitig
Nachteile und Eigenschaften, damit können wir wohl einige Diskussionen
leicht lösen ;-)
Außerdem kann man jedes Element mehreren Klassen zuordnen, damit könnte
man z.B. einen Lederhelm gleichzeitig unter Leder und unter Helme einordnen.
Zugeordnet wird alles über das class-Attribut, das als NMTOKEN definiert
ist (wie unter HTML auch):
<property id="MU" class="EigGut">
...
</property>
...
<advantage id="NatJähzorn" class="Nachteil EigSchlecht">
Das mit <advantage> ist Absicht, die Einordnung in Vor- und Nachteile
ist rein bedeutungsbezogen und hat für die Definition keinen Einfluss,
denn dies wird über die Klasse fest gelegt. Denkbar wäre auch:
<property id="NatJähzorn" class="Nachteil EigSchlecht">
Vielleicht sogar besser, wegen der Senkungsregeln.
Jetzt kommt der zweite Clue: Alle Klassen erben alle Definitionen,
Modifikationen etc. ihrer Vaterklasse!
Damit brauche ich z.B. bei den schlechten Eigenschaften nur einmal
festzulegen, dass statt zum Steigern dem Base-Wert (21-Base) heran
gezogen werden soll, und schon kann ich die schlechten Eigenschaften wie
normale Eigenschaften definieren.
Dritter Punkt: Da alle Elemente ebenfalls in diese Klassenstrukur
eingeordnet sind, brauche ich mich für Ableitungen oder den
Charakterbögen nur darauf zu beziehen:
<property id="MyJähzorn" ref="NatJähzorn">
<value base="7"/>
</property>
Eventuell kann man das ref-Attribut sogar als xlink definieren, aber mal
schauen, was Xerces aus solchen Angaben macht...
Bis dann,
Alex
--
Alexander Nofftz, Leverkusen, Germany
http://www.AlexNofftz.de Ale...@em...
|
|
From: Oliver S. <os...@ep...> - 2001-11-14 14:27:19
|
Hi!
> Ich habe mir mal Gedanken zu meiner Klassierungsidee gemacht. Wenn ich
> jetzt hergehe, und teile jedes Element, das wir im DSA Manager verwenden
> wollen, in eine hierarchische Klassenstruktur mit Mehrfachvererbung ein,
> kann man sehr viele Konflikte, auf die wir bisher gestoßen sind, lösen:
>
> DSA Manager
Besser: DSA. Wir wollen nicht unser Programm beschreiben, sondern
das DSA-Regelsystem. Vielleicht wird diese Struktur ja auch mal
außerhalb des Managers benutzt.
> | |--> Eigenschaften
> | | |--> Nicht steigerbar (AT, PA, MR, ST, SO...)
> | | \--> Steigerbar
Besser anders. Man weiß nie, was plötzlich doch steigerbar sein
wird. Und auf einige Sachen kann man z.B. Boni kaufen.
Die Klassifizierung aus der dsadmin-Struktur finde ich hier DSA
angemessener.
> Wie man sehen kann, sind etwa die schlechten Eigenschaften gleichzeitig
> Nachteile und Eigenschaften, damit können wir wohl einige Diskussionen
> leicht lösen ;-)
Inwiefern genau?
> Außerdem kann man jedes Element mehreren Klassen zuordnen, damit könnte
> man z.B. einen Lederhelm gleichzeitig unter Leder und unter Helme
> einordnen.
> Zugeordnet wird alles über das class-Attribut, das als NMTOKEN definiert
> ist (wie unter HTML auch):
NMTOKEN kommt nicht in Frage. NMTOKEN darf Dinge wie ":", "-", etc. enthalten.
Das gibt Operatorenkonflikte, außer die ID's kommen immer in Quotes.
> <property id="MU" class="EigGut">
> ...
> </property>
[...]
> ...
> <advantage id="NatJähzorn" class="Nachteil EigSchlecht">
Das geht mir zu weit. Wenn man nachher für alles das gleiche
Tag hat, verliert man alle Vorteile, die XML bietet. Abgesehen
davon sind Eigenschaften und Vorteile z.B. wirklich nicht das
gleiche. Basiseigenschaften haben Eigenschaftswerte, machen
aber keine action's, ... Das sind verschiedene Elemente mit
verschiedenen Attributen und verschiedenen möglichen Kindern.
> Das mit <advantage> ist Absicht, die Einordnung in Vor- und Nachteile
> ist rein bedeutungsbezogen und hat für die Definition keinen Einfluss,
Du hast schon recht, da advantage und disadvantage Tag genau die selbe
Definition haben werden, könnte man sie zusammenlegen.
Ich würd's dennoch lassen, denn man wird Vor- und Nachteile oft
getrennt handeln, und dann im Programm aufgrund der ersten
Buchstaben der ID's zu trennen ist nicht wirklich elegant.
> <property id="MU" class="EigGut">
...
> </property>
> <property id="NatJähzorn" class="Nachteil EigSchlecht">
Man kann nich fast alles in einen Topf werfen. Entweder verwendet
man verschiedene Elemente (sprich Tags) für verschiedene Dinge,
oder man benutzt XML als Meta-Sprache, um damit eine komplettes
Klassensystem nachzuprogrammieren. Das ist aber en gewaltiger Aufwand
(und man kann dann gleich ein Ontologie-System nehmen), und man
muß alles plötzlich wieder selbst machen. Auch Style-Sheet für
sowas werden XSLT vermutlich über seine Grenzen hinaus fordern.
Ich denke nicht, das das wirklich nötig ist.
Auch die Mehrfachvererbung löst nicht nur Probleme, sondern
schafft ganz eigene. XML ist geeignet für eine direkte
Hierarchie, nicht für Mehrfachvererbung.
Im Falle Rüstungen z.B. kann man einfach Rüstungstyp und
-material als zwei Eigenschaften einer Rüstung speichern.
Beides sind zentrale Faktoren, die das durchaus verdient haben.
> Vielleicht sogar besser, wegen der Senkungsregeln.
>
>
>
> Jetzt kommt der zweite Clue: Alle Klassen erben alle Definitionen,
> Modifikationen etc. ihrer Vaterklasse!
>
> Damit brauche ich z.B. bei den schlechten Eigenschaften nur einmal
> festzulegen, dass statt zum Steigern dem Base-Wert (21-Base) heran
> gezogen werden soll, und schon kann ich die schlechten Eigenschaften wie
> normale Eigenschaften definieren.
Sowas hatte ich mal angedacht, aber: Es kommt gar nicht so
häufig vor, das was vererbt wird (Die Attribute ein Beispiel,
aber so viel anderes gibts nicht). Ich denke, es besser, in
den paar Fällen die Dinge mehrfach anzugeben.
> Dritter Punkt: Da alle Elemente ebenfalls in diese Klassenstrukur
> eingeordnet sind, brauche ich mich für Ableitungen oder den
> Charakterbögen nur darauf zu beziehen:
>
> <property id="MyJähzorn" ref="NatJähzorn">
> <value base="7"/>
> </property>
value reicht nicht aus. Manche Dinge haben mehrere Werte (z.B. TaW und AT Wert
bei Talenten). Verschiedene Wert-Typen sollten verschiedene Tags haben.
Und man braucht auch hier nicht zwangsläufig Vererbung. Es ist eh mehr
eine Instanziierung.
> Eventuell kann man das ref-Attribut sogar als xlink definieren, aber mal
> schauen, was Xerces aus solchen Angaben macht...
Bitte nicht alle Cutting-Edge Features von Xerces ausnutzen, wir
werden Xerces für C++ vermutlich nicht benutzen.
cu
Oli
|
|
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-14 15:02:03
|
Hi Oliver! >> DSA Manager >> > > Besser: DSA. Wir wollen nicht unser Programm beschreiben, sondern > das DSA-Regelsystem. Vielleicht wird diese Struktur ja auch mal > außerhalb des Managers benutzt. Oder wir bleiben bei der "Wurzel" aller Bezeichnungen und nennen das Ding root ;-) >> | |--> Eigenschaften >> | | |--> Nicht steigerbar (AT, PA, MR, ST, SO...) >> | | \--> Steigerbar > > Besser anders. Man weiß nie, was plötzlich doch steigerbar sein > wird. Dann kann man die Klassenbezeichnung ja überschreiben. > Und auf einige Sachen kann man z.B. Boni kaufen. Ja, aber so etwas sehe ich eher als Vorteil an. LE kann man doppelt aufführen, einmal die Basis-LE unter "Meta-Eigenschaften" und dann die gekauften LeP als steigerbare Eigenschaft, das kommt auch der Regel sehr nahe. >>Wie man sehen kann, sind etwa die schlechten Eigenschaften gleichzeitig >>Nachteile und Eigenschaften, damit können wir wohl einige Diskussionen >>leicht lösen ;-) > > Inwiefern genau? Nun, schlechte Eigenschaften gelten als Nachteil, haben aber in gegesatz zu diesen einen Wert und sind "steigerbar", also genau wie Eigenschaften. >>Zugeordnet wird alles über das class-Attribut, das als NMTOKEN definiert >>ist (wie unter HTML auch): > > NMTOKEN kommt nicht in Frage. NMTOKEN darf Dinge wie ":", "-", etc. enthalten. > Das gibt Operatorenkonflikte, außer die ID's kommen immer in Quotes. Was willst du mit : und - in den Namen? Die kann man ja explizit ausschießen. >> <property id="MU" class="EigGut"> >> ... >> </property> >> > [...] > >> ... >> <advantage id="NatJähzorn" class="Nachteil EigSchlecht"> >> > > Das geht mir zu weit. Wenn man nachher für alles das gleiche > Tag hat, verliert man alle Vorteile, die XML bietet. Ein Tag für jede *Oberklasse* von Objekten, also eine für Eigenschaften, eine für Vor- und Nachteile, eine für Talente und Zauber, also alles, was sich nur minimal unterscheidet. > Abgesehen > davon sind Eigenschaften und Vorteile z.B. wirklich nicht das > gleiche. Basiseigenschaften haben Eigenschaftswerte, machen > aber keine action's, ... Das sind verschiedene Elemente mit > verschiedenen Attributen und verschiedenen möglichen Kindern. Richtig, eine Eigenschaft mit <action>s habe ich Meta-Eigenschaft genannt, kann man ja dann auch als <meta-property> definieren. >>Das mit <advantage> ist Absicht, die Einordnung in Vor- und Nachteile >>ist rein bedeutungsbezogen und hat für die Definition keinen Einfluss, >> > > Du hast schon recht, da advantage und disadvantage Tag genau die selbe > Definition haben werden, könnte man sie zusammenlegen. > Ich würd's dennoch lassen, denn man wird Vor- und Nachteile oft > getrennt handeln, und dann im Programm aufgrund der ersten > Buchstaben der ID's zu trennen ist nicht wirklich elegant. Nein, das geht anhand der Klasse. Die ersten drei Buchstaben sollen nur klar machen, auf was die ID sich bezieht und von vornerein einige Namenskollisionen ausschließen. Macht man in großen Klassenbibliotheken ja auch so. >><property id="MU" class="EigGut"> > ... >></property> >><property id="NatJähzorn" class="Nachteil EigSchlecht"> > > Man kann nich fast alles in einen Topf werfen. Nicht alles, aber denke mal streng nach, worin sich die guten und die schlechten Eigenschaften wirklich unterscheiden, außer der logischen Einordnung unter "Nachteile" und den abgewandelten Steigerungsregeln (zu denen ich schon was geschrieben hatte) eigentlich überhaupt nicht. > Auch die Mehrfachvererbung löst nicht nur Probleme, sondern > schafft ganz eigene. XML ist geeignet für eine direkte > Hierarchie, nicht für Mehrfachvererbung. Die Mehrfachvererbung bezieht sich ja nicht auf das XML, sondern darauf, wie der DSA Manager die darin enthaltenen Daten auswertet. Wenn ich z.B. alle Tags heraussuche, deren Klasse "Nachteil" enthält, erhalte ich alle Nachteile, auch die schlechten Eigenschaften. Will ich eine Liste aller Talente haben, suche ich nach der Klasse "Talente". Will ich nur die Kampfzauber haben, suche ich nach der entsprechenden Klasse etc. >>Damit brauche ich z.B. bei den schlechten Eigenschaften nur einmal >>festzulegen, dass statt zum Steigern dem Base-Wert (21-Base) heran >>gezogen werden soll, und schon kann ich die schlechten Eigenschaften wie >>normale Eigenschaften definieren. > > Sowas hatte ich mal angedacht, aber: Es kommt gar nicht so > häufig vor, das was vererbt wird (Die Attribute ein Beispiel, > aber so viel anderes gibts nicht). Ich denke, es besser, in > den paar Fällen die Dinge mehrfach anzugeben. Es kommt vor bei: - Eigenschaften - Meta-Eigenschaften - Vorteilen, Nachteilen - Talenten (erben aus der Talentgruppe) - Talent-Spezialisierungen - Rüstungs- und Waffenkategorien Soll ich weitermachen? ;-) >>Dritter Punkt: Da alle Elemente ebenfalls in diese Klassenstrukur >>eingeordnet sind, brauche ich mich für Ableitungen oder den >>Charakterbögen nur darauf zu beziehen: >> >> <property id="MyJähzorn" ref="NatJähzorn"> >> <value base="7"/> >> </property> >> > > value reicht nicht aus. Manche Dinge haben mehrere Werte (z.B. TaW und AT Wert > bei Talenten). Verschiedene Wert-Typen sollten verschiedene Tags haben. > Und man braucht auch hier nicht zwangsläufig Vererbung. Es ist eh mehr > eine Instanziierung. Die AT/PA-Werte sind ein Sonderfall, ansonsten reicht <value> wirklich. Warum unterschiedliche Tags für Dinge definieren, die im Grunde dasselbe meinen? >>Eventuell kann man das ref-Attribut sogar als xlink definieren, aber mal >>schauen, was Xerces aus solchen Angaben macht... > > Bitte nicht alle Cutting-Edge Features von Xerces ausnutzen, wir > werden Xerces für C++ vermutlich nicht benutzen. Bestimmt nicht, aber wenn ihr den C++-Xerces verwendet, stellen wir sicher, dass die XML-Datei gleich ausgewertet und gespeichert werden. Vielleicht macht eine andere Bibliothek einige Dinge minimal anders, und dann sind die Dateien nach ein paar Mal laden, steigen und speichern nicht mehr kompatibel... Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
|
From: Oliver S. <os...@ep...> - 2001-11-14 15:43:39
|
> > Sowas hatte ich mal angedacht, aber: Es kommt gar nicht so > > häufig vor, das was vererbt wird (Die Attribute ein Beispiel, > > aber so viel anderes gibts nicht). Ich denke, es besser, in > > den paar Fällen die Dinge mehrfach anzugeben. > > - Vorteilen, Nachteilen Welche Vorteile erben denn wirklich viele Werte voneinander? > - Talenten (erben aus der Talentgruppe) Was erben sie denn davon für Werte? Eigentlich nur ihre Steigerungsspalte. Und Talente erben nicht voneinander, auch Talentgruppen kaum. Das ist eher eine Hierarchie ohne Weitergabe von vielen Werten. Und wenn, wird nur besteht die Vererbung nur aus zwei Ebenen. > - Talent-Spezialisierungen Das muß man nicht zwangsläufig als Vererbung betrachten, Es kann auch EIN Talen mit Spezialisierungseigenschaft sein. Es gibt keine Subspezialisierungen, also auch hier keine tiefe Staffelung. > - Rüstungs- und Waffenkategorien > >> <property id="MyJähzorn" ref="NatJähzorn"> > >> <value base="7"/> [...] > > value reicht nicht aus. Manche Dinge haben mehrere Werte (z.B. TaW und AT [...] > Die AT/PA-Werte sind ein Sonderfall, ansonsten reicht <value> wirklich. Eine so gewaltig allgemeine Struktur wie die vorgeschlagene sollte dann wenigstens ohne Sonderfälle auskommen. Sonst lohnt der Aufwand erst recht nicht. > Warum unterschiedliche Tags für Dinge definieren, die im Grunde dasselbe > meinen? Weil z.B. XSLT seine Grenzen hat. Und weil es auch andere Dinge einfacher macht. Weil es Übersicht schaffen kann. Und weil es dadurch in einigen Fällen deutlich weniger kostet als es spart. > Bestimmt nicht, aber wenn ihr den C++-Xerces verwendet, stellen wir > sicher, dass die XML-Datei gleich ausgewertet und gespeichert werden. > Vielleicht macht eine andere Bibliothek einige Dinge minimal anders, und > dann sind die Dateien nach ein paar Mal laden, steigen und speichern > nicht mehr kompatibel... Da geht's schon los: Xerces C++ hat nämlich noch gar keine vernünftige Routine zum XML-Dateien schreiben, Xerces Java schon ... :-( Ich sehe kein Problem. XML ist ein Standard, die Dateien müssen so strukturiert werden, daß JEDER Parser damit klar kommt. Egal, wie oft geladen und gespeichert wird. Bei Dingen wie Whitespace und so müssen wir klar festlegen, was passieren soll. Es macht keinen Sinn XML zu verwenden, und dann einen Parser vorzuschreiben. Das stellt ja den ganzen Sinn von XML auf den Kopf! cu Oli |
|
From: Andreas H. <ahu...@gm...> - 2001-11-14 15:44:19
|
Hi, On Wednesday 14 November 2001 16:01, Alexander Nofftz wrote: > >> | |--> Eigenschaften > >> | | > >> | | |--> Nicht steigerbar (AT, PA, MR, ST, SO...) > >> | | > >> | | \--> Steigerbar > > > > Besser anders. Man weiß nie, was plötzlich doch steigerbar sein > > wird. > > Dann kann man die Klassenbezeichnung ja überschreiben. Aber man sollte an der Datenstruktur nacher so wenig wie moeglich aendern müssen. > > Und auf einige Sachen kann man z.B. Boni kaufen. > > Ja, aber so etwas sehe ich eher als Vorteil an. LE kann man doppelt > aufführen, einmal die Basis-LE unter "Meta-Eigenschaften" und dann die > gekauften LeP als steigerbare Eigenschaft, das kommt auch der Regel sehr > nahe. > > >>Wie man sehen kann, sind etwa die schlechten Eigenschaften gleichzeitig > >>Nachteile und Eigenschaften, damit können wir wohl einige Diskussionen > >>leicht lösen ;-) > > > > Inwiefern genau? > > Nun, schlechte Eigenschaften gelten als Nachteil, haben aber in gegesatz > zu diesen einen Wert und sind "steigerbar", also genau wie Eigenschaften. Und du kannst alle Nachteile mit EXP wegbekommen, also wegsteigern. "Die" schlechte eigenschaft gibt es nicht mehr es gibt nur noch Eigenschaten, Vorteile und Nachteile. Und bei den Nachteilen gibt es welche die so aussehen wie die schlechten Eigenschaften von DSA3. Doch es sind Nachteile und können wie alle anderen Nachteile auch weggesteigert werden > >>Zugeordnet wird alles über das class-Attribut, das als NMTOKEN definiert > >>ist (wie unter HTML auch): > > > > NMTOKEN kommt nicht in Frage. NMTOKEN darf Dinge wie ":", "-", etc. > > enthalten. Das gibt Operatorenkonflikte, außer die ID's kommen immer in > > Quotes. > > Was willst du mit : und - in den Namen? Die kann man ja explizit > ausschießen. > > >> <property id="MU" class="EigGut"> > >> ... > >> </property> > > > > [...] > > > >> ... > >> <advantage id="NatJähzorn" class="Nachteil EigSchlecht"> > > > > Das geht mir zu weit. Wenn man nachher für alles das gleiche > > Tag hat, verliert man alle Vorteile, die XML bietet. > > Ein Tag für jede *Oberklasse* von Objekten, also eine für Eigenschaften, > eine für Vor- und Nachteile, eine für Talente und Zauber, also alles, > was sich nur minimal unterscheidet. > > > Abgesehen > > davon sind Eigenschaften und Vorteile z.B. wirklich nicht das > > gleiche. Basiseigenschaften haben Eigenschaftswerte, machen > > aber keine action's, ... Das sind verschiedene Elemente mit > > verschiedenen Attributen und verschiedenen möglichen Kindern. > > Richtig, eine Eigenschaft mit <action>s habe ich Meta-Eigenschaft > genannt, kann man ja dann auch als <meta-property> definieren. > > >>Das mit <advantage> ist Absicht, die Einordnung in Vor- und Nachteile > >>ist rein bedeutungsbezogen und hat für die Definition keinen Einfluss, > > > > Du hast schon recht, da advantage und disadvantage Tag genau die selbe > > Definition haben werden, könnte man sie zusammenlegen. > > Ich würd's dennoch lassen, denn man wird Vor- und Nachteile oft > > getrennt handeln, und dann im Programm aufgrund der ersten > > Buchstaben der ID's zu trennen ist nicht wirklich elegant. > > Nein, das geht anhand der Klasse. Die ersten drei Buchstaben sollen nur > klar machen, auf was die ID sich bezieht und von vornerein einige > Namenskollisionen ausschließen. Macht man in großen Klassenbibliotheken > ja auch so. > > >><property id="MU" class="EigGut"> > > > > ... > > > >></property> > >><property id="NatJähzorn" class="Nachteil EigSchlecht"> > > > > Man kann nich fast alles in einen Topf werfen. > > Nicht alles, aber denke mal streng nach, worin sich die guten und die > schlechten Eigenschaften wirklich unterscheiden, außer der logischen > Einordnung unter "Nachteile" und den abgewandelten Steigerungsregeln (zu > denen ich schon was geschrieben hatte) eigentlich überhaupt nicht. Doch es gibt einen ganz gewaltigen Unterschied ... jeder hat alle Eigenschaften ( ich lasse das gut jetzt weg) aber nicht jeder muß Nachteile haben. Nachteile koennen auch nicht von Vorteilen betroffen sein, zb von herausragende Eigenschaft, was aber wenn man es unter Eigenschaft legt passieren kann. > > Auch die Mehrfachvererbung löst nicht nur Probleme, sondern > > schafft ganz eigene. XML ist geeignet für eine direkte > > Hierarchie, nicht für Mehrfachvererbung. > > Die Mehrfachvererbung bezieht sich ja nicht auf das XML, sondern darauf, > wie der DSA Manager die darin enthaltenen Daten auswertet. Wenn ich z.B. > alle Tags heraussuche, deren Klasse "Nachteil" enthält, erhalte ich alle > Nachteile, auch die schlechten Eigenschaften. Will ich eine Liste aller > Talente haben, suche ich nach der Klasse "Talente". Will ich nur die > Kampfzauber haben, suche ich nach der entsprechenden Klasse etc. Nachteile >= Schlechte Eigenschaft , sprich schlechte Eigenschaften sind eine Teilmenge der Nachteile.. > >>Damit brauche ich z.B. bei den schlechten Eigenschaften nur einmal > >>festzulegen, dass statt zum Steigern dem Base-Wert (21-Base) heran > >>gezogen werden soll, und schon kann ich die schlechten Eigenschaften wie > >>normale Eigenschaften definieren. > > > > Sowas hatte ich mal angedacht, aber: Es kommt gar nicht so > > häufig vor, das was vererbt wird (Die Attribute ein Beispiel, > > aber so viel anderes gibts nicht). Ich denke, es besser, in > > den paar Fällen die Dinge mehrfach anzugeben. > > Es kommt vor bei: > > - Eigenschaften > - Meta-Eigenschaften > - Vorteilen, Nachteilen > - Talenten (erben aus der Talentgruppe) > - Talent-Spezialisierungen > - Rüstungs- und Waffenkategorien > > Soll ich weitermachen? ;-) > > >>Dritter Punkt: Da alle Elemente ebenfalls in diese Klassenstrukur > >>eingeordnet sind, brauche ich mich für Ableitungen oder den > >>Charakterbögen nur darauf zu beziehen: > >> > >> <property id="MyJähzorn" ref="NatJähzorn"> > >> <value base="7"/> > >> </property> > > > > value reicht nicht aus. Manche Dinge haben mehrere Werte (z.B. TaW und AT > > Wert bei Talenten). Verschiedene Wert-Typen sollten verschiedene Tags > > haben. Und man braucht auch hier nicht zwangsläufig Vererbung. Es ist eh > > mehr eine Instanziierung. > > Die AT/PA-Werte sind ein Sonderfall, ansonsten reicht <value> wirklich. > Warum unterschiedliche Tags für Dinge definieren, die im Grunde dasselbe > meinen? > > >>Eventuell kann man das ref-Attribut sogar als xlink definieren, aber mal > >>schauen, was Xerces aus solchen Angaben macht... > > > > Bitte nicht alle Cutting-Edge Features von Xerces ausnutzen, wir > > werden Xerces für C++ vermutlich nicht benutzen. > > Bestimmt nicht, aber wenn ihr den C++-Xerces verwendet, stellen wir > sicher, dass die XML-Datei gleich ausgewertet und gespeichert werden. > Vielleicht macht eine andere Bibliothek einige Dinge minimal anders, und > dann sind die Dateien nach ein paar Mal laden, steigen und speichern > nicht mehr kompatibel... wieso sollten sie .. wenn man klare regeln definiert wie die Datei auszusehen hat muss man diese mit der entsprechenden lib umsetzen können. Wenn sich die ergebnisse dann doch unterscheiden liegts an einen schlechten definition oder am unvermögen des Menschen an der Tastatur. ;-) Ausserdem ist doch idee eines C++ frontend die, das wenig Ressourcen benötigt werden.... Bye Andreas P.S. Bitte verzeiht meine tippselfehler.. .ich hab hier 2 ami und 1 deutsche tastatur.... |
|
From: Oliver S. <da...@we...> - 2001-11-14 15:28:16
|
Hi Leute! Wir sind an dem üblichen Punkt angekommen, wo wir entscheiden müssen, wie allgemein unser Ansatz sein soll. Das klassische Problem: Wählt man den Ansatz zu eng, fährt man früher oder später gegen eine Steinwand. Wählt man ihn zu weit, fährt man sofort vor eine Wand. Die ist dann nur aus Gummi, aber sehr dick. Im Moment diskutieren wir zu viele Einzelfälle, es gibt für alles immer ein Beispiel dafür und dagegen, aber noch keinen Gesamtüberblick. Den brauchen wir, und den werden wir uns jetzt holen! Dazu folgender Vorschlag: Wir machen eine Liste mit ALLEN Elementen, die es gibt (Attribute, Vorteile, Nachteile, schlechte Eigenschaften, Rüstungen, ...), und führen bei allen getrennt ALLE Eigenschaften auf, die sie haben (TaW, Steigerungskosten, Anschaffungskosten, Attacke, Parade, Bruchfaktor, Ausprägung, Spezialisierung, ...). Und zwar noch nicht hierarchisch, sondern alles nebeneinander. Wenn jemand meint (bei geringstem Verdacht!), ein Element oder eine Elementeigenschaft könnte fehlen, sofort dazupacken. Wenn jemand meint, ein Element könnte eine Zusammenfassung zweier leicht oder grob verschiedener Dinge sein, sofort auftrennen. Wir sammeln erst alles, machen dann Fehlerkorrektur, und DANN werden wir sehen können, wie die "natürliche" Struktur ausschaut, und wie unsere aussehen kann und wie nicht. Da geben wir ein bischen Reserve dazu, und haben unseren Komplexitätsgrad. Damit wir dazu nicht immer irre lange Mails hin und her quoten, und vieles unterwegs verlorengeht, machen wir das im CVS. Wir legen in dsaman/data die Datei brainstorming.txt (oder anderer name) an, und sammeln da. Ich denke, auf die Weise kommen wir recht zügig weiter, und minimieren das Risiko eines Fehlers im Basisdesign (der Design-GAU schlechthin). OK? cu Oli |
|
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-14 16:07:53
|
Hi Oliver! > OK? OK, dann lade du aber das Grundgerüst hoch, damit nicht jeder mit seiner eigenen Basis anfängt ;-) Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
|
From: Oliver S. <os...@ep...> - 2001-11-14 16:18:17
|
Hi Alex! > OK, dann lade du aber das Grundgerüst hoch, damit nicht jeder mit seiner > eigenen Basis anfängt ;-) Ok, schon dabei. Ist aber auch nicht so kritisch. Jeder soll nach Herzenslust splitten und hinzufügen. Regel: Es wird erstmal nix gelöscht, das machen wir dann beim Korrekturdurchgang. cu Oli |
|
From: Oliver S. <os...@ep...> - 2001-11-14 16:42:50
|
Hi Leute! > OK, dann lade du aber das Grundgerüst hoch, damit nicht jeder mit seiner > eigenen Basis anfängt ;-) So, die Gerüstidee sollte jetzt stehen. Alle Mann ran! :-) cu Oli |
|
From: Andreas H. <ahu...@gm...> - 2001-11-14 17:31:46
|
Hi Oliver, Oliver Schulz wrote: >Hi Leute! > >>OK, dann lade du aber das Grundgerüst hoch, damit nicht jeder mit seiner >>eigenen Basis anfängt ;-) >> > >So, die Gerüstidee sollte jetzt stehen. Alle Mann ran! :-) > Aeh schoen, aber ich darf da nun angeblich kein upload machen .... cvs commit meldet das ich schreib rechte braeuchte .. Ja ich bin als developer mit cvs angemeldet ... Bye Andreas |
|
From: Matthias W. <Mat...@gm...> - 2001-11-15 09:39:01
|
Andreas Hugenroth wrote: > > Aeh schoen, aber ich darf da nun angeblich kein upload machen .... > cvs commit meldet das ich schreib rechte braeuchte .. > Ja ich bin als developer mit cvs angemeldet ... Und bei mir geht irgendwie gar nix. Nach ca. 50 blöden Tutorials läuft das Ding immer noch nicht. Dabei hab ichs mit SSH1 und mit SSH2 gemacht, zig Imgebungsvariablen, aber nix geht. Ich schick euch mal was: CVS_RSH: ssh CVSROOT: mw...@cv...:/cvsroot/dsaman HOME: C:\Programme\ssh HOMEDRIVE: C: HOMEPATH: \Programme\ssh USER: mwurm alle wichtigen Dinger sind natürlich im PATH drin, aber bei jedem checkout kriege ich nach einem: cvs co dsaman, aber auch bei dem ausführlichen: cvs -d:ext:mw...@cv...:/cvsroot/dsaman co dsaman den Fehler: Could not chdir to home directory /home/users/m/mw/mwurm: No such file or directory der erstellt mir zwar das Verzeichnis, aber da ist nix drin... Hattet ihr das auch schonmal ?? Ich hab jetzt nämlich echt keinen Plan mehr, was ich versuchen sollte Gruß Matthias |
|
From: Andreas H. <hug...@ba...> - 2001-11-15 11:22:33
|
Hi, ich hatte dasselbe Problem welches ich aber mit der Hilfe von Oliver lösen konnte. um dein Homeverzeichniss zu erstellen musst du erst per ssh auf den Server, also: ssh mw...@cv... ob das bei windows genauso aussieht weiss ich nun nicht, aber unter linux kam dann ne abfrage nach dem kennwort und eine meldung das mein homeverzeichniss erstellt wurde. Danach kannst du dann mit set(denke ich nunmal fuer windows) CVS_RSH: ssh cvs -z3 -d:ext:mw...@cv...:/cvsroot/dsaman co dsaman die aktuellen daten runterladen. Das sollte in ein leeren Ordner passieren da CVS sich merkt woher und wie die Daten geladen wurden, sprich sollte da noch ein "alter" dsaman ordner sein der mit anonymous geladen wurde, gehts nicht. Also vorher löschen oder aus anderen Verzeichniss ausführen. wenn du dann die brainstorming.txt aus dem Ordner dsaman/data geändert hast führst du in diesem Ordner ein cvs commit aus. Infos fuer log werden, unter Linux zumindest, danach abgefragt. Wie gesagt dieses cvsroot brauchst du beim ssh zugang nicht, geht damit eigentlich gar nicht. Ich hoffe das ich das alles richtig im kopf hatte ( bin noch auffe Arbeit) Bye Andreas -----Ursprüngliche Nachricht----- Von: dsa...@li... [mailto:dsa...@li...]Im Auftrag von Matthias Wurm Gesendet: Donnerstag, 15. November 2001 10:44 Cc: dsa...@li... Betreff: Re: [DSA Manager] CVS-Probleme Andreas Hugenroth wrote: > > Aeh schoen, aber ich darf da nun angeblich kein upload machen .... > cvs commit meldet das ich schreib rechte braeuchte .. > Ja ich bin als developer mit cvs angemeldet ... Und bei mir geht irgendwie gar nix. Nach ca. 50 blöden Tutorials läuft das Ding immer noch nicht. Dabei hab ichs mit SSH1 und mit SSH2 gemacht, zig Imgebungsvariablen, aber nix geht. Ich schick euch mal was: CVS_RSH: ssh CVSROOT: mw...@cv...:/cvsroot/dsaman HOME: C:\Programme\ssh HOMEDRIVE: C: HOMEPATH: \Programme\ssh USER: mwurm alle wichtigen Dinger sind natürlich im PATH drin, aber bei jedem checkout kriege ich nach einem: cvs co dsaman, aber auch bei dem ausführlichen: cvs -d:ext:mw...@cv...:/cvsroot/dsaman co dsaman den Fehler: Could not chdir to home directory /home/users/m/mw/mwurm: No such file or directory der erstellt mir zwar das Verzeichnis, aber da ist nix drin... Hattet ihr das auch schonmal ?? Ich hab jetzt nämlich echt keinen Plan mehr, was ich versuchen sollte Gruß Matthias _______________________________________________ Dsaman-list mailing list Dsa...@li... https://lists.sourceforge.net/lists/listinfo/dsaman-list |
|
From: Oliver S. <os...@ep...> - 2001-11-15 14:11:52
|
Hi! >> Und bei mir geht irgendwie gar nix. Nach ca. 50 blöden Tutorials läuft >> das Ding immer noch nicht. Dabei hab ichs mit SSH1 und mit SSH2 gemacht, >> zig Imgebungsvariablen, aber nix geht. Ich schick euch mal was: >> CVS_RSH: ssh >> CVSROOT: mw...@cv...:/cvsroot/dsaman >> HOME: C:\Programme\ssh >> HOMEDRIVE: C: >> HOMEPATH: \Programme\ssh >> USER: mwurm > Wie gesagt dieses cvsroot brauchst du beim ssh zugang nicht, geht damit > eigentlich gar nicht. Doch, kann man auch machen. Es muß dann aber CVSROOT=:ext:USE...@cv...:/cvsroot/dsaman heißen, das :ext: ist IMHO wichtig. Das HOME=... ist korrekt so, HOMEDRIVE und HOMEPATH braucht ssh.exe, soweit ich weiß, nicht. Ein Tipp noch zu SSH unter Win: Die ssh-keygen.exe, die bei der ssh.exe dabei ist funktioniert nicht. Es gibt unter http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html aber ein schönes Proggie namens Puttygen, das unter Windows ordentliche SSH-Keys generiert. Am einfachsten ist aber wirklich, das CVS-Root direkt im checkout-Befehl anzugeben, wie von Andreas beschrieben. Und natürlich muß das Homeverzeichnis wie beschrieben angelegt worden sein: > um dein Homeverzeichniss zu erstellen musst du erst per ssh auf den Server, > also: > > ssh mw...@cv... Das geht unter Win genauso wie unter Linux. cu Oli |
|
From: Andreas H. <ahu...@gm...> - 2001-11-14 15:48:39
|
Hi, ich war gerade am tippseln als dein Vorschlag kam... Ich wollte vorschlagen das wir mal ne Tabelle sammeln mit allen Elementen die es nun tatsächlich gibt .... wer fängt die Datei an , bzw wer kann diese verändern? Ich arbeite das erste mal mit sourcefourge und kenne die möglichkeiten noch nicht. Bye Andreas On Wednesday 14 November 2001 16:27, Oliver Schulz wrote: > Hi Leute! > > Wir sind an dem üblichen Punkt angekommen, wo wir entscheiden > müssen, wie allgemein unser Ansatz sein soll. Das klassische > Problem: Wählt man den Ansatz zu eng, fährt man früher oder > später gegen eine Steinwand. Wählt man ihn zu weit, fährt man > sofort vor eine Wand. Die ist dann nur aus Gummi, aber sehr > dick. > Im Moment diskutieren wir zu viele Einzelfälle, es gibt > für alles immer ein Beispiel dafür und dagegen, aber noch > keinen Gesamtüberblick. > Den brauchen wir, und den werden wir uns jetzt holen! > > Dazu folgender Vorschlag: Wir machen eine Liste mit > ALLEN Elementen, die es gibt (Attribute, Vorteile, > Nachteile, schlechte Eigenschaften, Rüstungen, ...), und > führen bei allen getrennt ALLE Eigenschaften auf, die sie > haben (TaW, Steigerungskosten, Anschaffungskosten, Attacke, > Parade, Bruchfaktor, Ausprägung, Spezialisierung, ...). > Und zwar noch nicht hierarchisch, sondern alles nebeneinander. > > Wenn jemand meint (bei geringstem Verdacht!), ein Element oder > eine Elementeigenschaft könnte fehlen, sofort dazupacken. Wenn > jemand meint, ein Element könnte eine Zusammenfassung zweier leicht > oder grob verschiedener Dinge sein, sofort auftrennen. > > Wir sammeln erst alles, machen dann Fehlerkorrektur, und > DANN werden wir sehen können, wie die "natürliche" Struktur > ausschaut, und wie unsere aussehen kann und wie nicht. > Da geben wir ein bischen Reserve dazu, und haben unseren > Komplexitätsgrad. > > Damit wir dazu nicht immer irre lange Mails hin und her > quoten, und vieles unterwegs verlorengeht, machen > wir das im CVS. Wir legen in dsaman/data die Datei > brainstorming.txt (oder anderer name) an, und sammeln da. > > Ich denke, auf die Weise kommen wir recht zügig weiter, > und minimieren das Risiko eines Fehlers im Basisdesign > (der Design-GAU schlechthin). > > OK? > > cu > Oli > > _______________________________________________ > Dsaman-list mailing list > Dsa...@li... > https://lists.sourceforge.net/lists/listinfo/dsaman-list |
|
From: Oliver S. <os...@ep...> - 2001-11-14 15:54:11
|
Hi Andreas! > ich war gerade am tippseln als dein Vorschlag kam... > Ich wollte vorschlagen das wir mal ne Tabelle sammeln mit allen Elementen Ich schlage vor, wir machen das als recht formlose Textdatei, da haben wir die größte Freiheit und können gut kommentieren. > wer fängt die Datei an , bzw wer kann diese verändern? Soweit ich sehe, sind Alex, Du, Matthias und ich alle CVS-zugriffsberechtigt, also kein Problem. Ich leg sie einfach mal an. > Ich arbeite das erste mal mit sourcefourge und kenne die möglichkeiten noch > nicht. Brauchst Du Tipps zum CVS-Zugang? cu Oli |
|
From: Oliver S. <os...@ep...> - 2001-11-14 16:07:00
|
> Soweit ich sehe, sind Alex, Du, Matthias und ich alle > CVS-zugriffsberechtigt, also kein Problem. > Ich leg sie einfach mal an. So, dsaman/data/brainstorming.txt ist da (noch fast nix drin). Tallyho! Alles rein! cu Oli |
|
From: Andreas H. <ahu...@gm...> - 2001-11-14 16:31:27
|
Hi Oliver, On Wednesday 14 November 2001 16:53, Oliver Schulz wrote: > Hi Andreas! > > > ich war gerade am tippseln als dein Vorschlag kam... > > Ich wollte vorschlagen das wir mal ne Tabelle sammeln mit allen Elementen > > Ich schlage vor, wir machen das als recht formlose Textdatei, da > haben wir die größte Freiheit und können gut kommentieren. > > > wer fängt die Datei an , bzw wer kann diese verändern? > > Soweit ich sehe, sind Alex, Du, Matthias und ich alle > CVS-zugriffsberechtigt, also kein Problem. > Ich leg sie einfach mal an. > > > Ich arbeite das erste mal mit sourcefourge und kenne die möglichkeiten > > noch nicht. > > Brauchst Du Tipps zum CVS-Zugang? wie ich was runterlade ist mir schon klar .. aber upload ? wie kann ich sicherstellen das wenn 4 leute nacheinander was verändern das alle änderungen reinkommen. Oder geht das nicht bei CVS ? Bye Andreas |
|
From: Oliver S. <os...@ep...> - 2001-11-14 16:47:38
|
Hi Andreas! > > Brauchst Du Tipps zum CVS-Zugang? > > wie ich was runterlade ist mir schon klar .. aber upload ? wie kann ich > sicherstellen das wenn 4 leute nacheinander was verändern das alle > änderungen reinkommen. Oder geht das nicht bei CVS ? Doch, genau das ist die große Leistung von CVS. CVS kann gleichzeitige Änderungen mehrerer Leute an der selben Datei handeln! Wenn Du cvs commit machst, integriert CVS Deine Änderungen mit denen der anderen. Nur falls wirklich zwei Leute die selbe Zeile geändert haben, mußt Du den entstehenden Konflikt manuell aufzulösen. Am besten für's Brainstorming sehr häufig commit'en. cu Oli |
Thanks for helping keep SourceForge clean.
X