dsaman-list

[DSA Manager] DSAdmin Datenstruktur

[Oliver S. <da...@we...>]

Hi Leute!

Mit einiger Verzögerung hier endlich die Struktur, die wir
für DSAdmin geplant hatten. Ich hab einiges angespaßt, um mich an
der Diskussion hier zu orientieren und Alex Vorschlag mit den
universellen Files übernommen.
kann sein, daß durch die Änderungen Inkonsistenzen reingekommen
sind, einfach ignorieren :-).

Die Struktur ist komplett internationalisiert (bis auf
zwei oder drei Dinge), um den Gerüchten um ein englisches
Myranor und Aventurien Rechnung zu tragen. Da besteht
sicherlich Diskussionsbedarf.
Einige Übersetzungen (einfach erstmal so gewählt):
AV = Attribute Value
SkV = Skill Value (TaW)

Kurze Erläuterung zum Skipting:

talent('swords').SkV.base spricht z.B. den Basiswert des
Schwerter-TaW an,

talent('swords').SkV ist eine Abkürzung für
talent('swords').SkV.effective.

Attribut-Effektivwerte können statt mit attribute('MU').AV.effective
auch mit MU angesprochen werden, usw.

Modifikatoren, Änderungen, usw. werden grundsätzlich über
<action on="TRIGGER" do="EXPRESSION"/>
gehandhabt. Dabei ist TRIGGER "once" für einmal (z.B. für
feste Änderungen), "calc" für Berechnung von Effektivwerten.
Denkbar sind auch Auslöser wie "bei Stufenanstieg" (wer weiß,
was so an Regeln noch kommt ...).

Das Skripting ist recht heftig geworden. Ich denke, so in der Art
können wir tatsächlich auch die wildesten Regeln umsetzen. Die
Implementierung wird allerdings nicht unaufwendig. Vielleicht sollte
man aber auch für einfache Modifikatoren neben <action> noch ein
simpler gestaltetes <mod> vorsehen.


Here we go: Die Regeln
----------------------

<dsa xmlns="http://dsaman.sf.net/dsa-4.0">
	<attributes>
		<base-attributes>
			<attribute id="MU">
				<name xml:lang="de">Mut</name>
				<short-name xml:lang="de">MU</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
			<attribute id="KL">
				<name xml:lang="de">Klugheit</name>
				<short-name xml:lang="de">KL</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
			<attribute id="IN">
				<name xml:lang="de">Intuition</name>
				<short-name xml:lang="de">IN</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
			<attribute id="CH">
				<name xml:lang="de">Charisma</name>
				<short-name xml:lang="de">CH</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
			<attribute id="FF">
				<name xml:lang="de">Fingerfertigkeit</name>
				<short-name xml:lang="de">FF</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
			<attribute id="GE">
				<name xml:lang="de">Gewandtheit</name>
				<short-name xml:lang="de">GE</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
			<attribute id="KK">
				<name xml:lang="de">KK</name>
				<short-name xml:lang="de">Körperkraft</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
			<attribute id="KO">
				<name xml:lang="de">KO</name>
				<short-name xml:lang="de">Konstitution</short-name>
				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
			</attribute>
		</base-attributes>
		<derived-attributes>
			<attribute id="LE">
				<name xml:lang="de">Lebensenergie</name>
				<short-name xml:lang="de">LE</short-name>
				<AV base="0" base-max="floor(KO/2)" add="ceil((KO+KO+KK)/2)" cost="..."/> 
			</attribute>
			<attribute id="AU">
				<name xml:lang="de">Ausdauer</name>
				<short-name xml:lang="de">AU</short-name>
				<AV base="0" base-max="KO*2" add="ceil((MU+KO+GE)/2)" cost="..."/> 
			</attribute>
			<attribute id="MR">
				<name xml:lang="de">Magieresistenz</name>
				<short-name xml:lang="de"></short-name>
				<AV base="0" add="round((MU+KL+KO)/5)"/> 
			</attribute>
			<attribute id="AE">
				<name xml:lang="de">Astralenergie</name>
				<short-name xml:lang="de">AE</short-name>
				<AV base="0" base-max="CH" add="ceil((MU+IN+CH)/2)" cost="..."/> 
			</attribute>
		</derived-attributes>
		<level-attributes>
			<attribute id="AP">
				<name xml:lang="de">Abenteuerpunkte</name>
				<short-name xml:lang="de">AP</short-name>
			</attribute>
			<attribute id="AP_REST">
				<name xml:lang="de">AP-Guthaben</name>
				<short-name xml:lang="de">AP_REST</short-name>
			</attribute>
			<attribute id="ST">
				<name xml:lang="de">Stufe</name>
				<short-name xml:lang="de">ST</short-name>
				<AV base="1" cost="100*(ST+1)"/> 
			</attribute>
			<attribute id="SO">
				<name xml:lang="de">Sozialstatus</name>
				<short-name xml:lang="de">SO</short-name>
				<AV base="0" base-min="1"/>
			</attribute>
		</level-attributes>
		<combat-attributes>
			<attribute id="AT_BASE">
				<name xml:lang="de">Attacke-Basiswert</name>
				<short-name xml:lang="de">AT-Basis</short-name>
				<AV base="0" add="round((MU+GE+KK)/5)"/>
			</attribute>
			<attribute id="PA_BASE">
				<name xml:lang="de">Parade-Basiswert</name>
				<short-name xml:lang="de">PA-Basis</short-name>
				<AV base="0" add="round((IN+GE+KK)/5)"/>
			</attribute>
			<attribute id="FK_BASE">
				<name xml:lang="de">Fernkampf-Basiswert</name>
				<short-name xml:lang="de">FK-Basis</short-name>
				<AV base="0" add="round((IN+FF+KK)/5)"/>
			</attribute>
			<attribute id="INI_BASE">
				<name xml:lang="de">Initiative-Basiswert</name>
				<short-name xml:lang="de">Ini-Basis</short-name>
				<AV base="0" add="round((MU+MU+IN+GE)/2)"/>
			</attribute>
			<attribute id="BE">
				<name xml:lang="de">Behinderung</name>
				<short-name xml:lang="de">BE</short-name>
				<AV base="0"/>
			</attribute>
		</combat-attributes>
	</attributes>

	<advantages>
		<advantage id="lucky" cost="15">
			<name xml:lang="de">Glück</name>
			<description xml:lang="de">
				<p> Ein Held, an dem sprichwörtlich das Glück klebt,
				bla, bla, ...  </p>
			</description>
			<short-description xml:lang="de">
				<p> Bis 3-mal am Tag eine Probe <emph>einmal</emph>
				wiederholen und günstigeres Ergebnis wählen.</p>
			</short-description>
		</advantage>
	
		<advantage id="gifted-skill" specialisation="required" cost="oh shit!">
			<name xml:lang="de">Begabung für Talent</name>
			<prerequisite expr="not Advantage('gifted-skill-group')"/>
			<action on="once" do="Talent(spec).TaW.base += 1"/>
			<action on="once" do="Talent(spec).TaW.cost_factor -= 1"/>
		</advantage>
	
		<advantage id="gifted-skill-group" specialisation="required" cost="ohshit!">
			<name xml:lang="de">Begabung für Talentgruppe</name>
			<prerequisite expr="not Advantage('gifted-skill')"/>
			<action on="once" do="this will be complicated ..."/>
		</advantage>
	
		<advantage id="special-possession" specialisation="required" cost="12">
			<name xml:lang="de">Besonderer Besitz</name>
		</advantage>
	
		<advantage id="high-spell-resistance" cost="choose([5,10,15])">
			<name xml:lang="de">Hohe Magieresistenz</name>
			<action on="once" do="Attribute(MR).AV += cost/5"/>
		</advantage>
	</advantages>

	<disadvantages>
		...
	</disadvantages>

	<races>
		<race id="human">
			<action on="calc" do="..."/>
			...
			<culture id="mittelreich"/>
			<culture id="..."/>
		</race>
	</races>

	<skills>
		<skill-category id="combat-skills">
			<name xml:lang="de">Kampftalente</name>

			<skill-category id="armed-combat">
				<name xml:lang="de">Bewaffneter Nahkampf</name>

				<skill id="swords">
					<name xml:lang="de">Schwerter</name>
					<SkV base="0" cost-table="5"/>
					<eBE base="BE-2"/>
					<similar to="sabers"/>
					<similar to="fencing"/>
					<similar to="blunt-weapons"/>
				</skill>
			</skill-category>
		</skill-category>

		<skill-category id="special-skills">
			<name xml:lang="de">Sonderfertigkeiten</name>

			<skill
				id="armor-tolerance-1" cost="150"
				specialisation="required" spec-type="armor"
			>
				<name xml:lang="de">Rüstungsgewöhnung I</name>
				<action
					on="calc"
					do="! skill(armor-tolerance-2) ? armor(spec).BE -= 1"
				/>
			</skill>
			<skill
				id="armor-tolerance-2"
				cost="profession_class('fighter') ? 150 : 300"
			>
				<name xml:lang="de">Rüstungsgewöhnung II</name>
				<prerequisite expr="skill('armor-tolerance-1')"
				<action on="calc" do="BE -= 1"/>
			</skill>
		</skill-category>
	</skills>

	<professions>
		<profession id="mercenary" cost="10">
			<name xml:lang="de">Söldner</name>
			<action on="once" do="talent('athletics').SkV.base += 2"/>
			<action on="once" do="talent('climbing').SkV.base  += 1"/>
			...
			<action on="once" do="skills.add('armor-tolerance-1')"/>
		</profession>
	</professions>

</dsa>


Ein Charakter (skizzenhaft):
----------------------------

<?xml-stylesheet type="text/xsl" href="character2xhtml.xsl"?>

<charakter
	xmlns="http://www.lowangen.de/dsa-4.0"
	
	age="21"
	size="90"
	weight="80"
>
	<name xml:lang="de">Alrik</name>
	<race id="human"/>
	<culture id="mittelreich"/>
	<description>
		Alrik ist ... bla, bla
	</description>
	<standing id="common"/>
	<siblings xml:lang="de">Alrik hat keine Geschwister</siblings>
	
	<attributes>
		<base-attributes>
			<attribute id="MU"><AV base="9" effective="9"/></attribute>
			...
		</base-attributes>
		<derived-attributes>
			...
		</derived-attributes>
		<level-attributes>
			<attribute id="ST"><AV base="1"/></attribute>
			...
		</level-attributes>
		<combat-attributes>
			<attribute id="AT_BASE">
				<name xml:lang="de">Attacke-Basiswert</name>
				<short-name xml:lang="de">AT-Basis</short-name>
				<AV effective="8"/>
			</attribute>
			<attribute id="PA_BASE">
				<name xml:lang="de">Parade-Basiswert</name>
				<short-name xml:lang="de">PA-Basis</short-name>
				<AV effective="8"/>
			</attribute>
			...
		</combat-attributes>
	</attributes>

	<professions>
		<profession id="mercenary" veteran="false" cost="10"/>
	</professions>

	<advantages>
		<advantage id="USER-ADVANTAGE-2f394e7a829" cost="10">
			<name xml:lang>Schwertmeister</name>
			<action on="calc" do="skill('swords').AT += 1"/>
			<action on="calc" do="skill('swords').PA += 2"/>
		</advantage>
		<advantage id="lucky"/>
	</advantages>
	
	<skills>
		<skill id="swords">
			<SkV base="4" effective="4"/>
			<AT base="13" effective="14"/>
			<PA base="11" effective="13"/>
		</skill>
		<skill
			id="armor-tolerance-1" spec="plate-armor"
		>
		</skill>
	</skills>
	
	<spells>
	</spells>
	
	<notes>
	</notes>

	...
</charakter>

Re: [DSA Manager] DSAdmin Datenstruktur

[Andreas H. <ahu...@gm...>]

Hallo Oliver,


On Tuesday 13 November 2001 18:39, Oliver Schulz wrote:
> Hi Leute!
>
> Mit einiger Verzögerung hier endlich die Struktur, die wir
> für DSAdmin geplant hatten. Ich hab einiges angespaßt, um mich an
> der Diskussion hier zu orientieren und Alex Vorschlag mit den
> universellen Files übernommen.
> kann sein, daß durch die Änderungen Inkonsistenzen reingekommen
> sind, einfach ignorieren :-).
>
> Die Struktur ist komplett internationalisiert (bis auf
> zwei oder drei Dinge), um den Gerüchten um ein englisches
> Myranor und Aventurien Rechnung zu tragen. Da besteht
> sicherlich Diskussionsbedarf.
> Einige Übersetzungen (einfach erstmal so gewählt):
> AV = Attribute Value
> SkV = Skill Value (TaW)

Hmm sollen wir uns das als deutsche User eines deutschsprachigen Spieles 
antun? Wir hauen da eher Fehler rein.
Wir können dann besser später den weg gehen und das ganze nach english 
umschreiben ..

Damit wir uns klar verstehen du schreibst in deiner XML Datei zwar 

<name xml:lang="de">Mut</name>

und gibst damit ne sprachdefinition mit aber dann

<name xml:lang="de">Alrik</name>
<race id="human"/>
<culture id="mittelreich"/>

verwischt es wenn du hier human als Rasse und Mittlereich als Herkunft wählst.

Natürlich fände ich es gut das man das Tool auch von englischsprachigen Usern 
benutzt werden könnte... wie sieht es mit der Holländischen oder Französichen 
Version aus ? ;-)

Der Rest der Datei sieht gut aus, hier noch was mir aufgefallen/unklar ist.


> 			<attribute id="MU">
> 				<name xml:lang="de">Mut</name>
> 				<short-name xml:lang="de">MU</short-name>
> 				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
> 			</attribute>

Was meinst du hier mit    base-max="gen ? 14 : 21" den Maximalwert allgemein? 
Evtl wird es später Rassen geben die zB. KK größer 21 haben koennen ...

> 			<attribute id="LE">
> 				<name xml:lang="de">Lebensenergie</name>
>				<short-name xml:lang="de">LE</short-name>
>				<AV base="0" base-max="floor(KO/2)" add="ceil((KO+KO+KK)/2)"cost="..."/>
>			 </attribute>

Verrechnest du evtl vorhandene Vorteile, Rasse und Professionsboni später ? 
Wofuer stehen hier cost ??


Bye
Andreas

Re: [DSA Manager] DSAdmin Datenstruktur

[Matthias W. <Mat...@gm...>]

Andreas Hugenroth wrote:
> 
> Hallo Oliver,
> 
> On Tuesday 13 November 2001 18:39, Oliver Schulz wrote:
> > Hi Leute!
> >
> > Mit einiger Verzögerung hier endlich die Struktur, die wir
> > für DSAdmin geplant hatten. Ich hab einiges angespaßt, um mich an
> > der Diskussion hier zu orientieren und Alex Vorschlag mit den
> > universellen Files übernommen.
> > kann sein, daß durch die Änderungen Inkonsistenzen reingekommen
> > sind, einfach ignorieren :-).
> >
> > Die Struktur ist komplett internationalisiert (bis auf
> > zwei oder drei Dinge), um den Gerüchten um ein englisches
> > Myranor und Aventurien Rechnung zu tragen. Da besteht
> > sicherlich Diskussionsbedarf.
> > Einige Übersetzungen (einfach erstmal so gewählt):
> > AV = Attribute Value
> > SkV = Skill Value (TaW)
> 
> Hmm sollen wir uns das als deutsche User eines deutschsprachigen Spieles
> antun? Wir hauen da eher Fehler rein.
> Wir können dann besser später den weg gehen und das ganze nach english
> umschreiben ..
> 
> Damit wir uns klar verstehen du schreibst in deiner XML Datei zwar
> 
> <name xml:lang="de">Mut</name>
> 
> und gibst damit ne sprachdefinition mit aber dann
> 
> <name xml:lang="de">Alrik</name>
> <race id="human"/>
> <culture id="mittelreich"/>
> 
> verwischt es wenn du hier human als Rasse und Mittlereich als Herkunft wählst.
> 
> Natürlich fände ich es gut das man das Tool auch von englischsprachigen Usern
> benutzt werden könnte... wie sieht es mit der Holländischen oder Französichen
> Version aus ? ;-)

Hmm, bleibt zu überlegen, ob es wirklich so viele englischsprachigen
DSA-Spieler gibt (Es gibt ja die Adaption "Realms of Arkania", aber ob
das nicht eher von der gigantischen AD&D Gemeinde überschattet ist, wer
weiß....)
Aber eins kann man ja schon sagen, dass nämlich Tags und ids die
englischen User nicht zu bocken haben. Und aus dem Grund können wir ja
zumindest mal die deutsch lassen. Das mit dem Mittelreich ist nämlich
ein echt gutes Beispiel für ne ID, von der wir keinen blassen Schimmer
haben, wie wir die auf englisch nennen sollen. Also mein Vorschlag: Tags
und IDs auf deutsch, aber eine Option für die englische Sprache nicht
ausschließen. Was meint ihr ? (obwohl englische Tags eigentlich auch gar
nicht so schlecht wären... naja, aber IDs auf jeden Fall deutsch, damit
kriegen wir dann auch keinen Ärger...)



> 
> Der Rest der Datei sieht gut aus, hier noch was mir aufgefallen/unklar ist.
> 
> >                       <attribute id="MU">
> >                               <name xml:lang="de">Mut</name>
> >                               <short-name xml:lang="de">MU</short-name>
> >                               <AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
> >                       </attribute>
> 
> Was meinst du hier mit    base-max="gen ? 14 : 21" den Maximalwert allgemein?
> Evtl wird es später Rassen geben die zB. KK größer 21 haben koennen ...

Hmm, das stimmt, spontan fallen mir Trolle ein, da wollte ich mal
spaßeshalber für zwischendurch einen spielen, und der hatte eine KK von
mehr als 20... am Anfang (war so n inoffizieller Vorschlag irgendwo im
Inet) Und falls FanPro die Viechers wirklich mal reinbringt, seh ichs
irgendwie schon kommen "Für die Generierung von Trollen gilt die
Obergrenze von KK 14 und die Untergrenze von KL 8 nicht..." Zugegeben
eine Ausnahme, die wir nicht berücksichtigen müssen... wollte es nur mal
als Beispiel bringen. 

Zum Rest kann ich noch keinen Kommentar abliefern, da ich mich da erst
noch durchkauen muss, sieht aber schonmal echt gut aus...

Re: [DSA Manager] DSAdmin Datenstruktur

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

Hi Matthias!

> Aber eins kann man ja schon sagen, dass nämlich Tags und ids die
> englischen User nicht zu bocken haben. Und aus dem Grund können wir ja
> zumindest mal die deutsch lassen. Das mit dem Mittelreich ist nämlich
> ein echt gutes Beispiel für ne ID, von der wir keinen blassen Schimmer
> haben, wie wir die auf englisch nennen sollen. Also mein Vorschlag: Tags
> und IDs auf deutsch, aber eine Option für die englische Sprache nicht
> ausschließen. Was meint ihr ? (obwohl englische Tags eigentlich auch gar
> nicht so schlecht wären... naja, aber IDs auf jeden Fall deutsch, damit
> kriegen wir dann auch keinen Ärger...)


Die IDs sind eindeutig, die Definition von xml:lang auch, daher können 
wir auch eine Datei komplett mit xml:lang ausstatten:

   <DSACharakter xml:lang="de">

Dann weiß das Programm, woran es ist und kann dann bei einer 
englischspachigen (holländischen, französischen...) Version des 
Programms direkt alle Bezeichnungen aus der Ursprungsdatei lesen und 
statt der Namen in dieser Datei anzeigen.

> Hmm, das stimmt, spontan fallen mir Trolle ein, da wollte ich mal
> spaßeshalber für zwischendurch einen spielen, und der hatte eine KK von
> mehr als 20... am Anfang (war so n inoffizieller Vorschlag irgendwo im
> Inet) Und falls FanPro die Viechers wirklich mal reinbringt, seh ichs
> irgendwie schon kommen "Für die Generierung von Trollen gilt die
> Obergrenze von KK 14 und die Untergrenze von KL 8 nicht..." Zugegeben
> eine Ausnahme, die wir nicht berücksichtigen müssen... wollte es nur mal
> als Beispiel bringen. 


Klar, obwohl vielleicht Trolle etwas übertrieben wären... Obwohl... Hat 
noch jemand hier die "Elementaren Gewalten" von Wieser gelesen? :-)

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

Re: [DSA Manager] DSAdmin Datenstruktur

[Oliver S. <da...@we...>]

> Hmm sollen wir uns das als deutsche User eines deutschsprachigen Spieles
> antun? Wir hauen da eher Fehler rein.
> Wir können dann besser später den weg gehen und das ganze nach english
> umschreiben ..

Wenn wir das nachträglich machen, kriegen wir das aber
kaum dann in eine geschlossene Struktur ... das liefe
dann eher auf eine komplette Zweitversion hinaus.

> Damit wir uns klar verstehen du schreibst in deiner XML Datei zwar
>
> <name xml:lang="de">Mut</name>
>
> und gibst damit ne sprachdefinition mit aber dann
>
> <name xml:lang="de">Alrik</name>
> <race id="human"/>
> <culture id="mittelreich"/>
>
> verwischt es wenn du hier human als Rasse und Mittlereich als Herkunft
> wählst.

Das war es, was ich mit "internationalisiert, von einigen Ausnahmen
abgesehen" meinte. Mir fiel spontan nix passendes für Mittelreich
ein.
Ein Problem ist ohnehin, das wir keinen Schimmer haben, wie das mal
alles auf Englisch heißen wird (Alex hat da ja auch schon was zu geschrieben).
Ein Kompromiß wäre, Tags und Attribute in Englisch, ID's erstmal
in deutsch. Da ID's nicht gedruckt werden, und nur Kennungen sind,
könnten wohl auch Amis damit leben. Aber man müßte nicht irgendwann nochmal
die ganze DTD umkrempeln.

> Natürlich fände ich es gut das man das Tool auch von englischsprachigen
> Usern benutzt werden könnte... wie sieht es mit der Holländischen oder
> Französichen Version aus ? ;-)

Dem steht dann (theoretisch) ja nix im Wege. Und Präzedenzen für
ein französisches DSA gibts ja ...

>
> Der Rest der Datei sieht gut aus, hier noch was mir aufgefallen/unklar ist.
>
> > 			<attribute id="MU">
> > 				<name xml:lang="de">Mut</name>
> > 				<short-name xml:lang="de">MU</short-name>
> > 				<AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
> > 			</attribute>
>
> Was meinst du hier mit    base-max="gen ? 14 : 21" den Maximalwert
> allgemein? Evtl wird es später Rassen geben die zB. KK größer 21 haben
> koennen ...

gen sollte ein Boolean sein, der während der Generierung gesetzt ist.

> > 			<attribute id="LE">
> > 				<name xml:lang="de">Lebensenergie</name>
> >				<short-name xml:lang="de">LE</short-name>
> >				<AV base="0" base-max="floor(KO/2)"
> > add="ceil((KO+KO+KK)/2)"cost="..."/> </attribute>

> Verrechnest du evtl vorhandene Vorteile, Rasse und Professionsboni später ?

Ja, machen dann die <action>'s.

> Wofuer stehen hier cost ??

Steigerungskosten des Attributs.

cu
Oli

Re: [DSA Manager] DSAdmin Datenstruktur

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

Hi Oliver!

Bin gerade aus Scary Movie II gekommen (<bg>) und habe jetzt Zeit hierfür...

> Die Struktur ist komplett internationalisiert (bis auf
> zwei oder drei Dinge), um den Gerüchten um ein englisches
> Myranor und Aventurien Rechnung zu tragen. Da besteht
> sicherlich Diskussionsbedarf.


Ja, da hatten wir ja auch schon über Telefon drüber geredet, an den 
anderen Reaktionen hier siehst du ja, wie die anderen darüber denken. 
BTW du weißt, wofür die letzen beiden Buchstaben beim DOCTYPE stehen?

Mal zur Verdeutlichung mein DOCTYPE für die Charaktere:

   -//FANPRO//DTD DSA Charakter 1.0//DE

und als Gegenbeispiel mal der von XHTML:

   -//W3C//DTD XHTML 1.1//EN

Fällt dir was auf? ;-)


> Einige Übersetzungen (einfach erstmal so gewählt):
> AV = Attribute Value
> SkV = Skill Value (TaW)


Wie gesagt, so etwas ist riskant. Entweder bekommen wir von FanPro die 
englischen Bezeichnungen, oder wir lassen es lieber, bevor das in 
totales Chaos ausartet.


> Kurze Erläuterung zum Skipting:
> 
> talent('swords').SkV.base spricht z.B. den Basiswert des
> Schwerter-TaW an,


Da widersprichst du dir aber, eigentlich müsste die Funktion jetzt 
skill() heißen <g>

 
> Das Skripting ist recht heftig geworden. Ich denke, so in der Art
> können wir tatsächlich auch die wildesten Regeln umsetzen. Die
> Implementierung wird allerdings nicht unaufwendig. Vielleicht sollte
> man aber auch für einfache Modifikatoren neben <action> noch ein
> simpler gestaltetes <mod> vorsehen.


Allerdings.

 
 
> <dsa xmlns="http://dsaman.sf.net/dsa-4.0">


Ist zwar nur kosmetisch, aber evtl. wäre hier ein URN besser. Die URLs 
als Namespaces waren nur eine Notlösung, weil bei der 
Namespace-Spezifikation die URN-Definition noch nicht fertig war.


> <attributes>
>  <base-attributes>
>   <attribute id="MU">
>    <name xml:lang="de">Mut</name>
>    <short-name xml:lang="de">MU</short-name>


Der short-name sollte der ID sein, daher ist diese Zeile eigentlich unnötig.


>    <AV base="0" base-min="8" base-max="gen ? 14 : 21"/>


Diese Anweisung ist mir nicht so ganz klar. Was soll dieses "gen" 
bedeuten? Dass der Wert bei der Generierung nicht höher als 14, danach 
bis max. 21 gehen kann? Das ist so nicht richtig. Das mit der 
Generierung stimmt, aber danach ist der Maximalwert das anderthalbfache 
des Startwertes. Dadurch ergibt sich durch den Startwert 14 die 21, aber 
wenn ich den Vorteil Herausragende Eigenschaft nehme, kann ich durchaus 
auch höher kommen.


> <derived-attributes>
>  <attribute id="LE">
>   <name xml:lang="de">Lebensenergie</name>
>   <short-name xml:lang="de">LE</short-name>
>   <AV base="0" base-max="floor(KO/2)" add="ceil((KO+KO+KK)/2)" cost="..."/>


Gute Definition, aber cost ist ganz einfach: cost="SKT(H)" ;-)


> <level-attributes>


Ein unglücklicher Name, da gefiel mir mein <Variablen> besser, außerdem 
gehört hier der SO nicht rein.


> <attribute id="ST">
>  <name xml:lang="de">Stufe</name>
>  <short-name xml:lang="de">ST</short-name>
>  <AV base="1" cost="100*(ST+1)"/>


NEIN, denn damit wäre laut deiner Syntax die Stufe dann ein steigerbarer 
  Wert, der mich immer genau so viele AP kostet, wie mir zur nächsten 
Stufe fehlen. Besser direkt berechnen über:

    <AV base="0" add="round(floor((5+sqrt(25+2*AP))/10))"/>


> <attribute id="SO">
>  <name xml:lang="de">Sozialstatus</name>
>  <short-name xml:lang="de">SO</short-name>
>  <AV base="0" base-min="1"/>
> </attribute>


Gehört nicht hierein! SO ist eine (nicht steigerungsfähige) Eigenschaft 
und sollte auch da hin.


>  <advantages>
>   <advantage id="lucky" cost="15">
>    <name xml:lang="de">Glück</name>
>    <description xml:lang="de">
>     <p> Ein Held, an dem sprichwörtlich das Glück klebt,
>      bla, bla, ...  </p>
>    </description>
>    <short-description xml:lang="de">
>     <p> Bis 3-mal am Tag eine Probe <emph>einmal</emph>
>      wiederholen und günstigeres Ergebnis wählen.</p>
>    </short-description>
>   </advantage>


Im Prinzip einverstanden, bis darauf, dass es in HTML <em> statt <emph> 
heißt ;-)


>  <advantage id="gifted-skill" specialisation="required" cost="oh shit!">


Wieso "oh shit!"? Was spricht dagegen, diesen Vorteil für jede 
Talentgruppe einzeln zu definieren? Allzu viele sind's ja nicht.


>   <name xml:lang="de">Begabung für Talent</name>
>   <prerequisite expr="not Advantage('gifted-skill-group')"/>


Außerdem darf "gifted-skill" nicht doppelt gewählt werden, es sei denn, 
es ist durch die RaKuPro vorgegeben.


>  <advantage id="gifted-skill-group" specialisation="required" cost="ohshit!">
>   <name xml:lang="de">Begabung für Talentgruppe</name>
>   <prerequisite expr="not Advantage('gifted-skill')"/>
>   <action on="once" do="this will be complicated ..."/>


Wird es nicht, wenn man einfach einer Talentgruppe einen ID zuweist, 
kann man sich darauf beziehen.


>  <advantage id="special-possession" specialisation="required" cost="12">
>   <name xml:lang="de">Besonderer Besitz</name>
>  </advantage>


Dieser Vorteil sollte bei den Professionen stehen und direkt aufzählen, 
was man dann bekommt.


> <races>
>  <race id="human">
>  <action on="calc" do="..."/>
>  ...
>  <culture id="mittelreich"/>
>  <culture id="..."/>
> </race>


Die Kulturen in der Rasse speichern? Und wenn ich jetzt einen Thorwaler 
spielen will, der im Bornland aufgewachsen ist? Das geht sogar schon bei 
den Basisregeln!


> <skills>
>  <skill-category id="combat-skills">
>   <name xml:lang="de">Kampftalente</name>
>   <skill-category id="armed-combat">
>    <name xml:lang="de">Bewaffneter Nahkampf</name>
>    <skill id="swords">
>     <name xml:lang="de">Schwerter</name>
>     <SkV base="0" cost-table="5"/>
>     <eBE base="BE-2"/>
>     <similar to="sabers"/>
>     <similar to="fencing"/>
>     <similar to="blunt-weapons"/>
>    </skill>
>   </skill-category>
>  </skill-category>


Hmm, ob diese Mehrfachverschachtelung überhaupt nötig ist? Außerdem 
merke ich langsam schon, wie viel meine Drei-Buchstaben-Prefixe bei den 
IDs ausmachen ;-)

>  <skill-category id="special-skills">
>   <name xml:lang="de">Sonderfertigkeiten</name>
>   <skill
>     id="armor-tolerance-1" cost="150"
>     specialisation="required" spec-type="armor"
>   >
>   <name xml:lang="de">Rüstungsgewöhnung I</name>
>   <action
>     on="calc"
>     do="! skill(armor-tolerance-2) ? armor(spec).BE -= 1"
>   />
>  </skill>


Sonderfertigkeiten sind keine Talente, daher sind sie hier etwas 
unglücklich eingeordnet. Ansonsten einverstanden.


> <professions>
>  <profession id="mercenary" cost="10">
>   <name xml:lang="de">Söldner</name>
>   <action on="once" do="talent('athletics').SkV.base += 2"/>
>   <action on="once" do="talent('climbing').SkV.base  += 1"/>
>   ...
>   <action on="once" do="skills.add('armor-tolerance-1')"/>
>  </profession>
> </professions>


Wäre es nicht viel übersichtlicher, die ID statt talent(ID).SkV.base - 
Schreibweise auch hier zuzulassen?

> 
> Ein Charakter (skizzenhaft):
> ----------------------------
> 
> <?xml-stylesheet type="text/xsl" href="character2xhtml.xsl"?>


StyleSheet vorgeben? Warum?

 
> <charakter
>   xmlns="http://www.lowangen.de/dsa-4.0"


hehe

 	
>   age="21"
>   size="90"
>   weight="80"


Ungünstig. Ich hatte diese Werte extra als eigene Tags definiert, damit 
man die Einheit angeben kann. Viele geben die Größe in "Halbfingern" an, 
andere in Schritt. Einige geben die Größe in Stein an, andere in Unzen etc.

 
>   <name xml:lang="de">Alrik</name>
>   <race id="human"/>
>   <culture id="mittelreich"/>


Besser hier auch Inhalte zulassen, einige wollen bestimmt einen 
"Dalmatier" spielen, obwohl sie die Werte eines "Garethers" nehmen ;-)


>  <description>
>    Alrik ist ... bla, bla
>  </description>


...was? :-)


>  <base-attributes>
>    <attribute id="MU"><AV base="9" effective="9"/></attribute>
>    ...
>  </base-attributes>


Warum einen Effektiv-Wert angeben? Da wären die Modifikatoren besser. 
Was bringt mir der Effektivwert, wenn ich nicht weiß, wie der sich 
berechnet.


>  <derived-attributes>
>    ...
>  </derived-attributes>
>  <level-attributes>
>    <attribute id="ST"><AV base="1"/></attribute>
>    ...
>  </level-attributes>
>  <combat-attributes>

[..]

Wenn ich dich richtig verstehe, willst du die Berechnungsvorschiften aus 
der o.a. Datei lesen, dann brauche ich aber all dies nicht zu speichern 
weil klar ist, wie ich diese Werte erhalte.


>  <professions>
>    <profession id="mercenary" veteran="false" cost="10"/>
>  </professions>


Mehrere Professionen? Veteran? Ähh... ?!


>  <advantages>
>    <advantage id="USER-ADVANTAGE-2f394e7a829" cost="10">


Wieso so ein merkwürdiger ID? Warum nicht einfach den Namen dafür 
verwenden, wie wir es hier schon besprochen hatten?


>    <name xml:lang>Schwertmeister</name>
>    <action on="calc" do="skill('swords').AT += 1"/>
>    <action on="calc" do="skill('swords').PA += 2"/>
>  </advantage>
>  <advantage id="lucky"/>


Wenn man einen Vorteil nicht modifiziert, wird er nur als Referenz 
übernommen? OK, leuchtet ein und spart Platz.


>  <skills>
>    <skill id="swords">
>    <SkV base="4" effective="4"/>


Wenn effektive==base ist, brauchen wir's nicht anzugeben, oder? ;-)


>    <AT base="13" effective="14"/>
>    <PA base="11" effective="13"/>


Schlecht, lieber:

      <AT base="3" add="AT_BASE"/>
      <PA base="2" add="PA_BASE"/>

genau genommen ist die PA überflüssig, da PA=TaW-AT


>  </skill>
>  <skill
>    id="armor-tolerance-1" spec="plate-armor"
>  >
>  </skill>


Dazu habe ich mir schon Gedanken gemacht. Wir sollten alle 
Ausrüstungsgegenstände in Klassen einteilen, wobei ein Gegenstand auch 
gleichzeitig mehreren Klassen angehören kann. Die Klassen wiederrum sind 
hierarchisch geordnet, damit lässt sich die Rüstungsgewohnung wunderbar 
beschreibung, aber auch die Begabung für ein Talent oder eine 
Talentgruppe etc.

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

Re: [DSA Manager] DSAdmin Datenstruktur

[Oliver S. <da...@we...>]

> Mal zur Verdeutlichung mein DOCTYPE für die Charaktere:
>    -//FANPRO//DTD DSA Charakter 1.0//DE
> und als Gegenbeispiel mal der von XHTML:
> Fällt dir was auf? ;-)

Das hat aber mit dem Inhalt ja nix zu tun. Deutsche
XHTML Seiten können auch doctype -//W3C//DTD XHTML 1.1//EN
haben.

> > Einige Übersetzungen (einfach erstmal so gewählt):
> > AV = Attribute Value
> > SkV = Skill Value (TaW)
>
> Wie gesagt, so etwas ist riskant. Entweder bekommen wir von FanPro die
> englischen Bezeichnungen, oder wir lassen es lieber, bevor das in
> totales Chaos ausartet.

Die Tags und Attribute würde ich trotzdem in Englisch halten (man
kann ja bei Fanpro mal anfragen), das sind nur ein paar. Was
allerdings die ID's angeht, sollte man in der Tat überlegen, ob
man die nicht in Deutsch läßt. Die ID's sind ja eh sprachunabhängig,
könnten auch nummern sein, ist ja nur text um's auf Dateiebene
übersichtlich zu halten.

> > talent('swords').SkV.base spricht z.B. den Basiswert des
> > Schwerter-TaW an,
>
> Da widersprichst du dir aber, eigentlich müsste die Funktion jetzt
> skill() heißen <g>

Heißt es auch. Ist aber vermutlich nicht die einzige Stelle,
an der ich vergessen habe anzupassen. 8-)

>
> > Das Skripting ist recht heftig geworden. Ich denke, so in der Art
> > können wir tatsächlich auch die wildesten Regeln umsetzen. Die
> > Implementierung wird allerdings nicht unaufwendig. Vielleicht sollte
> > man aber auch für einfache Modifikatoren neben <action> noch ein
> > simpler gestaltetes <mod> vorsehen.
>
> Allerdings.
>
> > <dsa xmlns="http://dsaman.sf.net/dsa-4.0">
>
> Ist zwar nur kosmetisch, aber evtl. wäre hier ein URN besser. Die URLs
> als Namespaces waren nur eine Notlösung, weil bei der

Auch eine URL ist gültiger URI und daher nicht nur eine Notlösung.
An der URL kann schließlich auch etwas sinnvolles liegen (DTD,
Schema, Dokumentation). Klar kann man auch eine URN nehmen, hätte ich
nix dagegen. Leider bauen aber einige XML-Parser Mist (und ich fürchte,
unser C-Parser gehört dazu), die unbedingt eine gültige URL sehen
wollen. :-(

> > <attributes>
> >  <base-attributes>
> >   <attribute id="MU">
> >    <name xml:lang="de">Mut</name>
> >    <short-name xml:lang="de">MU</short-name>
>
> Der short-name sollte der ID sein, daher ist diese Zeile eigentlich
> unnötig.

IMHO nicht, denn eine ID ist sprachunabhängig, während der
short-name in verschiedenen Sprachen auf Char.Bögen auftauchen
kann.


>
> >    <AV base="0" base-min="8" base-max="gen ? 14 : 21"/>
>
> Diese Anweisung ist mir nicht so ganz klar. Was soll dieses "gen"
> bedeuten? Dass der Wert bei der Generierung nicht höher als 14, danach
> bis max. 21 gehen kann? Das ist so nicht richtig. Das mit der
> Generierung stimmt, aber danach ist der Maximalwert das anderthalbfache
> des Startwertes. Dadurch ergibt sich durch den Startwert 14 die 21, aber

Genau das soll es heißen. Das mit den 21 stimmt natürlich nicht.



> wenn ich den Vorteil Herausragende Eigenschaft nehme, kann ich durchaus
> auch höher kommen.
>
> > <derived-attributes>
> >  <attribute id="LE">
> >   <name xml:lang="de">Lebensenergie</name>
> >   <short-name xml:lang="de">LE</short-name>
> >   <AV base="0" base-max="floor(KO/2)" add="ceil((KO+KO+KK)/2)"
> > cost="..."/>
>
> Gute Definition, aber cost ist ganz einfach: cost="SKT(H)" ;-)
>
> > <level-attributes>
>
> Ein unglücklicher Name, da gefiel mir mein <Variablen> besser, außerdem
> gehört hier der SO nicht rein.
>
> > <attribute id="ST">
> >  <name xml:lang="de">Stufe</name>
> >  <short-name xml:lang="de">ST</short-name>
> >  <AV base="1" cost="100*(ST+1)"/>
>
> NEIN, denn damit wäre laut deiner Syntax die Stufe dann ein steigerbarer
>   Wert, der mich immer genau so viele AP kostet, wie mir zur nächsten
> Stufe fehlen. Besser direkt berechnen über:
>
>     <AV base="0" add="round(floor((5+sqrt(25+2*AP))/10))"/>
>
> > <attribute id="SO">
> >  <name xml:lang="de">Sozialstatus</name>
> >  <short-name xml:lang="de">SO</short-name>
> >  <AV base="0" base-min="1"/>
> > </attribute>
>
> Gehört nicht hierein! SO ist eine (nicht steigerungsfähige) Eigenschaft
> und sollte auch da hin.
>
> >  <advantages>
> >   <advantage id="lucky" cost="15">
> >    <name xml:lang="de">Glück</name>
> >    <description xml:lang="de">
> >     <p> Ein Held, an dem sprichwörtlich das Glück klebt,
> >      bla, bla, ...  </p>
> >    </description>
> >    <short-description xml:lang="de">
> >     <p> Bis 3-mal am Tag eine Probe <emph>einmal</emph>
> >      wiederholen und günstigeres Ergebnis wählen.</p>
> >    </short-description>
> >   </advantage>
>
> Im Prinzip einverstanden, bis darauf, dass es in HTML <em> statt <emph>
> heißt ;-)

Aber in TeX heißt es emph ... :-). Aber meinetwegen auch
<em>, ist vielleicht gut, solche Sachen HTML-ähnlich zu
halten.

> >  <advantage id="gifted-skill" specialisation="required" cost="oh shit!">
>
> Wieso "oh shit!"? Was spricht dagegen, diesen Vorteil für jede
> Talentgruppe einzeln zu definieren? Allzu viele sind's ja nicht.

Nichts, war nur ein kurzer Anflug von Verzweiflung spät in der Nacht. ;-)

> >   <name xml:lang="de">Begabung für Talent</name>
> >   <prerequisite expr="not Advantage('gifted-skill-group')"/>
>
> Außerdem darf "gifted-skill" nicht doppelt gewählt werden, es sei denn,
> es ist durch die RaKuPro vorgegeben.

Yep. Bei anderen Sachen vermutlich auch, jemand eine Idee dazu?

> >  <advantage id="gifted-skill-group" specialisation="required"
> > cost="ohshit!"> <name xml:lang="de">Begabung für Talentgruppe</name>
> >   <prerequisite expr="not Advantage('gifted-skill')"/>
> >   <action on="once" do="this will be complicated ..."/>
>
> Wird es nicht, wenn man einfach einer Talentgruppe einen ID zuweist,
> kann man sich darauf beziehen.

Trotzdem wird es ein Spaghetti-Ausdruck ... :-(
Die id für Talentgruppen ist ja schon vorgesehen.


>
> >  <advantage id="special-possession" specialisation="required" cost="12">
> >   <name xml:lang="de">Besonderer Besitz</name>
> >  </advantage>
>
> Dieser Vorteil sollte bei den Professionen stehen und direkt aufzählen,
> was man dann bekommt.

Ich denke, dieser Vorteil ist auch für Charaktere gedacht, die
einfach so was besonderes haben wollen, auch wenn's nicht zur
Profession gehört. Daher muß er auch generell definiert werden.

> > <races>
> >  <race id="human">
[...]
> >  <culture id="..."/>
> > </race>
>
> Die Kulturen in der Rasse speichern? Und wenn ich jetzt einen Thorwaler
> spielen will, der im Bornland aufgewachsen ist? Das geht sogar schon bei

Ups, wohl wahr! Besser trennen.

> > <skills>
> >  <skill-category id="combat-skills">
> >   <name xml:lang="de">Kampftalente</name>
> >   <skill-category id="armed-combat">
[...]
> >  </skill-category>
>
> Hmm, ob diese Mehrfachverschachtelung überhaupt nötig ist? Außerdem

Irgendwie muß man jedenfalls darstellen, daß es bei den Talenten
nochmal Unterkategorien gibt. Die werden leider in einigen
Vor- und Nachteilen, Steigernungskosten, usw. auch benutzt. 

> Sonderfertigkeiten sind keine Talente, daher sind sie hier etwas
> unglücklich eingeordnet. Ansonsten einverstanden.

Ja, hab auch schon überlegt, sie eher als Vorteile darzustellen.
Gibt's irgendein Sondertalent, das auch einen TaW oder was ähnliches
hat?

> > <professions>
> >  <profession id="mercenary" cost="10">
> >   <name xml:lang="de">Söldner</name>
> >   <action on="once" do="talent('athletics').SkV.base += 2"/>
> >   <action on="once" do="talent('climbing').SkV.base  += 1"/>
> >   ...
> >   <action on="once" do="skills.add('armor-tolerance-1')"/>
> >  </profession>
> > </professions>
>
> Wäre es nicht viel übersichtlicher, die ID statt talent(ID).SkV.base -
> Schreibweise auch hier zuzulassen?

In diesem Fall nicht, meißt ändert mann ja SkV.effective, nict
SkV.base. Für Talent('ID').SkV.effective hatte ich Talent.SkV
vorgesehen. Nur die ID möchte ich nicht nehmen. Die ID's sollten
zwar eindeutig sein, aber sie sollten schon Bindestiche, etc.
enthalten können, müssen daher auch in Quotes, sonst gibt's
Konflikte mit Operatoren. Falls man strengere Regeln für die
ID's formuliert, nix dagegen. Meinungen? Wie komfortabel soll
man ID's schreiben können?

> >   age="21"
> >   size="90"
> >   weight="80"
>
> Ungünstig. Ich hatte diese Werte extra als eigene Tags definiert, damit
> man die Einheit angeben kann. Viele geben die Größe in "Halbfingern" an,
> andere in Schritt. Einige geben die Größe in Stein an, andere in Unzen etc.

Gern auch als eigene Tags. Ist ein Relikt aus unserem ersten Ansatz.

>
> >   <name xml:lang="de">Alrik</name>
> >   <race id="human"/>
> >   <culture id="mittelreich"/>
>
> Besser hier auch Inhalte zulassen, einige wollen bestimmt einen
> "Dalmatier" spielen, obwohl sie die Werte eines "Garethers" nehmen ;-)

Dann kann da ja noch ein <name>-Tag eingefügt werden. Aber
ich würde vorschlagen, nur bei Bedarf, sonst wird einfach
der Standard ausgelesen und verwendet.

> >  <description>
> >    Alrik ist ... bla, bla
> >  </description>
>
> ...was? :-)

Zu faul, mehr zu schreiben ... ;-)

>
> >  <base-attributes>
> >    <attribute id="MU"><AV base="9" effective="9"/></attribute>
> >    ...
> >  </base-attributes>
>
> Warum einen Effektiv-Wert angeben? Da wären die Modifikatoren besser.
> Was bringt mir der Effektivwert, wenn ich nicht weiß, wie der sich
> berechnet.

Ach ja, zu effective sollte ich noch was schreiben. effektive war
Für so ziemlich alles geplant, damit die ausgerechneten Endwerte
immer im Charakterbogen stehen (für Ausdruck, etc.).

Da Berechnen war vom Ablauf so geplant:
effective = base + add  (falls add vorhanden).
Dann alle actions mit trigger on="calc" ausführen (evtl.
muß da noch was zu, um die richtige Reihenfolge zu 
erwischen).
Fertig.

> >  <level-attributes>
> >    <attribute id="ST"><AV base="1"/></attribute>
> >    ...
[...]
> Wenn ich dich richtig verstehe, willst du die Berechnungsvorschiften aus
> der o.a. Datei lesen, dann brauche ich aber all dies nicht zu speichern
> weil klar ist, wie ich diese Werte erhalte.

Aber irgendwo muß es doch gespeichert werden, ich wollte das
nicht hart coden.

>
> >  <professions>
> >    <profession id="mercenary" veteran="false" cost="10"/>
> >  </professions>
>
> Mehrere Professionen? Veteran? Ähh... ?!

Jau ... in den Myranor Regeln drin, hab so den Verdacht, daß
das dann in Mantel-Schwert auch für Aventurien kommt. Man
kann zwei Professionen haben, oder in einer Profession Veteran
sein (schon bei Generierung). Und das schönste: Die Prof.-Modis,
die dabei doppelt anfallen (bei Veteran alle) werden beim
1,5 fach, nich 2-fach gezählt ... seufz ...

> >  <advantages>
> >    <advantage id="USER-ADVANTAGE-2f394e7a829" cost="10">
>
> Wieso so ein merkwürdiger ID? Warum nicht einfach den Namen dafür
> verwenden, wie wir es hier schon besprochen hatten?

Beispiel: Ein User führt einen neuen Vorteil ein.
Dieser Vorteil sollte 1. in seinen User-Files gespeichert werden,
damit er bei der Charaktergenerierung ausgewählt werden kann.
2. In jedem Charakter gespeichert werden, damit Charaktere
portabel sind, ohne jedesmal alle eigenen Definitionen
beizupacken (das alte DSA-Tools Problem). Das ist vor allem
beim Tauschen von Persönlichkeiten, NSC, etc. SEHR wichtig.
Situation: Ein zweiter User führt einen gleichnamigen Vorteil
bei sich ein, aber mit völlig anderen Eigenschaften. Wenn
Dann zwei Charaktere, einer von jedem, auf dem selben System
zusammenkommen, gibts einen bösen Konflikt.
Dieses Beispiel halte ich durchaus nicht für rein akademisch,
sowas wird häufig vorkommen.

> >    <name xml:lang>Schwertmeister</name>
> >    <action on="calc" do="skill('swords').AT += 1"/>
> >    <action on="calc" do="skill('swords').PA += 2"/>
> >  </advantage>
> >  <advantage id="lucky"/>
>
> Wenn man einen Vorteil nicht modifiziert, wird er nur als Referenz
> übernommen? OK, leuchtet ein und spart Platz.

Ja, auch bei anderen Dingen. Idee war: Was nicht variabel ist,
kommt nicht in den Bogen.

> >  <skills>
> >    <skill id="swords">
> >    <SkV base="4" effective="4"/>
>
> Wenn effektive==base ist, brauchen wir's nicht anzugeben, oder? ;-)

Effektive war überall geplant. Man weiß ja nie, was die ein oder
andere <action> so tut. Damit weiß man auch ohne komplexe Checks,
wo der Spiel- und Druckrelevante Wert steht.

> >    <AT base="13" effective="14"/>
> >    <PA base="11" effective="13"/>
>
> Schlecht, lieber:
>
>       <AT base="3" add="AT_BASE"/>
>       <PA base="2" add="PA_BASE"/>

Ja, schön! 8-)

> >  </skill>
> >  <skill
> >    id="armor-tolerance-1" spec="plate-armor"
> >  </skill>
>
> Dazu habe ich mir schon Gedanken gemacht. Wir sollten alle
> Ausrüstungsgegenstände in Klassen einteilen, wobei ein Gegenstand auch
> gleichzeitig mehreren Klassen angehören kann. Die Klassen wiederrum sind
> hierarchisch geordnet, damit lässt sich die Rüstungsgewohnung wunderbar

Ack! Obwohl - reicht vielleicht eine einfache Hierarchie, oder
gibts Fälle, wo ein Gegenstand wirklich in mehrere Klassen muß?

cu
Oli

Re: [DSA Manager] DSAdmin Datenstruktur

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

Hi Oliver!

Oliver Schulz wrote:

>>Mal zur Verdeutlichung mein DOCTYPE für die Charaktere:
>>   -//FANPRO//DTD DSA Charakter 1.0//DE
>>und als Gegenbeispiel mal der von XHTML:
>>Fällt dir was auf? ;-)
>>
> 
> Das hat aber mit dem Inhalt ja nix zu tun. Deutsche
> XHTML Seiten können auch doctype -//W3C//DTD XHTML 1.1//EN
> haben.


Stimmt, denn das DE oder EN bezieht sich auf die Sprache, in der die 
Tag-Namen geschrieben wurden.

> Die Tags und Attribute würde ich trotzdem in Englisch halten (man
> kann ja bei Fanpro mal anfragen), das sind nur ein paar. Was
> allerdings die ID's angeht, sollte man in der Tat überlegen, ob
> man die nicht in Deutsch läßt. Die ID's sind ja eh sprachunabhängig,
> könnten auch nummern sein, ist ja nur text um's auf Dateiebene
> übersichtlich zu halten.


Aha, und das gilt für Tags nicht? ;-)

 
 
> Auch eine URL ist gültiger URI und daher nicht nur eine Notlösung.
> An der URL kann schließlich auch etwas sinnvolles liegen (DTD,
> Schema, Dokumentation).


So war's auch ursprünglich gedacht, aber wie wir wissen, ist daraus 
nichts geworden... :-|

> Klar kann man auch eine URN nehmen, hätte ich
> nix dagegen. Leider bauen aber einige XML-Parser Mist (und ich fürchte,
> unser C-Parser gehört dazu), die unbedingt eine gültige URL sehen
> wollen. :-(


Ich bin dafür, dass wir sowohl unter Java, als auch unter C++ Xalan von 
xml.apache.org einsetzen, der kann nicht nur URNs, vor allem stellen wir 
dann so sicher, dass wir dieselben Routinen zum Lesen und Schreiben der 
XML-Dateien verwenden.

 
>>>   <short-name xml:lang="de">MU</short-name>
>>>
>>Der short-name sollte der ID sein, daher ist diese Zeile eigentlich
>>unnötig.
>>
> IMHO nicht, denn eine ID ist sprachunabhängig, während der
> short-name in verschiedenen Sprachen auf Char.Bögen auftauchen
> kann.
 

Ach, so meintest du das. Dann ist es klar.

 
> Aber in TeX heißt es emph ... :-). Aber meinetwegen auch
> <em>, ist vielleicht gut, solche Sachen HTML-ähnlich zu
> halten.


Am besten bei längeren Beschreibungen einfach den Namespace auf XHTML 
festlegen, dann brauchen wir uns darüber keine großen Gedanken zu machen.


>>Außerdem darf "gifted-skill" nicht doppelt gewählt werden, es sei denn,
>>es ist durch die RaKuPro vorgegeben.
> 
> Yep. Bei anderen Sachen vermutlich auch, jemand eine Idee dazu?


Ja, laut meinem Klassen-Vorschlag (siehe andere Mail), kann man eine 
Klasse für Begabungen definieren:

   ...
    |--> Begabung/Unfähigkeit
    |     |
    |     |--> Talent
    |     |
    |     \--> Talentgruppe
   ...

Die Begabungen werden dann einfach der Klasse "Vorteil" (bzw. 
"Nachteil") zugeordner, oder eben nicht, wenn sie fest zur Rasse oder 
Profession gehören:

  <advantage id="NatUnfähigkeit" class="Nachteil BegTalent">
    ...
  </advantage>

Jetzt die Rassendefinition für Zwerge:

  <race id="RasZwerg" class="Rasse">
    ...
    <advantage ref="NatUnfähigkeit" class="BegTalent">
      <name xml:lang="de">Unfähigkeit zum Schwimmen</name>
      <action on="once" do="TakSchwimmen--"/>
      <action on="once" do="cost(TakSchwimmen)++"/>
    </advantage>
  </race>

class für die Schwimmen-Unfähigkeit wurde überschrieben, damit es nicht 
mehr als Nachteil zählt. Wir müssen uns nur eine geeignete Notation 
überlegen, damit es eindeutig bleibt, aber ich denke, das ergibt sich 
schon durch das ref-Attribut. Normalerweise wird die Klasse ergänzt, 
aber bei ref-Attribut wird die ursprüngliche Klasse übernommen und evtl. 
*ersetzt*, oder?


>>> <advantage id="special-possession" specialisation="required" cost="12">
>>>  <name xml:lang="de">Besonderer Besitz</name>
>>> </advantage>
>>>
>>Dieser Vorteil sollte bei den Professionen stehen und direkt aufzählen,
>>was man dann bekommt.
> 
> Ich denke, dieser Vorteil ist auch für Charaktere gedacht, die
> einfach so was besonderes haben wollen, auch wenn's nicht zur
> Profession gehört. Daher muß er auch generell definiert werden.


Gut, aber dafür gibt es eine viel bessere Regel, nämlich die SO*SO*SO 
Silbertaler, die man zu beginn bekommt ;-)

 
>>Hmm, ob diese Mehrfachverschachtelung überhaupt nötig ist? Außerdem
> 
> Irgendwie muß man jedenfalls darstellen, daß es bei den Talenten
> nochmal Unterkategorien gibt. Die werden leider in einigen
> Vor- und Nachteilen, Steigernungskosten, usw. auch benutzt. 


Ja, aber das Thema hat sich jetzt durch die Klassen erledigt.

 
>>Sonderfertigkeiten sind keine Talente, daher sind sie hier etwas
>>unglücklich eingeordnet. Ansonsten einverstanden.
> 
> Ja, hab auch schon überlegt, sie eher als Vorteile darzustellen.
> Gibt's irgendein Sondertalent, das auch einen TaW oder was ähnliches
> hat?
 
Nein, es sei denn, du zählst die unterschiedlichen Stufen als TaW.


>>>  <name xml:lang="de">Alrik</name>
>>>  <race id="human"/>
>>>  <culture id="mittelreich"/>
>>>
>>Besser hier auch Inhalte zulassen, einige wollen bestimmt einen
>>"Dalmatier" spielen, obwohl sie die Werte eines "Garethers" nehmen ;-)
> 
> Dann kann da ja noch ein <name>-Tag eingefügt werden. Aber
> ich würde vorschlagen, nur bei Bedarf, sonst wird einfach
> der Standard ausgelesen und verwendet.


Ja, genau, dann aber:

   <race ref="human"/>
   <culture ref="mittelreich">
     <name xml:lang=">Dalmatierin</name>
   </culture>

 
> Ach ja, zu effective sollte ich noch was schreiben. effektive war
> Für so ziemlich alles geplant, damit die ausgerechneten Endwerte
> immer im Charakterbogen stehen (für Ausdruck, etc.).


Achso, für den XLST-Prozess... OK, das sehe ich ein. Ich bin aber 
dagegen, solche Anweisungen im Programm zu verwenden. Hier sollten die 
lieber redes Mal ausgerechnet werden, weil der Test, wo sich jetzt 
abgeleitete Werte durch die Steigerung eines Wertes verändern, mit 
Sicherheit viel komplexer ist.

 
> Da Berechnen war vom Ablauf so geplant:
> effective = base + add  (falls add vorhanden).
> Dann alle actions mit trigger on="calc" ausführen (evtl.
> muß da noch was zu, um die richtige Reihenfolge zu 
> erwischen).
> Fertig.


So, wie's momentan aussieht, kommen wir wohl ohne spezielle Reihenfolge 
aus. Notfalls könnte man ja Prioritäten zuordnen.

 
>>Mehrere Professionen? Veteran? Ähh... ?!
> 
> Jau ... in den Myranor Regeln drin, hab so den Verdacht, daß
> das dann in Mantel-Schwert auch für Aventurien kommt. Man
> kann zwei Professionen haben, oder in einer Profession Veteran
> sein (schon bei Generierung). Und das schönste: Die Prof.-Modis,
> die dabei doppelt anfallen (bei Veteran alle) werden beim
> 1,5 fach, nich 2-fach gezählt ... seufz ...


HMMMM :-S

 
> Beispiel: Ein User führt einen neuen Vorteil ein.
> Dieser Vorteil sollte 1. in seinen User-Files gespeichert werden,
> damit er bei der Charaktergenerierung ausgewählt werden kann.
> 2. In jedem Charakter gespeichert werden, damit Charaktere
> portabel sind, ohne jedesmal alle eigenen Definitionen
> beizupacken (das alte DSA-Tools Problem). Das ist vor allem
> beim Tauschen von Persönlichkeiten, NSC, etc. SEHR wichtig.
> Situation: Ein zweiter User führt einen gleichnamigen Vorteil
> bei sich ein, aber mit völlig anderen Eigenschaften. Wenn
> Dann zwei Charaktere, einer von jedem, auf dem selben System
> zusammenkommen, gibts einen bösen Konflikt.
> Dieses Beispiel halte ich durchaus nicht für rein akademisch,
> sowas wird häufig vorkommen.
 
Na, dann... Aber wie willst du sicherstellen, dass kein Hexcode doppelt vorkommt?


> Ack! Obwohl - reicht vielleicht eine einfache Hierarchie, oder
> gibts Fälle, wo ein Gegenstand wirklich in mehrere Klassen muß?

Ja, z.B. der in der anderen Mail angesprochene Lederhelm. Ich muss 
wissen, dass es Leder ist (wegen der Rüstungskombination), und ich muss 
wissen, dass es ein Helm ist (jeder nur ein Kreu... äh... Helm <g>)

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

Re: [DSA Manager] DSAdmin Datenstruktur

[Oliver S. <os...@ep...>]

Hi!

> > man die nicht in Deutsch läßt. Die ID's sind ja eh sprachunabhängig,
> > könnten auch nummern sein, ist ja nur text um's auf Dateiebene
> > übersichtlich zu halten.
>
> Aha, und das gilt für Tags nicht? ;-)

Nicht in der selben Weise, wie für die ID's. Eine ID könnte
tatsächlich auch numerisch sein, für einen Tag oder ein
Attribut wär's aber wirklich Blödsinn. Das sind schon verschiedene
Dinge. Bei einem internationalisierten System sollten zumindest
die Definition der Datenstruktur und ihre Elemente englisch sein.

> Ich bin dafür, dass wir sowohl unter Java, als auch unter C++ Xalan von
> xml.apache.org einsetzen, der kann nicht nur URNs, vor allem stellen wir
> dann so sicher, dass wir dieselben Routinen zum Lesen und Schreiben der
> XML-Dateien verwenden.

Xalan ist eine XSLT-Engine, kein Parser. Der zugehörige Parser
ist defaultmäßig Xerces. Den empfehle ich uneingeschränkt für
Java, aber nicht für C++. Die C++ library ist mehrere MB groß,
wenn man das IBM-Derivat (XML4C) mit Unicode Klassen nimmt gleich
10-20 MB. Da fahren wir mit libxml2 (<1MB) wirklich besser!
Wir brauchen nicht den selben Parser, und Xerces C kann eh nicht
genau das Gleiche wie Xerces Java.

> >>>   <short-name xml:lang="de">MU</short-name>
> >>
> >>Der short-name sollte der ID sein, daher ist diese Zeile eigentlich
> >>unnötig.
> >
> > IMHO nicht, denn eine ID ist sprachunabhängig, während der
> > short-name in verschiedenen Sprachen auf Char.Bögen auftauchen
> > kann.
>


> >>> <advantage id="special-possession" specialisation="required" cost="12">
[...]
> Gut, aber dafür gibt es eine viel bessere Regel, nämlich die SO*SO*SO
> Silbertaler, die man zu beginn bekommt ;-)

:-)
Der Vorteil soll erzielen, das die Leute nicht am Anfang
alles kaufen können (Oder anders gesagt: Nur mit Geld sind
manche Dinge nicht zu haben, man braucht Beziehungen, etc.
Das kostet GP).

> > Irgendwie muß man jedenfalls darstellen, daß es bei den Talenten
> > nochmal Unterkategorien gibt. Die werden leider in einigen
> > Vor- und Nachteilen, Steigernungskosten, usw. auch benutzt.
>
> Ja, aber das Thema hat sich jetzt durch die Klassen erledigt.

Ich denke nicht, siehe meine Mail zum Klassenkonzept.
Besser, man stellt solche Strukturen direkt dar.

> So, wie's momentan aussieht, kommen wir wohl ohne spezielle Reihenfolge
> aus. Notfalls könnte man ja Prioritäten zuordnen.

Wollen wirs hoffen! :-)

> > Dann zwei Charaktere, einer von jedem, auf dem selben System
> > zusammenkommen, gibts einen bösen Konflikt.
[...]
> Na, dann... Aber wie willst du sicherstellen, dass kein Hexcode doppelt
> vorkommt?

Kein Problem: MD5-Hash über die gesamte Definition. Wem
das nicht reicht, der mag noch eine Zufallszahl reinbauen.
Wer dann immer noch Konflikte befürchtet, den laß ich
meinen Lottoschein ausfüllen ... ;-)

> > gibts Fälle, wo ein Gegenstand wirklich in mehrere Klassen muß?
>
> Ja, z.B. der in der anderen Mail angesprochene Lederhelm. Ich muss
> wissen, dass es Leder ist (wegen der Rüstungskombination), und ich muss

Besser Material und Typ der Rüstung getrennt speichern.

cu
Oli

Re: [DSA Manager] Formatierungsflags

[Matthias W. <Mat...@gm...>]

Oliver Schulz wrote:
> 
> > Im Prinzip einverstanden, bis darauf, dass es in HTML <em> statt <emph>
> > heißt ;-)
> 
> Aber in TeX heißt es emph ... :-). Aber meinetwegen auch
> <em>, ist vielleicht gut, solche Sachen HTML-ähnlich zu
> halten.

Eigentlich wäre ich auch dafür, emph zu nehmen. Ich hab euch ja schon
die Geschichte von der Abenteuer-erstellung erzählt. Da brauchen wir
zweifelsohne Gliederungssachen, und da sollten wir uns denke ich mal
eher an TeX orientieren, weil einem da die Gliederungsbefehle besser ins
Ohr gehen als dieses <p><i><b> zeug von HTML. Mag ja sein, dass mehr
Leute HTML können, als TeX, aber an denen will ich mich ehrlich gesagt
nicht orientieren... Ich bin da eher für verständliche Befehle, auch
wenn sie etwas länger sind.

Dann kann man ja auch gleich in die Hintergrundstory des Helden solche
Flags setzten (z.B. auch Meitserinfos, die andere Spieler nicht erfahren
dürfen... Pakte z.B. *g*) Ich liste mal ein wenig auf:
chapter
section
subsection
subsubsection
meisterinf
allgemeininf
<emph>
<bf>
...
natürlich kann man alle unsere anderen Dinger auch reinbringen, z.B.
<Charakter id="CharAlrik/>, vielleich hier noch ein Attribut
detail="short/medium/full" der angibt ob Alrik nur als so ein
totzukloppender Straßenräuber ins Abenteuer eingefügt wird oder full,
wenn er ins dramatis personae soll...

Gruß
Matthias

Re: [DSA Manager] Formatierungsflags

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

Hi Matthias!

Matthias Wurm wrote:

> Eigentlich wäre ich auch dafür, emph zu nehmen. Ich hab euch ja schon
> die Geschichte von der Abenteuer-erstellung erzählt. Da brauchen wir
> zweifelsohne Gliederungssachen, und da sollten wir uns denke ich mal
> eher an TeX orientieren, weil einem da die Gliederungsbefehle besser ins
> Ohr gehen als dieses <p><i><b> zeug von HTML. Mag ja sein, dass mehr
> Leute HTML können, als TeX, aber an denen will ich mich ehrlich gesagt
> nicht orientieren... Ich bin da eher für verständliche Befehle, auch
> wenn sie etwas länger sind.

<em> steht doch für emphasis, wie das \emph von LaTeX auch. Bei 
Xtory-System von http://www.proc.org/stories/ erstelle ich acht 
unterschiedliche Formate auf der Basis von XLST und gehe im Grunde 
genommen von HTML aus. Wollt ihr mal ein Beispiel haben? ;-)

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

Re: [DSA Manager] DSAdmin Datenstruktur

[Matthias W. <Mat...@gm...>]

Oliver Schulz wrote:
> 
> > >  <advantage id="gifted-skill" specialisation="required" cost="oh shit!">
> >
> > Wieso "oh shit!"? Was spricht dagegen, diesen Vorteil für jede
> > Talentgruppe einzeln zu definieren? Allzu viele sind's ja nicht.
> 
> Nichts, war nur ein kurzer Anflug von Verzweiflung spät in der Nacht. ;-)

Falls ich hier einen Vorschlag mach dürfte: Solche Auswahl-Sachen kommen
ja oft vor, und wenn man dann aber ein separates Talent für jede
Auswahlmöglichkeit einfügt, wird das in der Gesamtliste der Vor- und
Nachteile schnell unschön:

Daher

<advantage id="gifted-skill">
  <name xml:lang="de">Begabung für Talent</name>
<choose>
  <selection text="Schwimmen" cost="12"/>
  <selection text="Klettern" cost="12"/>
  <selection text="Schwerter" cost="15"/>
</choose>

Ich hab mal die beiden Attribute weggenommen, da mans ja so machen
könnte, dass fehlende Kosten automatisch eine notwendige Spezialisierung
signalisieren

... ist natürlich blöd, weil wir - auch wenn die Kosten nur von der
Gruppe abhängig sind, dem Programm das ja nicht mitteilen können, dass
es aber eigentlich nur ein _einziges_ Talent ist, dass er steigern soll
(geht natürlich schon, aber das sind dann alles so Spezialtricks, die
wahrscheinlich nur auf dieses eine Ding anwendbar sind)

ne andere Möglichkeit wäre aber die:

<advantage id="gifted-skill" specialisation="required">
  <name xml:lang="de">Begabung für Talent</name>
  <choose>
   <selection text="Körperliche Talente" cost="12"/>
   <selection text="Kampftalente" cost="15"/>
   ...
  </choose>
  <prerequisite expr="not Advantage('gifted-skill-group')"/>
  <action on="once" do="Talent(spec).TaW.base += 1"/>
  <action on="once" do="Talent(spec).TaW.cost_factor -= 1"/>
</advantage>

Hier hab ich spec. wieder reingenommen, was heißt, ich wähle zwar was
aus, aber mein _eigentlicher_ Wert ist was anderes, siehe z.B. Angs vor
[]. Die Auswahl wäre häufiges Auftreten / seltenes Auftreten, aber der
eigentliche Wert wäre "Krieger mit Topfhaarschnitt", den man selber in
ein Textfeld eingibt (das dann in spec reinkommt). Dann ist nämlich der
daraufhin folgende Code immer noch gültig... Ok, ist zwar blöd, wenn man
dann die Gruppe auswählt und dann noch das Talent EINGEBEN muss.
Vielleicht kann man sich ja dafür noch was überlegen. Betrachtet dann
diesen Vorschlag einfach mal als den für die "erste Komplexitätsstufe"
*g* Das mit der Angst vor.... könnte man damit ja schonmal realisieren.
Vielleicht habt ihr einen guten Vorschlag, wie man das gekonnt ergänzen
kann, um auch dies Auswahl Gruppe->Talent zu ermöglichen.
Vielleicht ja
   <selection text="Körperliche Talente" cost="12">
    <choose>
      wobei man hier alle Childs der Talentgruppen, also alle Talente
als selection reinnimmt. Aber 	das geht in XML so nicht, oder ?
    </choose>
   </selection>




Gruß
Matthias

Re: [DSA Manager] DSAdmin Datenstruktur

[Andreas H. <ahu...@gm...>]

Hi,

also wenn ich das richtig sehe gibt es ein Problem mit dem Vorteil 
Talent/Talentfruppe.
Wieso muss XML das beruecksichtigen....

Matthias Wurm wrote:

>Oliver Schulz wrote:
>
>>>> <advantage id="gifted-skill" specialisation="required" cost="oh shit!">
>>>>
>>>Wieso "oh shit!"? Was spricht dagegen, diesen Vorteil für jede
>>>Talentgruppe einzeln zu definieren? Allzu viele sind's ja nicht.
>>>
>>Nichts, war nur ein kurzer Anflug von Verzweiflung spät in der Nacht. ;-)
>>
>
>Falls ich hier einen Vorschlag mach dürfte: Solche Auswahl-Sachen kommen
>ja oft vor, und wenn man dann aber ein separates Talent für jede
>Auswahlmöglichkeit einfügt, wird das in der Gesamtliste der Vor- und
>Nachteile schnell unschön:
>
>Daher
>
><advantage id="gifted-skill">
>  <name xml:lang="de">Begabung für Talent</name>
><choose>
>  <selection text="Schwimmen" cost="12"/>
>  <selection text="Klettern" cost="12"/>
>  <selection text="Schwerter" cost="15"/>
></choose>
>
>Ich hab mal die beiden Attribute weggenommen, da mans ja so machen
>könnte, dass fehlende Kosten automatisch eine notwendige Spezialisierung
>signalisieren
>
>... ist natürlich blöd, weil wir - auch wenn die Kosten nur von der
>Gruppe abhängig sind, dem Programm das ja nicht mitteilen können, dass
>es aber eigentlich nur ein _einziges_ Talent ist, dass er steigern soll
>(geht natürlich schon, aber das sind dann alles so Spezialtricks, die
>wahrscheinlich nur auf dieses eine Ding anwendbar sind)
>
hmmmm, ich schreibe mal meine idee

<advantage id="BegabungFuerTalent" specialisation="required" cost="Talent(spec).TaW.cost_factor * 3">
	<name xml:lang="de">Begabung für Talent</name>
	<prerequisite expr="not Advantage('BegabungFuerTalentGruppe')"/>
	<action on="once" do="Talent(spec).TaW.base += 1"/>
	<action on="once" do="Talent(spec).TaW.cost_factor -= 1"/>
</advantage>

Sprich man waehlt ein Talent und fertig. ;)


<advantage id="BegabungFuerTalentgruppe" specialisation="required" cost="TalentGroup(spec).cost_factor">	
	<name xml:lang="de">Begabung für Talentgruppe</name>
	<prerequisite expr="not Advantage('BegabungFuerTalent')"/>
	<action on="once" do="TalentGroup(spec).cost_factor -=1"/>
</advantage>

Das tolle sind hier leider wieder mal die Waffentalente...
Was bei den einzeltalenten noch geht ist bei der Talentgruppe etwas 
schwieriger...
man muesste das so formulieren das alle Talente in einer Gruppe um eins 
in den steigerungskosten nach unten korrigiert werden. Ich habe aber 
keine Idee wie man das in XML formulieren soll.
Aber ich denke das sowas besser im programm abgefangen wird, wir wollen 
ja ein tool fuer dsa schreiben und keins was allgemeingueltig jede 
XML-Datei parsen kann und damit quasi auch fuer D&D oder GURPS laufen 
wuerde wenn man dafuer eine saubere XML-Datei hinbekommt....

Im programm muesste dann wirklich beim erstellen des Helden ueberprueft 
werden ob BegabungFuerTalent gewaehlt wurde oder nicht. Ich finde diese 
vorgehensweise persoenlich besser.
Denn ansonsten koennen wir sofort XML  -> Java machen  ;-)
Desweiteren ist es doch egal wo was in einer XML datei steht, wie soll 
man dann Probleme loesen bei denen es auf eine Reihenfolge ankommt...
zB. Vorteil Herausragende Eigenschaft Konstitution mit der Berechnung 
der LE...
Da sollte man lieber die LE vom Programm berechnen lassen und diese dann 
in der Held.xml ablegen. (aufgeteilt in eLE (LE durch Eigenschaften) und 
xLE (LE durch EXP) )

Das bedeutet natuerlich das wir uns fuer jeden Vorteil und Nachteil der 
sich auf Werte beim Helden auswirkt etwas programmieren muessen, aber 
ist es nicht egal ob wir uns beim erstellen der XML total verkrampfen 
oder lieber 3 zeilen mehr beim Code...


<advantage id="BegabungFuerTalentgruppe" specialisation="required" cost="TalentGroup(spec).cost_factor">	
	<name xml:lang="de">Begabung für Talentgruppe</name>
	<prerequisite expr="not Advantage('BegabungFuerTalent')"/>

	<action on="once" do="TalentGroup(spec).cost_factor -=1"/>

waere dann ne Schleife die bei allen Talenten der TalentGroup(spec) den 
cost_factor um 1 senkt und nicht nur den Factor der Gruppe...

</advantage>



>ne andere Möglichkeit wäre aber die:
>
><advantage id="gifted-skill" specialisation="required">
>  <name xml:lang="de">Begabung für Talent</name>
>  <choose>
>   <selection text="Körperliche Talente" cost="12"/>
>   <selection text="Kampftalente" cost="15"/>
>   ...
>  </choose>
>  <prerequisite expr="not Advantage('gifted-skill-group')"/>
>  <action on="once" do="Talent(spec).TaW.base += 1"/>
>  <action on="once" do="Talent(spec).TaW.cost_factor -= 1"/>
></advantage>
>
>Hier hab ich spec. wieder reingenommen, was heißt, ich wähle zwar was
>aus, aber mein _eigentlicher_ Wert ist was anderes, siehe z.B. Angs vor
>[]. Die Auswahl wäre häufiges Auftreten / seltenes Auftreten, aber der
>eigentliche Wert wäre "Krieger mit Topfhaarschnitt", den man selber in
>ein Textfeld eingibt (das dann in spec reinkommt). Dann ist nämlich der
>daraufhin folgende Code immer noch gültig... Ok, ist zwar blöd, wenn man
>dann die Gruppe auswählt und dann noch das Talent EINGEBEN muss.
>Vielleicht kann man sich ja dafür noch was überlegen. Betrachtet dann
>diesen Vorschlag einfach mal als den für die "erste Komplexitätsstufe"
>*g* Das mit der Angst vor.... könnte man damit ja schonmal realisieren.
>Vielleicht habt ihr einen guten Vorschlag, wie man das gekonnt ergänzen
>kann, um auch dies Auswahl Gruppe->Talent zu ermöglichen.
>Vielleicht ja
>   <selection text="Körperliche Talente" cost="12">
>    <choose>
>      wobei man hier alle Childs der Talentgruppen, also alle Talente
>als selection reinnimmt. Aber 	das geht in XML so nicht, oder ?
>    </choose>
>   </selection>
>


Gruss
Andreas

Re: [DSA Manager] DSAdmin Datenstruktur

[Oliver S. <os...@ep...>]

Hi!

> Im programm muesste dann wirklich beim erstellen des Helden ueberprueft
> werden ob BegabungFuerTalent gewaehlt wurde oder nicht. Ich finde diese
> vorgehensweise persoenlich besser.

Wir sollten es unterlassen, das hart zu coden. Klar, dies
ist ein schwieriger Fall, aber es wird nicht der einzige
bleiben!

> Denn ansonsten koennen wir sofort XML  -> Java machen  ;-)
> Desweiteren ist es doch egal wo was in einer XML datei steht, wie soll
> man dann Probleme loesen bei denen es auf eine Reihenfolge ankommt...

Es ist nicht unbedingt egal. Die Reihenfolge von Attributen ist
beliebig, ja, die von Elementen aber mitnichten. Man kann
Sequenzen in XML problemlos darstellen.

> zB. Vorteil Herausragende Eigenschaft Konstitution mit der Berechnung
> der LE...

> Das bedeutet natuerlich das wir uns fuer jeden Vorteil und Nachteil der
> sich auf Werte beim Helden auswirkt etwas programmieren muessen, aber
> ist es nicht egal ob wir uns beim erstellen der XML total verkrampfen
> oder lieber 3 zeilen mehr beim Code...

Es wird unübersichtlich, und da wir mit mehreren Sprachen
parallel arbeiten, muß man dann immer zweimal anpassen,
und dann aufpassen, daß man konsistent bleibt ... nicht
schön. Wir kriegen das in den Daten hin!
Aber erstmal machen wir jetzt das Sammeln fertig, schlage
ich vor, sonst dreht sich das alles im Kreise.

cu
Oli

Re: [DSA Manager] Formatierungsflags

[Oliver S. <da...@we...>]

> <em> steht doch für emphasis, wie das \emph von LaTeX auch. Bei
> Xtory-System von http://www.proc.org/stories/ erstelle ich acht
> unterschiedliche Formate auf der Basis von XLST und gehe im Grunde
> genommen von HTML aus. Wollt ihr mal ein Beispiel haben? ;-)

Es ist zwar eigentlich nicht so weltbewegend, wie wirs nennen. Ein
Punkt ist da aber: Zu sehr HTML-like ist schlecht, weil HTML nicht
sauber hierarchisch strukturiert. Das ist XML nicht angemessen.
Also nicht

<h1>bla</h1>

<p> Text <em>Text</em> Text</p>
<p> Text Text Text</p>

<h2>bla bla</h2>

<p> Text Text Text</p>
<p> Text Text Text</p>

Sondern besser

<section>
	<title>bla</title>

	<p> Text Text Text</p>
	<p> Text Text Text</p>

	<subsection>
		<title>bla bla</title>

		<p> Text <em>Text</em> Text</p>
		<p> Text Text Text</p>
	</subsection>
</section>


Das ist strukturell besser und läßt mehr Möglichkeiten für
XSLT & Co. offen.

Vorschlag: Strukturelemente (section, ...) aus TeX (die Bezeichner
sind eingängig), der Rest (p, e, strong, ...) aus HTML (kennen viele),
aber auf eine sinnvolle Auswahl beschränkt.
Dazu dann noch ein paar RPG-spezifische Dinge (slinfo, und so).

cu
Oli

Re: [DSA Manager] Formatierungsflags

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

Hi Oliver!

> Sondern besser
> 
> <section>
> 	<title>bla</title>
> 
> 	<p> Text Text Text</p>
> 	<p> Text Text Text</p>
> 
> 	<subsection>
> 		<title>bla bla</title>
> 
> 		<p> Text <em>Text</em> Text</p>
> 		<p> Text Text Text</p>
> 	</subsection>
> </section>


Genau, so ähnlich mache ich's bei Xtory ja auch, allerdings geht das in 
HTML per <div>-Tag auch ;-)

 
> Vorschlag: Strukturelemente (section, ...) aus TeX (die Bezeichner
> sind eingängig),


Klar, aber die Anordnung entspricht den HTML-Tags für Überschriften. In 
dieser Hinsicht ist TeX sogar noch unübersichtlicher, weil da überhaupt 
nicht strukutiert wird (von den LaTeX-Environments mal abgesehen, die 
aber nur eine Formatierungsgliederung, keine logische Gliederung ergeben).

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

Re: [DSA Manager] Formatierungsflags

[Oliver S. <da...@we...>]

Hi Alex!

> Genau, so ähnlich mache ich's bei Xtory ja auch, allerdings geht das in
> HTML per <div>-Tag auch ;-)

Ok: div, subdiv, ... ;-)
Aber mal ernsthaft:

	<div>
		<h1>...</h1>
		<div>
			<h2> ...

Neeee ....

> > Vorschlag: Strukturelemente (section, ...) aus TeX (die Bezeichner
> > sind eingängig),
>
> Klar, aber die Anordnung entspricht den HTML-Tags für Überschriften. In
> dieser Hinsicht ist TeX sogar noch unübersichtlicher, weil da überhaupt
> nicht strukutiert wird (von den LaTeX-Environments mal abgesehen, die

Haarspalter! ;-)
Ich meinte natürlich LaTeX, nicht TeX, TeX hat kein section, ...
Es ging mit auch gar nicht um die Strukturierung von LaTeX
Dokumenten, sonden darum, daß section & co. geeignete Bezeichner sind.

cu
Oli