dsaman-list Mailing List for DSA Manager (Page 5)
Status: Planning
Brought to you by:
alexnofftz
Menu
▾
▴
dsaman-list — Allgemeine Diskussionsliste
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: Oliver S. <wh...@us...> - 2002-05-06 13:44:00
|
Hallo Tilmann!
> Welche Reihenfolgekonflikte ueberhaupt? Ich hab jetzt schon einiges
> hinsichtlich Modifikator-Management implementiert und bis jetzt gabs da noch
> keine Reihenfolgekonflikte.
Man stelle sich folgenden Fall vor:
1. Talent "Meditieren" gibt +1 auf MR, wenn TaW.basis > 10.
2. Artefakt "Mighty Alrik" gibt +5 auf KK, aber
wirkt nur, wenn MR(.effektiv!)<=4.
Nehmen wir an, Modi 1 kommt aus der Regelbox "Mohas in der Wüste",
Modi 2 aus "Tausend und ein Ding". Offensichtlich sollte erst
Modi 1, dann Modi 2 angewendet werden. Aber das kann unmöglich
schon in den Modulen drin stehen, die gar nix voneinander wissen.
Ergo muß das Programm das schon selbst rausfinden.
Es _wird_ Reihenfolgeprobleme geben (eher früher, als später), und
daß bis jetzt noch keine aufgetreten sind, liegt schlicht daran,
das wir noch kein umfangreiches Regelwerk umgesetzt haben.
> Wie gesagt, dass kann man machen, man braucht dann aber wieder fuer jeden
> Modifikator einen Wrapper im Charakter. Und das sind wirklich sehr viele
Na und? So groß sind die Syntaxbäume nicht. Es ist ja auch für jede
Eigenschaft, jedes Talent, jedes XYZ ein Wrapper geladen.
> (Modifikatoren-Anzahl x Geladene-Charakter-Anzahl) Bei meiner
Nein, je nach Implementierung entweder
Modifikatoren-im-Regelwerk-Anzahl x 1
oder
Im-Charakter-benutzte-Modis x Geladene-Charakter-Anzahl.
> Nein! Beim Auswerten wird direkt auf dem Syntaxbaum gearbeitet.
Nun, dann mußt Du eh den gesamten Syntaxbaum im Speicher halten.
Und ein großer Syntaxbaum ist auch nicht viel kleiner als mehrere
einzelne kleine (wenn überhaupt).
Und die Scripte auf (Script-)Quellcodeebene zusammenzukleben -
das fühlt sich wie ein Hack an ... :-)
> > Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand
> > die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen
[...]
> auch keine Reihenfogekonflikte. Ausserdem widerspricht die Vorgehensweise
> mit den Zuweisungen dem "Relationen als Nachrichten"-Konzept und macht das
Ist ja nur ein Implementierungsvorschlag, das kann in Java ja völlig
anders gemacht werden, als in C++.
Das mit dem "Relationen als Nachrichten" hat nix damit zu tun,
ob man schreibt ziel="x", quelle="y", oder "x=y" ist semantisch
identisch. Es ist auch kein Problem, im zweiten Fall das Ziel
zu ermitteln, das steht im Syntaxbaum ja deutlich drin.
Ich will auch gar nicht mit dem Scriptdesign eine Implementierung
festlegen, ich möchte, daß das Scriptdesign kompakt, elegant,
leistungsfähig und leicht zu handhaben ist (v.a. in der Anwendung).
Ein Modifikator ist eine logische Einheit (Quelle und Ziel), warum
soll man ihn auseinanderreißen?
Zudem hält man sich mit meinem Ansatz einfach mehr Möglichkeiten offen,
z.B. Modifikatoren mit mehrenen, oder sogar variablen Zielen
("a<b ? MU+=5 : GE+=5"). Mag sein, das wir sowas nicht brauchen, aber
ich möchte nicht drauf wetten. Viele Boxen sind noch nicht geschrieben
... wenn uns Flexibilität keinen (oder nicht viel) Aufwand kostet,
sollten wir sie wählen.
> > Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten,
[...]
> Die stellen in der Aktuellen java-Version sicher ein Problem dar, das
> allerdings nur dann auftritt, wenn jemand in den Regeldefinitionen rumpfuscht.
Wir bauen einen modularen Charaktergenerator. "Rumpfuschen" wird
hoffentlich keiner, aber es werden von unterschiedlichen Leuten
gebaute Regelmodule zusammenkommen, dann noch die Sonderregeln und
Gegenstände der User, usw. Das kann und wird nicht alles genau
aufeinander abgestimmt sein.
cu
Oli
|
|
From: Tilmann K. <ds...@tk...> - 2002-05-05 22:57:46
|
Hi Leute! Oliver Schulz wrote: > > Wenn man konkatenieren will, ist es natürlich einfacher, Ziel und Wert > getrennt zu speichern. Ich halte das aber für keine gute Idee, u.a., > weil daduch Reihenfolge-Konflikte kaum auflösbar sind. Welche Reihenfolgekonflikte ueberhaupt? Ich hab jetzt schon einiges hinsichtlich Modifikator-Management implementiert und bis jetzt gabs da noch keine Reihenfolgekonflikte. > Es ist auf jeden Fall stabiler und sauberer, die Modi-Scripts > einmal einzeln zu parsen und dann später beliebig oft auszuwerten. Wie gesagt, dass kann man machen, man braucht dann aber wieder fuer jeden Modifikator einen Wrapper im Charakter. Und das sind wirklich sehr viele (Modifikatoren-Anzahl x Geladene-Charakter-Anzahl) Bei meiner Implementierung bisher wars so, dass die Modifikations-Strings direkt von der Regelrepraesentation gezogen wurden. > Es kostet bei einem anständigen Parser auch nicht viel Performance. > Im Gegenteil: Wenn man konkateniert, muß das nach jeder Änderung neu > geschehen, und jedesmal der gesamte entstehende Ausdruck neu geparst > werden. Ja, bei jeder Aenderung. > Und bei jeder Auswertung müßte auch immer der Parser angestoßen > werden. Das erscheint mir umständlich. Nein! Beim Auswerten wird direkt auf dem Syntaxbaum gearbeitet. >>Glaube ich schon. >>Wie sollte ein Parser/Syntaxbaum dafuer aussehen? Wie sollen seine >>Rueckgabewerte gemamaged werden? > > > Ich stelle mir dazu folgendes Modell vor: > > Es gibt ein Scripting-Environment, das v.a. get und set-Routinen > für path's bereitstellt (z.B. set(MU.effektiv, 13), get(IN), ...). > Dies ist die Schnittstellen zu den Charakterwerten, etc. Kann man > direkt auf XML oder auf Wrapper-Ebene machen, beides kein Problem. Waere moeglich (s.u.). > > Dann Klassen für Nichtterminale: Evaluation, Expression, Function, ... > aus denen der Parser den Syntaxbaum aufbaut (man braucht natürlich nicht > für jedes Nichtterminal eine eigene Klasse). Diese Klassen haben dann > entsprechend Auswerte-Methoden, usw. > Auch nicht schwierig, und hält den Parser schlank und sauber getrennt von > der Auswertung. Geparst werden muß jedes Script nur einmal (und bei Änderung). Richtig, und genau so wie beschrieben ist das auch im Moment ;-) Zumindest in meinem Java-Code, der mit Ingberts Parser arbeitet. > Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand > die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen > Methoden, die ihre Abhängikeiten angeben, also Listen der benutzten > Pfade (uses) und Liste der veränderten Pfade (modifies). Kann einfach > rekursiv definiert werden. Nun kann man eine strikte Halbordnung für Scripte > definieren: > "ScriptA < ScriptB wenn (ScriptA.modifies) und (ScriptB.uses) gemeinsame > Pfade enthalten." > Nach dieser Ordnung kann das Environment die Modifikatorscripte vor der > Ausführung aufsteigend sortieren, und fertig. Hierzu sehe ich ehrlich gesagt die Notwendigkeit nicht. Wenn man wie ich es geschrieben habe keine "Zuweisungen" in diesen Ausdruecken zulaesst gibts auch keine Reihenfogekonflikte. Ausserdem widerspricht die Vorgehensweise mit den Zuweisungen dem "Relationen als Nachrichten"-Konzept und macht das Ausfindigmachen sowie die Kontrolle ueber die Modifikatoren durch deren Ziel selbst unnoetig kompliziert. > Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten, > handelt es sich um einen Wiederspruch im Regelwerk selbst. Solche Wiedersprüche > (falls vorhanden) findet man dann gleich heraus, und kann klären, > wie sie zu handhaben sind. Die stellen in der Aktuellen java-Version sicher ein Problem dar, das allerdings nur dann auftritt, wenn jemand in den Regeldefinitionen rumpfuscht. Gruss, tilmann |
|
From: Oliver S. <os...@ep...> - 2002-05-05 16:45:26
|
Hallo Leute! Tilmann schrieb: > wir brauchen aber bereits das Ziel. Geparst wird dann, wenn das Zielfeature > seine Realtionen auswertet. Dabei werden aber _alle_ Wertmodifikatoren > konkateniert und auf einen Schlag geparst, so dass wir lang nicht fuer jeden > Modifikator den Parser extra anstossen muessen. Wenn man konkatenieren will, ist es natürlich einfacher, Ziel und Wert getrennt zu speichern. Ich halte das aber für keine gute Idee, u.a., weil daduch Reihenfolge-Konflikte kaum auflösbar sind. Es ist auf jeden Fall stabiler und sauberer, die Modi-Scripts einmal einzeln zu parsen und dann später beliebig oft auszuwerten. Es kostet bei einem anständigen Parser auch nicht viel Performance. Im Gegenteil: Wenn man konkateniert, muß das nach jeder Änderung neu geschehen, und jedesmal der gesamte entstehende Ausdruck neu geparst werden. Und bei jeder Auswertung müßte auch immer der Parser angestoßen werden. Das erscheint mir umständlich. > > Eine Gesamtangabe fände ich sowohl eleganter und "natürlicher", wie auch > > flexibler. Der Implementierungsaufwand ist dabei nicht höher. > > Glaube ich schon. > Wie sollte ein Parser/Syntaxbaum dafuer aussehen? Wie sollen seine > Rueckgabewerte gemamaged werden? Ich stelle mir dazu folgendes Modell vor: Es gibt ein Scripting-Environment, das v.a. get und set-Routinen für path's bereitstellt (z.B. set(MU.effektiv, 13), get(IN), ...). Dies ist die Schnittstellen zu den Charakterwerten, etc. Kann man direkt auf XML oder auf Wrapper-Ebene machen, beides kein Problem. Dann Klassen für Nichtterminale: Evaluation, Expression, Function, ... aus denen der Parser den Syntaxbaum aufbaut (man braucht natürlich nicht für jedes Nichtterminal eine eigene Klasse). Diese Klassen haben dann entsprechend Auswerte-Methoden, usw. Auch nicht schwierig, und hält den Parser schlank und sauber getrennt von der Auswertung. Geparst werden muß jedes Script nur einmal (und bei Änderung). Will man auswerten, gibt man dem Environment eine Liste von Syntaxbäumen zum Ausführen. Fertig. Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen Methoden, die ihre Abhängikeiten angeben, also Listen der benutzten Pfade (uses) und Liste der veränderten Pfade (modifies). Kann einfach rekursiv definiert werden. Nun kann man eine strikte Halbordnung für Scripte definieren: "ScriptA < ScriptB wenn (ScriptA.modifies) und (ScriptB.uses) gemeinsame Pfade enthalten." Nach dieser Ordnung kann das Environment die Modifikatorscripte vor der Ausführung aufsteigend sortieren, und fertig. Bin im Moment dabei, das Ganze für C++ testweise zu implementieren, sieht so aus, als ob das gut geht. Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten, handelt es sich um einen Wiederspruch im Regelwerk selbst. Solche Wiedersprüche (falls vorhanden) findet man dann gleich heraus, und kann klären, wie sie zu handhaben sind. cu Oliver |
|
From: Tilmann K. <ds...@tk...> - 2002-05-05 15:46:40
|
Hi! Oliver Schulz wrote: >>>Wir werden >>>die Funktionen >>> >>>sqrt(x), >> > [...] > > Die brauchen wir ja nicht in der Grammatik zu verankern, ich > würde dies gern alles über dasNichtterminal "Function" erledigen, > und die einzelnen Funktionen dann in der Semantik differenzieren. > Das ist simpel, hält die Grammatik und den Parser schlank und > ist leicht erweiterbar. Juckt mich nicht, solange es nacher tut ;-) Gruss, tilmann |
|
From: Oliver S. <os...@ep...> - 2002-05-05 12:45:14
|
Hi Leute! > > Wir werden > > die Funktionen > > > > sqrt(x), [...] Die brauchen wir ja nicht in der Grammatik zu verankern, ich würde dies gern alles über dasNichtterminal "Function" erledigen, und die einzelnen Funktionen dann in der Semantik differenzieren. Das ist simpel, hält die Grammatik und den Parser schlank und ist leicht erweiterbar. > Und auch diverse booleschen: > > <= / < [...] > selbstverstaendlich mit klammerung. > Der dreistellige Operator a ? b : c ist evtl. auch nicht schlecht. Ist soweit in dem Entwurf im CVS ja alles drin. > Ausserdem sollte man die "Features" auch als boolsche terme verwenden > koennen. So sollte der Ausdruck "EIG_MU" genau dann true sein, wenn es das > Feature mit der Id EIG_MU in der Item-List gibt. Ja, das ist gut! cu Oli |
|
From: Tilmann K. <ds...@tk...> - 2002-05-05 12:14:12
|
Hallo! Oliver Schulz wrote: >> Dann wuerde er in etwa so aussehen: Ziel: "EIG_MR" Wirkung: "(EIG_ST < >> 4) ? -2 : +0" > > > Warum zwei getrennte Attribute/Angaben? > > Warum nicht einfach EIG_MR = EIG_MR + ... oder einen als Kürzel dafür > einen Modifikationsoperator wie EIG_MR += ... oder auch modify(EIG_MR, > ...) ? Parsen muß man die Ausdrücke eh, es bringt IMHO keinen Vorteil, > Ziel und Wert des Modis in getrennten Angaben zu speichern. Doch! Wir wollen einen Parser fuer Arithmetische/Boolesche Ausdruecke schreiben und keine zuweisungsorientierte Programmiersprache. EIG_MR = EIG_MR + ... soetwas ist weder ein arithmetischer noch ein boolscher Ausdruck, wenn man = als := und nicht als == interpretiert. Ich wuerde es ausserdem nicht gerne zusammenfassen, warum moechte ich kurz verdeutlichen: >> Ziel: "EIG_MR" >> Wirkung: "(EIG_ST < 4) ? -2 : +0" Das wird vom XMLReader interpretiert und in ein Objekt (WertModifikator) mit entsprechendem Ziel und Wirkung um gesetzt, der in einem RegelCharakterFeature liegt. Geparst kann hier eh noch nichts werden, da wir uns noch nicht in einem Helden befinden, sondern nur eine Regeldefinition vorliegt. Dieses Feature wird dann von einem einem PersonenCharakterFeature gewrappt. Dieses wiederum wird dann irgendwann sinen WertModifikator bei dessen Ziel PersonenCharakterFeature registrieren. Auch hier wird noch nichts geparst, wir brauchen aber bereits das Ziel. Geparst wird dann, wenn das Zielfeature seine Realtionen auswertet. Dabei werden aber _alle_ Wertmodifikatoren konkateniert und auf einen Schlag geparst, so dass wir lang nicht fuer jeden Modifikator den Parser extra anstossen muessen. Was man hier nacher noch machen kann, was ich mir gerade im Zusammenhang mit Vorteilen durch den Kopf gehen lasse ist, das man im Wertmodifikator selbst parst und dann einfach den Wert zurueckliefert. Das hat aber den Nachteil, dass wir dan fuer die Relationen auch noch Personen-Wrapper benoetigen. > Eine Gesamtangabe fände ich sowohl eleganter und "natürlicher", wie auch > flexibler. Der Implementierungsaufwand ist dabei nicht höher. Glaube ich schon. Wie sollte ein Parser/Syntaxbaum dafuer aussehen? Wie sollen seine Rueckgabewerte gemamaged werden? Gruss, tilmann |
|
From: Tilmann K. <ds...@tk...> - 2002-05-05 11:49:39
|
Hi!
Ungluecklicherweise brauchen wir doch für manches die Nicht-effektiv-Werte
:-( z.B. Fuer "herausragende Eigenschaft". Deshalb schlage ich mal vor, dass
man z.B. in dem Parser
- die Id fuer den Effektivwert
- unmodifiziert(Id) fuer den unmodifizierten Wert nehmen koennte.
(Dann kann man z.B. unmodifiziert bezueglich Parsen als einstellige Funktion
ansehen.)
Fuer das Interface ArithmeticItem ergeben sich dann in etwa folgende
Aenderungen:
public interface ArithmeticItem {
public static final int TYPE_TERM = 1;
public static final int TYPE_ATOMIC_VARIABLE = 2;
public static final int TYPE_REPOSITORY_ITEM = 3;
public double resolve() throws ArithmeticException, NullPointerException;
public double resolveUnmodified() throws ArithmeticException,
NullPointerException;
public boolean resolveBool() throws ArithmeticException,
NullPointerException;
}
Gruss, tilmann
|
|
From: Oliver S. <os...@ep...> - 2002-05-05 11:48:54
|
Hi Leute! > Dann wuerde er in etwa so aussehen: > Ziel: "EIG_MR" > Wirkung: "(EIG_ST < 4) ? -2 : +0" Warum zwei getrennte Attribute/Angaben? Warum nicht einfach EIG_MR = EIG_MR + ... oder einen als Kürzel dafür einen Modifikationsoperator wie EIG_MR += ... oder auch modify(EIG_MR, ...) ? Parsen muß man die Ausdrücke eh, es bringt IMHO keinen Vorteil, Ziel und Wert des Modis in getrennten Angaben zu speichern. Eine Gesamtangabe fände ich sowohl eleganter und "natürlicher", wie auch flexibler. Der Implementierungsaufwand ist dabei nicht höher. Was meint ihr? cu Oli |
|
From: Tilmann K. <ds...@tk...> - 2002-05-05 11:06:22
|
Tilmann Kuhn wrote: > Wir werden > die Funktionen > > sqrt(x), > round(x), > roundup(x)/ceil(x), > rounddown(x)/floor(x), > min(x1,x2,...), > max(x1,x2,...) > brauchen. Und auch diverse booleschen: <= / < >= / > == != && || ! selbstverstaendlich mit klammerung. Der dreistellige Operator a ? b : c ist evtl. auch nicht schlecht. Ausserdem sollte man die "Features" auch als boolsche terme verwenden koennen. So sollte der Ausdruck "EIG_MU" genau dann true sein, wenn es das Feature mit der Id EIG_MU in der Item-List gibt. Gruss, tilmann |
|
From: Tilmann K. <ds...@tk...> - 2002-05-03 10:06:31
|
Hi! Matthias Wurm wrote: > Ich hab im net/sf/dsaman/... Verzeichnis gearbeitet, Ouch, Du hast ausserdem noch die Forte-speziefischen .nbattrs-Dateien mit hochgeladen, in denen die Forte die dependencies speichert. Vielleich sollten wir doch auf ant-script compilation wechseln. Gruss, tilmann |
|
From: Tilmann K. <ds...@tk...> - 2002-05-03 09:39:36
|
Matthias Wurm wrote: > Ich habe per cvs remove alles wieder gelöscht, die schlechte Nachricht > ist allerdings, das man Verzeichnisse selber nicht löschen kann. D.h. > das GUI-Verzeichnis selber und alle seine Unterverzeichnisse bleiben als > leere Hülle bestehen. Dir ist klar, dass man nach dem remove noch ein commit ausfuehren muss, damit das Loeschen klappt? Gruss, tilmann |
|
From: Matthias W. <Mat...@gm...> - 2002-05-03 00:28:19
|
Ich hab Mist gebaut... Als ich mein bisheriges GUI-Zeugs hochgeladen hab, habe ich das import-Kommando irgendwie falsch verstanden.. und jetzt hab ich auf oberster Ebene einen Haufen Mist in ein "gui" Verzeichnis importiert. Ich habe per cvs remove alles wieder gelöscht, die schlechte Nachricht ist allerdings, das man Verzeichnisse selber nicht löschen kann. D.h. das GUI-Verzeichnis selber und alle seine Unterverzeichnisse bleiben als leere Hülle bestehen. In der Doku stand, dass man mit der -P Option bei checkout / update / export Befehelen CVS sagen kann, dass er leere Verzeichnisse nicht beachten soll. Naja, blöd bleibt es trotzdem. Zu der GUI-Sache: Ich hab im net/sf/dsaman/... Verzeichnis gearbeitet, und einen MainFrame in net/sf/dsaman/gui/main/ gesetzt. Wer das /net/... Zeug im Classpath hat, kann sich das mal anschauen. Es ist nicht viel, ich hab auch erstmal nur einen SAX-Parser verwendet, um den Baum samt Icons einzulesen. Für den Meister/Spieler Modus kann man links im Baum diverse Nodes ausblenden lassen (hab ich mal auf Datei-Neu-Charakter gelegt). Sorry wegen dem Mist mit der GUI Gruß Matthias |
|
From: Tilmann K. <ds...@tk...> - 2002-04-30 21:17:59
|
Hoi nochmal! Matthias Wurm wrote: > Was die LE betrifft, würde ich sagen, dass wir uns wie vorgeschlagen auf > die Methode mit der Steigerbaren Eigenschaft in Verbindung mit > (KO+KO+KK)/2 als Modifikator einigen. In diesem Fall wuerde es dann PersonenEigenschaft und PersonenSteigerbareEigenschaft (oder so) geben und die Eigenschaften, denen eine Berechnung zu grunde liegt haben dann einen Modifikator auf sich selbst (ist zwar lustig, aber moeglich :-). So sieht das modell-technisch aus; im XML kanns ja so bleiben wie bisher. > Theoretisch könnten wir dann auch soweit gehen, dass wir rein > abgeleitete Eigenschaften auch als einfache Eigenschaften betrachten - > wenn der Wert nicht einen normalen Wert sondern eine Formel enthält, > dann liefert die resolve() Methode trotzdem das, was wir wollen. Im Prinzip ist das im Moment so, wobei man dazu sagen muss, dass es die steigerbaren Eigenschaften im Moment auch noch nicht gibt (kommen erst noch). > Dann hätten wir die Eigenschaften auf einfache und steigerbare reduziert > - im ersten Fall kommen Formeln direkt rein, im 2. als Modifikator. > Was haltet ihr davon ? (insbesondere Till, es war ja schließlich sein > Vorschlag...) Ich wuerde gerne in beiden Faellen (steigerbar und nicht) gleich verfahren, was die abgeleiteten betrifft. Gehen tut beides, wobei man sich im oberen Fall das extra-Feld fuer die Formel spart, im anderen hat man dann halt mal nen String mal nen null-pointer. Gruss, tilmann |
|
From: Matthias W. <Mat...@gm...> - 2002-04-30 20:49:06
|
Das sieht ja schon alles sehr gut aus, und meine Überlegungen sind daher für die Katz gewesen, wenn das alles schon so weit fortgeschritten ist. Was die LE betrifft, würde ich sagen, dass wir uns wie vorgeschlagen auf die Methode mit der Steigerbaren Eigenschaft in Verbindung mit (KO+KO+KK)/2 als Modifikator einigen. Theoretisch könnten wir dann auch soweit gehen, dass wir rein abgeleitete Eigenschaften auch als einfache Eigenschaften betrachten - wenn der Wert nicht einen normalen Wert sondern eine Formel enthält, dann liefert die resolve() Methode trotzdem das, was wir wollen. Dann hätten wir die Eigenschaften auf einfache und steigerbare reduziert - im ersten Fall kommen Formeln direkt rein, im 2. als Modifikator. Was haltet ihr davon ? (insbesondere Till, es war ja schließlich sein Vorschlag...) Gruß Matthias |
|
From: Tilmann K. <ds...@tk...> - 2002-04-30 17:34:08
|
Hi Leute! Ich muss jetzt auch mal meinen Senf dazu geben und versuche mal (fuer alle die sich noch nicht in die (Vorschlags-)Implementierung unter net.sf.dsaman eingearbeitet haben einen Enblick zu geben wie ich die Sache angepackt habe. Wenn ich demnaechst mal Zeit finde werde ich auch die dsaman.argo ueberarbeiten. Jeder Held besitzt sogenannte PersonCharakterFeatures. Dieses sind Talente Zuaberfertigkeiten, Rassen etc die jeweils von P.C.F. abgeleitet sind. Alle diese Features implementieren drei Interfaces: 1. dsamath.ArithmeticItem: Dieses besagt nichts anderes, als das das Feature eine resolve()-Methode hat mit der man den aktuellen Effektivwert bekommt. Wie dieser berechnet wird kommt spaeter [2]. 2. model.relation.RelationAkzeptor: Das bedeutet, dass das Feature das Ziel einer Relation sein kann. Auch die Modifikatoren um die es hier geht sind Relationen, wie auch z.B. AT- und PA-Modifikatoren oder die "Auszeichnung" einer Sprache/Schrift als Muttersprache. Mehr zu Relationen in [1]. 3. model.relation.RelationQuelle: Bedeutet, dass von diesem Feature Relationen auf andere Features ausgehen koennen, wie zum Beispiel eine Profession sich (per Modifikator) auf die Talentwerte auswirkt. [1] Relationen sind sozusagen Mitteilungen. Diese haben einen Ursprung (RelationQuelle), der dem Ziel der Relation (RelationAkzeptor) diese Mitteilung ueberbringt. Dann entfaltet die Relation bei ihrem Ziel eine Wirkung oder auch nicht (Wenn mann einen +5 Modifikator auf eine Profession hat, wird die dort einfach verpuffen). Beispiel: Eine Rasse besitzt einen Modifikator mit Ziel:Schwimmen und Wirkung:+1. Dieser Modifikator wird dann, nachdem er von der Rasse an das Talent Schwimmen uebergeben wurde dort die Wirkung entfalten und den Effektivwert um 1 erhoehen. [2] Die Berechnung des Effektivwertes haengt natuerlich von der Art des Features ab, so gibt es z.B. einige Features die als Effektivwert permanent 0 liefern (Rasse, Kultur...). Ich schreibe mal wie es bisher implementiert ist bzw wie ich mir das vorgestellt habe: Talente(/Zauber): Genommen wird der Grundwert, der am Anfang (des Helden) 0 ist und der von Spieler gesteigert werden kann. Damit werden dann einfach die Modifikatoren verrechnet. Technische Realisierung der Berechnung [3]. Eigenschaft: Hier muss man etwas unterscheiden, da es im Modell vier Typen von Eigenschaften geben wird: Einfache Eigenschaften (Generierungspunkte), Steigerbare Eigenschaften (MU, KL...), Abgeleitete Eigenschaften (ATBasis..), und Abgeleitete Steigerbare Eigenschaften (LE...). (Eventuell koennen wir die Abgeleiteten dadurch einsparen, dass wir gerade eine einfache/steigerbare nehmen und einfach einen Modifikator, der die Formel enthaelt darauf anwenden.) Wertberechnung geht im Prinzip so: Formel auswerten falls vorhanden, dazu die gesteigerten Punkte falls vorhanden, dazu die Modifikatoren falls vorhanden. [3] [3] Technische Realisierung der Berechnungen: Die Idee die dahinter steckt ist die, dass man im Prinzip nur einmal parsen muss und so oft wie man will berechnen kann. Das lauft an einem Beispiel so: Ich habe jetzt die Abgeleitete Eigenschaft LE. Diese hat die Formel (KO+KO+KK)/2 und habe einen Modifikator +MU. Schon bevor die erste Berechnung gemacht werden soll (, weil z.B. jemand resolve() dieser Eigenschaft aufgerufen hat), zum Zeitpunkt nachdem alle Relationen an alle Ziele verteilt wurden (konkret in relationenAuswerten()), werden die Strings konkateniert zu (KO+KO+KK)/2+MU und an den Parser geschickt. Dieser bekommt zusaetzlich noch eine Map (Fuer die C Leute: eine Liste) in der alle ArithmeticItems, also alle Features dieses Charakters, sind. Was der Parser jetzt tut ist wieder ein ArithmeticItem (in Form eines dsamath.Term) zurueck geben, das in der Eigenschaft gespeichert wird. Dieser "Term" ist ein Syntaxbaum des Ausdrucks, der die Referenzen auf tatsaechlichen Features des Helden enthaelt. Will ich jetzt alse den Effektivwert der Eigenschaft berechnen rufe ich von diesem Term resolve() auf, dieser Term ruft dan von einem weiteren Term (, der dem Ausdruck "(KO+KO+KK)/2" entspricht,) resolve() auf, und ruft von dem ArithmeticItem MU resolve() auf, addiert die beiden Werte und gibt das Ergebnis zurueck. Das tolle an der Sache ist: Ich muss nicht aufpassen, in welcher Reihenfolge ich was berechne, denn das resolve() wandert sozusagen von oben nach unten durch. In dem Moment indem naemlich resolve von MU aufgerufen wird, wird dort der gleiche Prozess gestartet und ich bekomme immer das richtige Ergebnis auch, wenn sich der MU -Wert seit dem Parsen geaendert haben sollte. Matthias Wurm wrote: > Dann hätte ich da noch einige Fragen, aber die lasse ich vorerst mal, > weil ich mich selber erst wieder in das Modell einarbeiten muss. Nur > noch eines, und zwar die Arithmetic-Item-Geschichte / > Ausdruck-Geschichte: Vielleicht am Beispiel der AT: > > <Talentgruppe id="BspHeld_TagBewaffnet"> > <Name>Bewaffnet</Name> > <Talent ref="TalSpeere"> > <Wert effektiv="7">7</Wert> > <AT> > <Wert effektiv="10">4</Wert> > </AT> > </Talent> > ... > > Die 7 steht ja für den TaW, die effektiv-7 kommt dadurch, dass kein Modi > die 7 verändert. > Unter AT haben wir die 4, dazu kommen die 6 Basis-AT, die weiter oben > stehen, macht 10. Tatsaechlich ist es beim oben beschriebenen Vorgehen nicht erforderlich einen Effektivwert zu speichern, da er immer neu berechnet wird. > <Eigenschaften ref="EigAbgeleitet"> > <Eigenschaft ref="EigBasisAT"> > <Wert effektiv="6">0</Wert> > </Eigenschaft> > > Hier haben wir schon ein klassisches Beispiel der Verkettung. Die > EigBasisAT muss berechnet werden, danach kommt die EigBasisAT auf die AT > des Talents drauf. > Ich denke, dass es darauf hinauslaufen muss, dass wir eine > Vorberechnungs und eine Endberechnunsphase haben. Das spaltet sich nach obigen Ueberlegungen auf in eine Parse- und eine Berechnungsphase, wobei das Parsen nur dann notwendig wird, wenn sich die Modifikatoren aendern! > Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten > nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja > bescheid. Eventuell koennte man auch noch andere "Abkoemmlinge" von Relation in betracht ziehen sollten wir es brauchen. Im Moment siehts allerdings nicht so aus. > Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie, > sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE, > Wert (KO+KO+KK)/2). Kein Problem mit dem beschriebenen Vorgehen. > Damit fällt das Beispiel von Oliver (ich meine MR.effektiv = > (rasse=='RasThorwaler') && (ST<4) ? MR-2 : MR;) schonmal weg. Das > Problem ist hierbei einfach, dass es eine Reihenfolge impliziert, die > wir woanders noch festhalten müssen. Das faellt aber aus anderen Gruenden weg: 1. Modifikatoren gehen immer auf die Effektivwerte. 2. Im normalfall geht der Modifikator von der Rasse (hier der Rasse "Thorwaler) in Richtung MR, Daher faellt "(rasse=='RasThorwaler') &&" weg Dann wuerde er in etwa so aussehen: Ziel: "EIG_MR" Wirkung: "(EIG_ST < 4) ? -2 : +0" > Denn welche MR soll genommen werden > ? Natuerlich die effektive oder brauchen wir auch anderes? Gruss, tilmann |
|
From: Matthias W. <Mat...@gm...> - 2002-04-30 13:10:36
|
Könnten wir uns darauf einigen, Interfaces mit einem "I" vornedran zu bezeichnen ? Das würde das Lesen etwas erleichtern. Ich würde das auch ändern, wenn ich wieder was committen kann. Gruß Matthias |
|
From: Matthias W. <Mat...@gm...> - 2002-04-30 12:55:33
|
Oliver Schulz wrote: >>Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten >>nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja >>bescheid. Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie, >>sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE, >>Wert (KO+KO+KK)/2). Wichtig ist dabei das wir hier stets >> >> > >Aber das würde doch gut zu meinem Beispiel passen!? >Nach dem Motto LE = LE + (KO+KO+KK)/2 ? >Oder lieber LE = LE.basis + ... + ... + ... + (KO+KO+KK)/2 ? > Ja, ich wollte noch eine Mail hinterherschicken, dass es an sich schon ok ist. Aber eben nicht als LE = LE + ... sondern als (ich kenn jetzt nicht die genaue Syntax, darum umschreibe ich es): Modifikator auf : LE, Wert: (KO+KO+KK)/2 Entstellt zwar etwas den Sinn der LE, aber in der Tat ist es ja so, dass nur die Basis-LE gesteigert werden kann, also der Wert, mit dem jeder Held bei 0 anfängt, und bei dem jede zusätzliche LE anhand der SKT bezahlt wird. >>_totale_ Funktionen verwenden, sonst gibts Ärger. >> >> > >Was meinst Du mit totalen Funktionen? Im mathematisch-analytischen >Sinne total? > > Ja, also wie in deinem Beispiel wenn das und das, dann dieser Wert, SONST ein anderer Wert. Damit auf alle Fälle ein Wert da ist, der zu interpretieren ist. Zum Rest schau ich mir wie gesagt den aktuellen Stand nochmal an, nicht dass ich Arbeit doppelt mache. Gruß Matthias |
|
From: Matthias W. <Mat...@gm...> - 2002-04-30 12:43:50
|
Wollte grad eine Übersetzung der Javadoc von Tills Sachen hochladen, dann kam: cvs [server aborted]: "commit" requires write access to the repository hattet ihr das auch mal ? |
|
From: Oliver S. <wh...@us...> - 2002-04-30 12:26:47
|
Hallo Leute! Matthias schrieb: > Im Entwurf beim Thorwalerbeispiel werden wieder ein paar Probleme deutlich: > Ich würde z.B. (auch wenn dies im neuen Regelwerk nicht mehr zutrifft, > aber angenommen es wäre noch so), diesen Sachverhalt als eine Art > bedingten Modifikator in die Rassendeklaration des Thorwalers schreiben. Die Beispiele sollten reine Sprachbeispiele sein, noch keine konkreten Lösungsvorschläge - natürlich würde man so einen Modi nicht einfach allen Rassen anhängen, und dann abfragen, ob's ein Thorwaler ist - ich wollte nur einen schön komplexen Ausdruck vorführen, wie man ihn in anderen Fällen haben könnte ... :-) > Und es war doch auch so, dass der Effektiv-Wert die "letzte Instanz" > war, also das der quasi aus allen Basis-Wert und den Modis berechnet > wurde, oder ? Dann würde ich auf keinen Fall den Effektiv-Wert nochmal > ändern. Ja. Aber irgendwo muß der Effektivwert ja mal berechnet werden. Ein Modifikator wie der in dem Beispiel würde ich als Teil der Berechnung, nicht als nachträgliche Änderung des Effektivwertes begreifen. Nicht-permanente Modifikatoren, wie der in dem Beispiel, kommen zwangsläufig genau bei der Berechnung des Effektivwertes zum Zuge. Aber man könnte natürlich die Summe aller nicht-permanenten Modis in einem eigenen Wert speichern, der dann nur noch zum Effektivwert addiert werden muß. Ist auch nicht ohne Vorteile. > Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten > nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja > bescheid. Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie, > sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE, > Wert (KO+KO+KK)/2). Wichtig ist dabei das wir hier stets Aber das würde doch gut zu meinem Beispiel passen!? Nach dem Motto LE = LE + (KO+KO+KK)/2 ? Oder lieber LE = LE.basis + ... + ... + ... + (KO+KO+KK)/2 ? > _totale_ Funktionen verwenden, sonst gibts Ärger. Was meinst Du mit totalen Funktionen? Im mathematisch-analytischen Sinne total? > Damit fällt das Beispiel von Oliver (ich meine MR.effektiv = > (rasse=='RasThorwaler') && (ST<4) ? MR-2 : MR;) schonmal weg. Das > Problem ist hierbei einfach, dass es eine Reihenfolge impliziert, die > wir woanders noch festhalten müssen. Das Problem der Reihenfolge wird meines Erachtens durch die DSA-Regeln bestimmt, nicht durch die Art, wie wir Modifikatoren darstellen. Wenn laut Regeln X.basis einen Modi auf Y.effektiv und Y.effektiv einen auf Z.effektiv gibt, muß wissen, daß man Y vor Z berechnet. Da Modifikatoren aus unterschiedlichen Regelmodulen zusammenkommen werden, hilft hier die Darstellung der einzelnen Modis nicht weiter. Ich sehe zwei Lösungsmöglichkeiten: 1. Ein Prioritätattribut für Modis: Einfach realisierbar, aber macht Aufbau und Pflege eines modularisierten Regelbestandes evtl. sehr kompliziert und fehleranfällig. 2. Run-Time Dependency Analyse der Modi-Formeln. Aufwendiger zu Implementieren, meines Erachtens aber durchaus machbar. Dafür nicht fehleranfällig, keine Probleme beim Regelbestand. > Denn welche MR soll genommen werden ? > Die modifizierte ? Ja, denn das Ziel ist ja der effektiv-Wert. Da gibt Wie schon gesagt - bitte nicht zu sehr an diesem Beispiel festklammern. Man könnte aber z.B. MR als Kurzschreibweise für MR.effektiv begreifen, das entspräche dem üblichen Gebrauch von MR, KK, ... in den DSA-Regeln. Kann aber auch gern MR Kurzschreibweise für MR.basis sein, wenn XY.basis häufiger als XY.effiktiv oder XY.sonstwas gebraucht wird. cu Oli |
|
From: Matthias W. <Mat...@gm...> - 2002-04-30 07:09:35
|
Oliver Schulz wrote:
>Hallo Leute!
>
>
>
>>Das mit der BNF ist ne gute Frage... Ich weiß selber nicht, auf was ihr
>>euch geeinigt hab. Ist im CVS-Baum irgendeine Spezifikation hochgeladen,
>>oder eine Beispiel-XML, anhand derer ich sehe, wie ihr euch das
>>vorgestellt habt ?
>>
>>
>
>Da im CVS nix gefunden habe, hab mal einen Entwurf gemacht
>(siehe data/dsascript-grammar.txt).
>Das Ganze ist an der bisherigen Diskussion hier in der Mailingliste
>orientert, und sollte in etwa abwärts-kompatibel zu Ingberts Parser sein.
>Die definierte Sprache geht allerdings deutlich darüber hinaus,
>und bietet z.B. bedingte Ausdrücke, strings und Variablen der Form
>"MR.effektiv.xyz". Dennoch sollte sich die Sprache mit einem
>Parser-Generator problemlos handeln lassen.
>Die Grammatik ist mit flex/bison getestet, LALR(1) und konfliktfrei.
>Da alles sehr an C++, Java & Co. angelehnt ist, sollte sie auch recht
>intuitiv zu benutzbar sein.
>Ich hoffe, mit einem Ansatz in der Richtung kriegen wir dieses verflixte
>Regelwerk in den Griff. ;-)
>
>
Im Entwurf beim Thorwalerbeispiel werden wieder ein paar Probleme deutlich:
Ich würde z.B. (auch wenn dies im neuen Regelwerk nicht mehr zutrifft,
aber angenommen es wäre noch so), diesen Sachverhalt als eine Art
bedingten Modifikator in die Rassendeklaration des Thorwalers schreiben.
Und es war doch auch so, dass der Effektiv-Wert die "letzte Instanz"
war, also das der quasi aus allen Basis-Wert und den Modis berechnet
wurde, oder ? Dann würde ich auf keinen Fall den Effektiv-Wert nochmal
ändern.
Dann hätte ich da noch einige Fragen, aber die lasse ich vorerst mal,
weil ich mich selber erst wieder in das Modell einarbeiten muss. Nur
noch eines, und zwar die Arithmetic-Item-Geschichte /
Ausdruck-Geschichte: Vielleicht am Beispiel der AT:
<Talentgruppe id="BspHeld_TagBewaffnet">
<Name>Bewaffnet</Name>
<Talent ref="TalSpeere">
<Wert effektiv="7">7</Wert>
<AT>
<Wert effektiv="10">4</Wert>
</AT>
</Talent>
...
Die 7 steht ja für den TaW, die effektiv-7 kommt dadurch, dass kein Modi
die 7 verändert.
Unter AT haben wir die 4, dazu kommen die 6 Basis-AT, die weiter oben
stehen, macht 10.
<Eigenschaften ref="EigAbgeleitet">
<Eigenschaft ref="EigBasisAT">
<Wert effektiv="6">0</Wert>
</Eigenschaft>
Hier haben wir schon ein klassisches Beispiel der Verkettung. Die
EigBasisAT muss berechnet werden, danach kommt die EigBasisAT auf die AT
des Talents drauf.
Ich denke, dass es darauf hinauslaufen muss, dass wir eine
Vorberechnungs und eine Endberechnunsphase haben. Ich werde nachdem ich
wieder von der Uni heimkomme mal ein Bildchen machen, um das zu
verdeutlichen, wie ich mir es vorstelle.
Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten
nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja
bescheid. Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie,
sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE,
Wert (KO+KO+KK)/2). Wichtig ist dabei das wir hier stets _totale_
Funktionen verwenden, sonst gibts Ärger.
Damit fällt das Beispiel von Oliver (ich meine MR.effektiv =
(rasse=='RasThorwaler') && (ST<4) ? MR-2 : MR;) schonmal weg. Das
Problem ist hierbei einfach, dass es eine Reihenfolge impliziert, die
wir woanders noch festhalten müssen. Denn welche MR soll genommen werden
? Die modifizierte ? Ja, denn das Ziel ist ja der effektiv-Wert. Da gibt
es sicherlich irgendwann einen Konflikt, wo wir eine vertauschte
Reihenfolge bräuchten. Naja, ich muss mich jetzt aufmachen, ich hoffe,
ich konnte klar machen, wo meine Bedenken sind.
Gruß
Matthias
|
|
From: Oliver S. <os...@ep...> - 2002-04-30 03:13:04
|
Hallo Leute! > Das mit der BNF ist ne gute Frage... Ich weiß selber nicht, auf was ihr > euch geeinigt hab. Ist im CVS-Baum irgendeine Spezifikation hochgeladen, > oder eine Beispiel-XML, anhand derer ich sehe, wie ihr euch das > vorgestellt habt ? Da im CVS nix gefunden habe, hab mal einen Entwurf gemacht (siehe data/dsascript-grammar.txt). Das Ganze ist an der bisherigen Diskussion hier in der Mailingliste orientert, und sollte in etwa abwärts-kompatibel zu Ingberts Parser sein. Die definierte Sprache geht allerdings deutlich darüber hinaus, und bietet z.B. bedingte Ausdrücke, strings und Variablen der Form "MR.effektiv.xyz". Dennoch sollte sich die Sprache mit einem Parser-Generator problemlos handeln lassen. Die Grammatik ist mit flex/bison getestet, LALR(1) und konfliktfrei. Da alles sehr an C++, Java & Co. angelehnt ist, sollte sie auch recht intuitiv zu benutzbar sein. Ich hoffe, mit einem Ansatz in der Richtung kriegen wir dieses verflixte Regelwerk in den Griff. ;-) cu Oliver |
|
From: Oliver S. <wh...@us...> - 2002-04-29 20:34:04
|
Hi Matthias! > zu verwenden. Ich hab mal was mit SableCC gemacht, das Till und ich aus [...] > erweiterbar (insbesondere SableCC, JavaCC ist da wie ich gehört hab Schau Dir auch mal CUP an (http://www.cs.princeton.edu/~appel/modern/java/CUP), hab ich noch nicht viel mit gemacht, aber was ich gesehen habe, sah ganz nett aus. cu Oli |
|
From: Matthias W. <Mat...@gm...> - 2002-04-29 18:40:34
|
Das mit der BNF ist ne gute Frage... Ich weiß selber nicht, auf was ihr euch geeinigt hab. Ist im CVS-Baum irgendeine Spezifikation hochgeladen, oder eine Beispiel-XML, anhand derer ich sehe, wie ihr euch das vorgestellt habt ? Gruß Matthias |
|
From: Oliver S. <os...@ep...> - 2002-04-29 11:15:11
|
Hallo Matthias, > ich habe eigentlich auch nichts gegen Parsergeneratoren, ich habe unter > UNIX zumindest mal was mit flex gemacht. Außerdem habe ich festgestellt, > daß ich keine allzugroße Lust verspüre, meinen Parser für die > C++-Version unseres Tools nach dort zu portieren. Und wenn ihr euch mit > der Theorie gut auskennt, können wir diese Wissensressource auch nutzen Das würde ich sehr begrüßen - kannst Du mal die Grammatik für die Scriptsprache aufschreiben, in BNF? cu Oli |
|
From: Ingbert <bus...@in...> - 2002-04-29 07:14:49
|
Hallo Matthias, Matthias Wurm wrote: > Wenn wir das Ding stark erweitern wollen, wollte ich ohnehin > vorschlagen, einen Parsergenerator zu verwenden. Ich hab mal was mit > SableCC gemacht, das Till und ich aus der Info-Vorlesung kennen, und > da wir beide die ganze Info III nix anderes gemacht haben, als Theorie > für Parser zu büffeln, wüsste ich nicht, warum wir das auch nicht mal > anwenden sollten... ich habe eigentlich auch nichts gegen Parsergeneratoren, ich habe unter UNIX zumindest mal was mit flex gemacht. Außerdem habe ich festgestellt, daß ich keine allzugroße Lust verspüre, meinen Parser für die C++-Version unseres Tools nach dort zu portieren. Und wenn ihr euch mit der Theorie gut auskennt, können wir diese Wissensressource auch nutzen [:-)] . Viele Grüße Ingbert |