[Modding] Fragen zur Dialog-Modifikation

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
Was muss ich machen, um einem existierendem Dialog eine zusätzliche Antwortoption mit Bedingung zuzufügen?

Dialog finden, mit WeiDU in eine *.d umwandeln, dort den Block finden und sich die Nummer bzw. den state(?) merken oder aufschreiben. Und dann? EXTEND_TOP DLG-Name State? Und gibt es auch EXTEND_BOTTOM? Oder kann ich gar eine Nummer zuweisen, wo zwischen die ganzen Antworten die neue rein soll?

Und ja, deswegen muss man nicht einen neuen Thread aufmachen, aber ich vermute, da kommt schon noch mehr ;)

COPY_TRANS muss ich ja nur nutzen, wenn da noch andere sich dranhängen könnten (also bei populären Einmischstellen...)?
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Dafür einen Thread zu machen finde ich nicht verkehrt.

Bei einem exitierenden Dlg musst Du die Statenummer wissen, genau. Spezialfälle hier sind in der BGT die Dlgs der NPCs in BG1, die auch in BGII auftauchen, weil diese in der BGT hinten an die BGII-Dialoge angehängt werden. Sprich: Imoens Dlg aus BG1 ist irgendwo an ihren Dlg von BGII angehängt. Das sind dann zwar auch feste Nummern, aber eben andere Zahlen als für BG:EE oder EET (in der EET patcht man mit der Mod auch den BG1-Dialog. Der wird dann danach von der EET_End zusammengeführt, da muss man sich als Modder nicht um verschobene Statenummern kümmern).

Also, Du weißt die Statenummer. Dann kannst Du mit EXTEND_BOTTOM eine weitere Antwortoption einfügen. Die Syntax dazu ist folgende und kommt in eine d-Datei:
Code:
EXTEND_BOTTOM ~BRAGE~ 9
+ ~Global("C#q13Brage_AskedQuestions","GLOBAL",0) GlobalLT("C#Q13_BragesSwordQuest","GLOBAL",3)~ + @6 + brage_01
+ ~Global("C#q13Brage_AskedQuestions","GLOBAL",0) GlobalLT("C#Q13_BragesSwordQuest","GLOBAL",3)~ + @7 + brage_08
END

Die Höflichkeitsregel ist hier, dass man dies auch wirklich nur über EXTEND_BOTTOM macht. Der Grund ist, dass andere Mods eventuell bestimmte Antwortoptionen mit zusätzlichen Transaktionen oder auch Triggern versehen möchten. Fügt eine Mod vorher eine Antwortoption über EXTEND_TOP ein, verschieben sich die Nummern der Reply Options und die nachfolgende Mod patcht die falsche Antwortoption. (In I4E verwende ich eine Syntax von Argent, die das verhindert. Die wird aber nicht von allen anderen Mods verwendet.)

Sagen wir mal, Du möchtest nicht nur eine Antwortoption einfügen, sondern ein Charakter / NPC soll voher noch einen Satz sagen. Dann ginge das auch über EXTEND_BOTTOM, ist aber recht aufwändig. Hier eignet sich INTERJECT, das den Originalgesprächsfluss unterbricht und umleitet (im Gegensatz zu INTERJECT_COPY_TRANS). INTERJECT sollte daher nur verwendet werden, wenn 1. der Gespächsfluss definitiv gestört werden soll, oder 2. es mit einem COPY_TRANS des ursprünglichen Dialog-States endet, um den Abstecher als Kreis zu schließen und den Originaldialog wieder aufzunehmen (je nachdem, wie der NPC Einwurf mit Antwortoptionen aussehen soll).
Die Syntax hiervon wäre z.B. so. Dies ist ein geschlossener Einwirf mit Rückführung zum Originaldialog. Es ist Greys freudiges "Wau" wenn Oubleck Greywolf erwähnt, der HC kann darauf antworten, Oublek sagt noch was, dann geht der Originaldialog normal weiter, was über das COPY_TRANS gewährleistet wird:
Code:
INTERJECT ~%tutu_var%OUBLEK~ 0 C#GreyOublek0
== C#GreyJ IF ~OR(2) InParty("C#Grey") Global("C#GreyJoined","GLOBAL",2)  //Abfrage die auch 7. Partymember-Modus berücksichtigt
InMyArea("C#Grey") !StateCheck("C#Grey",CD_STATE_NOTVALID)~ THEN @60
END
++ @61 EXTERN ~%tutu_var%OUBLEK~ grey_ict
++ @62 EXTERN ~%tutu_var%OUBLEK~ grey_ict
++ @63 EXTERN ~%tutu_var%OUBLEK~ grey_ict

APPEND ~%tutu_var%OUBLEK~

IF ~~ THEN grey_ict
SAY @64
COPY_TRANS ~%tutu_var%OUBLEK~ 0
END

END //APPEND

COPY_TRANS muss ich ja nur nutzen, wenn da noch andere sich dranhängen könnten (also bei populären Einmischstellen...)?
COPY_TRANS kopiert alle (bis zur Installation Deiner Mod) vorhandenen Antwortoptionen des Originalstates an die Stelle, wo Du es gesetzt hast. Wenn über EXTEND_BOTTOM eine neue Antwortoption einfügst, kommt es darauf an, was Du möchtest. Machst Du dadurch einen Parallelweg auf? Dann reicht es, wenn Du nach der Antwort wieder zurück zum Originalgespächsverlauf gehst - aber an einer späteren Stelle. Oder ist Deine Antwortoption ein Abstecher, zum Beispiel eine zusätzliche Erklärung, und der Spieler soll danach nochmal die Fragen stellen können, die an dem State hingen, an den Du die weitere Antwortoption gesetzt hast? Dann lässt Du Deinen "Abstecher" mit COPY_TRANS enden und der Spieler sieht alle vorher vorhandenen Antwortoptionen nochmal, nachdem er Deine Frageoption mit Antwort durchgespielt hat.

Das mit den Einmischdialogen ist so eine Sache. Jeder Einmischdialog (mit COPY_TRANS, also auch I_C_T) verschiebt die nachfolgenden Reply Options zu dem sich einmischenden NPC. Das ist das Problem, warum I4E so früh wie möglich installiert werden muss. Denn sobald ein NPC sich an einer Stelle einmischt, an der man nach der verschwundenen Imoen fragen kann, findet I4E diese Stelle nicht mehr. I4E patcht dann zwar immer noch die Originalstelle (z.B. in Tolgerias' Dialog) - aber die dort vorhandenen Antwortoptionen werden dem Spieler nicht mehr angezeigt, sondern nur die nach dem NPC-Einwurf. Das ist auch der Grund, warum Brage's Sword vor BG1NPC installiert werden muss weil sonst die Antwortoption, ihn der Garnison abzuliefern, verloren geht.

Daher gibt es eine zweite Högflichkeitsregel: keinen Einmischdialog in einen Dlgstate machen, der Antwortoptionen enthält. Weil sonst jede Mod nach Deiner keine Antwortoptionen mehr an diesen State anhängen kann bzw. mit Triggern oder Aktionen versehen, da die in Deiner Mod kopierten ausgeführt werden, und nicht mehr die im Originalste.
Ja - diese Regel wird fröhlich von BG1NPC und auch meinen NPC-Mods gebrochen - das Beispiel oben mit der INTERJECT für Grey ist genau eine solche Stelle.
Ich denke aber, dass man die wirklich wichtigen Stellen, wo man Questcharakteren Fragen stellen kann z.B. Thalantyr in seinem "immer wahren" Dialogstate nachdem er zu Beginn rumgemuffelt hat, oder Cromwell wenn er Sachen schmieden soll - ganz gut erkennen kann und diese States dann auf alle für Einmischdialog auslässt.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
Was passiert eigentlich, wenn man nach StartStore kein EXIT macht? Kann man dann den Dialog weiterführen, nachdem man den Laden geschlossen hat?

Und wie ist das mit den weight-states? Die priorisieren ja die Auswahl der Dialoge? Hoher Wert = Hohe Priorität? Oder andersrum? Und benötigt man die überhaupt wenn man sauber mit Variablen triggert?
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Was passiert eigentlich, wenn man nach StartStore kein EXIT macht? Kann man dann den Dialog weiterführen, nachdem man den Laden geschlossen hat?
Gute Frage, keine Ahnung.
Und wie ist das mit den weight-states? Die priorisieren ja die Auswahl der Dialoge? Hoher Wert = Hohe Priorität? Oder andersrum? Und benötigt man die überhaupt wenn man sauber mit Variablen triggert?
Für eine eigene Mod müsste man die richtige Trigger-Reihenfolge ohne die Verwendung von WEIGHT hinbekommen.
Niederer WEIGHT-Wert ist höhere Wichtung, also 0 ist der wichtigste Dialog und wird als erstes abgeragt wenn die dlg aufgerufen wird.

Ich verwende WEIGHT zur höheren Gewichtung an folgenden Stellen, und zwar immer in der .d als "WEIGHT #-1" - weidu macht aus der -1 dann den niedrigsten Wert in der dlg beim Kompilieren:
-wenn ich einem existierenden Chrakter einen zusätzlichen Dialog geben möchte, der für bestimmte Konditionen triggert. Beispiel ist der Dialog von Taerom, wenn man mit Grey das erste mal zu ihn geht.
-in der BST habe ich die questrelevanten Dialoge, die zu bestimmten Konditionen triggern sollen mit einem WEIGHT #-1 versehen. Grund war: der normale Dialog der Charaktere wird zuerst kompiliert (z.B. für den Tower Commander: die "bstrcmdr.d".) Die Quest-d-Dateien werden danach kompiliert (z.B. "z_quest_doppelgangers.d"). Damit die - einmalig auftauchenden - Questdialoge im richtigen Moment auch triggern müssen sie nun einen wichtigeren WEIGHT haben, sonst würde der Commander immer nur seinen normalen "immer wahren" State sagen statt seiner Zeilen zur Doppelgängerquest.

Regel hierzu: die so eingefügten wichtigeren States sollten sich bei existierenden Charakteren immer gleich schließen/deaktivieren, d.h. füge zu existierenden Charakteren keinen neuen Immer-wahren State ein, denn damit wäre es anderen Mods unmöglich, neue Antwortoptionen für diesen CHarakter einzufügen.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
CHAIN IF WEIGHT #-1 ~Global("C0AuraTamoko","GLOBAL",2)~ THEN C0AURAJ tamoko3
~W-wait!!~
DO ~SetGlobal("C0AuraTamoko","GLOBAL",3)~
== TAMOKO ~...~
== C0AURAJ ~O-omachi-kudasai, Tamoko-san!~
== TAMOKO ~...~
== TAMOKO ~You have five seconds.~
== C0AURAJ ~Thank you. Do you... know Amanokagami Reika?~
== TAMOKO ~...~
== TAMOKO ~That is irrelevant to your current cause, is it not? Farewell.~
== C0AURAJ ~But-~
== TAMOKO ~If you desire an answer, gnome, then follow your leader and do as I have asked. Perhaps then we may meet again.~
DO ~AddJournalEntry(@20001,QUEST)~ EXIT

der Code bricht ab, nachdem Tamoko ~...~ sagt. Danach spricht Tamoko weiter mit Charname. Was ist da falsch?
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Dieser "Banter bricht ab"-Bug verfolgt mich wirklich... Ich sehe absolut nichts, was dazu führen würde. Der Dialog wird von Aura mit der "C0AURAJ" gestartet und genau die soll dann auch wieder weitersprechen. Es ist also noch nicht mal ein Wechsel von einem DLG von Aura zu einem anderen wie bei den Fällen abbrechender Banter die mir bisher bekannt sind. Und wenn Aura den Dialog eröffnet hat, dann wird sie wohl auch sprechen können. :confused:
 

Taimon

Infinity Engineer
Registriert
25.11.2001
Beiträge
1.501
Ich würde mir mal in NearInfinity anschauen, was in die DLG-Datei kompiliert wurde. Vielleicht findet man da einen Hinweis.
Davon abgesehen: Wenn jemand mehrere Zeilen hintereinander sagt, kann man doch "=" anstelle von "== DLGJ" verwenden, oder?
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920

Taimon

Infinity Engineer
Registriert
25.11.2001
Beiträge
1.501
Besteht hier noch Bedarf, dass sich das jemand anschaut? (den Dialogabbruch)
Wenn ja, dann bräuchte ich eine kleine Anleitung zum Nachstellen. (welcher Mod, welche Vars setzen, etc.)
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
Da Aura nicht hier im Forum betreut wird, hilft das nicht viel... müsste der Autor selber sich das anschauen. Fixen wird es von uns eher keiner denke ich ;)
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Ihr könnt gerne die Abbrüche in der Brandockmod untersuchen, wenn Banter stattfinden, während er im 7. Gruppenmitgliedsmodus ist. :shine: Genauere Infos über sinnvolle Testcases müsste ich aber erstmal selbst nachsehen, das mache ich wenn ich mir das genauer ansehe.
 

Taimon

Infinity Engineer
Registriert
25.11.2001
Beiträge
1.501
Okay, einfach noch mal kurz Bescheid geben, wenn Du etwas nachstellen kannst.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
Code:
IF ~  True()
~ THEN BEGIN 9 // from:
  SAY #16455 /* ~Don't keep Mr. G waiting now. C'mon you, get going!~ */
  IF ~~ THEN EXIT
END

Kann ich da mit EXTEND_BOTTOM ~~ 9 eine Antwort-Option hinzufügen und so den Dialog verlängern, oder stört da das IF THEN EXIT? Oder wäre hier das ein Fall für EXTEND_TOP damit das IF THEN EXIT nicht stört?
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Oder wäre hier das ein Fall für EXTEND_TOP damit das IF THEN EXIT nicht stört?
1.: Die Riehenfolge hat nicht diesen Einfluss, den Du da andeutest.
2.: Füge nie, nie, niemals nicht Reply Options oder Transactions mittels EXTEND_TOP in Dialogstates ein, das ist schlecht für die Kompatibilität mit anderen Mods. Das verschiebt die Nummerierung aller originalen (bzw. bereits vorhandenen) Reply Oprions, d.h. Mods, die mit ADD_TRANS_ACTION oder ADD_TRANS_TRIGGER arbeiten patchen danach die falsche Reply Option.

Kann ich da mit EXTEND_BOTTOM ~~ 9 eine Antwort-Option hinzufügen und so den Dialog verlängern, oder stört da das IF THEN EXIT?
Ich denke, dass sich das beißt. Man kann Transactions und Reply Options nebeneinander haben wenn sie verschieden (wahre) Trigger haben. Hier wäre es ratsam, mit ADD_TRANS_TRIGGER die originale Transaction mit einem unwahren Trigger zu versehen. Das einfachste ist "False()", aber vielleicht geht es auch etwas genauer je nachdem, für welchen Fall Du die Änderungen haben möchtest.

Oder an diesen Dialogstate einfach keine Antwortoptionen einfügen. ;) Sieht ja eher nach dem Ende eines Dialogs aus.
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Oder über INTERJECT Imoen eine weitere Zeile geben, da die Antwortoptionen anhängen, und das ganze mit einem COPY_TRANS beenden. Dann geht auch die originale Transaction nicht verloren - falls eine Mod da z.B. eine Variable setzt. Das ist kompatibilitätsmäßig die beste Variante. Auch versagt sie nicht, wenn eine Mod hier z.B. einen weiteren Transaction eingefüht hatte, also der Dialogstate nicht nur ein IF~~THEN EXIt sondern noch andere enthält.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
Ich könnte einen weiteren Dialog einfügen. Das Problem ist nur, dass der erste als Voraussetzung True() hat. Den bekomme ich nicht weg (und mit ADD-TRANS-TRIGGER kann ich gleich die Antwortoption anpassen...). Muss ich nur noch schauen, wie das passgenau geht.
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Mit WEIGHT #-1 erzeugst Du einen Dialog, der mit höherer Wichtung aufgerufen wird als alle zum Zeitpunkt der Installation.
Anaonsten kann man auch state trigger verändern.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
Ok, negative weight-states hatte ich jetzt nicht auf dem Schirm. Aber ich glaube, ich habe eine gute Lösung gefunden.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.379
So, Imoen ist ja ein sehr spezieller NPC. Da heißen die Dialoge wohl auch anders. Der Joined-Dialog in bg1ee ist wohl IMOEN2 und ihr Dialog, wenn sie nicht in der Gruppe ist, auch. Daher müsste, wenn sie den HC anspricht, alles hier drin landen. Aber wie sieht das in der EET aus? Nehme ich K4thos Liste, dann müsste das IMOEN2_ sein. Das ist aber eine leere dlg. Aus I4E würde ich tippen, dass es IMOEN2J sein könnte (und nachgeschaut, ist so).

Die states unterscheiden sich dann aber zwischen bgee und eet. Ich kann die noch finden. Aber was ist mit BGT?

Kann mir da jemand den state von der NumTimesTalkedTo(0) raussuchen (bgee 0, eet 1119)? Weil dem Dialog muss ich einen state-trigger verpassen
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.920
Nehme ich K4thos Liste, dann müsste das IMOEN2_ sein. Das ist aber eine leere dlg.
EET funktioniert zum Modden so: Du patchst die BG1 Ressourcen wie von k4thoas anhegeben.
Die EET_End vereinheitlicht das dann und transferieet alle BG1-dlgs und auch ToB-dlgs in die BGII-dlgs. Daher ist nach Installation der EET_End Imoens "BG1"-dlg " leer".
 
Oben