dsaman-list Mailing List for DSA Manager (Page 30)
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-13 11:58:47
|
Alexander Nofftz wrote: > > Hi Matthias! > > Matthias Wurm wrote: > Das mit dem Entwurf im CVS-Baum hab ich mir schon runtergeladen, konnte es mir aber wie gesagt wegen den XY-Constraint-Dingern nicht kompilieren... Gibts die nur bei JDK 1.4 ??? > > So, dass wärs erst mal grob. Man könnte das ja dann so machen, dass wir > > den Baum auch in XML machen (ist ja auch irgendwie naheliegend *g*), und > > bei jedem Knoten, bei dem in der Tabelle rechts etwas angezeigt werden > > soll: > > Ja, aber wir müssen erst einmal testen, in wie weit das überhaupt > übersichtlich implementierbar ist. Wahrscheinlich wird das eher auf die > Baumstruktur und den Hinweis auf die Plane-Klasse hinaus laufen. Es gibt > zwar auch irgendwo eine DTD, wie man Java-Quelltext in XML programmieren > kann, aber man kann's ja auch übertreiben, oder? Nee, nee, von sowas (DTD->Java) halt ich auch nix. Das mit dem Pane hab ich mir auch so gedacht (so, dass halt die GUI-Klasse von Pane abgeleitet ist, also quasi CharakterVorschau extends JPane oder wie auch immer... Dann nacher nur nocht getContentPane().add und schon hat mans eigentlich... naja, im groben > > > a) Verweise auf alle möglich Rein-GUI Klassen für die Menüs, Symboll., > > Vorschau, und das Fenster, das erscheint, wenn man auf einen Datensatz > > doppelklickt > > Da sollte man eher direkt editieren können. Der Doppelklick ist meistens > umständlich und man hantiert dann wieder mit mehreren Fenstern herum, > was nicht unbedingt nötig ist. Naja, direktes Editieren ist ja eigentlich aufgrund der Komplexität nicht möglich. Zum Charakter gehören ja tausend Dinge, da hab ich gedacht, machen wir ein neues Frame mit zum Char passenden Menü etc., der dann ein paar Reiter hat (TabbedPane, glaub ich), also Allgemein / Talente / Zauber / Kampfausrüstung / Ausrüstung / Begleiter / und was sonst noch. Und man hantiert dann auch _höchstens_ mit 3 Fenstern rum, ich mir zwar mal ne MDI-Anwendung überlegt, aber dann hab ich ehrlich gesagt lieber meinen Char in der Taskleiste als unter Fenster ... 1 Alrik 2 Torben ... > > > b) als ich das mit Datenbanken machen wollte, wollte ich noch auf eine > > View verweisen, die man dann 1:1 in die Tabelle einfügen kann. Was > > schlagt ihr dann hier vor ? (wenn ihr die Vorschläge so überhaupt > > akzeptiert....) > > Das geht natürlich in Java, aber hier würde ich wirklich wie oben > angegeben nicht nur Tabellen verwenden. Bei den Eigenschaften, Talenten, > Zaubern, Vor- und Nachteilen bietet es sich an, aber ich bin mir sicher, > dass wir bestimmt irgendwann auf Probleme stoßen, wenn wir uns auf die > Tabellensicht beschränken. Hmm, die Tabellen sollen ja nur die _wichtigsten_ Eigenschaften angeben. Beim Char wäre das: Name | Profession | Stufe |Rasse | Kultur Dann haben wir ja immer noch die Vorschau, die vielleicht einen Überblick über die besten Talente gibt, aber auf jeden Fall die Hintergrundgeschichte enthalten sollte (die ja eigentlich das wesentliche ist, wenn man etwas über den Charakter erfahren will). Und wenn man wirklich ALLES sehen will, öffnet man halt den Kerl (und hat dann ein neues Frame). Aber das meiste ist denke ich mit der Vorschau getan, daher müssen wir keine Angst vor einer Fensterüberschwemmung haben. Ich meine, bei den Mails ist es ja auch so... Die Vorschau tuts auch. Und noch keiner hat sich beklagt, dass der Entwurf einer neuen Mail in einem neuen Fenster stattfindet... Gruß Matthias > > Bis dann, > Alex |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-13 11:32:02
|
Hi Matthias! Matthias Wurm wrote: > Ich stelle mir das etwa so vor: > Im groben wäre das mit einem Explorer zu vergleichen. Links ein > Baum, rechts aufgeteilt in Tabelle und Vorschau. > Der Gedanke dahinter ist der, das im Baum links solche Knoten wie > "Helden" stehen, Unterknoten dessen sind "Spielercharaktere" und > "Begleiter" oder so ähnlich. Das ist denke ich mal gut erweiterbar, wenn > man noch so Sachen wie Tiere / Pflanzen dazufügt, dann muss man einfach > nur einen weiteren Knoten hinzufügen. Ja ja ja, genau. Schau mal in den CVS-Baum, da ist schon ein ganz grober Entwurf drin. Wobei mal rechts lieber Planes verwenden sollte, weil reine Tabellen nicht immer das Wahre sind. > Wie bei gängigen Mail-Clients hab ich mir das so vorgestellt, dass je > nach Auswahl des Knotens sich das Menü, die Symbolleiste, eventuelle > Kontextmenüs und die Vorschau sich an die aktuellen Objekte anpassen. Stimmt. > Beim erstellen eines neuen Objekts, also z.B. eines Charakters, > verwenden wir dann einen Wizard (ne passende Wizard-Klasse hab ich schon > gefunden), der die wichtigsten Schritte durchführt (Quasi die Schritte, > die auf S.36 im Regelwerk stehen) Genau, so hatte ich mir das auch überlegt. > So, dass wärs erst mal grob. Man könnte das ja dann so machen, dass wir > den Baum auch in XML machen (ist ja auch irgendwie naheliegend *g*), und > bei jedem Knoten, bei dem in der Tabelle rechts etwas angezeigt werden > soll: Ja, aber wir müssen erst einmal testen, in wie weit das überhaupt übersichtlich implementierbar ist. Wahrscheinlich wird das eher auf die Baumstruktur und den Hinweis auf die Plane-Klasse hinaus laufen. Es gibt zwar auch irgendwo eine DTD, wie man Java-Quelltext in XML programmieren kann, aber man kann's ja auch übertreiben, oder? > a) Verweise auf alle möglich Rein-GUI Klassen für die Menüs, Symboll., > Vorschau, und das Fenster, das erscheint, wenn man auf einen Datensatz > doppelklickt Da sollte man eher direkt editieren können. Der Doppelklick ist meistens umständlich und man hantiert dann wieder mit mehreren Fenstern herum, was nicht unbedingt nötig ist. > b) als ich das mit Datenbanken machen wollte, wollte ich noch auf eine > View verweisen, die man dann 1:1 in die Tabelle einfügen kann. Was > schlagt ihr dann hier vor ? (wenn ihr die Vorschläge so überhaupt > akzeptiert....) Das geht natürlich in Java, aber hier würde ich wirklich wie oben angegeben nicht nur Tabellen verwenden. Bei den Eigenschaften, Talenten, Zaubern, Vor- und Nachteilen bietet es sich an, aber ich bin mir sicher, dass wir bestimmt irgendwann auf Probleme stoßen, wenn wir uns auf die Tabellensicht beschränken. Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Matthias W. <Mat...@gm...> - 2001-11-13 10:10:25
|
Da wir ja gemerkt haben, dass wir ziemlich unterschiedliche Vorstellungen davon haben, wie das Programm überhaupt aussehen soll, könnten wir vielleicht mal kurz eine Diskussion über die GUI einschieben, damit wir mal wissen, wie wir uns das vorstellen... Ich stelle mir das etwa so vor: Im groben wäre das mit einem Explorer zu vergleichen. Links ein Baum, rechts aufgeteilt in Tabelle und Vorschau. Der Gedanke dahinter ist der, das im Baum links solche Knoten wie "Helden" stehen, Unterknoten dessen sind "Spielercharaktere" und "Begleiter" oder so ähnlich. Das ist denke ich mal gut erweiterbar, wenn man noch so Sachen wie Tiere / Pflanzen dazufügt, dann muss man einfach nur einen weiteren Knoten hinzufügen. Die Baumelemente, die man sich später mal vorstellen könnte, sind ja in der .txt auf http://www.uni-karlsruhe.de/~uub0/dsa4spec.txt aufgeführt... Wie bei gängigen Mail-Clients hab ich mir das so vorgestellt, dass je nach Auswahl des Knotens sich das Menü, die Symbolleiste, eventuelle Kontextmenüs und die Vorschau sich an die aktuellen Objekte anpassen. Beim erstellen eines neuen Objekts, also z.B. eines Charakters, verwenden wir dann einen Wizard (ne passende Wizard-Klasse hab ich schon gefunden), der die wichtigsten Schritte durchführt (Quasi die Schritte, die auf S.36 im Regelwerk stehen) So, dass wärs erst mal grob. Man könnte das ja dann so machen, dass wir den Baum auch in XML machen (ist ja auch irgendwie naheliegend *g*), und bei jedem Knoten, bei dem in der Tabelle rechts etwas angezeigt werden soll: a) Verweise auf alle möglich Rein-GUI Klassen für die Menüs, Symboll., Vorschau, und das Fenster, das erscheint, wenn man auf einen Datensatz doppelklickt b) als ich das mit Datenbanken machen wollte, wollte ich noch auf eine View verweisen, die man dann 1:1 in die Tabelle einfügen kann. Was schlagt ihr dann hier vor ? (wenn ihr die Vorschläge so überhaupt akzeptiert....) Ok, um Kommentare wird gebeten Gruß Matthias |
From: Andreas H. <ahu...@gm...> - 2001-11-12 23:52:00
|
Hi Alex, >> Aber wer kennt sich aus mit Java und XML bezüglich grosser XML >> Dateien und Laufzeit... > > > > StarOffice ist schnell ;-), davon abgesehen sind die Routinen von > xml.apache.org (die verwenden wir nämlich) sehr effizient. Wenn wir > alles komprimiert speichern, ist der durch die Tags "verschwendete" > Platz auch nur noch minimal, weil sich diese sehr gut packen lassen. > Hmm wie oeffne ich die mit Staroffice. .. MIt dem SO Browser ? > >> Kleinere Dateien können den Vorteil haben das die Applikation nur das >> im Speicher halten muss was gerade benötigt wird. > > > > Sicher, aber dafür muss ständig nachgeladen werden, was sicherlich > länger dauert. Ok Punkt an dich ... :) Bye Andreas |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 22:36:14
|
Hi Andreas! > Ok Ok ... wenn wir eine Oberfläche zum erstellen neuer Kulturen erstellen ist > es völlig egal wie die nun abgelegt werden. > Wenn ich das nun richtig sehe ist das als Applikation gedacht die via > webserver bereitgestellt wird.. Vielleicht auch, aber nicht nur. Ich wollte mir nur diese Applet-Option offenhalten, wenn wir auf Java-Basis programmieren, aber hauptsächlich ist das Programm als Basis gedacht. > Hmmmm, wieso dann nicht MySQL? :))) ( war ein Scherz will nun keien > Diskussion darüber) Erübrigt sich jetzt <g> > Aber wer kennt sich aus mit Java und XML bezüglich grosser XML Dateien und > Laufzeit... StarOffice ist schnell ;-), davon abgesehen sind die Routinen von xml.apache.org (die verwenden wir nämlich) sehr effizient. Wenn wir alles komprimiert speichern, ist der durch die Tags "verschwendete" Platz auch nur noch minimal, weil sich diese sehr gut packen lassen. > Kleinere Dateien können den Vorteil haben das die Applikation nur das im > Speicher halten muss was gerade benötigt wird. Sicher, aber dafür muss ständig nachgeladen werden, was sicherlich länger dauert. > Schon richtig. Ich habe mal wieder minimalistisch gedacht und bin davon > ausgegangen das wir Rassen/kulturen usw als gegeben annehmen und nur direkt > an den XML Dateien editierbar sein sollen. Und ich ging auch noch davon aus > das die Dateien beim Anwender liegen ( wegen dsadmin). Sollen sie auch, aber das sind *seine* Daten, mit denen er machen kann, was er will. Die "globale" Datenbasis ist ein ganz andere Geschichte. Beides müssen wir aber beachten. Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Andreas H. <ahu...@gm...> - 2001-11-12 22:07:11
|
Hi So nun denn > Ich weiß nicht, aber ich die da irgendwie völlig andere Vorstellungen > vom Aussehen des Programms. An die Dateien an sich langt sowieso > garniemand. Das Hinzufügen und ändern der Rassen / Kulturen etc. wird > alles über das Programm selbst bereitgestellt, mit einer gewohnten > Benutzeroberfläche die recht intuitiv zu bedienen ist. Wir können von > keinem Verlangen, die XML-Dateien selber zu editieren, auch wenn das > auch für einen Nicht-Programmierer eigentlich machbar sein sollte... Und > im Sinne einer übersichtlichen Verwaltung finde ich, dass sich dann > diese Methode ohnehin automatisch ausschließt... Ok Ok ... wenn wir eine Oberfläche zum erstellen neuer Kulturen erstellen ist es völlig egal wie die nun abgelegt werden. Wenn ich das nun richtig sehe ist das als Applikation gedacht die via webserver bereitgestellt wird.. Hmmmm, wieso dann nicht MySQL? :))) ( war ein Scherz will nun keien Diskussion darüber) Aber wer kennt sich aus mit Java und XML bezüglich grosser XML Dateien und Laufzeit... Kleinere Dateien können den Vorteil haben das die Applikation nur das im Speicher halten muss was gerade benötigt wird. > Wenn wir es später mal ermöglichen, Abenteuer zu schreiben, dann kann > sich das ja noch überlegen. > Aber es ist ein Unterschied, ob ich sowas wie > <Kapitel>Der Schwarze Turm</Kapitel> > <Meisterinformationen>Borbarad trägt rosa > Unterhöschen</Meisterinformationen> > eingeben muss, oder etwas wie: > > <Kampftechnik id="KamSäbel"> > <Name>Säbel</Name> > <Behinderung expr="-2"/> > <Wert num="0"/> > <Steigern spalte="D"/> > <Kampfwerte AT="0" PA="0"/> > </Kampftechnik> Schon richtig. Ich habe mal wieder minimalistisch gedacht und bin davon ausgegangen das wir Rassen/kulturen usw als gegeben annehmen und nur direkt an den XML Dateien editierbar sein sollen. Und ich ging auch noch davon aus das die Dateien beim Anwender liegen ( wegen dsadmin). > > > > Wir werden uns aber streng von oben nach unten durcharbeiten <g> > > > > AYE AYE SIR > > lasst mich raten, ihr kennt euch persönlich... *g* Noe, nur wenn er sagt das wir das durcharbeiten .... ;) Gruss Andreas |
From: Matthias W. <Mat...@gm...> - 2001-11-12 21:39:41
|
Alexander Nofftz wrote: > > Wird mein Aufbau jetzt deutlich? Hmm, ja, da bin ich von einem ganz anderen Aufbau ausgegangen. Dürfte ich aber vorschlagen, dass wir die endgültige Entscheidung, welcher Aufbau am günstigsten ist, bis dahin verschieben, wenn wir wissen, wie wir das mit der Entscheidung über hochgeladene Datensätze machen. Da könnte sich ja eine andere Struktur vielleicht als praktischer erweisen, aber mal sehen... Gruß Matthias |
From: Matthias W. <Mat...@gm...> - 2001-11-12 21:34:20
|
Andreas Hugenroth wrote: > > > Von der Vorgehensweise nicht verkehrt, aber so etwas wird schnell sehr > > unübersichtlich. > > Finde ich nicht. > Ueberleg dir die Alternative eine Textdatei mit was weiss ich wievielen > Zeilen zu editieren... > bis 1000 oder 2000 ist das alles fein. Doch garantiere ich dir das diese > Datei größer werden wird wenn du alles in eine pakst. > Wenn man 25 Kulturen, 10 Rassen, 60 Professionen in einzelnen Dateien hat ist > diese Struktur für nicht Programmierer leichter und bietet anderen Spielern > meiner Meinung nach die bessere Möglichkeit eigene Klassen hinzuzufügen. > Ich weiß nicht, aber ich die da irgendwie völlig andere Vorstellungen vom Aussehen des Programms. An die Dateien an sich langt sowieso garniemand. Das Hinzufügen und ändern der Rassen / Kulturen etc. wird alles über das Programm selbst bereitgestellt, mit einer gewohnten Benutzeroberfläche die recht intuitiv zu bedienen ist. Wir können von keinem Verlangen, die XML-Dateien selber zu editieren, auch wenn das auch für einen Nicht-Programmierer eigentlich machbar sein sollte... Und im Sinne einer übersichtlichen Verwaltung finde ich, dass sich dann diese Methode ohnehin automatisch ausschließt... Wenn wir es später mal ermöglichen, Abenteuer zu schreiben, dann kann sich das ja noch überlegen. Aber es ist ein Unterschied, ob ich sowas wie <Kapitel>Der Schwarze Turm</Kapitel> <Meisterinformationen>Borbarad trägt rosa Unterhöschen</Meisterinformationen> eingeben muss, oder etwas wie: <Kampftechnik id="KamSäbel"> <Name>Säbel</Name> <Behinderung expr="-2"/> <Wert num="0"/> <Steigern spalte="D"/> <Kampfwerte AT="0" PA="0"/> </Kampftechnik> > > > > Wir werden uns aber streng von oben nach unten durcharbeiten <g> > > AYE AYE SIR lasst mich raten, ihr kennt euch persönlich... *g* Gruß Matthias |
From: Andreas H. <ahu...@gm...> - 2001-11-12 21:27:10
|
Hi Ich hab nur ICQ im moment, aber leider nicht auf meiner Linuxbüchse die daueron ist. Hat da jemand evtl einen Tipp fuer einen guten IM client ? ICQ ist 97355699 bye Andreas On Monday 12 November 2001 22:08, Alexander Nofftz wrote: > Hi! > > Vielleicht sollten wir mal IM-Adressen austauschen, da wir ja > offensichtlich lange online sind! <g> > > Mein Lieblings-Messenger ist der MSN Messenger, bei dem ich unter > Ale...@em... zu erreichen bin. Außerdem habe ich noch über Opera > Zugriff auf ICQ, wo ich unter der Nummer 2621403 angemeldet bin. > > Bis dann, > Alex |
From: Matthias W. <Mat...@gm...> - 2001-11-12 21:23:24
|
Alexander Nofftz wrote: > > Hi! > > Vielleicht sollten wir mal IM-Adressen austauschen, da wir ja > offensichtlich lange online sind! <g> > > Mein Lieblings-Messenger ist der MSN Messenger, bei dem ich unter > Ale...@em... zu erreichen bin. Außerdem habe ich noch über Opera > Zugriff auf ICQ, wo ich unter der Nummer 2621403 angemeldet bin. > Meine ICQ#: 39030883 Hab dich auch schon mal gestern geaddet, bisher kam noch keine Authorisation. Hast du es bekommen? |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 21:12:00
|
Hi! Vielleicht sollten wir mal IM-Adressen austauschen, da wir ja offensichtlich lange online sind! <g> Mein Lieblings-Messenger ist der MSN Messenger, bei dem ich unter Ale...@em... zu erreichen bin. Außerdem habe ich noch über Opera Zugriff auf ICQ, wo ich unter der Nummer 2621403 angemeldet bin. Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 21:02:37
|
Hi Matthias! >>Ja, warum nicht? Zumindest für die Pakete wäre das sehr übersichtlich und Platzsparend. Ich kann euch ja mal eine StarOffice-Datei zukommen lassen, wenn ihr das Programm nicht habt. >> > > Ich will nur aus folgenden Gründen davon abraten: > - Wenn wir wirklich viele Helden drin haben (Stichwort NSC-Datenbank der > anderen Mail), dann haben wir da ziemlich viele Zips Ja, und? Die Leute müssen ja nicht wissen, dass es ZIP-Dateien ist, statt alrik.zip matajew.zip rahjana.zip valaria.zip könne es ja auch alrik.dmh matajew.dmh rahjana.dmh valaria.dmh heißen (dmh = DSA Manager Held). Wer soll dann noch merken, dass es eine ZIP-Datei ist? Davon abgesehen hält der dann binäre Aufbau einige davon ab, wild in den Dateien herumzueditieren ;-) > - Die XML-Dateien selbst interessieren den Anwender ja wenig, da machts > auch nix, wenn die "irgendwo" in einer großen Datei rumfahren. Für ihn > ist allenfalls die PDF oder die HTML-Datei interessant, die er sich bei > Bedarf neu erstellen un dann ausdrucken kann. Eben! > - Wenn er die Datei separat will, (und Beispielsweise bei einem Kumpel > importieren will), würde ich eine Option "Exportieren" einfügen. Das ist sowieso vorgesehen. > Habt ihr da irgendwelche Einwände ? Ehrlich gesagt denke ich nur, dass > wir da von unserem bisherigen Stil abweichen, wobei ich speziell bei > Charakteren noch keinen Grund sehe. Bei Abenteuern ok, da ist ja noch um > einiges mehr dabei. Aber das ist ja noch lang lang hin... Bei Helden wäre das ehrlich gesagt auch weniger interessant, aber stelle dir das mal bei den Paketen vor: * Paket DSA4-Basis.dmp, darin erhalten: - rassen.xml - kulturen.xml - professionen.xml - vornachteile.xml - talente.xml - zauber.xml - dateiinfo.xml (mit den Autorendaten, Datum etc.) - doc/*.html (mit der Beschreibung des ganzen Zeugs) * Paket Myranor.dmp mit demselben Aufbau * Paket Dunkelelfen.dmp (Dunkelelfen als Spielercharaktere): - rassen.xml (Rasse Dunkelelf) - kulturen.xml (Kultur Himmelsturm) - professionen.xml (Typische Dunkelelf-Professionen) - vornachteile.xml (Typisch für Dunkelelfen) - zauber.xml (Spezielle Zauber der Dunkelelfen - dateiinfo.xml - doc/*.html * Paket My_Talente.dmp (Individuell angepasste Talente): - talente.xml * Paket My_Zauber.dmp (Individuell angepasste Zauber): - zauber.xml etc. talente.xml wäre dann bei Dunkelelfen.dmp nicht enthalten, weil die Dunkelelfen keine speziellen Talente haben. Wird mein Aufbau jetzt deutlich? Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 21:02:20
|
Hi Andreas! >> > Ich gehe davon aus das du nicht alle Rassen Proffensionen usw in je >> > eine grosse XML datei packen willst? Oder doch ? >> > Ich dachte eher an Rasse_Mensch.XML >> > Rasse_Zwerg.XML >> > Kultur_Thorwal.XML >> > Kutur_Amboss.XML >> > Profession_Seefahrer.XML >> > Profession_Schmied.XML >> > usw >> > usw >> > Das Programm sucht dann alle Dateien die mit XXX und liefert daraus >> > dann ne Auswahlliste. Natuerlich muessen in den Einzelnen Dateien >> > enthalten wer nun Schmied werden darf oder aus dem Amboss stammen >> > darf. >> >>Von der Vorgehensweise nicht verkehrt, aber so etwas wird schnell sehr >>unübersichtlich. >> > > Finde ich nicht. > Ueberleg dir die Alternative eine Textdatei mit was weiss ich wievielen > Zeilen zu editieren... Das geschieht ja nur einmal manuell, dann automatisch über das Programm. Siehe außerdem meinen anderen Vorschlag zu den Paketen. > bis 1000 oder 2000 ist das alles fein. Doch garantiere ich dir das diese > Datei größer werden wird wenn du alles in eine pakst. Alles in eine will ich ja gar nicht, aber auch nicht jedes Objekt in eine eigene Datei, das wäre auf seine weise genauso unübersichtlich. Gilt halt, den richtigen Mittelweg zu finden. > Wenn man 25 Kulturen, 10 Rassen, 60 Professionen in einzelnen Dateien hat ist > diese Struktur für nicht Programmierer leichter und bietet anderen Spielern > meiner Meinung nach die bessere Möglichkeit eigene Klassen hinzuzufügen. Die sollen ja gar nicht in den XML-Dateien herumfummeln. <g> > wenn du meinst... es wird dann halt schwerer den zusammenhang nicht zu > verlieren .... Wie? Ach ja... Weiß zwar nicht, worüber du redest, aber ich bin völlig deiner Meinung <g,d&r> Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 20:59:44
|
Hi Matthias! >>Als Bonus Kampfsimulator. Wobei das mit am schwierigsten zu realisieren ist, >>oder will jemand eine Ki fuer Magier, Druiden, Elfen, Dämonen und was weiss >>ich alles schreiben... Wäre ein Thema für ne Diplomarbeit ;) > > Gnade ! Mir wird schlecht bei dem Gedanken ! Ich erinnere mich nur > ungern an die offiziellen DSA-Tools, wo ein ST 1 Streuner mal locker > Borbarad besiegen konnte. Fazit: totaaaaal unnötig und ohne Aussage ! > Dazu gehören auch diese Wetter / Seefahrt und Sternenhimmel tools. Die > braucht keiner... Also, ich habe mir immer einige Wochen Wetter im Voraus ausgewürfelt, dann hatte ich immer alles zur Hand ;-) >>Dann gibt es noch so Sachen wie Wahrscheinlichkeiten für Talentproben, mit >>was wäre wenn Funktion. Sprich soll ich lieber GE oder vielleicht doch IN >>steigern. Wobei das leider wieder mehr zu PG führen wird. > > Und genau aus letzterem Grund werden wir das auch nicht machen. Der Held > soll sich ne gute Hintergrundstory ausdenken, nicht auf seine doofen > Wertchen achten... ACK! ACK! ACK!!!! Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Matthias W. <Mat...@gm...> - 2001-11-12 20:22:43
|
Andreas Hugenroth wrote: > > Wieso sagst du nicht einfach die Eierlegende Vollmilchsau .... > > ... > Also (wichtigste zuerst): > Heldenwerte > Ausrüstung aller Art > Begleiter aller Art > Gespielte Abenteuer --> kleine Datenbank wo alle Abenteuer mit > kurzbeschreibung drin stehen > Mit welchen anderen Helden unterwegs gewesen, in welchen Abenteuern > Bereiste Orte Lndstriche, ergeben sich Z.b. aus Abenteuer > > Dann saubere, gut gestalltete Heldendokumente einmal mit wichtigsten > Informationen für den Meister und einmal die Deluxe Variante mit allen Daten > für Spieler. Und evtl. Überblick bogen für andere Spieler mit Name, Aussehen > und anderen "offensichtlichen" Details. Yupp, bis jetzt alles einverstanden > > Als Bonus Kampfsimulator. Wobei das mit am schwierigsten zu realisieren ist, > oder will jemand eine Ki fuer Magier, Druiden, Elfen, Dämonen und was weiss > ich alles schreiben... Wäre ein Thema für ne Diplomarbeit ;) Gnade ! Mir wird schlecht bei dem Gedanken ! Ich erinnere mich nur ungern an die offiziellen DSA-Tools, wo ein ST 1 Streuner mal locker Borbarad besiegen konnte. Fazit: totaaaaal unnötig und ohne Aussage ! Dazu gehören auch diese Wetter / Seefahrt und Sternenhimmel tools. Die braucht keiner... > > Dann gibt es noch so Sachen wie Wahrscheinlichkeiten für Talentproben, mit > was wäre wenn Funktion. Sprich soll ich lieber GE oder vielleicht doch IN > steigern. Wobei das leider wieder mehr zu PG führen wird. Und genau aus letzterem Grund werden wir das auch nicht machen. Der Held soll sich ne gute Hintergrundstory ausdenken, nicht auf seine doofen Wertchen achten... > > So das ist so in etwa was ich so unter einem DSA Manager verstehe. > Ich hab da einiges drin was du auch unten drin stehen hast, und Alex auch > schon eine Liste angefangen hat sollten wir und einigen wo und welche Liste > wir nun erweitern und führen wollen. > Wir sollten erstmal sammeln und dann sollten diejenigen die das sagen haben > sollen abstimmen was wichtig ist und was nicht. Evtl kann man sowas auch > nochmal zur Diskussion in eine NG posten. Aber das mit den Köchen und den > Brei ist ja jedem bekannt.... Naja, die .txt war auch als Obermenge an Features gedacht, aus denen man sich der Reihe nach die wichtigsten rauspickt... Gruß Matthias > > Gruss > Andreas |
From: Andreas H. <ahu...@gm...> - 2001-11-12 20:16:20
|
Hi > > Ich gehe davon aus das du nicht alle Rassen Proffensionen usw in je > > eine grosse XML datei packen willst? Oder doch ? > > Ich dachte eher an Rasse_Mensch.XML > > Rasse_Zwerg.XML > > Kultur_Thorwal.XML > > Kutur_Amboss.XML > > Profession_Seefahrer.XML > > Profession_Schmied.XML > > usw > > usw > > Das Programm sucht dann alle Dateien die mit XXX und liefert daraus > > dann ne Auswahlliste. Natuerlich muessen in den Einzelnen Dateien > > enthalten wer nun Schmied werden darf oder aus dem Amboss stammen > > darf. > > Von der Vorgehensweise nicht verkehrt, aber so etwas wird schnell sehr > unübersichtlich. Finde ich nicht. Ueberleg dir die Alternative eine Textdatei mit was weiss ich wievielen Zeilen zu editieren... bis 1000 oder 2000 ist das alles fein. Doch garantiere ich dir das diese Datei größer werden wird wenn du alles in eine pakst. Wenn man 25 Kulturen, 10 Rassen, 60 Professionen in einzelnen Dateien hat ist diese Struktur für nicht Programmierer leichter und bietet anderen Spielern meiner Meinung nach die bessere Möglichkeit eigene Klassen hinzuzufügen. > Dann quote nicht so viel! ;-> > wenn du meinst... es wird dann halt schwerer den zusammenhang nicht zu verlieren .... > 1. Charaktergenerierung > 2. Charaktersteigerung > 3. Nachschlagewerk für Rassen, Professionen, Kulturen, Vorteile, > Nachteile, Talente, Zauber, Waffen, Ausrüstungsgegenstände > (ergibt sich zum Großteil auch schon aus 1 und 2) > 4. Ausdruck von Heldenbögen, Export von allen Elementen als HTML > 5. "In-Game"-Tool für Meister (und Spieler) quasi als elektronischer > Heldenbogen > 6. Kampfverwaltung > 7. Krankheiten, Gifte etc.pp. > > Wir werden uns aber streng von oben nach unten durcharbeiten <g> AYE AYE SIR Naja ich habe meine ideen schon in eine andere Mail gepackt. Bye Andreas |
From: Matthias W. <Mat...@gm...> - 2001-11-12 20:11:46
|
Alexander Nofftz wrote: > > Ja, warum nicht? Zumindest für die Pakete wäre das sehr übersichtlich und Platzsparend. Ich kann euch ja mal eine StarOffice-Datei zukommen lassen, wenn ihr das Programm nicht habt. Ich will nur aus folgenden Gründen davon abraten: - Wenn wir wirklich viele Helden drin haben (Stichwort NSC-Datenbank der anderen Mail), dann haben wir da ziemlich viele Zips - Die XML-Dateien selbst interessieren den Anwender ja wenig, da machts auch nix, wenn die "irgendwo" in einer großen Datei rumfahren. Für ihn ist allenfalls die PDF oder die HTML-Datei interessant, die er sich bei Bedarf neu erstellen un dann ausdrucken kann. - Wenn er die Datei separat will, (und Beispielsweise bei einem Kumpel importieren will), würde ich eine Option "Exportieren" einfügen. Habt ihr da irgendwelche Einwände ? Ehrlich gesagt denke ich nur, dass wir da von unserem bisherigen Stil abweichen, wobei ich speziell bei Charakteren noch keinen Grund sehe. Bei Abenteuern ok, da ist ja noch um einiges mehr dabei. Aber das ist ja noch lang lang hin... Gruß Matthias |
From: Andreas H. <ahu...@gm...> - 2001-11-12 20:03:04
|
Wieso sagst du nicht einfach die Eierlegende Vollmilchsau .... Naja was du da alles aufzählst hört sich gut an, doch ich denke was sich gut anhört und was nacher praktikabel ist und benutzt wird ist was anderes. Z.b. die Tools mit Seefahrregeln und Wettergenerator. Ich meistere nun schon recht lange und bisher hab ich das nie benutzt, auch wenn es genial aussah als ich es mir angesehen habe. Was wirklich sinnvoll ist, alles das sauber verwalten zu können was einen Helden betrifft. Also (wichtigste zuerst): Heldenwerte Ausrüstung aller Art Begleiter aller Art Gespielte Abenteuer --> kleine Datenbank wo alle Abenteuer mit kurzbeschreibung drin stehen Mit welchen anderen Helden unterwegs gewesen, in welchen Abenteuern Bereiste Orte Lndstriche, ergeben sich Z.b. aus Abenteuer Dann saubere, gut gestalltete Heldendokumente einmal mit wichtigsten Informationen für den Meister und einmal die Deluxe Variante mit allen Daten für Spieler. Und evtl. Überblick bogen für andere Spieler mit Name, Aussehen und anderen "offensichtlichen" Details. Als Bonus Kampfsimulator. Wobei das mit am schwierigsten zu realisieren ist, oder will jemand eine Ki fuer Magier, Druiden, Elfen, Dämonen und was weiss ich alles schreiben... Wäre ein Thema für ne Diplomarbeit ;) Dann gibt es noch so Sachen wie Wahrscheinlichkeiten für Talentproben, mit was wäre wenn Funktion. Sprich soll ich lieber GE oder vielleicht doch IN steigern. Wobei das leider wieder mehr zu PG führen wird. So das ist so in etwa was ich so unter einem DSA Manager verstehe. Ich hab da einiges drin was du auch unten drin stehen hast, und Alex auch schon eine Liste angefangen hat sollten wir und einigen wo und welche Liste wir nun erweitern und führen wollen. Wir sollten erstmal sammeln und dann sollten diejenigen die das sagen haben sollen abstimmen was wichtig ist und was nicht. Evtl kann man sowas auch nochmal zur Diskussion in eine NG posten. Aber das mit den Köchen und den Brei ist ja jedem bekannt.... Gruss Andreas On Monday 12 November 2001 20:05, Matthias Wurm wrote: > So, dann sag ich mal, wie das alles begonnen hat: > Etwa im Juli, das hatte noch gar nix mit der 4. Edition zu tun gehabt, > hatte mal Christian Kutschera, wenn ich mich es recht erinnere, den > Einfall, dass man doch eine NSC-Datenbank erstellen könnte. Da entstand > ein ziemlich langer Thread, in dem diskutiert wurde, dass es sowas > eigentlich schon gäbe (ich kenne den Link leider nicht mehr, war auch > nur ne Homepage, also von technischer Seite total langweilig...), aber > das es inhaltlich gesehn nur Käse wäre, da da außer Werten und einem > *minimalen* Text über den Helden NIX drinstand. Auf jeden Fall kam dann > die Idee einer NSC-Datenbank, bei der Wert auf eine ausführliche > Hintergrundgeschichte gelegt wird, mit einer möglichst ergiebigen > Suchfunktion und und und... Dadurch kam auch die Idee eines "Gremiums", > das entscheidet, ob etwas aufgenommen werden darf oder nicht. > > Auf jeden Fall entwickelte sich der Thread immer mehr und immer weiter, > es wurde Bezug genommen auf Tools wie die auf www.dirkoz.de oder die > ColdSteel DSA-Utilities, die zwar einzelne ganz gute Tools haben, aber > in der Verknüpfung aller Tools eher mangelhaft sind. Einzelne Fragmente > von Funktionalität eben. Es wurde dann auch das Theme "Eher > 'während-dem-Spiel'-Untersrützung oder 'Vorbereitung zum > Spiel'-Unterstützung, wobei sich die Mehrheit eher das 2. wünschten, da > viele von ihnen den Computer nicht am Spieltisch sehen wollten. > > Letztlich führte es dann zu einem Tool, bei dem die einzelnen Sachen wie > Charaktergenerierung, Gegner/Monster erstellung, Ausrüstungsverwaltung > und und und einerseits stark verknüpft werden (Tiere können als > Begleiter verwendet werden, Bücher als Ausrüstung, Städte als Herkünfte, > und vieles darüberhinaus. Klingt jetzt nicht aufregend, aber es ist > schon ein Unterschied, ob man als Stadt "Festum" angibt und danach dann > nur einen Text stehen hat, oder einen Link, der auf eine ausführliche > Stadtbeschreibung führt, ebenso bei den Büchern. Das ist zwar > programmtechnisch gesehen minimalste Funktionalität, wurde von den > anderen Programmen aber nicht mitgebracht) > > Das führte dann soweit, das schließlich das Programm auch als > Abenteuereditor nutzbar sein sollte, bei dem all die einzelnen Objekte > eingegliedert werden. Charaktere in die Dramatis personae, Monster in > den Abentuertext, Städte mit Plan als Handout und übersichtliche > Beschreibung auf einer DIN A4-Seite, und das ganze nur mittels ein paar > Mausbewegungen, also Charaktere / Städte / Schätze und und und einfach > per Drag & Drop in das Abenteuer einbauen. > > Es ist mir klar, dass das noch ein weiter Weg wäre, und für mich > persönlich ist es auch schon das nächste Ziel, ein gutes > Charaktererstellungstool rauszubringen. Aber ich denke, die Ziele > darüberhinaus wären auch sehr reizvoll, und mit einer genügenden Anzahl > an Mitarbeitern könnte man die Aufgaben gut trennen. Keine Angst, ich > will jetzt nicht zu einem Massenaufruf ausholen, jetzt schauen wir erst, > wie wir mit dem hier klarkommen, und können es dann ja immer noch > ausbauen. > > Naja, das sollte einen kleinen Überblick über die Wünsche der Newsgroup > bieten. Von den Features her wäre da noch einiges rauszuquetschen. > Vielleich sollte man eine dsaman-features-list ins leben rufen, und > versuchen, da ein paar DSA-spielende zu holen, da können dann auch > Nicht-Entwickler mitreden, da finden sich sicherlich einige. Überlegt > euch das mal... > > Auf jeden Fall hier mal der Link auf eine kleine .txt, bei der von > unserer Rollenspielgruppe mal einiges an Objekten gesammelt wurde, die > man später einmal in das Programm einbauen könnte. > > http://www.uni-karlsruhe.de/~uub0/dsa4spec.txt > > Gruß > Matthias > > _______________________________________________ > Dsaman-list mailing list > Dsa...@li... > https://lists.sourceforge.net/lists/listinfo/dsaman-list |
From: Matthias W. <Mat...@gm...> - 2001-11-12 19:58:14
|
Alexander Nofftz wrote: > > Hi Matthias! > > Nur zur kurzen Zwischen-Info: Ich habe vorhin mit Oliver Schulz > telefoniert und wir haben beschlossen, beide Projekte unter der > Bezeichnung "DSA Manager" zusammen zu legen, d.h. wir entwerfen jetzt > alle zusammen das Datenformat (dazu wird Oli vermutlich heute noch > seinen Entwurf an diese Liste schicken), und dann werden parallel die > Java- und die native C++-Version für Linux und Windows entwickelt. kewl > > Brauchen wir das in den XML-Dateien? Da bin ich mir nicht so sicher, > viel eher ist so eine Info auf der Homepage interessant. Wenn wir aber > alles als "Pakete" bündeln, könnte so eine Datei durchaus Autoren-Infos > haben, diese hat aber nur informativen Charakter. Ich wollte eigentlich schon zu jedem Datensatz schreiben, woher er kommt, einerseits um nacher nach "nur FanPro" filtern zu können, andererseits um für dei Benutzergemeinde einen Ansporn zu geben (ich denke, viele geben auch ihren Beitrag zu uns, wenn wir dafür sagen, dass die Idee von ihnen kommt, natürlich ohne Veröffentlichung der E-Mail-Addi, sonst würden wir das genaue Gegenteil bewirken...) > > > BTW die Endung muss nicht unbedingt .xml sein, weil das XML-Format durch > das <?xml?>-Statement am Anfang der Datei festgelegt wird. Ich > persönlich finde .dsa vieeeel schöner! :-) > OK > Man kann die Dokumente auch durch die zlib jagen, bevor sie > abgespeichert werden, damit spielen lange Namen kaum noch eine Rolle. > Macht StarOffice übrigens genau so, daher auch die unschlagbar kleinen > Dateien... Hmm... wenn man das Zeug als ZIP-Datei abspeichert, kann ja > in jedem Dokument eine Professionen.xml, eine Vorteile.xml etc. drin > sein -- oder auch nicht... Häh ? Sie meinen ? Meinst du für jeden Helden eine .zip ? > > Oliver und Holger sind noch viel scheußlichere Sachen im Regelwerk > aufgefallen, warten wir mal, was die dazu zu sagen haben. oh oh... > > Oli schreibt gerade seine Ideen zusammen. Sobald die in dieser Liste > sind, haben wir wohl genug zu diskutieren <g> OH OH... |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 19:50:08
|
Hi Andreas! > > Ok, das ist ein guter Kompromiß. Dann machen wir das so. > Hört sich gut an.. Kompromisse sind immer gut, wie? <g> > Ich gehe davon aus das du nicht alle Rassen Proffensionen usw in je > eine grosse XML datei packen willst? Oder doch ? > Ich dachte eher an Rasse_Mensch.XML > Rasse_Zwerg.XML > Kultur_Thorwal.XML > Kutur_Amboss.XML > Profession_Seefahrer.XML > Profession_Schmied.XML > usw > usw > Das Programm sucht dann alle Dateien die mit XXX und liefert daraus > dann ne Auswahlliste. Natuerlich muessen in den Einzelnen Dateien > enthalten wer nun Schmied werden darf oder aus dem Amboss stammen > darf. Von der Vorgehensweise nicht verkehrt, aber so etwas wird schnell sehr unübersichtlich. > Hmm evtl Rüstungsgewöhnung und dabei ein Textfeld wo man einträgt um > welche es sich handelt. Muss das Tool nachher auswerten das es sich um > Gewöhnung bei Leder oder Stahl handelt ? Das ist doch mehr eine > Information für den Spieler. > Wenn das Tool natürlich auch noch Ausrüstung / Waffen / Rüstungen > verwalten soll muss man dieses und sicherlich noch einige Probleme > mehr lösen. Allerdings. Zuerst wollen wir nur einen Charaktergenerator machen, aber ich würde das Programm später auch gerne erweitern, dass ich es im Spiel einsetzen kann, um Werte etc. immer aktuell zu haben oder sogar Kämpfe zu verwalten. Spätestens dann muss es drin sein, daher können wir das auch direkt von Anfang an berücksichtigen. > Ich bekomm ich ne krise bei endlos mails ;-) Dann quote nicht so viel! ;-> [Kampfwerte] > evtl vorhandene boni oder mali nicht vergessen Die stehen i.d.R. bei den Waffen. Außerdem werden hier nur die *Zusatz*punkte auf die Basiswerte gespeichert, nicht die finiten AT/PA-Werte. > Hmm wie wäre es mal wenn wir erstmal sammeln was das Programm denn nun > alles können soll. So ein "Pflichtenheft" hilft echt weiter... 1. Charaktergenerierung 2. Charaktersteigerung 3. Nachschlagewerk für Rassen, Professionen, Kulturen, Vorteile, Nachteile, Talente, Zauber, Waffen, Ausrüstungsgegenstände (ergibt sich zum Großteil auch schon aus 1 und 2) 4. Ausdruck von Heldenbögen, Export von allen Elementen als HTML 5. "In-Game"-Tool für Meister (und Spieler) quasi als elektronischer Heldenbogen 6. Kampfverwaltung 7. Krankheiten, Gifte etc.pp. Wir werden uns aber streng von oben nach unten durcharbeiten <g> Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 19:49:26
|
Hi Matthias! Ich hatte ausversehen die Mail nur an dich geschickt. Kannst du bitte deine Mail, auf die ich hier Bezug nehme, noch mal an die Liste weiterleiten? >>Brauchen wir das in den XML-Dateien? Da bin ich mir nicht so sicher, >>viel eher ist so eine Info auf der Homepage interessant. Wenn wir aber >>alles als "Pakete" bündeln, könnte so eine Datei durchaus Autoren-Infos >>haben, diese hat aber nur informativen Charakter. > > Ich wollte eigentlich schon zu jedem Datensatz schreiben, woher er > kommt, einerseits um nacher nach "nur FanPro" filtern zu können, > andererseits um für dei Benutzergemeinde einen Ansporn zu geben (ich > denke, viele geben auch ihren Beitrag zu uns, wenn wir dafür sagen, dass > die Idee von ihnen kommt, natürlich ohne Veröffentlichung der > E-Mail-Addi, sonst würden wir das genaue Gegenteil bewirken...) Klar, aber das kann man dan nachvollziehen: ID -> Speicherort des Objekts -> XML-Datei -> Autoren-Info in der Datei >>Man kann die Dokumente auch durch die zlib jagen, bevor sie >>abgespeichert werden, damit spielen lange Namen kaum noch eine Rolle. >>Macht StarOffice übrigens genau so, daher auch die unschlagbar kleinen >>Dateien... Hmm... wenn man das Zeug als ZIP-Datei abspeichert, kann ja >>in jedem Dokument eine Professionen.xml, eine Vorteile.xml etc. drin >>sein -- oder auch nicht... > > Häh ? Sie meinen ? Meinst du für jeden Helden eine .zip ? Ja, warum nicht? Zumindest für die Pakete wäre das sehr übersichtlich und Platzsparend. Ich kann euch ja mal eine StarOffice-Datei zukommen lassen, wenn ihr das Programm nicht habt. >>Oliver und Holger sind noch viel scheußlichere Sachen im Regelwerk >>aufgefallen, warten wir mal, was die dazu zu sagen haben. >> > oh oh... > > >>Oli schreibt gerade seine Ideen zusammen. Sobald die in dieser Liste >>sind, haben wir wohl genug zu diskutieren <g> >> > OH OH... > LOL Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-12 19:42:17
|
Hi Matthias! Nur zur kurzen Zwischen-Info: Ich habe vorhin mit Oliver Schulz telefoniert und wir haben beschlossen, beide Projekte unter der Bezeichnung "DSA Manager" zusammen zu legen, d.h. wir entwerfen jetzt alle zusammen das Datenformat (dazu wird Oli vermutlich heute noch seinen Entwurf an diese Liste schicken), und dann werden parallel die Java- und die native C++-Version für Linux und Windows entwickelt. Außerdem habe ich den Betreff geändert, weil wir ja nicht mehr über das Charakterblatt reden. > Hmmm, irgendwie glaube ich, wir haben uns falsch verstanden... > Ich gehe mal von einer VorNachteile.xml, also werden ALLE Vor- und > Nachteil in *einer* XML-Datei gespeichert. So hatte ich das in der Tat auch vor, aber mittlerweile gefällt mir die Idee mit der logischen Gruppierung besser :-) > die IDs werden wie gehabt > verteilt, Vorteil beginnen mit Vot, Nachteil mit Nat, zumindest > diejenigen, die offiziel sind (unter offiziel verstehe ich hiermit > alle, die in UNSERER Kollektion sind, nur nur die FanPro-Sachen, also > auch evt. schon hochgeladene und für gut befunden Vor/Nachteile, > Professionen und was sonst noch alles) > Einträge, die der Benutzer selbst seinen eigenen lokalen Daten > hinzugefügt hat, bekommen vor der normalen ID ein "My_" davorgestellt. > also, My_NatIrgendwas. Das mit der Nummer ist nur für > Kollisionsauflösung. OK > Wenn der Benutzer meint, sein "My_NatIrgendwas" ist eine besonders > tolle Idee, dann lädt er das zu uns hoch. Wir oder jemand anderes > prüft dann, ob das wirklich gut ist, oder Mist... Bei der ersteren > Variante wird das dann in unseren offiziellen Topf geworfen. (Aus > diesem Grund würde ich nacher auch bei jedem VorNachteil / Profession > / Kultur etc., aber auch bei Charakteren angeben, von WEM der > Datensatz hochgeladen wurde (da könnten wir einen Login-Bereich für > unsere Webseite nehmen, die BenutzerID, auf die verwiesen wird, ist > dann gerade der Login-Name...)) Brauchen wir das in den XML-Dateien? Da bin ich mir nicht so sicher, viel eher ist so eine Info auf der Homepage interessant. Wenn wir aber alles als "Pakete" bündeln, könnte so eine Datei durchaus Autoren-Infos haben, diese hat aber nur informativen Charakter. > Ok, soweit so gut. Dann haben wir dadurch ja das Problem, dass der, > der neue Datensätze runterlädt, wissen muss, WELCHE Datensätze denn > anders sind als seine lokalen, sprich, was sich nach der letzten > Synchronisation, wenn ich sie mal so bezeichnen darf, geändert hat. [...] Ja, man merkt schon, dass du das mit Datenbanken geplant hattest. Bei diesen müsste man das in der Tat so machen, aber wir haben ja XML! :-) Wenn wir einfach sagen, dass alles, was ein "Autor" erstellt hat (also Professionen, Kulturen, Vor- und Nachteile, Talente, Zauber), die zusammen gehören, in einer Datei speichern, dann stattet man *diese Datei* einfach mit der Autoren-Info und einer *Versionsnummer* aus. Diese ist dann zur Synchronisation mehr als genug. > Ich hoffe, ich konnte das halbwegs verständlich rüberbringen. Das > würde dann dazu führen, dass wir XML-Dateien auf die Art: > > Charaktere.xml > VorNachteile.xml > Rassen.xml > Kulturen.xml > Professionen.xml (Rassen / Kulturen / Professionen vielleicht auch in > einer Datei, wobei mir da jetzt kein Überbegriff einfällt) > Sonderfertigkeiten.xml (oder auch in VorNachteile) > ...und was halt noch so alles dazukommt. BTW die Endung muss nicht unbedingt .xml sein, weil das XML-Format durch das <?xml?>-Statement am Anfang der Datei festgelegt wird. Ich persönlich finde .dsa vieeeel schöner! [:-)] > In diesen Dateien werden die eigenen Daten dann nur durch die ID "My_" > von den unseren getrennt. > Akzeptiert ihr den Vorschlag so in etwa ? Das mit dem my_ ist einer sehr gute Idee, damit kann man auch sehr schnell implementieren, wenn jemand aufgrund von "Hausregeln" einfach vorgegebene Sachen umdefiniert. > > Gut, aber wenn ich nun NatNiedrigeMR1, NatNiedrigeMR2 und > > NatNiedrigeMR3 > > habe, woher weiß ich dann, welcher Nachteil eigentlich gemeint ist? > > Diese IDs in dem Charakterblatt sind nur Referenzen, wo die > > Definition ursprünglich her kam, im Bogen selbst kann die dann > > anders aussehen, > > sonst müsste man ja für jeden Wert eine eigene Eigenschaft > > definieren. > > Hier wäre die einzige Möglichkeit, den ganzen Name als ID zu verwenden > (unerlaubte Zeichen natürlich rausfiltern / umwandeln. Dann weiß man > _immer_, woran man ist. Außerdem, ist die ID für den Benutzer ja > gänzlich uninteressant, weil er von ihr ja eigentlich gar nix > mitbekommt. Weil an den Daten selbst soll er ja eigentlich nicht > rumpfuschen... Kann man auch machen, sicher. Dann müssen wir nur eine geeignete Umwandlungsfunktion Name -> XML-ID haben. > > > Das wär das simpelste. Dann muss der Benutzer schonmal nix selber > > > eingeben, und kann sich - falls er wirklich mal später diese Id > > > brauchen sollte, den richtigen Namen mit höchster > > > Wahrscheinlichkeit aus dieser einfachen Regel anhand des Namens > > > selber erstellen. > > > > > Ja, genau. So hatte ich's mir auch gedacht. Nur sollte man halt > > solche absoluten Namensähnlichkeiten abfangen und den Benutzer > > fragen, ob er nicht schon das vorhandene Element gemeint hatte. > > Falls nicht, sollte er den Namen lieber umformulieren, und damit > > ergibt sich auch wieder eine völlig anders generierte ID. > > s.oben. Weil der komplette Name sollte ja eigenltich schon eindeutig > sein, sonst machts ja auch keinen Sinn mehr, wenn mal zweimal > Meeresangst hat... Beim Vorschlag oben droht aber die Gefahr zu langer > IDs. Da die aber ja eigneltich die Ausnahme sind, kann man damit > leben, oder was meint ihr *fragendguck* ? *zuschlag* ;-> Man kann die Dokumente auch durch die zlib jagen, bevor sie abgespeichert werden, damit spielen lange Namen kaum noch eine Rolle. Macht StarOffice übrigens genau so, daher auch die unschlagbar kleinen Dateien... Hmm... wenn man das Zeug als ZIP-Datei abspeichert, kann ja in jedem Dokument eine Professionen.xml, eine Vorteile.xml etc. drin sein -- oder auch nicht... > > Eventuell könnte man ja alle Rüstungen in Klassen einteilen, denn > > eine Lederrüstung ist selten gleichzeitig eine Metallrüstung ;-) > > Ja, die Frage ist, was später mal kommt. Anhand dieser > Sonderfertigkeit wissen wir, dass wir sowas brauchen. Aber vielleicht > kommt später mal was, das wir nicht berücksichtigt habe. Dann könnte > man konsequent sein, und einen Schnitt machen: Bis zu diesem > Detailgrad unterstützen wir Modifikatoren und nicht weiter. Weil wir > stoßen in den Regeln sicherlich noch auf Sachen, die wir nur mit > übermäßigem Aufwand ermöglichen können. Aber warten wir mal ab... Oliver und Holger sind noch viel scheußlichere Sachen im Regelwerk aufgefallen, warten wir mal, was die dazu zu sagen haben. > > > Hab ich aber leider erst danach gelesen... *g* Blöde Lang-Mails ! > > > > Na ja, man könnte ja auch die einzelnen Teile des Datenblatts in > > unterschiedlichen Mails besprechen, aber dann haben wir viele > > kleine, anstatt einer großen Mail... > > War eigentlich kein Ernst-gemeinter Vorwurf vor mir, und so isses > eigentlich auch besser. > Ich muss halt mal öfters zwischendurch Mails checken ;-) Schon, aber zumindest den Betreff sollten wir eindeutig halten, damit man irgendwelche Punkte schnell wiederfindet. > > > Ok, was sollen wir dann als nächstes in die Hand nehmen ? Die > > > Syntax ? Oder die "BE-1 auf Lederrüstungen"-Geschichte ? > > > > Weiß nicht, schlag was vor! ;-) > > Nee, schlag du was vor ! > Naja, vielleicht kommt mir heut abend ja noch ne Idee... *blink* Oli schreibt gerade seine Ideen zusammen. Sobald die in dieser Liste sind, haben wir wohl genug zu diskutieren <g> Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Matthias W. <Mat...@gm...> - 2001-11-12 18:59:57
|
So, dann sag ich mal, wie das alles begonnen hat: Etwa im Juli, das hatte noch gar nix mit der 4. Edition zu tun gehabt, hatte mal Christian Kutschera, wenn ich mich es recht erinnere, den Einfall, dass man doch eine NSC-Datenbank erstellen könnte. Da entstand ein ziemlich langer Thread, in dem diskutiert wurde, dass es sowas eigentlich schon gäbe (ich kenne den Link leider nicht mehr, war auch nur ne Homepage, also von technischer Seite total langweilig...), aber das es inhaltlich gesehn nur Käse wäre, da da außer Werten und einem *minimalen* Text über den Helden NIX drinstand. Auf jeden Fall kam dann die Idee einer NSC-Datenbank, bei der Wert auf eine ausführliche Hintergrundgeschichte gelegt wird, mit einer möglichst ergiebigen Suchfunktion und und und... Dadurch kam auch die Idee eines "Gremiums", das entscheidet, ob etwas aufgenommen werden darf oder nicht. Auf jeden Fall entwickelte sich der Thread immer mehr und immer weiter, es wurde Bezug genommen auf Tools wie die auf www.dirkoz.de oder die ColdSteel DSA-Utilities, die zwar einzelne ganz gute Tools haben, aber in der Verknüpfung aller Tools eher mangelhaft sind. Einzelne Fragmente von Funktionalität eben. Es wurde dann auch das Theme "Eher 'während-dem-Spiel'-Untersrützung oder 'Vorbereitung zum Spiel'-Unterstützung, wobei sich die Mehrheit eher das 2. wünschten, da viele von ihnen den Computer nicht am Spieltisch sehen wollten. Letztlich führte es dann zu einem Tool, bei dem die einzelnen Sachen wie Charaktergenerierung, Gegner/Monster erstellung, Ausrüstungsverwaltung und und und einerseits stark verknüpft werden (Tiere können als Begleiter verwendet werden, Bücher als Ausrüstung, Städte als Herkünfte, und vieles darüberhinaus. Klingt jetzt nicht aufregend, aber es ist schon ein Unterschied, ob man als Stadt "Festum" angibt und danach dann nur einen Text stehen hat, oder einen Link, der auf eine ausführliche Stadtbeschreibung führt, ebenso bei den Büchern. Das ist zwar programmtechnisch gesehen minimalste Funktionalität, wurde von den anderen Programmen aber nicht mitgebracht) Das führte dann soweit, das schließlich das Programm auch als Abenteuereditor nutzbar sein sollte, bei dem all die einzelnen Objekte eingegliedert werden. Charaktere in die Dramatis personae, Monster in den Abentuertext, Städte mit Plan als Handout und übersichtliche Beschreibung auf einer DIN A4-Seite, und das ganze nur mittels ein paar Mausbewegungen, also Charaktere / Städte / Schätze und und und einfach per Drag & Drop in das Abenteuer einbauen. Es ist mir klar, dass das noch ein weiter Weg wäre, und für mich persönlich ist es auch schon das nächste Ziel, ein gutes Charaktererstellungstool rauszubringen. Aber ich denke, die Ziele darüberhinaus wären auch sehr reizvoll, und mit einer genügenden Anzahl an Mitarbeitern könnte man die Aufgaben gut trennen. Keine Angst, ich will jetzt nicht zu einem Massenaufruf ausholen, jetzt schauen wir erst, wie wir mit dem hier klarkommen, und können es dann ja immer noch ausbauen. Naja, das sollte einen kleinen Überblick über die Wünsche der Newsgroup bieten. Von den Features her wäre da noch einiges rauszuquetschen. Vielleich sollte man eine dsaman-features-list ins leben rufen, und versuchen, da ein paar DSA-spielende zu holen, da können dann auch Nicht-Entwickler mitreden, da finden sich sicherlich einige. Überlegt euch das mal... Auf jeden Fall hier mal der Link auf eine kleine .txt, bei der von unserer Rollenspielgruppe mal einiges an Objekten gesammelt wurde, die man später einmal in das Programm einbauen könnte. http://www.uni-karlsruhe.de/~uub0/dsa4spec.txt Gruß Matthias |
From: Matthias W. <Mat...@gm...> - 2001-11-12 18:59:50
|
Andreas Hugenroth wrote: > > > Ich gehe davon aus das du nicht alle Rassen Proffensionen usw in je eine > grosse XML datei packen willst? Oder doch ? Eigentlich doch. Weil das untenstehende führt ja gerade zu dem großen Dateienwusel, den Alexander befürchtet hat... > Ich dachte eher an > Rasse_Mensch.XML > Rasse_Zwerg.XML > Kultur_Thorwal.XML > Kutur_Amboss.XML > Profession_Seefahrer.XML > Profession_Schmied.XML > > > > Ja, die Frage ist, was später mal kommt. Anhand dieser Sonderfertigkeit > > wissen wir, dass wir sowas brauchen. Aber vielleicht kommt später mal > > was, das wir nicht berücksichtigt habe. Dann könnte man konsequent sein, > > und einen Schnitt machen: Bis zu diesem Detailgrad unterstützen wir > > Modifikatoren und nicht weiter. Weil wir stoßen in den Regeln sicherlich > > noch auf Sachen, die wir nur mit übermäßigem Aufwand ermöglichen können. > > Aber warten wir mal ab... > > Hmm evtl Rüstungsgewöhnung und dabei ein Textfeld wo man einträgt um welche > es sich handelt. Muss das Tool nachher auswerten das es sich um Gewöhnung bei > Leder oder Stahl handelt ? Das ist doch mehr eine Information für den Spieler. > Wenn das Tool natürlich auch noch Ausrüstung / Waffen / Rüstungen verwalten > soll muss man dieses und sicherlich noch einige Probleme mehr lösen. > Denn nichts nervt mehr wenn man sich eine Ruestung zum Held legt ( im tool) > und dieses dann die falsche RS/BE berechnet. Der Fehler wirkt sich ja auch > noch auf Talente aus. > Man kann natürlich eine "leichte" Lösung wählen wo die Ausrüstung usw > Textfelder sind. Der Spieler trägt dann die RS/BE werte in dafür vorgesehende > Felder ein. Man kann auf die Waffen-Rüstungs Seite ja Hinweisfelder legen wo > Waffenspezifiesche Vor/Nachteile angezeigt werden. > Hmmmmm, naja es wäre aber schon toll wenn man sich ne Waffe aussucht und das > Programm alles weitere selbst macht. ;-) Diese "selbsteintragen"-Variante sollten wir wirklich nur für die Fälle aufheben, wo ein zu übermäßiger Aufwand nötig wäre und man davon ausgehen kann, und falls wir selber meinen, dass das nur einmal alle 1000 Charaktere der Fall sein wird. z.B. alle grünen Strumpfhosen kosten 5 Heller weniger oder sowas... > > > Genau, wobei man eigentlich nur die AT angeben müsste, denn die PA > > > ergibt sich automatisch aus TaW-AT. > > > > Okidoki > > > > evtl vorhandene boni oder mali nicht vergessen > > > > > Ok, was sollen wir dann als nächstes in die Hand nehmen ? Die Syntax ? > > > > Oder die "BE-1 auf Lederrüstungen"-Geschichte ? > > > > > > Weiß nicht, schlag was vor! ;-) > > > > Nee, schlag du was vor ! > > Naja, vielleicht kommt mir heut abend ja noch ne Idee... > > > > Hmm wie wäre es mal wenn wir erstmal sammeln was das Programm denn nun alles > können soll. So ein "Pflichtenheft" hilft echt weiter... > siehe andere Mail... Gruß Matthias |
From: Andreas H. <ahu...@gm...> - 2001-11-12 17:37:49
|
Hi, > > Letzteres könnte man > > dadurch regeln, dass man sich einfach den ID anschaut: Alle Schlechten > > Eigenschaften beginnen laut Konvention mit "Nat", die guten nicht ;-) > > Ok, das ist ein guter Kompromiß. Dann machen wir das so. > Hört sich gut an.. > Ok, soweit so gut. Dann haben wir dadurch ja das Problem, dass der, der > neue Datensätze runterlädt, wissen muss, WELCHE Datensätze denn anders > sind als seine lokalen, sprich, was sich nach der letzten > Synchronisation, wenn ich sie mal so bezeichnen darf, geändert hat. Bei > Datenbanken geht das ja, da hätte ich einfach die SQL-Anweisungen mit > Datum + Uhrzeit davor in einer Textdatei gespeichert, und alle > Anweisungen ab dem letzten Sync.Zeitpunkt ausgeführt. Wie man das in XML > am praktischsten macht, kann ich nicht beurteilen, Hinzufügungen und > Löschungen sind ja einfach zu realisieren, aber Änderungen > wahrscheinlich weniger. Da muss man sich noch was überlegen, das kannst > du vielleicht besser einschätzen. > Gehen wir mal davon aus, das klappt, dann stellt sich folgendes Problem: > Nehmen wir jetzt mal 3 Gruppen: > 1.) Die, die das Objekt "X" bei sich lokal nicht haben, auch kein > ähnliches, die dürfen es ja runterladen. > 2.) Derjenige, der es hochgeladen hatte, muss das hochgeladene Suchen > und die ID von "My_X" auf "X" ändern. Dasselbe gilt aber auch für die > Leute in seinem Freundeskreis, denen er das Objekt X weitergegeben hat - > sagen wir durch dir Möglichkeit des Exportierens und Importierens. Die > haben ja auch dieses Objekt, und zwar mit dem "My_"-Anhängsel. > 3.) Die Leute die Quasi das gleiche Objekt bei sich erstellt haben, aber > eben leicht modifiziert, so dass das Programm selbst es nicht erkennen > kann. Diese Leute sind für das Programm praktisch das gleiche wie unter. > Ich denke, ein Hinweis "Achtung. Das [Objekt X] könnte bereits so oder > ähnlich unter ihren Datensätzen vorhanden sein... bla bla", auf jeden > Fall sollte sie das eigene Objekt dann löschen. Ach ja, noch was, NUR > die "My_"-Dinger sollte gelöscht werden können, KEINE offiziellen. Schwer schwer, eine idee zur Lösung hab ich auch noch nicht. > Fazit: 2 ist recht einfach, eine Automatische Erkennung unter 3 > wahrscheinlich nur bedingt zu realisieren. Das Problem betrifft unsere > Struktur aber ja ohnehin nicht, so dass wir sie zu einem späteren > Zeitpunkt verlegen können. Bis auf die Geschichte mit dem Benutzer, das > könnten wir ja mittels einem <User id="usrFanPro"> realisieren, mehr > brauchen wir ja nicht. > > Ich hoffe, ich konnte das halbwegs verständlich rüberbringen. Das würde > dann dazu führen, dass wir XML-Dateien auf die Art: > > Charaktere.xml > VorNachteile.xml > Rassen.xml > Kulturen.xml > Professionen.xml (Rassen / Kulturen / Professionen vielleicht auch in > einer Datei, wobei mir da jetzt kein Überbegriff einfällt) > Sonderfertigkeiten.xml (oder auch in VorNachteile) > ...und was halt noch so alles dazukommt. > In diesen Dateien werden die eigenen Daten dann nur durch die ID "My_" > von den unseren getrennt. > Akzeptiert ihr den Vorschlag so in etwa ? Ich gehe davon aus das du nicht alle Rassen Proffensionen usw in je eine grosse XML datei packen willst? Oder doch ? Ich dachte eher an Rasse_Mensch.XML Rasse_Zwerg.XML Kultur_Thorwal.XML Kutur_Amboss.XML Profession_Seefahrer.XML Profession_Schmied.XML usw usw Das Programm sucht dann alle Dateien die mit XXX und liefert daraus dann ne Auswahlliste. Natuerlich muessen in den Einzelnen Dateien enthalten wer nun Schmied werden darf oder aus dem Amboss stammen darf. > > > > Und für die Namensgenerierung "NatNiedrigeMR" Nat als Vorgabe für > > > Nachteil nehmen, der Rest ergibt sich z.B. so: Nehme die ersten 10 > > > nicht-Spache Zeichen aus dem Namen, klatsche sie zusammen und mache > > > alle ä's zu a's etc. (es sei denn, die sind bei ids erlaubt...) > > > > Sind sie. Als ID darf laut XML-Spec so ziemlich alles verwendet werden, > > was in Unicode definiert ist -- die abstrusesten Sachen mal ausgenommen. > > Einzig bei Dateinamen muss man aufpassen. Ich weiß nicht, ob die JavaVM > > dieses Problem automatisch berücksichtigt, daher siehe auch oben. > > > > > Wenn dann > > > aber trotzdem schon ein Datensatz vorhanden ist, setze ein 1 hintendran > > > (oder eine 2 bei einer weiteren Kollision)... > > > > Gut, aber wenn ich nun NatNiedrigeMR1, NatNiedrigeMR2 und NatNiedrigeMR3 > > habe, woher weiß ich dann, welcher Nachteil eigentlich gemeint ist? > > Diese IDs in dem Charakterblatt sind nur Referenzen, wo die Definition > > ursprünglich her kam, im Bogen selbst kann die dann anders aussehen, > > sonst müsste man ja für jeden Wert eine eigene Eigenschaft definieren. > > Hier wäre die einzige Möglichkeit, den ganzen Name als ID zu verwenden > (unerlaubte Zeichen natürlich rausfiltern / umwandeln. Dann weiß man > _immer_, woran man ist. Außerdem, ist die ID für den Benutzer ja > gänzlich uninteressant, weil er von ihr ja eigentlich gar nix > mitbekommt. Weil an den Daten selbst soll er ja eigentlich nicht > rumpfuschen... > > > Das wär das simpelste. Dann muss der Benutzer schonmal nix selber > > > eingeben, und kann sich - falls er wirklich mal später diese Id > > > brauchen sollte, den richtigen Namen mit höchster Wahrscheinlichkeit > > > aus dieser einfachen Regel anhand des Namens selber erstellen. > > > > Ja, genau. So hatte ich's mir auch gedacht. Nur sollte man halt solche > > absoluten Namensähnlichkeiten abfangen und den Benutzer fragen, ob er > > nicht schon das vorhandene Element gemeint hatte. Falls nicht, sollte er > > den Namen lieber umformulieren, und damit ergibt sich auch wieder eine > > völlig anders generierte ID. > > s.oben. Weil der komplette Name sollte ja eigenltich schon eindeutig > sein, sonst machts ja auch keinen Sinn mehr, wenn mal zweimal > Meeresangst hat... Beim Vorschlag oben droht aber die Gefahr zu langer > IDs. Da die aber ja eigneltich die Ausnahme sind, kann man damit leben, > oder was meint ihr *fragendguck* ? > > > >>Problem bleibt nur, wie man solche Dinge wie die Rüstungsgewöhnung I > > >> bei etwa Söldnern ("Alle Lederrüstungen BE-1") in unserer > > >>Modifikatoren-Sprache schreibt. > > > > > > Da fällt mir jetzt auch nix vernünftiges ein, das auch auf evt. andere > > > Fälle greifen würde. Ein Attribut, das "Leder/Stahl/..." als wert hat, > > > und dann ein entspr. Modifikator ist ja auch Quatsch, weil viel zu > > > speziell. Über solch allgemeinen Dinge sollten wir uns alle mal später > > > separat unterhalten, und alles zusammentragen, was so ähnlich ist, wie > > > dein Beispiel. Dann können wir das vielleicht irgendwann unter einen > > > Hut packen. Aber irgendwie hab ich das Gefühl, dass das nicht richtig > > > klappen wird, und wir daher auf ein unspektakuläres "Bemerkungsfeld" > > > > Eventuell könnte man ja alle Rüstungen in Klassen einteilen, denn eine > > Lederrüstung ist selten gleichzeitig eine Metallrüstung ;-) > > Ja, die Frage ist, was später mal kommt. Anhand dieser Sonderfertigkeit > wissen wir, dass wir sowas brauchen. Aber vielleicht kommt später mal > was, das wir nicht berücksichtigt habe. Dann könnte man konsequent sein, > und einen Schnitt machen: Bis zu diesem Detailgrad unterstützen wir > Modifikatoren und nicht weiter. Weil wir stoßen in den Regeln sicherlich > noch auf Sachen, die wir nur mit übermäßigem Aufwand ermöglichen können. > Aber warten wir mal ab... Hmm evtl Rüstungsgewöhnung und dabei ein Textfeld wo man einträgt um welche es sich handelt. Muss das Tool nachher auswerten das es sich um Gewöhnung bei Leder oder Stahl handelt ? Das ist doch mehr eine Information für den Spieler. Wenn das Tool natürlich auch noch Ausrüstung / Waffen / Rüstungen verwalten soll muss man dieses und sicherlich noch einige Probleme mehr lösen. Denn nichts nervt mehr wenn man sich eine Ruestung zum Held legt ( im tool) und dieses dann die falsche RS/BE berechnet. Der Fehler wirkt sich ja auch noch auf Talente aus. Man kann natürlich eine "leichte" Lösung wählen wo die Ausrüstung usw Textfelder sind. Der Spieler trägt dann die RS/BE werte in dafür vorgesehende Felder ein. Man kann auf die Waffen-Rüstungs Seite ja Hinweisfelder legen wo Waffenspezifiesche Vor/Nachteile angezeigt werden. Hmmmmm, naja es wäre aber schon toll wenn man sich ne Waffe aussucht und das Programm alles weitere selbst macht. ;-) > > Bei den Sprachen werden wir um so etwas auch nicht herum kommen, weil > > für Sprachfamilien ja andere Steigerungsregeln gelten. > > > > >>Hatte ich schon woanders geschrieben. > > > > > > Hab ich aber leider erst danach gelesen... *g* Blöde Lang-Mails ! > > > > Na ja, man könnte ja auch die einzelnen Teile des Datenblatts in > > unterschiedlichen Mails besprechen, aber dann haben wir viele kleine, > > anstatt einer großen Mail... > > War eigentlich kein Ernst-gemeinter Vorwurf vor mir, und so isses > eigentlich auch besser. > Ich muss halt mal öfters zwischendurch Mails checken ;-) > Ich bekomm ich ne krise bei endlos mails ;-) > > >>>und aus Behinderung würde ich (bei den Talenten und bei > > >>>Kampffertigkeiten), da es ja schon vom Regelwerk her so ist, einfach > > >>> eBE machen, da spart man Zeichen. Nix weltbewegendes, aber nur ein > > >>> kleiner Vorschlag... > > >> > > >>Du meinst > > >> > > >> <Modifikator expr="eBE*2"/> > > >> > > >>? > > >> > > >>Wäre eine Möglichkeit, obwohl wir die eBEs dann aus der allgemeinen > > >>Auswertung für Modifikatoren rausnehmen müssten... > > > > > > ne, Hab nur den Bezeichner gemeint, also: <eBE expr="*2"/> > > > War nur ein Schnickschnack-Vorschlag, um ein paar Zeichen zu kürzen, > > > und da die Bezeichnung schon vor FanPro kommt, kann mans ja grad > > > übernehmen... > > > > Achso, ja klar, könnte man so machen. > > > > > > ... > > > > > > Genau, wobei man eigentlich nur die AT angeben müsste, denn die PA > > ergibt sich automatisch aus TaW-AT. > > Okidoki > evtl vorhandene boni oder mali nicht vergessen > > > Ok, was sollen wir dann als nächstes in die Hand nehmen ? Die Syntax ? > > > Oder die "BE-1 auf Lederrüstungen"-Geschichte ? > > > > Weiß nicht, schlag was vor! ;-) > > Nee, schlag du was vor ! > Naja, vielleicht kommt mir heut abend ja noch ne Idee... > Hmm wie wäre es mal wenn wir erstmal sammeln was das Programm denn nun alles können soll. So ein "Pflichtenheft" hilft echt weiter... Gruss Andreas |