[Modding] Wie weise ich konfliktfrei einer Original-cre ein Override-Script zu?

[Maus]

Ehrliche Antwort: nein. Lass die Spieler da Kreaturen beschwören, das können sie an anderen Stellen im Spiel auch wo das regeltechnisch nicht möglich sein sollte. Lustig, wo überall Nymphen herkommen können...

Ich würde sagen: mach es weiter, wenn dich die Technologie/Technik interessiert, weil du es auch anderswo nutzen könntest und es allgemein immer gut ist, mehr Ahnung zu haben. Ansonsten ist es den Aufwand nicht wert oder kann später auch mal mit einem Update verbessert werden.

 

[Taimon]

Das ist eine gute Idee. Mit einer unsichtbaren Cre habe ich es gestern abend schon versucht, auch das läuft. Wenn ich die cre in einen Bereich stelle, der in der Searchmap ausgeblockt (=schwarz) ist, läuft diese auch nicht Gefahr, von Zaubern etc. getroffen zu werden.
An sich wäre mir eine Cre etwas lieber, weil der Aufwand nicht so groß ist, anstatt in jeder Area einen Area-Trigger hineinzupatchen.

Aus Engine-Sicht sollte es fast keinen Unterschied machen, ob der Block im Area-Skript ist oder ein einem eigenem Actor in der Area.
Wenn ich mich recht erinnere, ist das Area-Skript intern sogar mit einem Pseudo-Actor umgesetzt, folglich dürfte es keinen Einfluss auf die Performance haben. (Es sei denn in den EEs gibt es diesbezüglich Multithreading. In der originalen Engine wurden die Skripte mit ziemlicher Sicherheit sequenziell abgearbeitet.)
Aus meiner Sicht sollte man das dann nur auslagern, wenn es um die Vermeidung von Blockade-Situationen geht. (Falls ein Block im Area-Skript häufig die weitere Ausführung des Skripts verhindert.)

Hier hänge ich auch noch fest. Den Schritt Hilfsfunktion -> patchen zahlreicher Cre's habe ich noch nicht hinbekommen.

Sollte eigentlich "normal" funktionieren.
Also Auswahl der CRE über die COPY_EXISTING TP2-Action (o. ä.) und dann der Aufruf via LAUNCH_PATCH_FUNCTION mit den entsprechenden Parametern.
Vielleicht nochmal konkret beschreiben, welcher Teil unklar ist.

 

[Acifer]

Also Auswahl der CRE über die COPY_EXISTING TP2-Action (o. ä.) und dann der Aufruf via LAUNCH_PATCH_FUNCTION mit den entsprechenden Parametern.
Vielleicht nochmal konkret beschreiben, welcher Teil unklar ist.

Bei den Parametern weiß ich nicht, was ich eingeben soll.
Ich habe in meine tp2 die Funktion per INCLUDE eingefügt. Dann habe ich COPY_EXISTING ~ELFIRPR.CRE~ ~override~ LAUNCH_PATCH_FUNCTION CRE_insert_script_high
eingegeben, weiß aber nicht, was für Parameter ich danach eingeben muss, damit das override-Script gepatcht wird.

Aus meiner Sicht sollte man das dann nur auslagern, wenn es um die Vermeidung von Blockade-Situationen geht. (Falls ein Block im Area-Skript häufig die weitere Ausführung des Skripts verhindert.)

Ah, verstehe. Habe nachgesehen, das ist bisher nicht der Fall. Dann lasse ich doch alles im Area-Script, wenn das besser ist.

Ehrliche Antwort: nein. Lass die Spieler da Kreaturen beschwören, das können sie an anderen Stellen im Spiel auch wo das regeltechnisch nicht möglich sein sollte. Lustig, wo überall Nymphen herkommen können...

Danke für Deine Einschätzung. Ich hadere damit auch ein wenig. Das Reizvolle daran wäre, dass der Spieler dadurch das Gefühl bekommt, sehr weit weg von zuhause zu sein. Und ich würde gerne den Eindruck vermitteln, dass der Ort an sich böse ist. Es wohnen auch Dämonen da, klar, aber die Luft, der Boden, einfach alles ist verdorben und hat sich gegen Dich verschworen. Insofern würde ich zumindest einen Teil, für den ich das o.g. Script brauche, lassen, nämlich, dass bei Zaubern, die Monster beschwören, gelegentlich ein neugieriger Tanar'ri auftaucht.

 

[Taimon]

Bei den Parametern weiß ich nicht, was ich eingeben soll.
Ich habe in meine tp2 die Funktion per INCLUDE eingefügt. Dann habe ich COPY_EXISTING ~ELFIRPR.CRE~ ~override~ LAUNCH_PATCH_FUNCTION CRE_insert_script_high
eingegeben, weiß aber nicht, was für Parameter ich danach eingeben muss, damit das override-Script gepatcht wird.

Die Aufruf-Syntax ist bei Funktionen etwas komplexer als bei Makros. (siehe Readme)
Bei der Funktionsdefinition wurde spezifiziert, welche Variablen die Funktion verwendet:

DEFINE_PATCH_FUNCTION CRE_insert_script_high
     STR_VAR
         arguments=""
BEGIN
...

Die "arguments"-Variable wird später als Override-Skript genutzt:

WRITE_ASCIIE 0x248 ~%arguments%~ (8)

Beim Aufruf der Funktion gibt man also den jeweiligen Skriptnamen mit:

LPF CRE_insert_script_high STR_VAR arguments = ~ELFIRPR~ END

 

[Acifer]

Beim Aufruf der Funktion gibt man also den jeweiligen Skriptnamen mit:

Ah! Da wäre ich jetzt nie drauf gekommen.

Die Aufruf-Syntax ist bei Funktionen etwas komplexer als bei Makros. (siehe Readme)

Die Readme hatte ich hinzugezogen, aber leider nicht verstanden. Zu niedriges Level, fürchte ich...
Vielen Dank, dass Du es mir erklärt hast!

 

[Acifer]

Es funktioniert nun alles reibungslos. Vielen Dank für die Hilfe!

So sieht der fertige Code aus (hoffentlich ohne Fehler...):

Spoiler: Code

EXTEND_TOP ~ELFIRPR.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~ELFIRPR.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~ELFIRPR~ END

EXTEND_TOP ~ELFIRPR2.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~ELFIRPR2.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~ELFIRPR2~ END

EXTEND_TOP ~ELFIRPR3.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~ELFIRPR3.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~ELFIRPR3~ END

EXTEND_TOP ~ELEARPR.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~ELEARPR.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~ELEARPR~ END

EXTEND_TOP ~ELEARPR2.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~ELEARPR2.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~ELEARPR2~ END

EXTEND_TOP ~ELEARPR3.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~ELEARPR3.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~ELEARPR3~ END

EXTEND_TOP ~STALKE.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~STALKE.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~STALKE~ END

EXTEND_TOP ~EFREETSU.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~EFREETSU.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~EFREETSU~ END

EXTEND_TOP ~DJINNISU.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
COPY_EXISTING ~DJINNISU.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~DJINNISU~ END

// summoning monsters / animals will summon Tanar'ri
EXTEND_TOP ~SUMSHT02.bcs~ ~godcall/scripts/abyss_summon_animals.baf~

EXTEND_TOP ~wolfdisu.bcs~ ~godcall/scripts/abyss_summon_animals.baf~
COPY_EXISTING ~wolfdisu.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~wolfdisu~ END

EXTEND_TOP ~dogwasu.bcs~ ~godcall/scripts/abyss_summon_animals.baf~
COPY_EXISTING ~dogwasu.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~dogwasu~ END

EXTEND_TOP ~wolfwwsu.bcs~ ~godcall/scripts/abyss_summon_animals.baf~
COPY_EXISTING ~wolfwwsu.cre~ ~override~
LPF CRE_insert_script_high STR_VAR arguments = ~wolfwwsu~ END

 

[Taimon]

Bei Bedarf kann man das noch etwas wartungsfreundlicher gestalten:

ACTION_FOR_EACH summon IN
    ELFIRPR
    ELFIRPR2
    ELFIRPR3
    ELEARPR
    ELEARPR2
    ELEARPR3
    STALKE
    EFREETSU
    DJINNISU
    wolfdisu
    dogwasu
    wolfwwsu
BEGIN
    EXTEND_TOP ~%summon%.bcs~ ~godcall/scripts/abyss_inner_planes_summon_failure.baf~
    COPY_EXISTING ~%summon%.cre~ ~override~
        LPF CRE_insert_script_high STR_VAR arguments = ~%summon%~ END
END

// summoning monsters / animals will summon Tanar'ri
EXTEND_TOP ~SUMSHT02.bcs~ ~godcall/scripts/abyss_summon_animals.baf~

(Ungetestet. Funktioniert auch nur, wenn das bei allen dasselbe Muster war. Habe nicht alle einzeln geprüft.)
Die Zeilenumbrüche in der FOR-Schleife sind nur für die Optik, könnte auch alles in einer Zeile stehen. (Durch Leerzeichen getrennt.)

 

[Acifer]

Bei Bedarf kann man das noch etwas wartungsfreundlicher gestalten:

Sehr geil! Vielen Dank! Da wäre ich - wie immer - nie von selbst darauf gekommen.

Lass die Spieler da Kreaturen beschwören, das können sie an anderen Stellen im Spiel auch wo das regeltechnisch nicht möglich sein sollte. Lustig, wo überall Nymphen herkommen können...

Ich habe es jetzt so gestaltet, dass es abhängig vom Schwierigkeitsgrad ist. Nicht umsonst gibt es einen SG mit dem Namen "D&D-Regeln", den ich bisher nie so richtig genutzt habe. Dort läuft jetzt das volle Programm an Gemeinheiten ab. Wenn z.B. eine Nymphe beschworen werden soll, erscheint stattdessen mit einer gewissen Wahrscheinlichkeit ein feindlich gesonnenes Alu-Scheusal, bei "Tiere beschwören" erscheinen affenartige Bar-Lgura-Dämonen und so fort.
Bei niedrigerem SG kann der Spieler in gewohnter Weise seine Kreaturen ohne negative Effekte beschwören.

 

[Taimon]

@Acifer
Eine Sache noch zu der Funktion CRE_insert_script_high:
David Wallace (DavidW) hat sicher nichts dagegen, aber man sollte ihn doch kurz um Erlaubnis fragen, wenn man seinen Code benutzt. (falls noch nicht geschehen)
In dem Teil steckt wahrscheinlich nicht viel Arbeit drin, gehört aber trotzdem irgendwie zum guten Ton.

Ich hatte ja einen Teil der Funktion entfernt. Der Fall, dass alle Skriptplätze belegt sind, könnte natürlich trotzdem eintreten.
Also entweder diesen Teil auch noch vom Original kopieren oder irgendeine andere Lösung einbauen. (Zum Beispiel eine Warnung ausgeben und die entsprechende CRE nicht patchen.)

 

[Acifer]

David Wallace (DavidW) hat sicher nichts dagegen, aber man sollte ihn doch kurz um Erlaubnis fragen, wenn man seinen Code benutzt. (falls noch nicht geschehen)

Das mache ich. Ich werde alles zunächst intensiv im Spiel testen. Wenn es bleiben kann, frage ich bei DavidW nach. Ich habe mir angewöhnt, erst, wenn ich ganz sicher bin, dass ich anderer Leute Arbeit auch verwenden möchte, um Erlaubnis zu fragen, weil ich schon viele Dinge kurz vor knapp wieder herausgeschmissen habe.

Also entweder diesen Teil auch noch vom Original kopieren oder irgendeine andere Lösung einbauen.

Mache ich.

 

[Maus]

Hier die Frage, ob folgender tp2-Eintrag korrekt ist, wenn man nicht das override-Skript, sondern das default-Skript ändern möchte:

    COPY_EXISTING ~ULCAST.CRE~ ~override~
    READ_ASCII 0x268 ~walk~
    PATCH_IF ((~%walk%~ STRING_EQUAL ~RANDWALK.BCS~))
    BEGIN
    WRITE_EVALUATED_ASCII 0x268 ~WTARSGT.BCS~ #8
    END
    BUT_ONLY

Ist die "#8" die Länge des ASCII-Blocks? Dann müsste es passen. Oder ist es etwas anderes?

Und da es ein fertiges Skript aus dem Spiel ist: Dann müsste es oder könnte es auch einfach WRITE_ASCII sein, oder?

 

[Jastey]

@Maus und jetzt bitte die fortgeschrittene Variante, wo Dein Patch durch alle Skriptslots zirkelt, falls es nicht dieser eine ist. ^^

 

[Maus]

So, der obere Syntax war nicht korrekt, man muss das ".BCS" im Namen weglassen. Dann funktioniert es. Haken dran

 

[Jastey]

Boah, das hätte ich eigentlich sehen können.

 

[Maus]

Ach ja, und das EVALUATED weglassen... hatte ich vergessen zu erwähnen.

und kein Ding, da bekommt man eine sinnvolle Fehlermeldung und kann es korrigieren. Bzw. es funktioniert schon und man hat einen komischen Eintrag in der cre

 

[Argent]

Beim READ_ASCII sollte man die Option "NULL" anfügen, um nur die lesbaren Zeichen einzulesen. Ansonsten wird der komplette Text (inklusive möglicher 0-bytes) eingelesen, was den nachfolgenden Stringvergleich erschwert.

Und statt STRING_EQUAL würde ich STRING_EQUAL_CASE (bzw. STR_EQ) nutzen, da der Name des Skripts nicht unbedingt nur aus Großbuchstaben besteht.

So, der obere Syntax war nicht korrekt, man muss das ".BCS" im Namen weglassen. Dann funktioniert es. Haken dran

Sowohl bei WRITE_ASCII als auch beim Stringvergleich.