dsaman-list Mailing List for DSA Manager (Page 26)
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: Matthias W. <Mat...@gm...> - 2001-11-19 10:36:17
|
Tilmann Kuhn wrote: > Oder auch: > > In irgend einer talente.xml oder so: > <dsaman:talente> > <dsaman:talent id="fussball"> > .... > </dsaman:talent> > </dsaman:talente> > > In derm charkter.xml: > <dsaman:charakter xmlns:xlink="http://www.w3.org/1999/xlink"> > ... > <dsaman:talente> > <dsaman:talent xlink:type="simple" > xlink:href="talente.xml#xpointer(id("fussball"))"> > .... <!-- falls noetig --> > </dsaman:talent> > </dsaman:talente> > ... > <dsaman:charakter> > > Klarer Nachteil aller dieser Verfahren ist natuerlich, der Geschwindigkeitsverlust, > > der durch das Aufloesen der Links entsteht. Yupp, quasi genauso wie dieses zweite Bsp hab ich mir das vorgestellt. Das zusammenschmeißen in eine Datei ist nicht so übersichtlich, daher würde ich davon abraten, aber ob das auseinandertrennen von der Geschwindigkeit her noch übler wird, kann ich natürlich nicht beurteilen. Tilmann, was sagt denn XMLDB dazu ? Da hast du ja sowas in der Richtung erwähnt ?! Gruß Matthias |
From: Matthias W. <Mat...@gm...> - 2001-11-19 10:27:20
|
Andreas Hugenroth wrote: > > > > >Genauso bei Talenten: > >Im Grunde bräuchten wir pro Talent nur die ID und den TaW, mehr nicht, > >da anhand der ID ja schon _alles_ (Name, Probe, Kategorie, > >Steigerungsspalte) beschrieben ist. Zwar werden wir hier aufgrund > >solcher Vorteile wie "Begabung für... Unfähigkeit für..." noch ein paar > >mehr Infos zu den Talenten geben müssen, die aber wohl in der Regel > >EMPTY sein werden, dazu gehören dann solche Regelungen zur > >Steigerungsmodifikation (wie die von dir oben genannten) > > > Und wie willst du diese Infos nun gestallten ? Das laueft dann doch auf > meine Misch-Idee hinaus. Es gilt so lange default bis die emptyfelder > einen Wert haben. > Nur du musst dann fuer sehr viele Punkte diese Sonderfelder mitnehmen. > Nimm zb den Zweihaender fuer 300 Dukaten der mit einem normalen > Zweihaender nur noch den Namen gemeinsam hat. > > > > >Die von dir angesprochene Freiheit lässt sich ja ohne Probleme mit dem > >von Tilmann angesprochenen Prinzip vereinigen (wie eben beschrieben). > >Und im Sinne von sauberer Programmierung sollten wir das, was sich auf > >einen Kernpunkt reduzieren lässt, auch reduzieren, und nicht > >überflüssigerweise woanders noch mitschleppen (wie z.B. den Namen der > >Rasse, des Talents oder ähnliches) > > > Das ist schon richtig, ich komme aus der Datenbankecke und bin > garantiert kein Fan von doppelt und dreifachspeicherung ein und > derselben daten nur um Sonderfaelle abzufangen. > Hmm wir koennen natuerlich auch versuchen solche Modifikatoren vor der > Steigerung/ Ausdruck aufloesen zu lassen. > Dann muss der Zweihaender als neue Waffe aufgenommen werden und zb mit > der ID 2handfuer300D laufen ... > > Und je laenger ich darueber nachdenke ist das sicher auch ein guter Weg. > > suche passende SKT-Spalte > if HerausragendeTalentGruppe=Talentgruppegewaehlt > SKT-Spalte-- > fi > usw usw > > D.h aber das wir jeden neuen Vorteil der sisch auf steigerbare Werte und > deren Kosten auswirkt coden muessen, oder sieht da jemand einen anderen > Weg? Nein nein, das wäre ja vollkommen ab von unserem Weg. 1.) Solche Sachen wie Zweihänder für 300 D können ja von Zöllen (die Herkunftsfaktoren aus Kaiser Retos Waffenkammer) kommen, oder dadurch, dass sie Spezialfertigungen sind, die dann auch noch mehr TP machen etc. Zwar wollen wir solche Sachen wohl erstmal nicht implementieren, aber zumindest mal berücksichtigen. Von daher: rein in die probleme.txt, unter "Waffen" oder so. 2.) Zu der Misch-Idee: Nein, die will ich auch nicht. Dazu tragen wir das ja in der brainstorming.txt ein. Man kann ja diverse Objekte als "modifizierend" betrachten (dabei muss man wiederum die Art der Modi betrachten: permanent, temporär, permanent unter gewissen Umständen) Jedes dieser modifizierenden Objekte modfiziert ein anderes. Naja, ich sags mal lieber mathematisch, ist einleuchtender. Sei B ein modifizierendes Objekt, A1 und A2 seien in der Lage, von B modifiziert zu werden. Ich denke man kann davon ausgehen, dass A1 und A2 von der selben Klasse sind, oder zumindest von der selben abgeleitet. Damit meine ich, dass Ringe nur Lebewesen modifizieren, besondere Metalle nur Waffen. Alle Lebewesen habe in etwa die gleichen Attribute, ebenfalls die Waffen. Das läuft dann darauf hinaus, dass wir versuchen, unsere Objekte vernünftig zu gruppieren. Dann können wir z.B. sagen: A1 und A2 gehören zur Klasse X, B zur Klasse Y. Y kann X modifizieren. Daher wäre dann folgenden Vorgehensweise möglich. Wir setzen unter Objekte der Klasse Y einfach ein Tag <Modifikatoren>, alles unter dieses Tag sieht aus, als wäre es ein Objekt der Klasse X, nur dass die Werte, die beiden Unterelementen angegeben sind, als relativ zu betrachten sind. Eigentlich können wirs gleich so machen, dass wir ein <Modifikatoren modify=""> machen, das angibt, für welche Klasse / Klassen die darunterstehenden Modis gelten. Und für jeden Modi angeben, ob er absolut oder rel. zu verstehen ist, aber gerade bei dem Punkt sollten wir nix überstürzen, erst Ideen sammeln. Zwar kann man das auch mit Skripting machen (wie vorgeschlagen), ich will aber nur so _wenig_ Skripting wie möglich einführen, da wir da selber einen Parser schreiben müssen und das auch noch schlechter pflegen können, als wenn wir uns eine gute XML-Struktuer überlegen, die das auch mit weniger Skripting ermöglicht (ganz ohne wirds wohl nicht gehen). Gruß Matthias PS: Noch was: auch wenn ich hier von einer Art Vererbung rede, meine ich nicht, dass wir das irgendwie realisieren müssen. Ich meine nur, dass wir uns bei solchen Klassen auf eine einheitliche Struktur einigen, also beim Begleiter statt Tag <LO> für Loyalität dies besser als Basis-Attribut nehmen (also in den Topf mit MU, KL, ...). Mehr mein ich damit nicht |
From: Tilmann K. <ti...@tk...> - 2001-11-19 10:06:48
|
Tilmann Kuhn wrote: > 2. Also ich denke eine sauberere Loesung ist es wenn wir vermeiden, dass > Daten mehrfach gespeichert werden und (z.B. bei dem Helden) wo es geht > nur Referenzen (Meinetwegen in Form von idref / xlink & xpointer / ...?) > in der XML speichern. > > Mittelwege halte ich fuer eher chaotisch und daher unguenstig. > > Was meint ihr? Ich koennte mir das grob so vorstellen: In irgend einer talente.xml oder so: <dsaman:talente> <dsaman:talent id="TALfussball"> .... </dsaman:talent> </dsaman:talente> In derm charkter.xml: <dsaman:charakter> ... <dsaman:talente> <dsaman:talent idref="TALfussball"> .... <!-- falls noetig --> </dsaman:talent> </dsaman:talente> .. </dsaman:charakter> Oder auch: In irgend einer talente.xml oder so: <dsaman:talente> <dsaman:talent id="fussball"> .... </dsaman:talent> </dsaman:talente> In derm charkter.xml: <dsaman:charakter xmlns:xlink="http://www.w3.org/1999/xlink"> ... <dsaman:talente> <dsaman:talent xlink:type="simple" xlink:href="talente.xml#xpointer(id("fussball"))"> .... <!-- falls noetig --> </dsaman:talent> </dsaman:talente> ... <dsaman:charakter> Klarer Nachteil aller dieser Verfahren ist natuerlich, der Geschwindigkeitsverlust, der durch das Aufloesen der Links entsteht. tilmann -- "Tu es oder tu es nicht, es gibt kein Versuchen." Yoda Jedi Master Tilmann G. Kuhn http://www.tkuhn.de |
From: Andreas H. <ahu...@gm...> - 2001-11-19 09:42:19
|
Hi, Tilmann Kuhn wrote: > Servus! > > Matthias Wurm wrote: > >> >> Ich verstehe im Moment dein Problem nicht. Tilmann will in der >> Charaktere-Datei ja nur jegliche Information auf das Wesentliche >> reduzieren, und das geht nunmal meisten schon anhand der Angabe von der >> ID (und NUR der ID). Ein Beispiel aus dem ersten Strukturvorschlag: >> <Rasse id="RasMittel"> >> <Name>Mittelländer</Name> >> <Modifikator expr="LE+10"/> >> <Modifikator expr="AU+10"/> >> <Modifikator expr="MR-4"/> >> </Rasse> >> Alles außer der ID ist hier redundant, da es ja gerade DURCH die id >> schon eindeutig bestimmt ist (In einer externen Rassen-Datei oder so >> etwas). Jede zusätzliche Information wäre überflüssig. >> > > >... > > Dieses Vorgehen wuerde auch den Vorteil haben, dass man beim Aendern > irgend eines Names/Wertes/... diesen _nur_ in einer Datei aendern > muesste und nicht Sorge tragen muss, dass die Aenderung in alle > Dateien, die eventuell eine Kopie des Datensatzes beinhalten, kopiert > werden muss. Punkt fuer euch... Ok dann versuche ich bei den Vorschlaegen und Problemen diese vorgehensweise im Hinterkopf zu behalten. Also eine Helden.datei die hauptsaechlich aus IDs bestehen soll erweitert um die Werte die frei zu waehlen waren. Die 3 Zauber bei elfischer Weltsicht, das Talent oder die Gruppe bei Begabung, die Eigenschaft mit Vor oder Nachteil. Gruss Andreas |
From: Andreas H. <ahu...@gm...> - 2001-11-19 09:36:13
|
Hi, Matthias Wurm wrote: >Andreas Hugenroth wrote: > >>Hi, >> >>Tilmann Kuhn wrote: >> >>>Halloechen! >>> >>>Wir haben im Wesentlichen wohl zwei Alternativen (hier am Beispiel >>>eines Helden): >>> >>>1. In jedem "Helden" werden alle wichtigen Daten gespeichert. >>> >>Mein Favorit. >>Es bietet einfach mehr moeglichkeiten den Helden nacher zu manipulieren. >>Sei es nur der nette Meister der dir nach einer seltenen 3fach 1 >>talentprobe gesattet dieses Talent mit der naechst leichteren >>Kostenspalte zu steigern. >>Rollenspiel lebt ja daher das man eigentlich keiner festen Regel >>unterliegt. Man muss alles manipulieren koennen. >>... >> > >Ich verstehe im Moment dein Problem nicht. Tilmann will in der >Charaktere-Datei ja nur jegliche Information auf das Wesentliche >reduzieren, und das geht nunmal meisten schon anhand der Angabe von der >ID (und NUR der ID). Ein Beispiel aus dem ersten Strukturvorschlag: ><Rasse id="RasMittel"> > <Name>Mittelländer</Name> > <Modifikator expr="LE+10"/> > <Modifikator expr="AU+10"/> > <Modifikator expr="MR-4"/> ></Rasse> >Alles außer der ID ist hier redundant, da es ja gerade DURCH die id >schon eindeutig bestimmt ist (In einer externen Rassen-Datei oder so >etwas). Jede zusätzliche Information wäre überflüssig. > Hier bei Rasse ist das eindeutig, wenn alles so eindeutig waere waer ich sofort fuer Tilmans Vorschlag die Char-Datei quasi nur mit IDs zu fuellen. > > >Genauso bei Talenten: >Im Grunde bräuchten wir pro Talent nur die ID und den TaW, mehr nicht, >da anhand der ID ja schon _alles_ (Name, Probe, Kategorie, >Steigerungsspalte) beschrieben ist. Zwar werden wir hier aufgrund >solcher Vorteile wie "Begabung für... Unfähigkeit für..." noch ein paar >mehr Infos zu den Talenten geben müssen, die aber wohl in der Regel >EMPTY sein werden, dazu gehören dann solche Regelungen zur >Steigerungsmodifikation (wie die von dir oben genannten) > Und wie willst du diese Infos nun gestallten ? Das laueft dann doch auf meine Misch-Idee hinaus. Es gilt so lange default bis die emptyfelder einen Wert haben. Nur du musst dann fuer sehr viele Punkte diese Sonderfelder mitnehmen. Nimm zb den Zweihaender fuer 300 Dukaten der mit einem normalen Zweihaender nur noch den Namen gemeinsam hat. > >Die von dir angesprochene Freiheit lässt sich ja ohne Probleme mit dem >von Tilmann angesprochenen Prinzip vereinigen (wie eben beschrieben). >Und im Sinne von sauberer Programmierung sollten wir das, was sich auf >einen Kernpunkt reduzieren lässt, auch reduzieren, und nicht >überflüssigerweise woanders noch mitschleppen (wie z.B. den Namen der >Rasse, des Talents oder ähnliches) > Das ist schon richtig, ich komme aus der Datenbankecke und bin garantiert kein Fan von doppelt und dreifachspeicherung ein und derselben daten nur um Sonderfaelle abzufangen. Hmm wir koennen natuerlich auch versuchen solche Modifikatoren vor der Steigerung/ Ausdruck aufloesen zu lassen. Dann muss der Zweihaender als neue Waffe aufgenommen werden und zb mit der ID 2handfuer300D laufen ... Und je laenger ich darueber nachdenke ist das sicher auch ein guter Weg. suche passende SKT-Spalte if HerausragendeTalentGruppe=Talentgruppegewaehlt SKT-Spalte-- fi usw usw D.h aber das wir jeden neuen Vorteil der sisch auf steigerbare Werte und deren Kosten auswirkt coden muessen, oder sieht da jemand einen anderen Weg? Gruss Andreas |
From: Tilmann K. <ti...@tk...> - 2001-11-19 09:31:56
|
Servus! Matthias Wurm wrote: > > Ich verstehe im Moment dein Problem nicht. Tilmann will in der > Charaktere-Datei ja nur jegliche Information auf das Wesentliche > reduzieren, und das geht nunmal meisten schon anhand der Angabe von der > ID (und NUR der ID). Ein Beispiel aus dem ersten Strukturvorschlag: > <Rasse id="RasMittel"> > <Name>Mittelländer</Name> > <Modifikator expr="LE+10"/> > <Modifikator expr="AU+10"/> > <Modifikator expr="MR-4"/> > </Rasse> > Alles außer der ID ist hier redundant, da es ja gerade DURCH die id > schon eindeutig bestimmt ist (In einer externen Rassen-Datei oder so > etwas). Jede zusätzliche Information wäre überflüssig. > >... Dieses Vorgehen wuerde auch den Vorteil haben, dass man beim Aendern irgend eines Names/Wertes/... diesen _nur_ in einer Datei aendern muesste und nicht Sorge tragen muss, dass die Aenderung in alle Dateien, die eventuell eine Kopie des Datensatzes beinhalten, kopiert werden muss. Gruss, tilmann -- "Auch wenn es sich falsch anhoert, muss es nicht unbedingt richtig sein." Hindemith Tilmann G. Kuhn http://www.tkuhn.de |
From: Matthias W. <Mat...@gm...> - 2001-11-18 23:26:25
|
Andreas Hugenroth wrote: > > Hi, > > Tilmann Kuhn wrote: > > > Halloechen! > > > > Wir haben im Wesentlichen wohl zwei Alternativen (hier am Beispiel > > eines Helden): > > > > 1. In jedem "Helden" werden alle wichtigen Daten gespeichert. > > Mein Favorit. > Es bietet einfach mehr moeglichkeiten den Helden nacher zu manipulieren. > Sei es nur der nette Meister der dir nach einer seltenen 3fach 1 > talentprobe gesattet dieses Talent mit der naechst leichteren > Kostenspalte zu steigern. > Rollenspiel lebt ja daher das man eigentlich keiner festen Regel > unterliegt. Man muss alles manipulieren koennen. > ... Ich verstehe im Moment dein Problem nicht. Tilmann will in der Charaktere-Datei ja nur jegliche Information auf das Wesentliche reduzieren, und das geht nunmal meisten schon anhand der Angabe von der ID (und NUR der ID). Ein Beispiel aus dem ersten Strukturvorschlag: <Rasse id="RasMittel"> <Name>Mittelländer</Name> <Modifikator expr="LE+10"/> <Modifikator expr="AU+10"/> <Modifikator expr="MR-4"/> </Rasse> Alles außer der ID ist hier redundant, da es ja gerade DURCH die id schon eindeutig bestimmt ist (In einer externen Rassen-Datei oder so etwas). Jede zusätzliche Information wäre überflüssig. Genauso bei Talenten: Im Grunde bräuchten wir pro Talent nur die ID und den TaW, mehr nicht, da anhand der ID ja schon _alles_ (Name, Probe, Kategorie, Steigerungsspalte) beschrieben ist. Zwar werden wir hier aufgrund solcher Vorteile wie "Begabung für... Unfähigkeit für..." noch ein paar mehr Infos zu den Talenten geben müssen, die aber wohl in der Regel EMPTY sein werden, dazu gehören dann solche Regelungen zur Steigerungsmodifikation (wie die von dir oben genannten) Die von dir angesprochene Freiheit lässt sich ja ohne Probleme mit dem von Tilmann angesprochenen Prinzip vereinigen (wie eben beschrieben). Und im Sinne von sauberer Programmierung sollten wir das, was sich auf einen Kernpunkt reduzieren lässt, auch reduzieren, und nicht überflüssigerweise woanders noch mitschleppen (wie z.B. den Namen der Rasse, des Talents oder ähnliches) Gruß Matthias |
From: Andreas H. <ahu...@gm...> - 2001-11-18 22:45:41
|
Hi, Tilmann Kuhn wrote: > Halloechen! > > Wir haben im Wesentlichen wohl zwei Alternativen (hier am Beispiel > eines Helden): > > 1. In jedem "Helden" werden alle wichtigen Daten gespeichert. Mein Favorit. Es bietet einfach mehr moeglichkeiten den Helden nacher zu manipulieren. Sei es nur der nette Meister der dir nach einer seltenen 3fach 1 talentprobe gesattet dieses Talent mit der naechst leichteren Kostenspalte zu steigern. Rollenspiel lebt ja daher das man eigentlich keiner festen Regel unterliegt. Man muss alles manipulieren koennen. > > 2. Also ich denke eine sauberere Loesung ist es wenn wir vermeiden, > dass Daten mehrfach gespeichert werden und (z.B. bei dem Helden) wo es > geht nur Referenzen (Meinetwegen in Form von idref / xlink & xpointer > / ...?) in der XML speichern. Bietet meiner meinung nach kaum moeglichkeit zur Manipulation. Wenn die Referenz etwas nicht vorsieht geht es nicht... Oder es muss eine eigene Erweiterung geschaffen werden ( in den obrigen Beispiel dann das Meistergeschenk Kostenmodifikator) Es gibt sicher noch andere Beispiele wo man im laufe des Spiels von der Norm abweicht. Gruss Andreas |
From: Tilmann K. <ti...@tk...> - 2001-11-18 22:21:29
|
Halloechen! Wir haben im Wesentlichen wohl zwei Alternativen (hier am Beispiel eines Helden): 1. In jedem "Helden" werden alle wichtigen Daten gespeichert. 2. Also ich denke eine sauberere Loesung ist es wenn wir vermeiden, dass Daten mehrfach gespeichert werden und (z.B. bei dem Helden) wo es geht nur Referenzen (Meinetwegen in Form von idref / xlink & xpointer / ...?) in der XML speichern. Mittelwege halte ich fuer eher chaotisch und daher unguenstig. Was meint ihr? Gruesse, tilmann -- "Die Sprache ist nicht nur Mittel zur Kommunikation, sie beeinflusst unser Handeln." Worf Tilmann G. Kuhn http://www.tkuhn.de |
From: Andreas H. <ahu...@gm...> - 2001-11-18 21:50:20
|
Hi, also ich denke wir kommen langsam nicht mehr drumrum uns auch Gedanken zur Struktur des ganzen zu machen. Als Beispiel nenn ich mal die Talente. a) Beim Helden wird nur Talent-ID, Vorteil-id, Nachteil-ID usw usw und die Werte gesichert. Dann muss beim steigern immer herleiten welche kostenspalte usw nun gueltig ist. b) Beim Helden werden Talente mit allen Werten ( inkl Kostendefinition) gesichert. Dann kann das Programm beim steigern die kosten direkt bestimmen. Das ganze geht weiter bei den Eigenschaftsmodifikatoren... Die char.xml wwird natuerlich kleiner wenn man nur die relevanten Daten sichert. Alternativ waere ja eine gemischte Struktur. Beim Helden steht die ID und der Wert. Solange keine weiteren angaben dort stehen werden die "default" werte genommen. Sollte beim erstellen dann Herausragendes Talent gewaehlt worden sein, stehen neben der ID auch noch die neuen Kosten in der Datei. Gruss Andreas |
From: Andreas H. <ahu...@gm...> - 2001-11-18 15:48:49
|
Hi, Matthias Wurm wrote: >Da ja im Moment das Weiterkommen in der brainstorming.txt ja recht >stockend ist - es ist ja schon ziemlich viel drin - wollte ich mal >vorschlagen, dass wir vielleicht ein paar neue dateien einfügen. > >regelwerk.txt >Da könnten wir ja mal die Regeln kurz und knapp festhalten, ohne dem >FanPro bla bla drumherum. Praktisch in PseudoCode. Da könnten wir auch >mal die "globalen" Variablen einbauen, wie z.B. die Grund-GP. > >probleme.txt >sachen aus dem regelwerk suchen, die rel. schwer zu realisieren sind >(wie das beispiel mit den lederrüstugen...) > Beides hoert sich gut an, ich habe auch schon in der probleme.txt einige weitere kommentare eingefuegt. Bye Andreas |
From: Oliver S. <os...@ep...> - 2001-11-18 14:51:25
|
Hi Matthias! > regelwerk.txt > Da könnten wir ja mal die Regeln kurz und knapp festhalten, ohne dem > FanPro bla bla drumherum. Praktisch in PseudoCode. Da könnten wir auch > mal die "globalen" Variablen einbauen, wie z.B. die Grund-GP. Gute Idee! Legst Du das an? cu Oli |
From: Matthias W. <Mat...@gm...> - 2001-11-17 12:29:02
|
Da ja im Moment das Weiterkommen in der brainstorming.txt ja recht stockend ist - es ist ja schon ziemlich viel drin - wollte ich mal vorschlagen, dass wir vielleicht ein paar neue dateien einfügen. regelwerk.txt Da könnten wir ja mal die Regeln kurz und knapp festhalten, ohne dem FanPro bla bla drumherum. Praktisch in PseudoCode. Da könnten wir auch mal die "globalen" Variablen einbauen, wie z.B. die Grund-GP. probleme.txt sachen aus dem regelwerk suchen, die rel. schwer zu realisieren sind (wie das beispiel mit den lederrüstugen...) Weil wenn wir da was eingeben, fällt uns im Vergleich zur Brainstorming.txt vielleicht auch noch was auf, was wir ergänzen können. Die probleme.txt hab ich schonmal hochgeladen (mit etwas Inhalt), wenn ihr nix davon hält, einfach wieder löschen... Gruß Matthias |
From: Andreas H. <ahu...@gm...> - 2001-11-16 22:13:59
|
test weil gmx stresst |
From: Andreas H. <ahu...@gm...> - 2001-11-16 11:18:10
|
Hi, ich habe gerade mal einen Zwergen nach DSA4 System gebaut, eigentlich nur um noch Sachen zu finden die ich bisher evtl uebersehen habe. Doch dann habe ich mal den mitgeliefetern Zwerg mit den meinigen verglichen. Kann mir einer sagen wie die es geschafft haben. 92 Punkte in die Eigenschaften zu verteilen wenn der Ambosszwerg 20 GP und Soeldner 10 GP kosten. einen Nachteil haben sie nicht hinzugefuegt.... Hab ich was uebersehen. Gruss Andreas |
From: Andreas H. <ahu...@gm...> - 2001-11-16 01:34:25
|
Hi, zerbrecht euch lieber nicht den kopf an diesen Funktionen, ich meine in einem vinsalter Forum mal ne Formel gesehen zu haben, war aber wohl eine vor myranische mystirien version... Lasst uns einfach diese Tabelle abtippen und in ein 2dim feld legen... ( Hardcoded) ... Sollte sich wirkllich was aendern ... nagut dann legt man die in eine kleine datei und laesst sie bei programmstart einlesen... Oliver Schulz wrote: >Hi Leute! > >>>Das hier sind die Steigerungskosten, wenn man sie nach >>> >>> St.Kosten = 40 * Aktivierungsfaktor * (Wert/26)^1.2 >>> > >>Sieht gut aus, besser, als ich es bisher hinbekommen habe, aber einige >>Werte brechen doch aus. Ist das jetzt ein Fehler von FanPro oder stimmt >>die Funktion immer noch nicht? >> > >Ich hab den Verdacht, da hat bei Fanpro jemand falsch gerundet. >Denn oh Wunder: Die Analyse der Talent(kauf)kosten hat ein >recht ähnliches Ergebnis geliefert: > > Talentkosten = 29 * Aktivierung * (Wert/20)^1.2 > >Die Abweichungen in der E Spalte (Aktivierung = 5) sind > > 0, 0.1, 0.1, 0, 0.5, 0.2, 0.1, 0.7, 0.6, 1.9, 0.8, 1.4, > 1.5, 0.5, 2.3, 0.9, 0.7, 2.2, 1.3, 0 > >und auch die Plots passen wieder super. Und das trotz >offensichtlicher Rundung höherer Werte auf Vielfache von >5 in der Fanpro-Tabelle. >Hmmm ... ob die 29 mal hätte eine 30 sein sollen? Irgendwer >rechnet da bei Fanpro, aber entweder rundet er zwischendurch, >oder tut sonst was komisches. Das ist zu gut, um nicht >die richtige Funktion zu sein. > Die funktion sieht schon recht gut aus .... Es ist mir nun aber zu spaet fuer etwas Zahlentheorie :) Evtl rechne ich morgen mal etwas rum... Bye Andreas |
From: Oliver S. <os...@ep...> - 2001-11-16 01:18:10
|
Hi Alex! > > Ein dickes Problem, das z.B. auftreten würde, ist, daß Dinge wie XSLT > > keine Ahnung von XMLDB und XQUERY haben. > > Gut, aber du wolltest die ganzen Werte ja sowieso ausgerechnet speichern. Ausgerechnet schon, aber doch in der selben Struktur wie alles andere. Zugriffsprobleme könnten (evtl.) also schon auftreten. cu Oli |
From: Oliver S. <os...@ep...> - 2001-11-16 00:32:27
|
Hi Leute! > > Das hier sind die Steigerungskosten, wenn man sie nach > > > > St.Kosten = 40 * Aktivierungsfaktor * (Wert/26)^1.2 > Sieht gut aus, besser, als ich es bisher hinbekommen habe, aber einige > Werte brechen doch aus. Ist das jetzt ein Fehler von FanPro oder stimmt > die Funktion immer noch nicht? Ich hab den Verdacht, da hat bei Fanpro jemand falsch gerundet. Denn oh Wunder: Die Analyse der Talent(kauf)kosten hat ein recht ähnliches Ergebnis geliefert: Talentkosten = 29 * Aktivierung * (Wert/20)^1.2 Die Abweichungen in der E Spalte (Aktivierung = 5) sind 0, 0.1, 0.1, 0, 0.5, 0.2, 0.1, 0.7, 0.6, 1.9, 0.8, 1.4, 1.5, 0.5, 2.3, 0.9, 0.7, 2.2, 1.3, 0 und auch die Plots passen wieder super. Und das trotz offensichtlicher Rundung höherer Werte auf Vielfache von 5 in der Fanpro-Tabelle. Hmmm ... ob die 29 mal hätte eine 30 sein sollen? Irgendwer rechnet da bei Fanpro, aber entweder rundet er zwischendurch, oder tut sonst was komisches. Das ist zu gut, um nicht die richtige Funktion zu sein. cu Oli |
From: Alexander N. <webmaster@AlexNofftz.de> - 2001-11-16 00:25:18
|
Hi Oliver! > Mal eine Anmerkung zu XMLDB. Das ganze macht nur dann Sinn, wenn wir > um eine sehr sehr abstrakte Datenstruktur nicht herumkommen (z.B. evtl. > Alex Klassenmodell in vollem Umfang). Wenn wir mit einer halbwegs direkten > Struktur hinkommen (lasset uns beten ...), dann weiß man nach dem > Parsen, wo man auf was zugreifen muß. Ein XMLDB Ansatz bringt da > keinerlei Einsparung, ganz im Gegenteil. Sowas brauchen wir nur in > einer Struktur, in der an Dinge schwer ranzukommen ist. Achso. > Ein dickes Problem, das z.B. auftreten würde, ist, daß Dinge wie XSLT > keine Ahnung von XMLDB und XQUERY haben. Gut, aber du wolltest die ganzen Werte ja sowieso ausgerechnet speichern. > Ich möchte deshalb vorschlagen, diese Diskussion zurückzustellen > bis wir unsere Sammelaktion beendet und ausgewertet haben. Eben, daher ja der deutliche Hinweis auf die brainstorming.txt Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-16 00:15:05
|
Hi Oliver! > Das hier sind die Steigerungskosten, wenn man sie nach > > St.Kosten = 40 * Aktivierungsfaktor * (Wert/26)^1.2 Aha, doch "nur" ein Polynom... > ausrechnet. Vergleicht mal mit der DSA4-Tabelle, und sagt was zu > den Abweichungen: Sieht gut aus, besser, als ich es bisher hinbekommen habe, aber einige Werte brechen doch aus. Ist das jetzt ein Fehler von FanPro oder stimmt die Funktion immer noch nicht? Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |
From: Oliver S. <os...@ep...> - 2001-11-15 23:31:37
|
Das hier sind die Steigerungskosten, wenn man sie nach St.Kosten = 40 * Aktivierungsfaktor * (Wert/26)^1.2 ausrechnet. Vergleicht mal mit der DSA4-Tabelle, und sagt was zu den Abweichungen: ---------------------------------------------------------------------- Steigerungskosten-Tabelle (SKT) - Theorie-Werte Wert A B C D E F G H 1 1.0 1.6 2.4 3.2 4.0 6.0 8.0 16.0 2 1.8 3.7 5.5 7.4 9.2 13.8 18.4 36.8 3 3.0 6.0 9.0 12.0 15.0 22.5 30.0 59.9 4 4.2 8.5 12.7 16.9 21.2 31.7 42.3 84.6 5 5.5 11.1 16.6 22.1 27.7 41.5 55.3 110.6 6 6.9 13.8 20.7 27.5 34.4 51.6 68.9 137.7 7 8.3 16.6 24.8 33.1 41.4 62.1 82.8 165.7 8 9.7 19.4 29.2 38.9 48.6 72.9 97.2 194.5 9 11.2 22.4 33.6 44.8 56.0 84.0 112.0 224. 10 12.7 25.4 38.1 50.8 63.5 95.3 127.1 254.2 11 14.2 28.5 42.7 57.0 71.2 106.9 142.5 285.0 12 15.8 31.6 47.4 63.3 79.1 118.6 158.2 316.3 13 17.4 34.8 52.2 69.6 87.1 130.6 174.1 348.2 14 19.0 38.1 57.1 76.1 95.2 142.7 190.3 380.6 15 20.7 41.4 62.0 82.7 103.4 155.0 206.7 413.5 16 22.3 44.7 67.0 89.4 111.7 167.5 223.4 446.8 17 24.0 48.1 72.1 96.1 120.1 180.2 240.2 480.5 18 25.7 51.5 77.2 102.9 128.6 193.0 257.3 514.6 19 27.4 54.9 82.4 109.8 137.3 205.9 274.5 549.1 20 29.2 58.4 87.6 116.8 146.0 219.0 292.0 583.9 21 31.0 61.9 92.9 123.8 154.8 232.2 309.6 619.1 22 32.7 65.5 98.2 130.9 163.7 245.5 327.3 654.7 23 34.5 69.1 103.6 138.1 172.6 259.0 345.3 690.6 24 36.3 72.7 109.0 145.4 181.7 272.5 363.4 726.7 25 38.2 76.3 114.5 152.6 190.8 286.2 381.6 763.2 26 40.0 80.0 120.0 160.0 200.0 300.0 400.0 800.0 Akt.f. 1 2 3 4 5 7.5 10 20 ---------------------------------------------------------------------- cu Oli |
From: Oliver S. <os...@ep...> - 2001-11-15 23:21:25
|
Hallo Alle! > Nicht ganz korrekt. Das xml:db api bezieht sich eigentlich darauf, das man > eine Ansammlung von xml-files hat, und bietet eine einfache Moeglichkeit > aus diesen Text/binaer/Dom -Stuecke zu extrahieren(z.B. mittels xpath), zu > lesen/bearbeiten und rueckzuspeichern, files hinzuzufuegen zu loeschen etc. > also eigentlich genau das was wir brauchen, wenn wir nicht jedes File per > Hand parsen und auswerten wollen. Fuer Interessierte hier mal die > > use cases: > http://www.xmldb.org/xapi/UseCases.html > den working-draft mit links zur api: > > http://www.xmldb.org/xapi/xapi-draft.html [...] Mal eine Anmerkung zu XMLDB. Das ganze macht nur dann Sinn, wenn wir um eine sehr sehr abstrakte Datenstruktur nicht herumkommen (z.B. evtl. Alex Klassenmodell in vollem Umfang). Wenn wir mit einer halbwegs direkten Struktur hinkommen (lasset uns beten ...), dann weiß man nach dem Parsen, wo man auf was zugreifen muß. Ein XMLDB Ansatz bringt da keinerlei Einsparung, ganz im Gegenteil. Sowas brauchen wir nur in einer Struktur, in der an Dinge schwer ranzukommen ist. Ein dickes Problem, das z.B. auftreten würde, ist, daß Dinge wie XSLT keine Ahnung von XMLDB und XQUERY haben. Hinzu kommt, daß man (selbst wenn's ganz dick kommt) auch mit XPATH allein schon ziemlich viel machen kann, man braucht auch da nicht zwangsläufig gleich XQUERY und eine Datenbank. Und XPATH steht bei vielen Parsern zur Verfügung und ist integraler Bestandteil von XSLT (und eine fertige W3C Rec.). Ich möchte deshalb vorschlagen, diese Diskussion zurückzustellen bis wir unsere Sammelaktion beendet und ausgewertet haben. cu Oli |
From: Oliver S. <os...@ep...> - 2001-11-15 23:03:38
|
Hi! > Ich habe gerade mal kurz die Dateien der c-Version inspiziert und wollte > mal fragen ob von euch schon jemand den "quasi"-Nachfolger von "make", also > "Ant" ausprobiert hat oder Lust hat das mal zu testen. Ich kenn Ant nur von den Apache Java-Programmen, scheint gut zu funktionieren. Von Nachfolger kann aber im Bezug auf C/C++ kaum die Rede sein, hier sind make/imake/automake,etc. nach wie vor das Maß der Dinge. Für Java ist Ant sehr nett, und für unsere Java-DSAMan-Implementierung sicher eine Option. Diese Entscheidung steht aber im Moment wohl noch nicht dringlich an, bleibt also Zeit, das mal in Ruhe zu testen. cu Oli |
From: Tilmann K. <ti...@tk...> - 2001-11-15 22:51:52
|
Hi! Ich habe gerade mal kurz die Dateien der c-Version inspiziert und wollte mal fragen ob von euch schon jemand den "quasi"-Nachfolger von "make", also "Ant" ausprobiert hat oder Lust hat das mal zu testen. http://jakarta.apache.org/ant/index.html Gruss, tilmann -- "Auge um Auge wird die ganze Welt blind machen." Mahatma Ghandi Tilmann G. Kuhn http://www.tkuhn.de |
From: Oliver S. <os...@ep...> - 2001-11-15 22:28:07
|
Hi! > > denke ich auch, und einmal die paar zahlen eintippen isrt nichts, da wird > > noch besseres auf uns zukommen... > > Inwiefern? Die Tabellen aus Myranor und DSA4 sind (bis auf die neue > Spalte) identisch. Sind sie ... fast (seufz). Bei DSA4 sind höhere Zahlenwerte auf Faktoren von 5 gerundet worden, bei Myranor nicht. Ich hab die Funktion jetzt, es ist: St.Kosten = 40 * Aktivierungsfaktor * (Wert/26)^1.2 Das ganze sieht doch sehr nach Thomas Römer persönlich aus ... :-) Korrelation ist sehr gut, größte Abweichung bei Myranor ist 3.2 (in der 20er Spalte), typische Abweichung ist <0.5. Bei DSA4 nicht ganz so gut, weil da noch komischer gerundet wird. Auch die Plot's sehen super aus. cu Oli |