dsaman-list Mailing List for DSA Manager (Page 2)
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: Tilmann K. <ds...@tk...> - 2002-05-16 08:16:41
|
Hi! Oliver Schulz wrote: > > Aber das läßt sich doch leicht als Script mit bedingten > Ausdrücken/Anweisungen formulieren!? > Oder meinetwegen auch mit mehreren getrennten Scripten, > wenn nicht zuviele Anweisungen in ein Script sollen. > Nenn bitte mal ein konkretes Beispiel, bei dem Du mit > meinem Scripting Darstellungsprobleme siehst - ich bin > nicht ganz sicher, ob ich deine Bedenken richtig > verstanden hab. Sieh dir mal o Profession 'Forscher' unter 'Wissen' und unter 'Sprachen' an o Vorteil 'Begabung fuer...' o Vorteil 'Herausragende Eigenschaft' letzter Absatz Um mal ein paar kuriositaeten zu nennen, es gibt bestimmt auchnoch ein paar mehr. Ich will jetzt nicht beahaupten dass ich diese bereits vollstaendig geloest habe, aber ich denke sie sind auf alle Faelle machbar. Gruss, tilmann |
From: Oliver S. <wh...@us...> - 2002-05-15 20:31:14
|
Hallo Tilmann! > Also ich lege gegen Olivers Variante ein Veto ein, solange mir nicht eine > vernuenftige Moeglichkeit praesentiert wird wie damit Gruppen und Listen von > Zielen _mit_ Ausnahmen gehandhabt werden koennen, da wir diese effektiv > brauchen. Aber das läßt sich doch leicht als Script mit bedingten Ausdrücken/Anweisungen formulieren!? Oder meinetwegen auch mit mehreren getrennten Scripten, wenn nicht zuviele Anweisungen in ein Script sollen. Nenn bitte mal ein konkretes Beispiel, bei dem Du mit meinem Scripting Darstellungsprobleme siehst - ich bin nicht ganz sicher, ob ich deine Bedenken richtig verstanden hab. > Aus der Sicht miener Implementierung ist beides ohne Probleme moeglich. Aus Sicht meines Modells doch auch. cu Oliver |
From: Matthias W. <Mat...@gm...> - 2002-05-15 16:29:55
|
Tilmann Kuhn wrote: > Matthias Wurm wrote: > >> >> Haben wir das eigentlich schon irgendwie berücksichtigt ? (im Modell >> oder in XML ?) > > > In den aktuellen Java-Klassen ist das so drin. Mit der Ausnahme, dass > bie den SteigerbarenEigenschaften allle Modifikatoren unberuecksichtigt > bleiben, das kann man aber ohne Probleme dahingehend aender dass, die > von Rasse etc getrennt betrachtet werden. > > Fue alle die mal ein UML-Diagramm von den Klassen wollen: > Poseidon installieren. Im Menue Datei-Importieren aufrufen, das > 'net'-Verzeichnis waehlen und Import starten. > > Gruss, tilmann > Wobei man sich eigentlich auf das net.sf.dsaman.model Verzeichnis beschränken, und auch da nur regelwerk und charakter "richtig" interessant sind. Die zig von SableCC generierten Klassen erschlagen da einen ja regelrecht... (sind in model/arithmetic) Gruß Matthias |
From: Tilmann K. <ds...@tk...> - 2002-05-15 16:27:06
|
Jipiiiii! Ich habs geschaft! Die JavaDoc von net.sf.dsaman.model (ohne arithmetic) ist jetzt komplett in Deutsch. Bis dann, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-15 15:59:39
|
Hi! Matthias Wurm wrote: > > Das mit der LE haben wir schon im Griff. Wir verwenden ja eigentlich die > _gekauften_ LE als Eigenschaft, und darauf kommt ein Modifikator, der > gerade der KO+KO+KK / 2 Term ist. > Solche Konstrukte sind also kein Problem (ich glaube, bei der MR ist es > z.B. genauso, bei den AsP sowieso) Jou: protected double resolveMe(String property) throws ArithmeticException, NullPointerException { if (property.equals(PROPERTY_effektiv)) { if (wertTerm == null) return wert + wertModSum.resolve(); else return wert + wertTerm.resolve() + wertModSum.resolve(); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } if (property.equals(PROPERTY_basis)) return getWert(); throw new NullPointerException("Property " + getId() + "." + property + " existiert nicht!"); } Und: public double getSteigerungsKosten() { return ((RegelSKT)charakter.getReferenzFeature(ModelOptionen.SKT_ID)).getKosten(new Double(wert+1).intValue(),getSktSpalte()); ^^^^^^^^^^^^^^^^^^^^ } Gruss, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-15 15:59:35
|
Hi! Alexander Nofftz wrote: > Die "Modifikatoren" auf die Startwerte der Talente sind aber genau keine > Modifikatoren; sie werden einfach bei der Generierung verrechnet und > danach nie wieder benutzt. Im Moment habe ich sie als normale Modifikatoren realisiert, theoretisch kann man sie aber auch ohne Probleme als StartwertModifikatoren realisieren, die nur am Anfang verrechnet werden und den Wert dirket veraendern. Rein in meiner Implementierung ist es dann so, dass man sie spaeter auch noch nachvollziehen kann, sie aber keine Wirkung mehr zeigen. Gruss, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-15 15:59:31
|
Matthias Wurm wrote: > > Haben wir das eigentlich schon irgendwie berücksichtigt ? (im Modell > oder in XML ?) In den aktuellen Java-Klassen ist das so drin. Mit der Ausnahme, dass bie den SteigerbarenEigenschaften allle Modifikatoren unberuecksichtigt bleiben, das kann man aber ohne Probleme dahingehend aender dass, die von Rasse etc getrennt betrachtet werden. Fue alle die mal ein UML-Diagramm von den Klassen wollen: Poseidon installieren. Im Menue Datei-Importieren aufrufen, das 'net'-Verzeichnis waehlen und Import starten. Gruss, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-15 15:07:15
|
Hi! Pir...@gm... wrote: > Zu 1. Soweit ich das in Erinnerung habe sind da die Kosten, > dann die fuer uns (zumindest derzeit) nicht interessanten temporaeren Modis > aufgrund von Spruechen. Da wir nicht wissen, ob es weitere in der Magier oder Goetter-Box > geben wird (z.B: permanente Stab-/Kugel-/...- Zauber) bion ich der Meinung wir > sollten die multiplikativen Modifikatoren genau da zulassen, wo modifikatoren zugelassen sind!! Ok bau ich ein. Gruss, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-15 13:48:39
|
Hallo! Matthias Wurm wrote: > > Mir ist es mittlerweile egal. Beide Varianten funktionieren, die eine > hat die Vorteile die andere eben andere. Also ich lege gegen Olivers Variante ein Veto ein, solange mir nicht eine vernuenftige Moeglichkeit praesentiert wird wie damit Gruppen und Listen von Zielen _mit_ Ausnahmen gehandhabt werden koennen, da wir diese effektiv brauchen. > Wir müssen aufpassen, wie das mit der SOF_Schildkampfi.kosten*=0.5 > Geschichte ist, was die Sonderfertigkeiten betraf, ob wir das jetzt > machen dürfen, oder die Kosten als bedingten Ausdruck schreiben sollen. > Lässt sich sicherlich beides umsetzen, nur weiß ich nicht, wie ihr das > im Moment seht. Aus der Sicht miener Implementierung ist beides ohne Probleme moeglich. > > Ich kann das jetzt nur mal aus der Modellsicht beschreiben: > > Wenn wir annehmen, dass wir 2 Klassen haben: RegelSonderfertigkeit und > PersonenSonderfertigkeit, die eine beschreibt die SoF als kaufbares > Regelelement, das andere ist die Sicht auf dasselbe, wie sie im > Charakter aussieht, dann ist es ja naheliegend, dass wir auch 2 Typen > von Modifikatoren haben können: > Solche die eine Person ändern, wenn sie der Person zugewiesen wurden. > Und solche die Regeln ändern, wenn sie verwendet werden. > Die Rasse Elf verdreht z.B. die Zauberkosten. Also ein RegelModifikator. > Die Rasse Elf erhöht die GE um 2. Ein PersonenModifikator. > > Ich denke, diese Sachen sollten wir in XML auch als solche einteilen. > Ich weiß, das ist jetzt der 100. anders-aussehende Vorschlag, aber ich > denke, so macht es am meisten Sinn, da ja schließlich auch unser Modell > so strukturiert ist. Regelelemente an sich, dann Regelelemente, wie sie > bei einem Charakter aussehen, etc. > Bei den Java-Leuten ist diese Trennung in net.sf.dsaman.model.charakter > / und ...model.regelwerk zu sehen. > > Und wenn wir das dann so machen, spricht nix mehr gegen einen > Regelmodifikator mit dem Ausdruck Sof_Bla*=0.5, der dann bei der > Profession Krieger auftauchen würde. Man kann sich jetzt wieder darum > streiten, ob der Modi überhaupt dahin gehört, klar. Aber wenn man davon > ausgeht, dass der GRUND, warum die Kosten niedriger sind, die Profession > ist, dann kann man die Profession als Quelle bezeichnen, und der Modi > sollte dann auch dort stehen. Im Prinzip richtig ich habe auch schon die Vorarbeit dafuer geleistet: Die Features die (noch) nicht im Charakter sind, aber gekauft werden koennen bekommen trotzdem schon einen Wrapper im Charakter. Dieser implementiert das Interface "KaeuflichesCharakterFeature" und tut sonst nichts, mal abgesehen davon Modifikatoren zu akzeptieren. Kauft man dann dieses Feature wird es zu einem vollwertigen PersonenCharakterFeature incl. ausgehender Relationen etc. Jetzt kann man sich z.B. auch in jeder Gruppe z.B. Sonderfertigkeiten/ Vorteile anzeigenlassen was man bereits besitzt und was mann sich theoretisch/praktisch kaufen kann und wieviel es kostet. Bis dann, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-15 13:42:55
|
Hi! Pir...@gm... wrote: > > Soweit ich die Mailings mitverfolgt habe, hat sich zu diesem Thema noch > keiner Gedanken gemacht. Doch! > Wir haben aber nicht nur hier (Eigenschaften) > das Problem, sondern auch bei LE, denn > > LE = Berechnet aus Eiogenschaften LE += LE Steigerungen (hier enstehen > die Kosten) > > Was ist mit LE = Berechnet zu 25, gesteigert auf 26 dann Eigenschaften > gesteigert => LE berechnet zu 26 und um einen Punkt gesteigert => LE = 27 > > > LE Steigerung, welche Kosten werden verursacht? Von 26 auf 27 oder von 27 > auf 28 Was wenn ich die Eigenschaften und die LE "gleichzeitig" erhoehen > will, welche Reighenfolge ist richtig?? Egal, denn: (seite 123) Die _zugekauften_ LE kosten, das heisst: Du bezahlst _nur_ was du kaufst, Beispiel: LE auf Eigenschaften: 20 LE bereits gekaufte punkte: 5 willst du jetzt Einkaufen schaust du in der Tabelle unter 6 egal wieviele Punkte du von den Eigenschaften hast. Damit eruebrigt sich auch das Problem der Reihenfolge. Gruss, tilmann |
From: Matthias W. <Mat...@gm...> - 2002-05-15 09:07:37
|
Pir...@gm... wrote: > Hi, > > Matthias schrieb: > > >>Und nachdem dann alles vorgetragen wurde, sollten wir einfach >>demokratisch abstimmen. Sonst nimmt das kein Ende. > > > Gute Idee, sonst geht es nie weiter. > > Im Grunde ist es mir egal welche Variante wir nutzen, die muss schliesslich Oli implementieren, > ABER ich persoenlich wuerde die Variante on Oli waehlen, denn die laesst sich nach meiner > Meinung besser als in sich geschlossene Einheit implementieren und ist zudem besser Erweiterungsfaehig, > falls es sich irgendwann als noetig erweisen solte. > > Ich stimme also hiermit fuer Olis - Variante Mir ist es mittlerweile egal. Beide Varianten funktionieren, die eine hat die Vorteile die andere eben andere. In der Modellumsetzung würde das bei Olis Methode dann heißen, dass jeder Charakter einen "Modifikatorpool" hat, der bei Hinzufügen oder entfernen von Features neu sortiert werden muss. Das kann dann ein einziger großer Syntaxbaum sein. Da die Linkswerte der Zuweisungen identisch mit den 'auf'Tags sind, dürfte das ja keine größeren Unterschiede im Modell machen. Mir ist es im Grunde egal, wenn wir aber Ollis Variante aus Gründen der "geschlossenen Einheit" nehmen, sollten wir auch das hier klären, sonst haben wir auch da einen Mix: Wir müssen aufpassen, wie das mit der SOF_Schildkampfi.kosten*=0.5 Geschichte ist, was die Sonderfertigkeiten betraf, ob wir das jetzt machen dürfen, oder die Kosten als bedingten Ausdruck schreiben sollen. Lässt sich sicherlich beides umsetzen, nur weiß ich nicht, wie ihr das im Moment seht. Ich kann das jetzt nur mal aus der Modellsicht beschreiben: Wenn wir annehmen, dass wir 2 Klassen haben: RegelSonderfertigkeit und PersonenSonderfertigkeit, die eine beschreibt die SoF als kaufbares Regelelement, das andere ist die Sicht auf dasselbe, wie sie im Charakter aussieht, dann ist es ja naheliegend, dass wir auch 2 Typen von Modifikatoren haben können: Solche die eine Person ändern, wenn sie der Person zugewiesen wurden. Und solche die Regeln ändern, wenn sie verwendet werden. Die Rasse Elf verdreht z.B. die Zauberkosten. Also ein RegelModifikator. Die Rasse Elf erhöht die GE um 2. Ein PersonenModifikator. Ich denke, diese Sachen sollten wir in XML auch als solche einteilen. Ich weiß, das ist jetzt der 100. anders-aussehende Vorschlag, aber ich denke, so macht es am meisten Sinn, da ja schließlich auch unser Modell so strukturiert ist. Regelelemente an sich, dann Regelelemente, wie sie bei einem Charakter aussehen, etc. Bei den Java-Leuten ist diese Trennung in net.sf.dsaman.model.charakter / und ...model.regelwerk zu sehen. Und wenn wir das dann so machen, spricht nix mehr gegen einen Regelmodifikator mit dem Ausdruck Sof_Bla*=0.5, der dann bei der Profession Krieger auftauchen würde. Man kann sich jetzt wieder darum streiten, ob der Modi überhaupt dahin gehört, klar. Aber wenn man davon ausgeht, dass der GRUND, warum die Kosten niedriger sind, die Profession ist, dann kann man die Profession als Quelle bezeichnen, und der Modi sollte dann auch dort stehen. Gruß Matthias PS: Falls nicht ganz klar wurde, was damit gemeint ist... Eine Schlechte Eigenschaft gibt ja im ReWe an wieviel GP pro Eigenschaftspunkt man dazubekommt. Das ist eine Information aus dem Regelwerk. Eine Schlechte Eigenschaft bei einem Charakter hat ja diese Info nicht mehr, sondern nur, wieviel Eigenschaftspunkt letzten Endes da sind. Daher die Trennung. Ein komplexeres Beispiel ist da dann schon die Profession mit ihren Talentauswahlmöglichkeiten, die dann solch eine Trennung richtig sinnvoll machen. |
From: Matthias W. <Mat...@gm...> - 2002-05-15 09:07:34
|
Pir...@gm... wrote: > > Soweit ich die Mailings mitverfolgt habe, hat sich zu diesem Thema noch keiner Gedanken gemacht. > Wir haben aber nicht nur hier (Eigenschaften) das Problem, sondern auch bei LE, > denn > > LE = Berechnet aus Eiogenschaften > LE += LE Steigerungen (hier enstehen die Kosten) > > Was ist mit > LE = Berechnet zu 25, gesteigert auf 26 > dann Eigenschaften gesteigert => LE berechnet zu 26 und um einen Punkt gesteigert => LE = 27 > > LE Steigerung, welche Kosten werden verursacht? Von 26 auf 27 oder von 27 auf 28 > Was wenn ich die Eigenschaften und die LE "gleichzeitig" erhoehen will, welche Reighenfolge ist richtig?? Das mit der LE haben wir schon im Griff. Wir verwenden ja eigentlich die _gekauften_ LE als Eigenschaft, und darauf kommt ein Modifikator, der gerade der KO+KO+KK / 2 Term ist. Solche Konstrukte sind also kein Problem (ich glaube, bei der MR ist es z.B. genauso, bei den AsP sowieso) Gruß Matthias |
From: <Pir...@gm...> - 2002-05-15 07:38:16
|
Hi, Matthias schrieb: >Und nachdem dann alles vorgetragen wurde, sollten wir einfach=20 >demokratisch abstimmen. Sonst nimmt das kein Ende. Gute Idee, sonst geht es nie weiter. Im Grunde ist es mir egal welche Variante wir nutzen, die muss schliesslich= Oli implementieren, ABER ich persoenlich wuerde die Variante on Oli waehlen, denn die laesst = sich nach meiner Meinung besser als in sich geschlossene Einheit implementieren und ist = zudem besser Erweiterungsfaehig, falls es sich irgendwann als noetig erweisen solte. Ich stimme also hiermit fuer Olis - Variante Holger |
From: <Pir...@gm...> - 2002-05-15 07:33:35
|
Hi, Tilmann Kuhn wrote: >Dann nenn ihn doch einfach <Multiplikator> ;-) das war doch nur so >hingeschrieben. Hat ja niemand behauptet, dass der Tatsaechlich so >heissen muss. Oder nenn ihn <Relation typ=3D"KostenModifikator" >ziel=3D"VNT_Vorteile" mult=3D"1.5"/> oder wie auch immer. Worueber wir >uns eigentlich einigen sollten ist=20 >1. Fuer was alles wir multiplikative Modifikatoren zulassen wollen >2. Wie sie zu handhaben sind (hintenanstellen nach den additiven) >Zu 2. sind wir uns ja mit dem Hintenanstellen denke ich einig. Zu 1. >wuerde mich mal eure Meinung interessieren. Brauchen wir >mutliplikative nur fuer Kosten oder auch fuer alles andere? Zu 2. stimme ich Dir zu Zu 1. Soweit ich das in Erinnerung habe sind da die Kosten, dann die fuer uns (zumindest derzeit) nicht interessanten = temporaeren Modis aufgrund von Spruechen. Da wir nicht wissen, ob es weitere in der = Magier oder Goetter-Box geben wird (z.B: permanente Stab-/Kugel-/...- Zauber) bion ich = der Meinung wir sollten die multiplikativen Modifikatoren genau da zulassen, wo = modifikatoren zugelassen sind!! Gruss Holger |
From: <Pir...@gm...> - 2002-05-15 07:27:57
|
Hi, >Heut ist mir noch was eingefallen, und zwar die Modifikatoren betreffend: >Wenn eine Rasse MU+2 gibt, dann zahle ich von 14 auf 15 soviel, wie = wenn=20 >ich von 12 auf 13 steigern w=FCrde. >D.h. die SKT wird nach unten versetzt. >Die +x Modifikatoren auf Talente, die von Rassen oder Kulturen kommen,=20 >sind ja aber nicht so zu verstehen. D.h. von 7 auf 8 zahle ich nicht = wie=20 >von 7-x auf 8-x, sondern die vollen Kosten. >Haben wir das eigentlich schon irgendwie ber=FCcksichtigt ? (im Modell=20 >oder in XML ?) Soweit ich die Mailings mitverfolgt habe, hat sich zu diesem Thema noch = keiner Gedanken gemacht. Wir haben aber nicht nur hier (Eigenschaften) das Problem, sondern auch = bei LE, denn LE =3D Berechnet aus Eiogenschaften LE +=3D LE Steigerungen (hier enstehen die Kosten) Was ist mit LE =3D Berechnet zu 25, gesteigert auf 26 dann Eigenschaften gesteigert =3D> LE berechnet zu 26 und um einen Punkt = gesteigert =3D> LE =3D 27 LE Steigerung, welche Kosten werden verursacht? Von 26 auf 27 oder von 27 = auf 28 Was wenn ich die Eigenschaften und die LE "gleichzeitig" erhoehen will, = welche Reighenfolge ist richtig?? Gruss Holger |
From: Alexander N. <lists@AlexNofftz.de> - 2002-05-14 21:45:10
|
Hi Matthias! Matthias Wurm schrieb: > Haben wir das eigentlich schon irgendwie berücksichtigt ? (im Modell > oder in XML ?) Ja, denn Modifikatoren werden dadurch definiert, dass sie im Prinzip zurücknehmbar sind, daher müssen wir sie jederzeit zurück verfolgen können. Die "Modifikatoren" auf die Startwerte der Talente sind aber genau keine Modifikatoren; sie werden einfach bei der Generierung verrechnet und danach nie wieder benutzt. Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany Ale...@em... http://www.AlexNofftz.de Jabber: ale...@am... (Jabber?! http://amessage.de) |
From: Matthias E. <dsa...@em...> - 2002-05-14 17:28:33
|
Hi! > Matthias schrieb: >> (Wollte damit nur sagen, dass man unsere Variante auch "schneller" >> machen KANN.) > > Wie schon gesagt - ich habe bei keinem der beiden Vorschl=E4ge > echte Sorgen, da=DF es zu langsam wird. Ich melde mich einfach mal als interessierter Mitleser aus dem Untergrund. Ich vermute, bis ihr fertig seid sind die Rechner so schnell geworden, dass die Performance wirklich kein Problem mehr darstellt. So, und jetzt haut mich! :-) Gru=DF, Matthias |
From: Tilmann K. <ti...@tk...> - 2002-05-14 16:40:32
|
Hallo! Matthias Wurm wrote: > Was MIR jetzt mittlerweile auch nicht so gefällt, ist das > <KostenMultiplikator> - Tag, dass also quasi der Modi-Typ (ob Kosten, > Basiswert, oder Effektivwert) und Operation (*,+) als Information in das > Tag gemixt werden. Dann nenn ihn doch einfach <Multiplikator> ;-) das war doch nur so hingeschrieben. Hat ja niemand behauptet, dass der Tatsaechlich so heissen muss. Oder nenn ihn <Relation typ="KostenModifikator" ziel="VNT_Vorteile" mult="1.5"/> oder wie auch immer. Worueber wir uns eigentlich einigen sollten ist 1. Fuer was alles wir multiplikative Modifikatoren zulassen wollen 2. Wie sie zu handhaben sind (hintenanstellen nach den additiven) Zu 2. sind wir uns ja mit dem Hintenanstellen denke ich einig. Zu 1. wuerde mich mal eure Meinung interessieren. Brauchen wir mutliplikative nur fuer Kosten oder auch fuer alles andere? Gruss, tilmann |
From: Matthias W. <Mat...@gm...> - 2002-05-14 15:22:29
|
Heut ist mir noch was eingefallen, und zwar die Modifikatoren betreffend: Wenn eine Rasse MU+2 gibt, dann zahle ich von 14 auf 15 soviel, wie wenn ich von 12 auf 13 steigern würde. D.h. die SKT wird nach unten versetzt. Die +x Modifikatoren auf Talente, die von Rassen oder Kulturen kommen, sind ja aber nicht so zu verstehen. D.h. von 7 auf 8 zahle ich nicht wie von 7-x auf 8-x, sondern die vollen Kosten. Haben wir das eigentlich schon irgendwie berücksichtigt ? (im Modell oder in XML ?) Gruß Matthias |
From: Oliver S. <wh...@us...> - 2002-05-14 14:28:00
|
Hi Leute! Matthias schrieb: > (Wollte damit nur sagen, dass man unsere Variante auch "schneller" > machen KANN.) Wie schon gesagt - ich habe bei keinem der beiden Vorschläge echte Sorgen, daß es zu langsam wird. > Bei Oliver (in etwa zumindest): > <Modifikator ausdruck="VNT_BLA.kosten *= 2"/> Ja, so würde ich das vorschlagen. Ich finde, dies entspricht auf sehr natürliche Weise den Regeln, wie sie auch im Freitext formuliert werden. > Wenn man aber davon ausgeht, dass es aber meist so aussehen wird: > <Modifikator ausdruck="EIG_MU+=2"> > dann ist > <Modifikator auf="EIG_MU" ausdruck="2"> > auch nicht gerade unübersichtlich, wenn man attribut="effektiv" und > operand="+" als DEFAULT annimmt. Ok, bei rein additiven Modis ist's nicht viel länger. Aber bei komplexen Modis schon, oder sie sind evtl. gar nicht darstellbar, ohne noch mehr Erweiterungen. Das mit dem Default-Operator ist eine Ersparnis, aber es ist insgesamt doch umständlicher. Erst recht, wenn noch Schachtelungen dazukommen. > Das die beiden Sachen semantisch gleich sind, streitet wohl niemand an, > dass Olivers Variant oftmals weniger "Overhead" erzeugt, auch. > > ICH für meinen Teil bin aber der Ansicht, dass wir aus XML Informationen > besser extrahieren können, wenn wir die 'auf'-Tags verwenden, etc. In der Tat sind meinem Modell mehr Informationen für den reinen XML-Parser nicht zugänglich. Ich sehe das aber nicht als Problem, aus folgendem Grunde: Diese Informationen werden nur bei der Auswertung der Ausdrücke gebraucht. Und dort steht ja auch ein entsprechender Parser zur Verfügung. Ich sehe keinen Vorteil darin, einen Teil der Ausdrücke (z.B. die Schachtelung) in XML auszulagern, da man mit diesem Teil allein nichts anfangen kann. Wenn nicht der gesamte Ausdruck, einschließlich jeder Operation, komplett in XML codiert wird, ist das Konstrukt ohne den Ausdrucksparser IMHO eh nicht nutzbar. Mein Modell kommt zudem insgesamt mit weniger Konstrukten aus, um die nötige Leistungsfähigkeit zu erreichen - es ist schlanker. > Das kann z.B. für "Debuggen" der Ausdrücke nützlich werden, falls sich > mal irgendwo ein Fehler einschleicht. Ich denke, mein Modell ist hervorragend zu debuggen, sowohl Implementierung, wie auch die eigentlichen Scripte, aus folgenden Gründen: - Die Schnittstelle zwischen Scriptsparser/-auswerter und der XML-Engine & Co. kann sehr schmal ausfallen. Das Scripting braucht kein XML, der Rest braucht sich und Bedingungen, Operationen, etc. nicht zu kümmern. Die Schnittstelle kann z.B. lediglich in einem Environment- Object bestehen, daß als Charakterinterface das Lesen und Setzen von Werten ermöglicht. Es kann z.B. auch leicht eine Debugging-Enviroment erstellt werden, das ein gründliches Testen von Scripts ermöglicht. Die Scripte selbst sind zudem in sich geschlossene Objekte, und daher unkompliziert zu handhaben. - Meine Scripts werden linear ausgewertet, nicht rekursiv wie eure Ausdrücke. Wenn man dann einen Script-Bug sucht, ist linear erheblich leichter durchschaubar als rekursiv. Kann man z.B. leicht loggen, und sehen, wo der Wurm ist. - Die klare Trennung von Charakter/Werten/XML und Scripts/Operationen ermöglicht eine streng modulare Implementierung, die viel leichter zu testen ist als eine gemischte Implementierung. - Da die Ausdrücke sehr "natürlich" sind, halte ich meinen Ansatz von vornherein für weniger Fehler anfällig. > Außerdem denke ich noch, dass wir es im XMLReader einfacher haben > werden, wenn wir die XML-nähre Variante verwenden. Da man auch eure Ausdrücke parsen muß, braucht man eh einen Parser zusätzlich zum XML Reader. Ob der dann ein bischen mehr oder weniger tut, macht doch keinen Unterschied. Die kompletten Script-Syntaxbäume wären in jedem Fall voll zugänglich. Es ist nicht so, daß man an irgend was schwer rankommt. > So, bin jetzt schon gespannt, was für Argumente von Oliver ausgekramt > werden... ;-) Nun, ich hab versucht, meine Argumente hier nochmal zusammenzufassen. Ergänzend ist noch anzufügen, daß Scripting mit unvorhergesehen Aufgaben deutlich besser klarkommt, als die XML+Ausdrücke Variante, wie wir am Beispiel "multiplikative Modis" erlebt haben. Wie wichtig das ist, wird jeder unterschiedlich beurteilen. Ich persönlich hab im Design immer gern ein paar Reserven. > Und nachdem dann alles vorgetragen wurde, sollten wir einfach > demokratisch abstimmen. Sonst nimmt das kein Ende. Wohl war ... cu Oliver |
From: Matthias W. <Mat...@gm...> - 2002-05-14 10:25:32
|
Also wir sollten jetzt mal echt einen Schlußstrich ziehen: Fakt ist, dass wir unsere Variante so modifizieren können, dass: wir bei ArithmeticExpression ein hasChanged() einführen können. Ist dieses false, dann kann die Methode einfach den Effektiv-Wert zurückgeben. Ändert sich ein Feature, so können die Features ausgewählt werden, die von dem geänderten Feature abhängig sind. hasChanged() wird angepasst, resolve() ausgeführt, und alle abhängige Features sind wieder auf dem korrekten Effektiv-Wert. Wir ein Feature hinzugefügt, ändern sich die Abhängigkeiten, die dann neu erstellt werden müssen, und alle Werte werden neu berechnet -> Auch dann sind alle Features auf dem korrekten Wert. (Wollte damit nur sagen, dass man unsere Variante auch "schneller" machen KANN.) Und ob einem die XML-Ausdrücke schmecken oder nicht, ist Ansichtssache. Ich für meinen Teil habe ja gesagt, dass ich <KostenMultiplikator ...> ersetzen würde, vielleicht durch <Modifikator auf= "VNT_BLA" attribut="kosten" operand="*" ausdruck="2"/> Bei Oliver (in etwa zumindest): <Modifikator ausdruck="VNT_BLA.kosten *= 2"/> Wenn man aber davon ausgeht, dass es aber meist so aussehen wird: <Modifikator ausdruck="EIG_MU+=2"> dann ist <Modifikator auf="EIG_MU" ausdruck="2"> auch nicht gerade unübersichtlich, wenn man attribut="effektiv" und operand="+" als DEFAULT annimmt. Das ganze natürlich noch mit der Möglichkeit der wenn- und auf-Schachtelung, wie von Alex gezeigt. Das die beiden Sachen semantisch gleich sind, streitet wohl niemand an, dass Olivers Variant oftmals weniger "Overhead" erzeugt, auch. ICH für meinen Teil bin aber der Ansicht, dass wir aus XML Informationen besser extrahieren können, wenn wir die 'auf'-Tags verwenden, etc. Das kann z.B. für "Debuggen" der Ausdrücke nützlich werden, falls sich mal irgendwo ein Fehler einschleicht. Außerdem denke ich noch, dass wir es im XMLReader einfacher haben werden, wenn wir die XML-nähre Variante verwenden. So, bin jetzt schon gespannt, was für Argumente von Oliver ausgekramt werden... ;-) Und nachdem dann alles vorgetragen wurde, sollten wir einfach demokratisch abstimmen. Sonst nimmt das kein Ende. Gruß Matthias |
From: Matthias W. <Mat...@gm...> - 2002-05-14 07:12:40
|
Oliver Schulz wrote: > >>auch nennen mag) zu verwenden. Ich finde es nur komisch, da eigentlich >>DU immer nach Performance rufst... *ggg* > > > ??? Ich hab mich doch lediglich gegen Deine stete Behauptung > verteidigt, meine Lösung sei ineffizient. Ich hab schließlich > selbst geschrieben, daß die GUI eh den Löwenanteil der > Performance frißt, und daß die Rechenperformance daher nicht > so wichtig ist. :-) > a) Das was ich gesagt habe, bezog sich auf das stetige anwenden eines Ausdruck-Tags statt Teilung wert / ausdruck und hatte gar nix mit deiner Methode zu tun. b) Ich habe nie behauptet, deine Methode wäre "ineffizient". Ich habe nur als Manko genannt, das wir häufig den Artihmetik-Parser verwenden müssten. Aber da sich das sicher auch umgehen lässt, dann ist halt deine Methode SUPER-effizient... zufrieden ? Und was ich deiner Methode aber wirklich zugute halten muss, ist dass nach einem Durchlauf durch alle Modi-Anweisungen wirklich ALLE Werte aktualisiert sind. Es ist halt die Frage, wie stark die Verflechtungen im Regelwerk sind (oder genauer gesagt, bei der Instanz eines Charakters). Müssen bei der Änderung eines Wertes fasst alle anderen berechnet werden, oder eher wenige ? Das ist wohl schwer abzuschätzen... Es gibt auch bei uns Methoden, Performance rauszuholen, die letzten Endes auf eine ähnliche Art hinauslaufen (Bei Änderung eines Wertes Bestimmung aller abhängigen Werte aus einer Matrix, Einführung einer hasChanged() Methode, um keinen Rekursionsschritt tiefergehen zu müssen...) Was MIR jetzt mittlerweile auch nicht so gefällt, ist das <KostenMultiplikator> - Tag, dass also quasi der Modi-Typ (ob Kosten, Basiswert, oder Effektivwert) und Operation (*,+) als Information in das Tag gemixt werden. Naja, ich muss jetzt los, schreibe nachher vielleicht noch was. Gruß Matthias |
From: Tilmann K. <ds...@tk...> - 2002-05-13 23:11:05
|
Tilmann Kuhn wrote: > Zu Modifikatoren auf Einkaufskosten wie z.B. Vorteile oder > Spezialfertigkeiten gaebe eine recht einfache Loesung wenn man wie oben > erwaehnt Modifikatoren auf den Charakater zulaesst. Bsp: > > <KostenMultiplikator ziel="CHARAKTER" fuer="VNT_Vorteile" wert="2" Komisch dass es noch keiner gemerkt hat. Das ist natuerlich Quatsch. Man sollte schon wie Oliver es sagt zwischen xml und Implementierung trennen. Deshalb muss es heissen: <KostenMultiplikator ziel="VNT_Vorteile" wert="2"/> Wenn der Charakter als ziel angesprochen werden sollte ist das natuerlich von der Implementierung umzusetzen nicht vom xml ;-) Gruss, tilmann |
From: Alexander N. <lists@AlexNofftz.de> - 2002-05-13 22:54:58
|
Hi! > Oh mann! Grad ist 0:32 und ich hab eben 'ne mail von 14:26 bekommen..... Bei mir war's schon mal viel schlimmer, sodass ich nur =FCber das Web-Archiv mitlesen konnte. Aber jetzt scheint's wieder zu gehen. Vielleicht ist SF.net =FCberlastet? Bis dann, Alex --=20 Alexander Nofftz, Leverkusen, Germany Ale...@em... http://www.AlexNofftz.de=20 Jabber: ale...@am... (Jabber?! http://amessage.de) |
From: Tilmann K. <ds...@tk...> - 2002-05-13 22:31:43
|
Oh mann! Grad ist 0:32 und ich hab eben 'ne mail von 14:26 bekommen..... |