[quote='lunatic','index.php?page=Thread&postID=103263#post103263']Noch etwas ganz Wichtiges: mehr *additives" Modding (Chris wird mich schlagen ob dieser zu "allgemeinen" Aussage ), damit möglichst alle Mods nebeneinander existieren können und sich nicht gegenseitig überschreiben.[/quote]
Mal für mich (Laie) und andere Programmierlaien gefragt: Ich gehe davon aus, das es von Anfang an ein weltweit bekanntes Problem ist. Ist das äußerst kompliziert oder sehr zeitaufwändig oder so gut wie unmöglich zu realisieren oder warum wird das nicht schon zu Beginn gemacht/berücksichtigt ?

Das ist ein Problem der Granularität Fairplay, und natürlich auch der Erfahrung mit dem Bau von modifizierbaren Systemen. Schick HD ist ja schon in 1.34 durchaus "additiv" modifizierbar, d.h. man kann neue Charakterklassen hinzufügen, alte Klassen überschreiben, neue Items hinzufügen, Händlersortimente ändern usw. In der Praxis hat sich jetzt aber gezeigt, dass diese "Überschreibbarkeit" einfach derzeit noch zu grob angelegt ist, d.h. man kann zwar eine ganze Charakterklasse überschreiben, aber wenn man die Start-LE des Magiers um 3 Punkte anheben möchte, muss man die gesamte Magierklasse mit Ritual, Anfangstalentwerten, Voraussetzungen usw. überschreiben. Was grundsätzlich auch noch kein Problem ist. Solange die "Basis" gleich bleibt. Und solange niemand anderes ein Mod macht, das dem Magier zwei neue Zauberspruch-Startwerte hinzufügt.

Was lunatic möchte (und was er für 1.35 auch schon bekommen hat, er war ja lange genug lästig damit ), ist die Möglichkeit, mit Mod A die startle des Magiers zu überschreiben, mit Mod B die Sprüche hinzuzufügen und bei Mod C die Steigerungsversuche für Zauber zu erhöhen. Und wenn dann noch ein Update kommt, das drei neue Zaubersprüche aktiviert, sollen alle drei Mods trotzdem nach wie vor funktionstüchtig sein.

Bei einer Charakterdefinition der Komplexität DSA3, wie sie in Schick HD vorkommt, sind das dann so um die 40 Einzelwerte, plus ein paar Listen, komplexen Datentypen (Inventar anyone?) usw. Damit das alles klappt, muss man sich hinsetzen und jeden einzelnen Wert für die "Zusammenführung" getrennt einlesen und mit einem anderen Standardwert als dem "normalen" (zB 1W6 für die LE beim Levelanstieg) versehen, nämlich jenem aus dem bisherigen Leseprozess.

Und nachdem das nicht nur für Charakterklassen gehen soll, sondern auch für Dungeons, Sortimentsdefinitionen von Händlern, Talente und noch ein paar andere Dinge, artet das so richtig in Arbeit aus, das umzusetzen .

Und, jetzt muss ich noch was spoilern zum Thema "hätte man das nicht schon lange machen können": [spoiler]Ich bin weder allwissend noch perfekt[/spoiler]Von daher habe ich das Modding-System so gebaut, wie ich es für sinnvoll erachtet habe. Über ein Jahr Erfahrung mit exzessivem Modding hat aber gezeigt, dass es Verbesserungspotenzial hat - und das wird jetzt gehoben .

[quote='craftyfirefox','index.php?page=Thread&postID=103702#post103702']Und nachdem das nicht nur für Charakterklassen gehen soll, sondern auch für Dungeons, Sortimentsdefinitionen von Händlern, Talente und noch ein paar andere Dinge, artet das so richtig in Arbeit aus, das umzusetzen[/quote]
Ist bei den "noch ein paar andere Dinge" auch die "Hilfe-Einträge" mit vorgesehen?
Keine Kompatibilität der "Hilfe"-Einträge im Questbuch
Ich wollte nur noch Mal darauf hinweisen, da sich dadurch die Mods ja schon jetzt beißen.

Guter Punkt, danke für den Hinweis.

Ich hätte da ne Idee wie man das allgemein mit IDs, XPath und Namespaces umsetzen könnte, soll ich dazu mal ein paar Sätze schreiben?

Lass jucken!

Also zuerst der lästige Teil, der aber per Programm generiert werden kann. Jedes XML-Tag braucht eine systematische-menschenlesbare-ID

Beispiel 1:
[spoiler]class:hunter:le als ID für [/spoiler]
Beispiel: 2
[spoiler]
dngthorwal":itemsets:chest_0_1:92 [/spoiler]

Modifikationen könnten dann so beschrieben werden:
Bsp: Klassen
[spoiler] Mit "inherit" würde der aktuelle Zustand der Klasse "Hunter" kopiert inkl. aller früheren Modifikationen und Patches.
Der dynamische Zusammenbau zum Programmstart vermeidet Konflikte.
Danach wird der geerbte Knoten "le" durch den neuen ersetzt. Durch den Namespace dsa können die Tags der classdefinitions verwendet werden.
Wird kein Knoten mit der passenden ID gefunden sind Mod und Programm nicht kompatibel, Die Modifikation könnte deaktiviert werden.
Will ich nur einen Wert einer Klasse ändern kann ich das mit dem Modify direkt machen.
[/spoiler]

Beispiel Dungeon
[spoiler] Diese Mod Zeile fügt in eine existierende Kiste zusätzlich das Item 159 ein. Man kann wegen der ID alle Usermods durchsuchen ob eine andere Mod erkennen die an der gleichen Truhe Änderungen vornimmt und auf Konflikte hinweisen.
AddDungeon optional sollte bewirken, dass der Spieler beim Betreten des Dungeons gefragt wird, welche Version er haben möchte Vanilla oder Mod
[/spoiler]

Da alle Elemente IDs haben sollten sie leicht per XPath gefunden werden können:
z.B: //*[@id='dungeon:dngthorwal":itemset:chest_0_1']

Im Prinzip müssten Konflikte zwischen usermods weitgehend vermieden werden bzw. könnten im Vorfeld an den identischen IDs erkannt werden.

Ich hoffe das Konzept ist so einigermaßen verständlich.

Verständlich ist das System schon, ich halte es nur für einerseits höchst kompliziert für einen "Normalsterblichen", da etwas modifizieren zu können, zum Anderen müsste ich den *gesamten* Leseprozess für so um die 30 verschachtelte Datenstrukturen komplett von null weg neu machen. Die Sache ist nämlich, dass ein "Modder" jetzt nicht unbedingt einen Plan von Programmieren hat - und vermutlich allergischen Ausschlag bekommt, wenn er da was von "inherit" und "addclass" liest.

Die Eleganz von dieser für mich in der Erstellung sehr aufwändigen "Überschreibelogik" ist halt, dass man wirklich den Originaljäger nehmen, alles identische rauslöschen und den Rest nach Lust modifizieren kann. Klar, so elegant wie du krieg ich einen "Ranger" nicht hin (mal abgesehen davon, dass die ID und die LE zu wechseln allein nicht ausreichen würde, und dann eine "richtige" Modifikation schon wieder um ein Eckhaus komplexer wäre ), aber wenn ich mir deine Jäger-Mod anschaue: So krieg ich das in meinem System etwas einfacher lesbar hin: Sowas kann ich ganz ohne Computerkurs und ohne Plan von ID-Hierarchien, einem "mode replace" oder sonstwas sogar einem Laien in wenigen Sätzen klar machen. Ein System wie das deine hätte aus meiner Sicht den Haken, dass potenzielle Modder die Ausrede "das ist ja viel zu kompliziert, das verstehe ich nicht" hätten.

Wie gesagt, dein System wäre höchst elegant und technisch durchaus umsetzbar. Ein Problem hab ich dann aber doch noch damit: Technisch wäre es natürlich umsetzbar, aber in der Performance wäre es fürchte ich grottenschlecht, weil ich zum Einen kein serielles Parsing der DLCs und Mods mehr machen könnte, sondern immer sämtliche Mods parallel geöffnet haben müsste. Und dann würde ich über jede einzelne eingelesene ID eine XPath-Suche über sämtliche Module laufen lassen müssen. Extrembeispiel Texte, allein die Texte haben über 10.000 Einträge, und so gut wie jedes Mod hat wenigstens ein paar Texte zusätzlich - ich brauch dir glaub ich nicht zu erklären, was das für Auswirkungen auf die Performance hat, wenn du dann 10 oder 15 Mods von der Komplexität eines "Zwischen Mast und Mole" oder der "Taverne 2.0" hast

Additiv habe ich mir an der Stelle auch gewünscht, je weiter man den Zugriff beschränken kann umso runder läuft das System... Dickes + an der Stelle für das System! Langsam kann ich wohl mit dem Modden anfangen. ^^

Was die offenen Mods betrifft, so würde ich die Mod jeweils einmalig nach der Installtion/Update zu einer XML-Datei zusammenfassen. Dabei sollten die Modeinträge ebenfalls IDs kriegen, damit man weiß wo sie herkommen.
Für die Suche nach doppelten Keys, muss dann auch erstmal nur eine Datei durchsucht werden.
Die vollständige Routine würde nur bei einer Installation zu durchlaufen, bei einem normalen Start des Programms kann man das sparen.
Der erste Teil der Id ist eigentlich eine Datei/Typinformation.
Also bei class: braucht man zunächst mal nur classdefinition.xml zu parsen, dachte ich.
Ein Mod-Eintrag auf eine ID dlcgold:.. würde also direkt festlegen welche xml-Datei geparst werden muss.

Da Dungeons auch außerhalb der dungeon.xml definiert sein können müsste man da vielleicht auch über eine caching Strategie nachdenken.

Und ja dieses Format schreit nach einem Modding Benutzerinterface
Und nach einem Verzeichnis wo Mods ihre Images ablegen können.

... und nachdem niemand absehbar ist, der ein solches Interface auch für die komplexeren Bereiche wie Klassendefinition und gamedata machen wird (wo es dann so Sachen wie Templates für Öffnungszeiten der Marktstände im XML definiert gibt), bleib ich lieber bei einem System, das zum Einen keine dreifache Überarbeitungs- und Cachingstrategie benötigt, zum Anderen "out of the Box" das bestehende Spiel auch als Entwicklungsplattform nutzen kann (indem man einfach in der Konsole "reloadXML" eingibt und da kein Caching über alle Mods drüberfahren und erst mal ein "GesamtXML" erstellen muss), und und zu guter Letzt auch bei einem System, das bisher schon ausgezeichnete Dienste leistet und somit auch bereits bewiesenermaßen sehr Bugarm ist .

[quote='craftyfirefox','index.php?page=Thread&postID=103702#post103702']Was lunatic möchte (und was er für 1.35 auch schon bekommen hat, er war ja lange genug lästig damit ), ist die Möglichkeit, mit Mod A die startle des Magiers zu überschreiben, mit Mod B die Sprüche hinzuzufügen und bei Mod C die Steigerungsversuche für Zauber zu erhöhen. Und wenn dann noch ein Update kommt, das drei neue Zaubersprüche aktiviert, sollen alle drei Mods trotzdem nach wie vor funktionstüchtig sein.[/quote]

Sehr cool!