Ist das Modden von Skripten möglich?

[Penthesilea]

Hey zusammen :)

Ich sags schonmal vorne weg: Ich hab mich vorher noch nie mit dem Modden von Spielen beschäftigt und lerne noch ;) Durch eure tolle Vorarbeit ist es mir ja immerhin schon gelungen, einen würdigen Endgegner zu erschaffen :)
Doch ich würde gerne noch weitere, kleinere Änderungen vornehmen, so z.B. den Kältezuwachs beim Konsum von Elextränken.
Ich habe mir die Templates zu den Tränken angeschaut und keinen konkreten Hinweis darauf gefunden, dafür jedoch dies:


class gCItemPotion_PS {
[...]
class eCScriptProxyScript ConsumeScript = "ConsumeElex";
unsigned int Amount = 1;


Meine Vermutung wäre jetzt, dass in diesem Skript auch der Befehl für "erhöhe Kälte um xy" steht. In diesem konkreten Fall könnte man bestimmt auch "unsigned int Amount" um einen gewissen Faktor erhöhen, so dass das Skript einfach mehrfach aufgerufen wird, doch in welche Sector Dateien müsste man das Template dann übernehmen, damit z.B. auch selbst hergestellt Tränke davon betroffen sind?
Es erscheint mir deutlich einfacher, wenn man stattdessen einfach das Skript ändern würde um global eine Veränderung zu erreichen. Kommt man irgendwo an diese Skripte heran? Ich habe mir einmal die gesamte c_1_na.pak entpackt und durchwühlt, konnte aber nichts finden. Hat da schon jemand etwas versucht?

PS: Wenn ich schon dabei bin zu Fragen: Kann es sein, dass es noch ein paar überbleibsel aus G3 und Risen im Code gibt? Telekinese ist in Elex nicht vorhanden, trotzdem findet man u.a. bei den Itemtemplates diese Zeilen:


class gCInteraction {
Version = 1;
Properties {
enum gEInteractionType Type = gEInteractionType_Magic;
class eCScriptProxyScript CanInteractScript = "CanInteract_Magic_Item";
class gCScriptProxyAIFunction PreInteractScript = "PreInteract_Magic_Item";
class gCScriptProxyAIFunction InteractScript = "Telekinesis_Item";
class eCScriptProxyScript PostInteractScript = "";
}

[tombom81]

Kommt man irgendwo an diese Skripte heran? Ich habe mir einmal die gesamte c_1_na.pak entpackt und durchwühlt, konnte aber nichts finden. Hat da schon jemand etwas versucht?Script-Aufrufe gab's in Gothicc 3 und Risen 3 in den info-Dateien. Allerdings ist dieses scripting nicht allzu mächtig; wurde in Gothic 3 benutzt, um neue Sektoren freizuschalten und items in inventories zu legen, z.B.

Bei Risen 3 waren Script-Aufrufe in der w_infos - hdr Datei enthalten, iirc. Das sollte sich bei ELEX nicht geändert haben. hdr ist ziemlich identisch zu r3sec; kannst ja mal versuchen, sie in r3sec umzubenennen und durch den r3resman zu jagen (eventuell fehlen ein paar hashes, werde ich heute abend mal testen).

edit: "Scripte" durch "Script-Aufrufe" ersetzt; ein kleiner, aber bedeutender Unterschied :eek:

[Penthesilea]

Scripte gab's in Gothicc 3 und Risen 3 in den info-Dateien. Allerdings ist dieses scripting nicht allzu mächtig; wurde in Gothic 3 benutzt, um neue Sektoren freizuschalten und items in inventories zu legen, z.B.

Bei Risen 3 waren sie in der w_infos - hdr Datei enthalten, iirc. Das sollte sich bei ELEX nicht geändert haben. hdr ist ziemlich identisch zu r3sec; kannst ja mal versuchen, sie in r3sec umzubenennen und durch den r3resman zu jagen (eventuell fehlen ein paar hashes, werde ich heute abend mal testen).

Items in Inventories zu legen wäre gar nicht so verkehrt, dann könnte man die Rüstungen der Albs für den Spieler verfügbar machen :)

Die .hdr Dateien lassen sich sogar ohne umbennen vom Ressorcen Manager in ein lesbares Format umwandeln, wenn auch nicht ganz perfekt...aber halb so wild. Wenn man sie vorher umbennent, wird das Dateiformat nicht akzeptiert.

Ich werde dann mal schauen ob ich dort finde was ich suche, danke für den Hinweis :)

edit: sieht nur durch die Zeilenumbrüche einiger sehr langen Arrays etwas unübersichtlich aus, das dürften wohl die Stellen sein, an denen die hashes fehlen.

edit2: Wenn man den elexresman verwendet, muss man die .hdr Endung erst noch in .elexhdr umbennen. Mit dem r3resman klappt das auch ohne. Die Ergebnisse scheinen sich dabei nicht zu unterscheiden.

edit3: Die gesuchten Skripte befinden sich leider nicht in den /documents/w_*.hdr Dateien. w_quest.hdr war zwar noch ganz interessant anzuschauen, mehr aber leider auch nicht :(

[JFaron]

Scripte gab's in Gothicc 3 und Risen 3 in den info-Dateien.

edit3: Die gesuchten Skripte befinden sich leider nicht in den /documents/w_*.hdr Dateien. w_quest.hdr war zwar noch ganz interessant anzuschauen, mehr aber leider auch nicht :(

An dieser Stelle ist Vorsicht geboten! In der Genome-Engine und ihren Nachfolgern (G3 bis heute) ist der Begriff Skript je nach Hintergrund nicht ganz eindeutig.

In den Info-Skripten sind im Kern die einzelnen Dialoge beschrieben, d. h. sie enthalten Informationen darüber, wer was wann wem sagt. Skripte im eigentlichen Sinne -- also zum Beispiel das ConsumeScript "ConsumeElex" aus dem Eingangspost -- sind quasi Teil des Quellcodes des Spiels (im Gegensatz zu den Info-Skripten, die wie Textur- oder Sounddateien Ressource-Dateien sind, kein Code).

Aus diesem Grund haben wir versucht in Risen 1 Infos und Skripte als zwei verschiedene Bezeichnungen zu prägen.

Praktisch bedeutet das, dass alles, was in den Infos steht, im Dialog stattfindet; richtig ist aber auch, dass ich in diesen Infos u. a. Skripte aufrufen kann, um z. B. NPCs Items ins Inventar zu legen oder um Sektoren zu aktivieren und zu deaktivieren. Aber aufgepasst, wichtig ist, dass ich an dieser Stelle eine Info-Ressource ändere, nicht das eigentliche (weiterhin unantastbare) Skript. Wie Infos sind auch Templates Ressourcen -- und auch Templates können an gewissen Stellen Skripte aufrufen. Genau das passiert mit dem "ConsumeElex"-Skript: Wenn mein Template über ein "ConsumeScript" verfügt, dann kann es idR auch vom Spieler aus dem Inventar heraus angeklickt und konsumiert werden. (So, wie man es vom klassischen Heiltrank oder dem Elextrank her kennt.) Wenn der Spieler dann also auf seinen Elextrank geklickt hat, dann wird genau das Skript aufgerufen, das als ConsumeScript (hier ConsumeElex) eingetragen ist.

Kurz zusammengefasst: In den Ressource-Dateien (Templates, Infos; Zugang über Baltrams resman, den Resource Manager) kannst du zwar manchmal ändern, welches Skript aufgerufen wird (sofern dieses Skript die entsprechenden Bedingungen erfüllt), das aufzurufende Skript selbst kannst du allerdings nicht ändern. (In Risen 1 wäre dies möglich.)

---

Bzgl. deines Problems (und basierend auf dem It_Po_Resistance.r3tpldoc aus Risen 3) glaube ich auch nicht, dass die beiden Properties ConsumeScript und Amount zusammenhängen. Oder hattest du das bereits ausprobiert und erfolgreich getestet? §kratz

[Baltram]

doch in welche Sector Dateien müsste man das Template dann übernehmen, damit z.B. auch selbst hergestellt Tränke davon betroffen sind?Für Items reicht es aus, die Templates zu verändern. Die Sektoren spielen da keine Rolle.
(Items kommen zwar auch in Sektoren vor, aber sobald man sie aufhebt und sie ins Inventar wandern, bestimmen nur noch die entsprechenden Templates, welche Eigenschaften sie haben.)


Kommt man irgendwo an diese Skripte heran?Nein, an den Skripten können wir nichts ändern, die sind fest in der ELEX.exe verbaut. Siehe JFarons Antwort.


Kann es sein, dass es noch ein paar überbleibsel aus G3 und Risen im Code gibt?Aber sicher!


edit: sieht nur durch die Zeilenumbrüche einiger sehr langen Arrays etwas unübersichtlich aus, das dürften wohl die Stellen sein, an denen die hashes fehlen.Dort wo die Hashes fehlen steht so etwas wie <unknown hash 0xFFFFFFFF> oder <unknown class 0xFFFFFFFF>, sollte aber nicht häufig vorkommen.
Die langen Arrays, die mit Bytes gefüllte sind (etwa <10 00 00 00 47 45 43 32 [...]>), stehen für Daten, die in einem (noch) unbekannten Format sind.


edit2: Wenn man den elexresman verwendet, muss man die .hdr Endung erst noch in .elexhdr umbennen. Mit dem r3resman klappt das auch ohne. Die Ergebnisse scheinen sich dabei nicht zu unterscheiden.Danke für den Hinweis, in der nächsten Version werden die Dateien wieder auf .hdr und .hdrdoc enden (anstatt .elexhdr und .elexhdrdoc).

[Penthesilea]

Wow, danke für diese ausführliche Antwort :)
Evtl. sollte ich mal dem Moddingbereich von Risen einen besuch abstatten und mich dort ein bisschen einlesen^^

Ich hatte schon befürchtet, dass man an die Skripte nicht herran kommt. Da müsste man sich ggf. noch was anderes überlegen. Ob die beiden Properties zusammenhängen konnte ich noch nicht testen, werde ich heute Abend aber noch versuchen und dann berichten ;)

Angenommen es funktioniert (und selbst wenn nicht wäre das ggf. an anderer Stelle nochmal interessant), müsste ich ja sowohl das Template ändern, als auch sämtliche *_Items.elexsec, doch bleibt dann immernoch das Problem mit selbst hergestellen Tränken. Werden diese vom Spiel gemäß des Templates erstellt und wären damit schon abgedeckt oder gäbe es da noch mehr zu beachten?

edit: Ok, letzteres hat Baltram beantwortet wärend ich am tippen war^^ Danke dafür :)

edit2: Habs jetzt mal ausprobiert und "unsigned int Amount = 1" unter dem Aufruf von dem Skript auf einen höheren Wert gesetzt, ändert aber leider nichts...hab ich auch nicht wirklich erwartet aber versuchen kann man es ja mal^^
Da der Skriptaufruf unter "ClassData" steht, nehme ich mal an, dass an dieser Stelle auch wirklich nur klassifiziert wird und kein Einfluss auf die Menge genommen werden kann. Schlimmstenfalls kann man die Tränke ja auch anders nerfen....teurere Herstellung würde mir da spontan noch einfallen.

[tombom81]

sind quasi Teil des Quellcodes des Spiels (im Gegensatz zu den Info-Skripten, die wie Textur- oder Sounddateien Ressource-Dateien sind, kein Code).naja, in den Risen 3 Infos gibt es z.B. gCInfoCommandAttack; das geht über eine Resourceneigenschaft weit hinaus; ich würde behaupten, dieses Command (und damit die Info, in der es steht) haben Codeeigenschaften, weil ausführbarer code aufrufen wird.

Das könnte man nachweisen, indem man in der Attack-Routine einen Breakpoint setzt, dann über den stack zum Aufrufpunkt zurückverfolgt; leider fehlen mir momentan die tools, das nachzuweisen (mit windbg komme ich nicht wirklich klar).

Dieser Ansatz wäre aber insofern interessant, weil man gegebenenfalls neue Verknüpfungen von den Infos (also neue Commands) zu anderen Routinen herstellen könnte, wenn man den Ablauf erstmal verstanden hat.

[JFaron]

naja, in den Risen 3 Infos gibt es z.B. gCInfoCommandAttack; das geht über eine Resourceneigenschaft weit hinaus; ich würde behaupten, dieses Command (und damit die Info, in der es steht) haben Codeeigenschaften, weil ausführbarer code aufrufen wird.
Worauf ich hinweisen wollte ist, dass Skripte und Infos ("Info-Skripte") zwei verschiedene Paar Schuh sind. Auf Infos haben wir über den resman Zugriff, auf die Skripte nicht. Dafür wäre sowas nötig: https://forum.worldofplayers.de/forum/threads/886883-release-RisenSDK

gCInfoCommandAttack wird (anders als beim Elextrank) immer aus einem Dialog heraus aufgerufen, denn das ist die ultimative Beschränkung der Infos. Mithilfe von gCInfoRunScript (Risen 1) kannst du von diesem Punkt ausgehend auch noch viel mehr machen, zB ConsumeElex aufrufen. (Obwohl ich nicht weiß, ob so ein Aufruf mit diesem Skript kompatibel wäre. Aber an ConsumeElex selbst (oder auch an den Inhalt des Attack-Commands) kommst du nicht ran -- nicht über die Infos. Das ist, was ich richtig stellen wollte. :gratz

[Penthesilea]

Ist halt wirklich sehr schade, kann so nicht mal die kleinere "Fixes" die ich mir vorgestellt hatte, realisieren oder jedenfalls nicht ohne Bugs. Hatte jetzt zuletzt mal die Stims in Angriff genommen um diese aus dem Inventar heraus benutzbar zu machen und nicht immer einen Slot auf den Quickslots braucht. Funktioniert soweit auch wunderbar, nur das man die Stims dann futtern kann wie Bonbons weil scheinbar keine Abfrage erfolgt, ob ausreichend Energie zur Verfügung steht. So lange Energie vorhanden ist, wird diese abgezogen aber wenn alles aufgebraucht ist, störts auch niemanden :rolleyes:

Musste um das umzusetzen auf das "InventoryUse_Player_ConsumeFood" Skript zurückgreifen, da wundert mich das auch nicht, wenn so eine Abfrage nicht erfolgt. Ein Blindschuss mit "InventoryUse_Player_UseStim" hat leider nicht funktioniert.

[JFaron]

Hatte jetzt zuletzt mal die Stims in Angriff genommen um diese aus dem Inventar heraus benutzbar zu machen und nicht immer einen Slot auf den Quickslots braucht. Funktioniert soweit auch wunderbar, nur das man die Stims dann futtern kann wie Bonbons weil scheinbar keine Abfrage erfolgt, ob ausreichend Energie zur Verfügung steht.

Wird jetzt rein spekulativ -- weder hab ich R3 gemoddet noch besitze ich ELEX, aber du hast doch einen neuen gEInteractionType_InventoryUse_Player-Block erstellt, damit die Stims aus dem Inventar heraus verwendet werden können. Was vorher nicht ging. Habe ich das richtig verstanden? Du könntest versuchen in diesem neuen Block als Interact-Script einfach das Script zu verwenden, das der QuickUse-Block aufruft. (Ich vermute QuickUse_Player.)

Die Idee wäre also, aus dem Inventar heraus das QuickUse-Script aufzurufen. Keine Ahnung ob das funktioniert.

(Was hat es denn eigentlich mit dieser Energie auf sich? Wird die noch für andere Tränke (oder irgendetwas anderes, was man sich abschauen könnte) verwendet? Wenn ja, wäre auch InventoryUse_Player_ConsumePotion (o. ä.) einen Versuch wert. :))

[Penthesilea]

Wird jetzt rein spekulativ -- weder hab ich R3 gemoddet noch besitze ich ELEX, aber du hast doch einen neuen gEInteractionType_InventoryUse_Player-Block erstellt, damit die Stims aus dem Inventar heraus verwendet werden können. Was vorher nicht ging. Habe ich das richtig verstanden? Du könntest versuchen in diesem neuen Block als Interact-Script einfach das Script zu verwenden, das der QuickUse-Block aufruft. (Ich vermute QuickUse_Player.)

Die Idee wäre also, aus dem Inventar heraus das QuickUse-Script aufzurufen. Keine Ahnung ob das funktioniert.

(Was hat es denn eigentlich mit dieser Energie auf sich? Wird die noch für andere Tränke (oder irgendetwas anderes, was man sich abschauen könnte) verwendet? Wenn ja, wäre auch InventoryUse_Player_ConsumePotion (o. ä.) einen Versuch wert. :))

Ich weiß gar nicht was ich sagen soll...aber das hat tatsächlich funktioniert :D :gratz

Der Block sieht jetzt so aus:

class gCInteraction {
Version = 1;
Properties {
enum gEInteractionType Type = gEInteractionType_InventoryUse_Player;
class eCScriptProxyScript CanInteractScript = "";
class gCScriptProxyAIFunction PreInteractScript = "";
class gCScriptProxyAIFunction InteractScript = "QuickUse_Player_UseStim";
class eCScriptProxyScript PostInteractScript = "";
}
ClassData {
}

Hätte nicht gedacht, dass man die so kombinieren kann.

Jetzt muss ich nur noch ausknobeln wieso es bei einem einzigen Stim nicht funktioniert, dann stelle ich das hier auch rein :)

Vielen vielen Dank für diesen wirklich grandiosen Tipp :)

edit: Das diese Lösung nicht für alle Stims funktionierte war, dass einige von denen nicht als "Stim", sondern als "Spell" klassifiziert sind. Entsprechend habe ich bei denen "QuickUse_Player_UseStim" geändert in "QuickUse_Player_Spell" und jetzt funktioniert alles :)

edit 2: Ich bin jetzt auch auf eine Lösung für mein ursprüngliches Problem mit den Elextränken gekommen. Beim dürchwühlen der Templates bin ich auch auf die PC_HERO.elextpl gestoßen und habe dort gesehen, dass der Kältewert als ganz normaler Skill eingetragen ist. Also habe ich kurzer Hand einen weiteren gCModifySkill-Block bei den Elextränken hinzugefügt:


class gCModifySkill {
Version = 1;
Properties {
enum gESkillModifier Modifier = gESkillModifier_AddValue;
int Amount = 1;
enum gESkill Skill = gESkill_Soul;
}
ClassData {
}
}

Jetzt klappt das auch ganz wunderbar und der Kältewert steigt direkt um 1 (naja, wahrscheinlich eher um 1,1 das muss ich noch testen)