dsaman-list Mailing List for DSA Manager (Page 28)
Status: Planning
Brought to you by:
alexnofftz
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(244) |
Dec
(108) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(169) |
Feb
(41) |
Mar
(29) |
Apr
(69) |
May
(98) |
Jun
(9) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
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: gandalf <ds...@tk...> - 2001-11-15 09:38:08
|
Hallo Entwickler ;-) Ich bin ein Freund von Matthias Wurm und studiere ebenfalls Info im 3.Semester in KA und wuerde gerne an diesem Projekt mitentwickeln. Einsatzmaesig denkbar im Java, XML, evtl. Parser-Bereich. Erfahrungen Bisher: XML mit guten XSLT,XPATH-Kenntnissen Java ohne GUI Etwas Client-Server, Multithreading in Java Vorschlaege zu dsaman/Was haltet ihr von?: 1. Entwicklung gemaess Model-View-Controller Modell 2. Aufbauen auf bestehende Projekte, z.B. Implementationen des XML-DataBase Working Draft von http://www.xmldb.org und/oder Unterprojekte von Apaches Jakarta-Project http://jakarta.apache.org, falls eine Netzversion etwickelt werden soll. Viele Gruesse, tilmann -- "Murphys law was not discovered by Murphy but by a man with the same name." Tilmann G. Kuhn http://www.tkuhn.de |
From: Oliver S. <os...@ep...> - 2001-11-14 23:37:33
|
Hi! > Im programm muesste dann wirklich beim erstellen des Helden ueberprueft > werden ob BegabungFuerTalent gewaehlt wurde oder nicht. Ich finde diese > vorgehensweise persoenlich besser. Wir sollten es unterlassen, das hart zu coden. Klar, dies ist ein schwieriger Fall, aber es wird nicht der einzige bleiben! > Denn ansonsten koennen wir sofort XML -> Java machen ;-) > Desweiteren ist es doch egal wo was in einer XML datei steht, wie soll > man dann Probleme loesen bei denen es auf eine Reihenfolge ankommt... Es ist nicht unbedingt egal. Die Reihenfolge von Attributen ist beliebig, ja, die von Elementen aber mitnichten. Man kann Sequenzen in XML problemlos darstellen. > zB. Vorteil Herausragende Eigenschaft Konstitution mit der Berechnung > der LE... > Das bedeutet natuerlich das wir uns fuer jeden Vorteil und Nachteil der > sich auf Werte beim Helden auswirkt etwas programmieren muessen, aber > ist es nicht egal ob wir uns beim erstellen der XML total verkrampfen > oder lieber 3 zeilen mehr beim Code... Es wird unübersichtlich, und da wir mit mehreren Sprachen parallel arbeiten, muß man dann immer zweimal anpassen, und dann aufpassen, daß man konsistent bleibt ... nicht schön. Wir kriegen das in den Daten hin! Aber erstmal machen wir jetzt das Sammeln fertig, schlage ich vor, sonst dreht sich das alles im Kreise. 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: 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 |
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 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: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: 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: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: 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: 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: 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. <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: 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 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. <da...@we...> - 2001-11-14 14:44:19
|
Hi Alex! > Genau, so ähnlich mache ich's bei Xtory ja auch, allerdings geht das in > HTML per <div>-Tag auch ;-) Ok: div, subdiv, ... ;-) Aber mal ernsthaft: <div> <h1>...</h1> <div> <h2> ... Neeee .... > > Vorschlag: Strukturelemente (section, ...) aus TeX (die Bezeichner > > sind eingängig), > > Klar, aber die Anordnung entspricht den HTML-Tags für Überschriften. In > dieser Hinsicht ist TeX sogar noch unübersichtlicher, weil da überhaupt > nicht strukutiert wird (von den LaTeX-Environments mal abgesehen, die Haarspalter! ;-) Ich meinte natürlich LaTeX, nicht TeX, TeX hat kein section, ... Es ging mit auch gar nicht um die Strukturierung von LaTeX Dokumenten, sonden darum, daß section & co. geeignete Bezeichner sind. cu Oli |
From: Oliver S. <os...@ep...> - 2001-11-14 14:38:49
|
Hi! > > man die nicht in Deutsch läßt. Die ID's sind ja eh sprachunabhängig, > > könnten auch nummern sein, ist ja nur text um's auf Dateiebene > > übersichtlich zu halten. > > Aha, und das gilt für Tags nicht? ;-) Nicht in der selben Weise, wie für die ID's. Eine ID könnte tatsächlich auch numerisch sein, für einen Tag oder ein Attribut wär's aber wirklich Blödsinn. Das sind schon verschiedene Dinge. Bei einem internationalisierten System sollten zumindest die Definition der Datenstruktur und ihre Elemente englisch sein. > Ich bin dafür, dass wir sowohl unter Java, als auch unter C++ Xalan von > xml.apache.org einsetzen, der kann nicht nur URNs, vor allem stellen wir > dann so sicher, dass wir dieselben Routinen zum Lesen und Schreiben der > XML-Dateien verwenden. Xalan ist eine XSLT-Engine, kein Parser. Der zugehörige Parser ist defaultmäßig Xerces. Den empfehle ich uneingeschränkt für Java, aber nicht für C++. Die C++ library ist mehrere MB groß, wenn man das IBM-Derivat (XML4C) mit Unicode Klassen nimmt gleich 10-20 MB. Da fahren wir mit libxml2 (<1MB) wirklich besser! Wir brauchen nicht den selben Parser, und Xerces C kann eh nicht genau das Gleiche wie Xerces Java. > >>> <short-name xml:lang="de">MU</short-name> > >> > >>Der short-name sollte der ID sein, daher ist diese Zeile eigentlich > >>unnötig. > > > > IMHO nicht, denn eine ID ist sprachunabhängig, während der > > short-name in verschiedenen Sprachen auf Char.Bögen auftauchen > > kann. > > >>> <advantage id="special-possession" specialisation="required" cost="12"> [...] > Gut, aber dafür gibt es eine viel bessere Regel, nämlich die SO*SO*SO > Silbertaler, die man zu beginn bekommt ;-) :-) Der Vorteil soll erzielen, das die Leute nicht am Anfang alles kaufen können (Oder anders gesagt: Nur mit Geld sind manche Dinge nicht zu haben, man braucht Beziehungen, etc. Das kostet GP). > > Irgendwie muß man jedenfalls darstellen, daß es bei den Talenten > > nochmal Unterkategorien gibt. Die werden leider in einigen > > Vor- und Nachteilen, Steigernungskosten, usw. auch benutzt. > > Ja, aber das Thema hat sich jetzt durch die Klassen erledigt. Ich denke nicht, siehe meine Mail zum Klassenkonzept. Besser, man stellt solche Strukturen direkt dar. > So, wie's momentan aussieht, kommen wir wohl ohne spezielle Reihenfolge > aus. Notfalls könnte man ja Prioritäten zuordnen. Wollen wirs hoffen! :-) > > Dann zwei Charaktere, einer von jedem, auf dem selben System > > zusammenkommen, gibts einen bösen Konflikt. [...] > Na, dann... Aber wie willst du sicherstellen, dass kein Hexcode doppelt > vorkommt? Kein Problem: MD5-Hash über die gesamte Definition. Wem das nicht reicht, der mag noch eine Zufallszahl reinbauen. Wer dann immer noch Konflikte befürchtet, den laß ich meinen Lottoschein ausfüllen ... ;-) > > gibts Fälle, wo ein Gegenstand wirklich in mehrere Klassen muß? > > Ja, z.B. der in der anderen Mail angesprochene Lederhelm. Ich muss > wissen, dass es Leder ist (wegen der Rüstungskombination), und ich muss Besser Material und Typ der Rüstung getrennt speichern. cu Oli |
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 13:25:08
|
Hi Oliver! > Sondern besser > > <section> > <title>bla</title> > > <p> Text Text Text</p> > <p> Text Text Text</p> > > <subsection> > <title>bla bla</title> > > <p> Text <em>Text</em> Text</p> > <p> Text Text Text</p> > </subsection> > </section> Genau, so ähnlich mache ich's bei Xtory ja auch, allerdings geht das in HTML per <div>-Tag auch ;-) > Vorschlag: Strukturelemente (section, ...) aus TeX (die Bezeichner > sind eingängig), Klar, aber die Anordnung entspricht den HTML-Tags für Überschriften. In dieser Hinsicht ist TeX sogar noch unübersichtlicher, weil da überhaupt nicht strukutiert wird (von den LaTeX-Environments mal abgesehen, die aber nur eine Formatierungsgliederung, keine logische Gliederung ergeben). Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Oliver S. <da...@we...> - 2001-11-14 13:13:24
|
> <em> steht doch für emphasis, wie das \emph von LaTeX auch. Bei > Xtory-System von http://www.proc.org/stories/ erstelle ich acht > unterschiedliche Formate auf der Basis von XLST und gehe im Grunde > genommen von HTML aus. Wollt ihr mal ein Beispiel haben? ;-) Es ist zwar eigentlich nicht so weltbewegend, wie wirs nennen. Ein Punkt ist da aber: Zu sehr HTML-like ist schlecht, weil HTML nicht sauber hierarchisch strukturiert. Das ist XML nicht angemessen. Also nicht <h1>bla</h1> <p> Text <em>Text</em> Text</p> <p> Text Text Text</p> <h2>bla bla</h2> <p> Text Text Text</p> <p> Text Text Text</p> Sondern besser <section> <title>bla</title> <p> Text Text Text</p> <p> Text Text Text</p> <subsection> <title>bla bla</title> <p> Text <em>Text</em> Text</p> <p> Text Text Text</p> </subsection> </section> Das ist strukturell besser und läßt mehr Möglichkeiten für XSLT & Co. offen. Vorschlag: Strukturelemente (section, ...) aus TeX (die Bezeichner sind eingängig), der Rest (p, e, strong, ...) aus HTML (kennen viele), aber auf eine sinnvolle Auswahl beschränkt. Dazu dann noch ein paar RPG-spezifische Dinge (slinfo, und so). cu Oli |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-14 13:00:05
|
Hi Oliver! Oliver Schulz wrote: >>Mal zur Verdeutlichung mein DOCTYPE für die Charaktere: >> -//FANPRO//DTD DSA Charakter 1.0//DE >>und als Gegenbeispiel mal der von XHTML: >>Fällt dir was auf? ;-) >> > > Das hat aber mit dem Inhalt ja nix zu tun. Deutsche > XHTML Seiten können auch doctype -//W3C//DTD XHTML 1.1//EN > haben. Stimmt, denn das DE oder EN bezieht sich auf die Sprache, in der die Tag-Namen geschrieben wurden. > Die Tags und Attribute würde ich trotzdem in Englisch halten (man > kann ja bei Fanpro mal anfragen), das sind nur ein paar. Was > allerdings die ID's angeht, sollte man in der Tat überlegen, ob > man die nicht in Deutsch läßt. Die ID's sind ja eh sprachunabhängig, > könnten auch nummern sein, ist ja nur text um's auf Dateiebene > übersichtlich zu halten. Aha, und das gilt für Tags nicht? ;-) > Auch eine URL ist gültiger URI und daher nicht nur eine Notlösung. > An der URL kann schließlich auch etwas sinnvolles liegen (DTD, > Schema, Dokumentation). So war's auch ursprünglich gedacht, aber wie wir wissen, ist daraus nichts geworden... :-| > Klar kann man auch eine URN nehmen, hätte ich > nix dagegen. Leider bauen aber einige XML-Parser Mist (und ich fürchte, > unser C-Parser gehört dazu), die unbedingt eine gültige URL sehen > wollen. :-( Ich bin dafür, dass wir sowohl unter Java, als auch unter C++ Xalan von xml.apache.org einsetzen, der kann nicht nur URNs, vor allem stellen wir dann so sicher, dass wir dieselben Routinen zum Lesen und Schreiben der XML-Dateien verwenden. >>> <short-name xml:lang="de">MU</short-name> >>> >>Der short-name sollte der ID sein, daher ist diese Zeile eigentlich >>unnötig. >> > IMHO nicht, denn eine ID ist sprachunabhängig, während der > short-name in verschiedenen Sprachen auf Char.Bögen auftauchen > kann. Ach, so meintest du das. Dann ist es klar. > Aber in TeX heißt es emph ... :-). Aber meinetwegen auch > <em>, ist vielleicht gut, solche Sachen HTML-ähnlich zu > halten. Am besten bei längeren Beschreibungen einfach den Namespace auf XHTML festlegen, dann brauchen wir uns darüber keine großen Gedanken zu machen. >>Außerdem darf "gifted-skill" nicht doppelt gewählt werden, es sei denn, >>es ist durch die RaKuPro vorgegeben. > > Yep. Bei anderen Sachen vermutlich auch, jemand eine Idee dazu? Ja, laut meinem Klassen-Vorschlag (siehe andere Mail), kann man eine Klasse für Begabungen definieren: ... |--> Begabung/Unfähigkeit | | | |--> Talent | | | \--> Talentgruppe ... Die Begabungen werden dann einfach der Klasse "Vorteil" (bzw. "Nachteil") zugeordner, oder eben nicht, wenn sie fest zur Rasse oder Profession gehören: <advantage id="NatUnfähigkeit" class="Nachteil BegTalent"> ... </advantage> Jetzt die Rassendefinition für Zwerge: <race id="RasZwerg" class="Rasse"> ... <advantage ref="NatUnfähigkeit" class="BegTalent"> <name xml:lang="de">Unfähigkeit zum Schwimmen</name> <action on="once" do="TakSchwimmen--"/> <action on="once" do="cost(TakSchwimmen)++"/> </advantage> </race> class für die Schwimmen-Unfähigkeit wurde überschrieben, damit es nicht mehr als Nachteil zählt. Wir müssen uns nur eine geeignete Notation überlegen, damit es eindeutig bleibt, aber ich denke, das ergibt sich schon durch das ref-Attribut. Normalerweise wird die Klasse ergänzt, aber bei ref-Attribut wird die ursprüngliche Klasse übernommen und evtl. *ersetzt*, oder? >>> <advantage id="special-possession" specialisation="required" cost="12"> >>> <name xml:lang="de">Besonderer Besitz</name> >>> </advantage> >>> >>Dieser Vorteil sollte bei den Professionen stehen und direkt aufzählen, >>was man dann bekommt. > > Ich denke, dieser Vorteil ist auch für Charaktere gedacht, die > einfach so was besonderes haben wollen, auch wenn's nicht zur > Profession gehört. Daher muß er auch generell definiert werden. Gut, aber dafür gibt es eine viel bessere Regel, nämlich die SO*SO*SO Silbertaler, die man zu beginn bekommt ;-) >>Hmm, ob diese Mehrfachverschachtelung überhaupt nötig ist? Außerdem > > Irgendwie muß man jedenfalls darstellen, daß es bei den Talenten > nochmal Unterkategorien gibt. Die werden leider in einigen > Vor- und Nachteilen, Steigernungskosten, usw. auch benutzt. Ja, aber das Thema hat sich jetzt durch die Klassen erledigt. >>Sonderfertigkeiten sind keine Talente, daher sind sie hier etwas >>unglücklich eingeordnet. Ansonsten einverstanden. > > Ja, hab auch schon überlegt, sie eher als Vorteile darzustellen. > Gibt's irgendein Sondertalent, das auch einen TaW oder was ähnliches > hat? Nein, es sei denn, du zählst die unterschiedlichen Stufen als TaW. >>> <name xml:lang="de">Alrik</name> >>> <race id="human"/> >>> <culture id="mittelreich"/> >>> >>Besser hier auch Inhalte zulassen, einige wollen bestimmt einen >>"Dalmatier" spielen, obwohl sie die Werte eines "Garethers" nehmen ;-) > > Dann kann da ja noch ein <name>-Tag eingefügt werden. Aber > ich würde vorschlagen, nur bei Bedarf, sonst wird einfach > der Standard ausgelesen und verwendet. Ja, genau, dann aber: <race ref="human"/> <culture ref="mittelreich"> <name xml:lang=">Dalmatierin</name> </culture> > Ach ja, zu effective sollte ich noch was schreiben. effektive war > Für so ziemlich alles geplant, damit die ausgerechneten Endwerte > immer im Charakterbogen stehen (für Ausdruck, etc.). Achso, für den XLST-Prozess... OK, das sehe ich ein. Ich bin aber dagegen, solche Anweisungen im Programm zu verwenden. Hier sollten die lieber redes Mal ausgerechnet werden, weil der Test, wo sich jetzt abgeleitete Werte durch die Steigerung eines Wertes verändern, mit Sicherheit viel komplexer ist. > Da Berechnen war vom Ablauf so geplant: > effective = base + add (falls add vorhanden). > Dann alle actions mit trigger on="calc" ausführen (evtl. > muß da noch was zu, um die richtige Reihenfolge zu > erwischen). > Fertig. So, wie's momentan aussieht, kommen wir wohl ohne spezielle Reihenfolge aus. Notfalls könnte man ja Prioritäten zuordnen. >>Mehrere Professionen? Veteran? Ähh... ?! > > Jau ... in den Myranor Regeln drin, hab so den Verdacht, daß > das dann in Mantel-Schwert auch für Aventurien kommt. Man > kann zwei Professionen haben, oder in einer Profession Veteran > sein (schon bei Generierung). Und das schönste: Die Prof.-Modis, > die dabei doppelt anfallen (bei Veteran alle) werden beim > 1,5 fach, nich 2-fach gezählt ... seufz ... HMMMM :-S > Beispiel: Ein User führt einen neuen Vorteil ein. > Dieser Vorteil sollte 1. in seinen User-Files gespeichert werden, > damit er bei der Charaktergenerierung ausgewählt werden kann. > 2. In jedem Charakter gespeichert werden, damit Charaktere > portabel sind, ohne jedesmal alle eigenen Definitionen > beizupacken (das alte DSA-Tools Problem). Das ist vor allem > beim Tauschen von Persönlichkeiten, NSC, etc. SEHR wichtig. > Situation: Ein zweiter User führt einen gleichnamigen Vorteil > bei sich ein, aber mit völlig anderen Eigenschaften. Wenn > Dann zwei Charaktere, einer von jedem, auf dem selben System > zusammenkommen, gibts einen bösen Konflikt. > Dieses Beispiel halte ich durchaus nicht für rein akademisch, > sowas wird häufig vorkommen. Na, dann... Aber wie willst du sicherstellen, dass kein Hexcode doppelt vorkommt? > Ack! Obwohl - reicht vielleicht eine einfache Hierarchie, oder > gibts Fälle, wo ein Gegenstand wirklich in mehrere Klassen muß? Ja, z.B. der in der anderen Mail angesprochene Lederhelm. Ich muss wissen, dass es Leder ist (wegen der Rüstungskombination), und ich muss wissen, dass es ein Helm ist (jeder nur ein Kreu... äh... Helm <g>) Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
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: Alexander N. <lists@AlexNofftz.de> - 2001-11-14 11:57:30
|
Hi Matthias! Matthias Wurm wrote: > Eigentlich wäre ich auch dafür, emph zu nehmen. Ich hab euch ja schon > die Geschichte von der Abenteuer-erstellung erzählt. Da brauchen wir > zweifelsohne Gliederungssachen, und da sollten wir uns denke ich mal > eher an TeX orientieren, weil einem da die Gliederungsbefehle besser ins > Ohr gehen als dieses <p><i><b> zeug von HTML. Mag ja sein, dass mehr > Leute HTML können, als TeX, aber an denen will ich mich ehrlich gesagt > nicht orientieren... Ich bin da eher für verständliche Befehle, auch > wenn sie etwas länger sind. <em> steht doch für emphasis, wie das \emph von LaTeX auch. Bei Xtory-System von http://www.proc.org/stories/ erstelle ich acht unterschiedliche Formate auf der Basis von XLST und gehe im Grunde genommen von HTML aus. Wollt ihr mal ein Beispiel haben? ;-) Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Andreas H. <ahu...@gm...> - 2001-11-14 09:59:40
|
Hi, also wenn ich das richtig sehe gibt es ein Problem mit dem Vorteil Talent/Talentfruppe. Wieso muss XML das beruecksichtigen.... Matthias Wurm wrote: >Oliver Schulz wrote: > >>>> <advantage id="gifted-skill" specialisation="required" cost="oh shit!"> >>>> >>>Wieso "oh shit!"? Was spricht dagegen, diesen Vorteil für jede >>>Talentgruppe einzeln zu definieren? Allzu viele sind's ja nicht. >>> >>Nichts, war nur ein kurzer Anflug von Verzweiflung spät in der Nacht. ;-) >> > >Falls ich hier einen Vorschlag mach dürfte: Solche Auswahl-Sachen kommen >ja oft vor, und wenn man dann aber ein separates Talent für jede >Auswahlmöglichkeit einfügt, wird das in der Gesamtliste der Vor- und >Nachteile schnell unschön: > >Daher > ><advantage id="gifted-skill"> > <name xml:lang="de">Begabung für Talent</name> ><choose> > <selection text="Schwimmen" cost="12"/> > <selection text="Klettern" cost="12"/> > <selection text="Schwerter" cost="15"/> ></choose> > >Ich hab mal die beiden Attribute weggenommen, da mans ja so machen >könnte, dass fehlende Kosten automatisch eine notwendige Spezialisierung >signalisieren > >... ist natürlich blöd, weil wir - auch wenn die Kosten nur von der >Gruppe abhängig sind, dem Programm das ja nicht mitteilen können, dass >es aber eigentlich nur ein _einziges_ Talent ist, dass er steigern soll >(geht natürlich schon, aber das sind dann alles so Spezialtricks, die >wahrscheinlich nur auf dieses eine Ding anwendbar sind) > hmmmm, ich schreibe mal meine idee <advantage id="BegabungFuerTalent" specialisation="required" cost="Talent(spec).TaW.cost_factor * 3"> <name xml:lang="de">Begabung für Talent</name> <prerequisite expr="not Advantage('BegabungFuerTalentGruppe')"/> <action on="once" do="Talent(spec).TaW.base += 1"/> <action on="once" do="Talent(spec).TaW.cost_factor -= 1"/> </advantage> Sprich man waehlt ein Talent und fertig. ;) <advantage id="BegabungFuerTalentgruppe" specialisation="required" cost="TalentGroup(spec).cost_factor"> <name xml:lang="de">Begabung für Talentgruppe</name> <prerequisite expr="not Advantage('BegabungFuerTalent')"/> <action on="once" do="TalentGroup(spec).cost_factor -=1"/> </advantage> Das tolle sind hier leider wieder mal die Waffentalente... Was bei den einzeltalenten noch geht ist bei der Talentgruppe etwas schwieriger... man muesste das so formulieren das alle Talente in einer Gruppe um eins in den steigerungskosten nach unten korrigiert werden. Ich habe aber keine Idee wie man das in XML formulieren soll. Aber ich denke das sowas besser im programm abgefangen wird, wir wollen ja ein tool fuer dsa schreiben und keins was allgemeingueltig jede XML-Datei parsen kann und damit quasi auch fuer D&D oder GURPS laufen wuerde wenn man dafuer eine saubere XML-Datei hinbekommt.... Im programm muesste dann wirklich beim erstellen des Helden ueberprueft werden ob BegabungFuerTalent gewaehlt wurde oder nicht. Ich finde diese vorgehensweise persoenlich besser. Denn ansonsten koennen wir sofort XML -> Java machen ;-) Desweiteren ist es doch egal wo was in einer XML datei steht, wie soll man dann Probleme loesen bei denen es auf eine Reihenfolge ankommt... zB. Vorteil Herausragende Eigenschaft Konstitution mit der Berechnung der LE... Da sollte man lieber die LE vom Programm berechnen lassen und diese dann in der Held.xml ablegen. (aufgeteilt in eLE (LE durch Eigenschaften) und xLE (LE durch EXP) ) Das bedeutet natuerlich das wir uns fuer jeden Vorteil und Nachteil der sich auf Werte beim Helden auswirkt etwas programmieren muessen, aber ist es nicht egal ob wir uns beim erstellen der XML total verkrampfen oder lieber 3 zeilen mehr beim Code... <advantage id="BegabungFuerTalentgruppe" specialisation="required" cost="TalentGroup(spec).cost_factor"> <name xml:lang="de">Begabung für Talentgruppe</name> <prerequisite expr="not Advantage('BegabungFuerTalent')"/> <action on="once" do="TalentGroup(spec).cost_factor -=1"/> waere dann ne Schleife die bei allen Talenten der TalentGroup(spec) den cost_factor um 1 senkt und nicht nur den Factor der Gruppe... </advantage> >ne andere Möglichkeit wäre aber die: > ><advantage id="gifted-skill" specialisation="required"> > <name xml:lang="de">Begabung für Talent</name> > <choose> > <selection text="Körperliche Talente" cost="12"/> > <selection text="Kampftalente" cost="15"/> > ... > </choose> > <prerequisite expr="not Advantage('gifted-skill-group')"/> > <action on="once" do="Talent(spec).TaW.base += 1"/> > <action on="once" do="Talent(spec).TaW.cost_factor -= 1"/> ></advantage> > >Hier hab ich spec. wieder reingenommen, was heißt, ich wähle zwar was >aus, aber mein _eigentlicher_ Wert ist was anderes, siehe z.B. Angs vor >[]. Die Auswahl wäre häufiges Auftreten / seltenes Auftreten, aber der >eigentliche Wert wäre "Krieger mit Topfhaarschnitt", den man selber in >ein Textfeld eingibt (das dann in spec reinkommt). Dann ist nämlich der >daraufhin folgende Code immer noch gültig... Ok, ist zwar blöd, wenn man >dann die Gruppe auswählt und dann noch das Talent EINGEBEN muss. >Vielleicht kann man sich ja dafür noch was überlegen. Betrachtet dann >diesen Vorschlag einfach mal als den für die "erste Komplexitätsstufe" >*g* Das mit der Angst vor.... könnte man damit ja schonmal realisieren. >Vielleicht habt ihr einen guten Vorschlag, wie man das gekonnt ergänzen >kann, um auch dies Auswahl Gruppe->Talent zu ermöglichen. >Vielleicht ja > <selection text="Körperliche Talente" cost="12"> > <choose> > wobei man hier alle Childs der Talentgruppen, also alle Talente >als selection reinnimmt. Aber das geht in XML so nicht, oder ? > </choose> > </selection> > Gruss Andreas |