[Modding] Fragen zur Dialog-Modifikation

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
Die states unterscheiden sich dann aber zwischen bgee und eet. Ich kann die noch finden. Aber was ist mit BGT?
Mit dem was ich wben beschrieben habe unterscheiden sich die States zwischen bgee und eet gerade nicht - aus Moddersicht betrachtet. Im laufenden Spiel nach der EET_End dann natürlich schon, aber das intwressiert nicht weil die Mod davor inatalliert wird.
Bei der BGT unterscheiden sich die States, genau. Wobei es hier einen feste Zahl gibt, da BGT immer auf dieselbe Art Imoens bg1-Begrüßungsdialog und ihren BGII-Begrüßungsdialog verschmilzt. (Da BGT aus den unveränderten Originalspielen erstellt wird).
Manche der cpmvars.tpa haben auch dafür schon OUTER_SPRINTs. Dasselbe Problem hat auch Edwin, Viconia, Minsk und Jaheira.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Das heißt ich verwende dann die IMOEN2_ und die gleichen States wie auch für BG 1. Weil andersrum weiß ich nicht, welche States in der IMOEN2 von anderen Mods hinzugefügt werden und damit auch nicht, bei welchen States die aus der IMOEN_ dann nachher landen... Richtig?

zu BGT: kann ich das nachlesen? Also steht das irgendwo, welche states das werden?

Und dann benötigt man die OUTER_SPRINTS für states eigentlich nur für BGT? Oder halt auch für nicht-NPC Dialoge bei bgee und eet?
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
Das heißt ich verwende dann die IMOEN2_ und die gleichen States wie auch für BG 1
Ja. Den andersrum Fall kannst Du vergessen, da Du die Mod nicht nach EET_End installieren wirst. Wie Du schon gemerkt hast wird man da sonst wahnsinnig, und es läuft der Idee der EET_End komplett zuwider.

states eigentlich nur für BGT? Oder halt auch für nicht-NPC Dialoge bei bgee und eet?
Da Du eine Datei verwenden möchtest logischerweise auch für BG:EE und EET.

Hast Du in die cpmvars.tpa mal reingeschaut, welche da definiert sind? Du musst ja nur wissen, welcher State die "0" ist, danach kannst Du abzählen. Falls BeamDog die Statenummern nicht in der EE verändert hat...
Wenn ich mal wieder am richtigen Rechner bin kann ich auch nachsehen.
Erfahrungsgemäß ist es aber ungünstig, auf der EE zu entwickeln und dann erst die BGT-Kompatibilität einzufügen. Andersrum ist eine Kompatibilität sicher, sorum nicht.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
es gibt sehr viele unterschiedliche cpmvars... (und deswegen finde ich die echt unpraktisch) Ich habe da auch schon einige mit states gefunden, aber dieser state für Imoen war nicht dabei.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Code:
++ @17 DO ~SetGlobal("M8IGImoenIsGone","GLOBAL",92) DisplayStringHead(Myself,@18) EscapeArea()~ EXIT

Kompilieren kann man das ohne Warning. Aber glaubt ihr, dass das funktioniert mit dem DisplayStringHead? Also dass man es tatsächlich sehen kann im Spiel? In der Konsole nachlesen müsste auf jeden Fall funktionieren.
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
DisplayStringHeads sind immer sehr schnell weg. Wenn es was ist, was der Spieler auf alle Fälle sehen soll, dann lieber einen richtigen Dialog starten (und Journaleintrag setzen wär das Optimum für die "Spielerawareness"^^). Um was geht es denn?
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Nur um ein kurzes "Damn you Charname", weil der böse Sachen gesagt hat, deswegen dann auch das EscapeArea. Also nichts, was Inhalt hat.

Journal-Einträge muss ich auch mal noch lernen... das habe ich glaube ich noch gar nie genutzt...
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
Nur um ein kurzes "Damn you Charname", weil der böse Sachen gesagt hat, deswegen dann auch das EscapeArea. Also nichts, was Inhalt hat.
Naja - ist das Imoen und danach ist sie weg für immer oder sowas in der Art - dann würde ich mehr Vorwarnung und Info erwarten, weil das sonst zu großer Verwirrung und Frust führen kann.
EDIT: Vor allem, weil es ja schon ein Dialog ist. Statt DisplayString Head lieber eine Antwortzeile des Characters und dann das EscapeArea() (idealwerweise mit ActionOverride() so dass NPC-Mods einfach einen Einmischdialog einfügen können ohne eine zusätzliche Passback-Zeile einfügen zu müssen).
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Das ist schon der Dialog mit "sicher?", "ja, hau ab" ;)
Mit der anderen Antwort kann man das wieder einrenken.
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
Wenn der DisplayStringHead gesehen wird vom Spieler könnte das klappen. Ansonsten hat ein Dialogende hinter der Reply Option die Tendenz, beim Spieler als Bug/Dialog ist abgebrochen wahrgenommen zu werden.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Naja, viele Dialoge enden mit der Antwort des Spielers. Allerdings solche mit EscapeArea() eher selten, das stimmt schon.
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
Kann sein, dass es im Spiel viele sind. Ist halt meine Erfahrung.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Alleine bei Questgebern:
SAY Nehmt ihr die Quest an:
++ Ja EXIT
++ Nein EXIT

Hat man oft aus meiner Sicht.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Mal ne Frage: kann ich in Dialogen zufallsgeneriert Texte erstellen? Oder muss ich das immer über ein Skript machen, dass dann zufallsmäßig (und weiter über Variablen) den zufälligen Dialogstrang startet? Ich meine man kann das nicht in den in den Dialog-Dateien selbst machen, aber bevor ich mir mit Skripten was abbreche (oder die Idee fallen lasse), frage ich mal besser ;)

Als Beispiel: random(3) soll unterschiedliche Launen zufällig bedienen und führt zu:
a) Hallo CHARNAME, wie kann ich dir helfen?
b) Was gibts?
c) Kann man nicht mal seine Ruhe habe?
Die Antwortoptionen können dann schon dieselben sein. Oder halt darauf eingehen, wenn eh verzweigte Dialoge entstehen.
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
RandomNum() kannst Du natürlich auch in Dialogen verwenden. Die ganzen Zufalls-Textzeilen der Commoner funktionieren so.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Stimmt. Ich hab mir es mal für die ACDuerga.dlg in der ACForres.d angeschaut. Aber die Frage wäre: woher weiß nachher das System, welche RandomNum zusammengehören, wenn ich mehr als eine davon in einer d-Datei habe? Oder geht halt nur eine pro dlg-/d-Datei? Wahrscheinlich kann man das mit der ersten Zahl noch steuern, so dass das System erkennt, dass RandomNum(4,1) und RandomNum(4,2) zusammengehören, aber RandomNum(5,3) nicht mehr dazugehört. Aber 2x RandomNum(2,1) dürfte halt Probleme machen, oder?

Oder aber das geht schon und muss halt noch durch zusätzliche Variablen eingeschränkt werden? Was man ja sowieso in den dlg-Dateien immer macht, damit der "richtige" Dialog kommt, wenn ein Gespräch gestartet wird...

Ich hatte RandomNum tatsächlich kürzlich schon mal gesehen (wahrscheinlich bei FishingForTrouble, da musste ich ein wenig nachlesen), mir aber noch keinen Reim drauf gemacht und es einfach ignoriert.
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
Wie die Engine das genau berechnet und ob die Random-Verteilung wirklich random oder doch etwas biased ist weiß ich nicht, baer wie Du schon vermutet hast, fasst die Engine die Trigger mit der ersten gleich Zahl zu einer Auswahl zusammen, also RandomNum(3,1) mit (3,2) und (3,3). Wenn es nun nur RandomNum(3,1) gibt, dann würde es entsprechend nur in einem Drittel der Fälle einen gültigen Dialog geben, in 2/3 keinen ("hat nichts zu sagen").
 

Taimon

Infinity Engineer
Registriert
25.11.2001
Beiträge
1.501
Die Zufallszahl wird für jeden Akteur einmal pro Skriptrunde neu gewürfelt.
Mehrere Checks desselben Akteurs in derselben Skriptrunde vergleichen also gegen denselben Wert.
 

Maus

Senior Member
Registriert
07.08.2002
Beiträge
9.380
Eine Frage zu PID:
Mein Problem ist: wie stelle ich sicher, dass die PID-Dialoge (bzw. ist es ja nur einer meist; ja, Brandock hat zwei) nur dann ausgeführt werden, wenn auch wirklich die PID beabsichtigt ist? Ich habe das Skript von Jastey für BG1 gesehen, das mache ich sicher nicht, weil zu kompliziert. Aber wenn ich bspw. einen PID-Dialog habe und einen für einen getriggerten Dialog, der mit einer GLOBAL "gesichert" ist, wie stelle ich sicher, dass bei dem getriggerten Dialog nicht der PID-Dialog kommt? Beide wären ja erstmal true().

Das häufig verwendete IsGabber(Player1) sollte nichts ändern, weil das auch bei getriggertem Dialog true ist, oder?

Meine zweite Idee war so etwas wie WEIGHT #500 zu benutzen, damit der PID-Dialog nur kommt, so lange kein anderer true ist. Aber das funktioniert eigentlich nur, wenn danach kein weiterer kommt und der PID-Dialog der letzte in der d-Datei ist? Und dann könnte man sich das WEIGHT auch sparen? Klingt für mich aber halt auch ziemlich riskant, da darf man dann keinen Fehler machen und bei der Installation kein "Schluckauf" passieren...

Andere Ideen?

p.s.: meine aktuelle PID-Abfrage:
~InParty(Myself) NumTimesTalkedToGT(3) IsGabber(Player1) !StateCheck(Myself,CD_STATE_NOTVALID)~
 

Jastey

Matron Modderholic
Registriert
16.05.2004
Beiträge
12.922
Aber wenn ich bspw. einen PID-Dialog habe und einen für einen getriggerten Dialog, der mit einer GLOBAL "gesichert" ist, wie stelle ich sicher, dass bei dem getriggerten Dialog nicht der PID-Dialog kommt? Beide wären ja erstmal true().
Der PID ist entweder
1- ganz "unten" in der dlg, oder
2 - Dialogue "darunter" kriegen einen höhren WEIGHT-Wert.

Das heißt, triggerst Du einen Dialog über Skript, dann findet die Engine ihn zuerst entweder, weil sie von oben nach untern die dlg durchsucht, oder weil sie die mit gewichtigerem WEIGHT-Wert (der niedrigere) zuerst abprüft.

Hast Du einen getriggerten Dialog mit Checkvariable, der sich unterhalb des PID befindet aber keinen gewichtigeren WEIGHT-Wert, dann ergibt das einen Stutterbug.
Das kannst Du in Deiner eigenen Mod aber steuern: Breagar z.B. installiert den PID erst am Ende der Kompatibilitätskomponente. Ich lasse den PID zumindest in der tp2 als letzte d-file kompilieren, achte dann aber darauf, dass über Crossmod eingefügte Dialoge immer einen WEIGHT #-1 kriegen. Letzteres sollte man bei Dialogen in die J.dlg eh machen - also auch bei anderen NPCs - genau für den Fall, dass eine andere Mod einen PID für diesen NPC eingefügt haben könnte.
~InParty(Myself) NumTimesTalkedToGT(3) IsGabber(Player1) !StateCheck(Myself,CD_STATE_NOTVALID)~
Das InParty() kannst Du Dir sparen, weil der J.dlg nur für NPC in der Gruppe gilt; die Abfrage, ob der NPC sprechen kann auch, sonst triggert der Dialog ja eh nicht. Das mit dem NumTimesTalkedTo größer 3 musst Du wissen.
 
Oben