Re: [DSA Manager] Charakter XML-Format (Fassung 1)

[Alexander N. <webmaster@AlexNofftz.de>]

Hi Matthias!

> <VorNachteile>
>   <Nachteil id="NatNiedrigeMR">
>        <Name>Niedrige Magieresistenz</Name>
>        <Modifikator expr="MR-2"/>
>   </Nachteil>
> 
>   <Nachteil id="NatAngstWeißeMäuse">
>       <Name>Angst vor weißen Mäusen</Name>
>       <Wert num="5"/>
>   </Eigenschaft>
> </VorNachteile>
> 
> so dürft's stimmen, oder ? Ich hab jetzt mal die Schlechte Eigenschaft
> hier auch reingepackt, weil man hier "Standard"-Nachteile von Schlechten
> Eig. unterscheiden kann. Das hindert ja nix daran, neue Nachteile
> hinzuzufügen, egal ob sie Schlechte Eigenschafte sind, oder keinen Wert
> haben. Zu der "offizielle Sachen trennen"-Sache siehe unten.


Na ja, das ist dann aber auch genauso übersichtlich oder unübersichtlich 
wie die Schlechten Eigenschaften unter Eigenschaften einzusortieren. 
Hier muss ich bei allen Nachteilen prüfen, ob sie schlechte 
Eigenschaften sind, bei meiner Variante muss ich bei allen Eigenschaften 
  prüfen, ob sie schlechte Eigenschaften sind. Letzteres könnte man 
dadurch regeln, dass man sich einfach den ID anschaut: Alle Schlechten 
Eigenschaften beginnen laut Konvention mit "Nat", die guten nicht ;-)



> Und zur separaten Datei: ich würde die eigenen Daten einfach in die
> selbe Datei schreiben, und dann anstelle von "NatNiedrigeMR"  lediglich
> "My_NatNiedrigeMR" nehmen (natürlich angenommen, NatNiedrigeMR wäre
> jetzt ein selbst erstellter Nachteil...)


IMHO nicht so gut, wenn man alle Nachteile in eigenen Dateien speichert, 
weil wir dass dann auch für alle Vorteile, Talente, Zaubersprüche etc. 
machen müssten. Da kommen schon alleine bei dem DSA-Basisregeln weit 
über 100 Dateien zusammen, daher bin ich eher dafür, dass man auch 
mehrere Elemente in einer Datei gespeichert werden können. So kann man 
sehr gut einzelne Module aus passenden Professionen, Talenten, 
Vor-/Nachteilen zusammen stellen und als einen Download auf den Server 
legen. Wenn alle diese Dateien beim Programmstart geladen werden, wäre 
es auch kein Problem, irgend etwas schnell zu finden, wenn man alle 
einfach "zusammenmixt", geändert werden diese Dateien nicht. Nur die 
selbstdefinierten Sachen sollten dann eher nach Typ geordnet werden, 
weil diese ja immer bei Änderung geschrieben werden müssen. Mit einer 
Export-Funktion könnte man dann auswählen, was zusammen gehört und 
dieses in einer Datei speichern.


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

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

>>>Da wüsste ich gerne, was die Nr bei Rüstungsgewöhnung bringen soll. Ist
>>>ja irgendwie Quatsch von FanPro, dass keine Regelung zum Steigern von I
>>>auf II da ist... oder hab ich das überlesen ? Wenn nicht, sollten wir da
>>>auch mal nachfragen...
>>
>>Du hast was überlesen: DSA4, Seite 96:
>>
>>Sonderfertigkeit: Rüstungsgewöhnung II
>>...
>>Voraussetzungen: KK 12, _Rüstungsgewöhnung I_
>>
>>Das heißt, man muss erst Rüstungsgewöhnung I haben, bevor man auf II
>>erweitern kann. Irgendwie auch nachvollziehbar.
> 
> Gut, da hab ich jetzt was dazugelernt zu den DSA-Regeln, wo steht das
> genau ? Zu Sonderfert. im allgemeinen hab ich nämlich nix gefunden.


Ich auch nicht. Auch die Beschreibung von Linkhand I ist nur auf den 
Schildkampf bezogen, was wir ja wohl mit Kenntnis des "alten" Talents 
Linkhand besser wissen. Ich denke eher, dass hier nur die 
Sonderfertigkeiten enthalten sind, die unbedingt für das Grundregelwerk 
nötig waren. Den Rest incl. genauerer Beschreibung gibt's wohl erst in 
"Schwerter und Helden"... :-|

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

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

 
>>>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. 
 
>>>Ok, das sieht ja schon mal sehr gut aus. Nur das mit der Trennung von
>>>Sprachen/Schriften/Talenten/Kampffertigkeiten, wäre noch zu klären.
>>>Talente und Kampff. kann man ja noch zusammenmixen. Sprachen und
>>>Schriften... mal sehen, les ich mir ein andermal durch
>>
>>Kampftalente könne man übernehmen, wenn man als Psedo-Probe GE/KK/KK
>>oder so etwas annimmt. GE und KK werden ja als Eigenschaften für den
>>Maximalwert benötigt. Diese Eigenschaftswerte müssen allerdings beim
>>Ausdruck ausgefiltert werden.
> 
> Yupp, stimmt, das muss man ja auch berücksichtigen... aber irgendworan
> merken sollte man schon, dass es _Kampf_Talente sind, was ja aber durch
> die beigelieferte AT / PA gegeben ist...


Genau, wobei man eigentlich nur die AT angeben müsste, denn die PA 
ergibt sich automatisch aus TaW-AT.

 
> 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! ;-)

Bis dann,
   Alex
-- 
Alexander Nofftz, Leverkusen, Germany
http://www.AlexNofftz.de  Ale...@em...