[DSA Manager] =?ISO-8859-1?Q?Re=3A_=5BDSA_Manager=5D_Modifikatoren_-_?= =?ISO-8859-1?Q?1_oder_2_Angaben=3F_=28Re=3A_Grammatik_f=FCr_?= =?ISO-8859-1?Q?=2E=2E=2E=29?=

[Tilmann K. <ds...@tk...>]

Hallo Oliver!

Oliver Schulz wrote:

> 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.

Ja.

> Aber das kann unmöglich
> schon in den Modulen drin stehen, die gar nix voneinander wissen.
> Ergo muß das Programm das schon selbst rausfinden.

Ja, aber das tuts bei der java-Implementierung schon von ganz alleine ohne 
Ordnung und sortieren, weil der Aufruf von MR in der Berrechnung von 2. 
seinerseits eine Berechnung von MR anstoesst. Das Problem mit dem Sortieren 
der Reihenfolge gibt es da nicht wenn man nicht zuweisungsorientiert arbeitet.


> 
>>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.

Ich hab mir diese Moeglichkeit auf jeden Fall mal offen gehalten.


> Nein, je nach Implementierung entweder
> 	Modifikatoren-im-Regelwerk-Anzahl x 1

So hab ichs im Moment.

> oder
> 	Im-Charakter-benutzte-Modis x Geladene-Charakter-Anzahl.

Das meinte ich eigentlich.

> 
> 
> 
>>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).

Im Prinzip schon nur wird der Syntaxbaum vom Parser erstellt, der 
seinerseits von Matthias mit SableCC erstellt wurde und wir wollen 
eigentlich nicht in diesem Code rumpfuschen.

> Und die Scripte auf (Script-)Quellcodeebene zusammenzukleben -
> das fühlt sich wie ein Hack an ... :-)

Jep, bei der Java-version gibts aber keine Scripte in dem Sinne es gibt nur 
Arithmetische und Boolsche Ausdruecke.

> 
> 
> 
>>>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++.

sicher

> 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.

Ok ich kann es dann mittels Vorverarbeitung trennen durch Substring 
before/after "=", im Syntaxbaum hat es bei uns nix verloren geparst wird 
dann nur der zweite Teil.


> 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).

Ich frage mich wirklich was du mit dem ganzen script-Zeug machen willst. Ich 
fuer meinen Teil will keine DSA-Programmiersprache schreiben.

> Ein Modifikator ist eine logische Einheit (Quelle und Ziel), warum
> soll man ihn auseinanderreißen?

Genauer gesagt Quelle(Rasse), Wirkung(+2), Ziel(Talent Schwimmen)

> 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").

Geht bei meiner doch auch:
1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0]
2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5]

Dabei wird der erste Modifikator sauber bei seinem Ziel dem MU-Objekt 
registriert und der Zweite beim GE-Objekt. Und diese beiden wissen nacher 
sogar noch welche Modifikationen von wo gekommen sind ;-)


> ... wenn uns Flexibilität keinen (oder nicht viel) Aufwand kostet,
> sollten wir sie wählen.

Ich muss dazu mal folgendes Vermutung aeussern:
Ich hab jetzt die Grundregeln in java implementiert es fehlen noch 
(Sonderfertigeiten, Zauber, SchlechteEigenschaften, Gaben und Vorteile zuer 
Haelfte). Dabei habe ich einige Regelteile hart codiert. Und die waren zum 
teil so Umfangreich, dass ich glaube, dass du eine Script-Sprache fuer DSA 
zu einer fast kompletten Programmiersprache ausbauen musst, wenn du schon 
die im Standardregelheft vorkommenden Faelle damit abdecken willst.

> 
>>>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.
> 

Das hat sich erledigt ich hab eine simple Loesung fuer solche Schleifen 
gefunden.

Viele Gruesse, tilmann