[Tutorial] Moddingerfahrungen - Tricks und Kniffe

Dieses Thema im Forum "Modding Forum" wurde erstellt von Ascalon, 8. September 2009.

  1. Jastey

    Jastey Senior Member

    Registriert seit:
    Mai 2004
    Beiträge:
    6.364
    Zustimmungen:
    145
    Weiter oben hatte ich schon mal geschrieben, dass es Aktionen gibt, die am Ende der Transaction-Liste stehen müssen - weil sonst dahinter befindliche Aktionen nicht mehr ausgeführt werden. Dazu gehören JoinParty(), LeaveParty(), MoveToArea(), EscapeAreaMove().

    Es gibt aber auch Aktionen die dürfen nicht am Ende der Transaktions-Liste stehen, sonst werden sie schlichtweg nicht ausgeführt. Dazu gehört GiveItemCreate().

    In folgender Riehenfolge wird kein Gegenstand übergeben:
    Code:
    DO ~ActionOverride("C#Q01004",TakePartyGold(20))
    SetGlobal("C#Q01_TalkedToTulbor","GLOBAL",2)
    SetGlobal("C#Q01_BoughtAlternative","GLOBAL",1)
    GiveItemCreate("C#Q01004",[PC],1,0,0) //wird hier NICHT ausgeführt!
    ~ GOTO 27
    Der Gegenstand wird nur übergeben, wenn die Aktion GiveItemCreate() weiter vorne steht:

    Code:
    DO ~ActionOverride("C#Q01004",TakePartyGold(20))
    GiveItemCreate("C#Q01004",[PC],1,0,0) //so wird es ausgeführt
    SetGlobal("C#Q01_TalkedToTulbor","GLOBAL",2)
    SetGlobal("C#Q01_BoughtAlternative","GLOBAL",1)
    ~ GOTO 27
    (Dies gilt erstmal vor allem für die EE, ob es dieses Problem auch in der alten Engine gab, weiß ich nicht.)
     
    Zuletzt bearbeitet: 8. August 2019
  2. Acifer

    Acifer Senior Member

    Registriert seit:
    Apr. 2019
    Beiträge:
    477
    Zustimmungen:
    36
    Es ist ja sowohl möglich, Scripte über das Cre-File als auch über das Are-File den Kreaturen zuzuordnen. Was ich bisher nicht wusste, war, dass die im are-File angegebenen Scripte die Scripte im cre-file "overriden". Das bedeutet z.B., wenn im cre-file das Override-Script "SHOUTDLG" zugewiesen ist, im are-file aber nicht, wird der Dialog nicht gestartet.
    Normalerweise ist das kein Problem, wenn die Kreaturen einfach in der Area platziert werden.
    Dann zählt das Script aus dem cre-file und alles läuft problemlos.

    Aber:

    Falls jemand außer mir noch den DLTCEP fürs Area-Editing verwendet, spielt das schon eine gewisse Rolle. Dort gibt es im "Actor"-Header den Button "refresh fields", der mit einem Knopfdruck alle Scripte aller Kreaturen im Area-Bereich updatet. Praktisch, um dort zu sehen, welche Scripte den Kreaturen zugewiesen wurden. Unpraktisch, wenn man im Nachhinein ein Script einer Kreatur ändert. Dann läuft in der Area nämlich noch das "alte" Cre-File-Script ab. Die Lösung ist einfach: Einfach wieder "refresh fields" drücken.

    Ich bin vorhin fast verzweifelt, weil ein Dialog nicht losgegangen ist, obwohl im cre-File alles richtig war. Aber eben nicht in der Area, in der die Kreatur platziert wurde.
     
  3. Jastey

    Jastey Senior Member

    Registriert seit:
    Mai 2004
    Beiträge:
    6.364
    Zustimmungen:
    145
    Sehr guter Hinweis! Das ist einem beim normalen Modden echt nicht klar.
     
  4. Acifer

    Acifer Senior Member

    Registriert seit:
    Apr. 2019
    Beiträge:
    477
    Zustimmungen:
    36
    Danke! Vielleicht eine etwas doofe Frage, aber:
    Gibt es eigentlich Erfahrungen, einem gleichen cre-file im Area-Actor-Header unterschiedliche Scripte zuzuweisen? Ich bin bisher immer den dilettantischen Weg gegangen und habe dafür unterschiedliche cre-files erstellt, weil ich die Befürchtung hatte, dass es sonst Chaos gibt.
    So könnte man ja z.B. ein Wolf-cre-file erstellen, 20 Wölfe in die Area setzen und jedem Wolf unterschiedliche Scripte (und Dialoge?) zuweisen. Nur die DeathVariable bliebe immer gleich. Funktioniert das zuverlässig?
     
  5. Jastey

    Jastey Senior Member

    Registriert seit:
    Mai 2004
    Beiträge:
    6.364
    Zustimmungen:
    145
    Ich vermute schon. Hast Du mal nach Beispielen in den Originalareas geschaut?
    Man kann übrigens über die area auch Deathvariables zuweisen, die die in der cre überschreiben. Ich hatte das letzthin im Originalspiel gesehen, aber vergessen, wo. War glaube ich in der EE von daher weiß ich nicht, ob es auch im Originalspiel ging.
     
  6. Acifer

    Acifer Senior Member

    Registriert seit:
    Apr. 2019
    Beiträge:
    477
    Zustimmungen:
    36
    Da konnte ich in BG2 bisher- außer ein Script bei Rylock- nichts finden.
    Dass man die Death-Variable auch ändern kann ist ja cool.
    Ich werde mal ein bisschen herumprobieren und wieder berichten.
     
  7. Jastey

    Jastey Senior Member

    Registriert seit:
    Mai 2004
    Beiträge:
    6.364
    Zustimmungen:
    145
    Das mit der Deathvariablen hat mich fast zum Verzweifeln gebracht, weil ich esnlange nicht verstanden habe, was da abgeht. Wenn ich mich wieder erinnere wo.das war, sage ich bescheid.
     
  8. Jastey

    Jastey Senior Member

    Registriert seit:
    Mai 2004
    Beiträge:
    6.364
    Zustimmungen:
    145
    Unsichtbare Kreaturen kann man als Helferlein einsetzen, z.B. wenn der Spieler mit einem Gegenstand interagieren können soll. Dabei ist zu beachten, dass nicht alle unsichtbaren Kreaturen einen Dialog starten können. Ich glaube, die kreatur darf nicht "Disbale Creature(271)" als effekt haben. Invisibility und Remove feef circle(287) sollten gehen.
    Es ist jedenfalls ein Tipp an den man denken kann, wenn das Starten des Dialogs über die unsichtbare Kreatur einfach nicht klappen will. Daneben gibt es noch die Standardsachen wie: hat die cre die richtige Skriptvariable und Dialog- und Skriptfile zugewiesen etc.

    Auch ganz wichtig: in der alten Engine konnten zu viele unsichtbare Kreaturen zu Problemen führen. Wenn sie z.B. auch Remove Fog of War als Effekt hatten, dann kann es zu Problemen führen, da die Engine nur 8 Kreaturen mit dieser Eigenschaft pro Area berücksichtigt - davon sind die Gruppe mit HC bereits 6. Werden es mehr als 8, dann versagt der RFW bei einigen, was z.B. zu "schwarzen" Cutscenes führen kann. Soweit ich weiß, besteht dieses Problem in der EE weiterhin. Daher unsichtbare Helferkreaturen nach dem Dienst immer über DestroySelf() wieder verschwinden lassen.
     
  9. Jastey

    Jastey Senior Member

    Registriert seit:
    Mai 2004
    Beiträge:
    6.364
    Zustimmungen:
    145
    In der EE erhält man plötzlich aus dem "Nichts" im Dialogfenster die Nachricht, dass ein NPC was sagen wollte aber alles was da steht ist "NPC XY: Invalid"? Ohne dass ein Dialogfenster aufpoppen würde oder der NPC so aussah, als hätte er was sagen wollen.
    Dann handelt es sich um eine ungültige der cre-Datei zugewiesene Soundreferenz. Hier ein Beispiel:
    blacksmith_soundref.jpg

    Wie zu sehen, ist die Soundreferenz Nummer "2147483647" zugewiesen. Diese gibt es nicht. Die alte Engine hat diese Einträge ignoriert. Die EE tut das nicht, und meldet gehorsam: "Invalid", also ungültig!

    Um das zu verhindern, müssen alle nichtgewollten Soundrefs die Zahl -1 zugewiesen bekommen. Dann passiert das nicht. Leider kann man über den angezeigten Eintrag "No such index" nicht sehen, ob die gewollte -1 oder eine "zu hohe" Zahl dort steht, so dass man alle Soundreferenzen von Hand durchgehen und ändern muss. Um das zu tun, einfach im Feld "StringRef:" die -1 eintragen und über den Knopf "Update value" diesen Wert zuweisen.
    Wie gesagt muss man das leider für alle Soundreferenzen einzeln machen. Also der Tipp: am besten gleich mit einer "unverseuchten" cre-Datei starten! ;)
     
  10. Jastey

    Jastey Senior Member

    Registriert seit:
    Mai 2004
    Beiträge:
    6.364
    Zustimmungen:
    145
    Modding Imoen im Irenicus Dungeon: Unterschiede zwischen den BGII-Spielen

    Es gibt ja mittlerweile diverse BGII-Spiele: BGII original, BGT, BGII:EE und EET. Imoen hat durch ihre besondere Stellung im Spiel und dem Umstand, dass die Entwickler ihr leider unterschiedliche Death Varibalen innerhalb und außerhalb vom ID gegeben haben aber dies für BGT und EET für die Kontinuität vereinheitlicht werden muss eine besondere Stellung in der Komplexität der Dateien und Namen, die verwendet werden müssen, um für sie Inhalte in Ireniucs Dungeon einzufügen.

    Sobald der ID verlassen ist, gilt für alle Spiele:
    Imoen Death Variable = Imoen2
    Imoen Joined Dialoge = Imoen2J.dlg
    Imoen Kickout Dialoge = Imoen2P.dlg
    Imoens Override Skript = Imoen2.bcs
    Dream Skript = Imoen2D.bcs

    Aber innrhalb von Irenicus Dungeon gilt folgende Konstellation:
    Imoens Override Skript im ID ist in allen Spielen Imoen.bcs. Ansonsten:

    BGII und BGII:EE:
    Imoen Death Variable = Imoen --> Imoen nach dem ID ist eine andere
    Imoen Joined Dialoge = ImoenJ.dlg
    Imoen Kickout Dialoge = ImoenP.dlg
    Dream Skript = ImoenD.bcs

    BGT:
    Imoen Death Variable = Imoen2 --> vereinheitlicht über das ganze Spiel
    Imoen Joined Dialoge = Imoen2J.dlg --> Inhalte aus ID sind an das Ende der dlg für "draußen" angehängt. Achtung! Dadurch verschieben sich die Statenummern für Imoens Dialoge innerhalbdes ID, s.u.!
    Imoen Kickout Dialoge = Imoen2P.dlg --> Inhalte aus ID sind an das Ende der dlg für "draußen" angehängt. Achtung! Dadurch verschieben sich die Statenummern für Imoens Dialoge innerhalbdes ID, s.u.!
    Dream Skript = Imoen2D.bcs --> vereinheitlicht über das ganze Spiel

    EET:
    Imoen Death Variable = Imoen2 --> vereinheitlicht über das ganze Spiel
    Imoen Joined Dialoge = ImoenJ.dlg --> wird dann von der EET_End.exe mit imoen2J.dlg fürs Spielen vereint, aber zum Modden muss dieser verwendet werden.
    Imoen Kickout Dialoge = ImoenP.dlg --> wird dann von der EET_End.exe mit imoen2P.dlg fürs Spielen vereint, aber zum Modden muss dieser verwendet werden.
    Dream Skript = Imoen2D.bcs --> vereinheitlicht über das ganze Spiel

    Um nun Inhalte für Imoen in ID einzufügen und eine Verdopplung gleicher Dateien zu umgehen, kann hier ganz einfach mit defnierten Variablen gearbeitet werden.
    Für Imoens Death Variable in ID z.B. die %ImoenDV_ID%, Imoens Joined Dialog in ID die %IMOENJ_ID%, Imoens Kickout Dialoge in ID die %IMOENP_ID%, für Imoens Dream Skript die %IMOEND_ID%.
    Dann fügt man z.B. in der tp2 in den ALWAYS Block das folgende ein:
    Code:
    /* Imoen in ID! */
    
    ACTION_IF GAME_IS "tob bg2ee" AND !GAME_IS "bgt" BEGIN
      OUTER_SPRINT ~ImoenDV_ID~ ~imoen~
      OUTER_SPRINT ~IMOENJ_ID~ ~imoenj~
      OUTER_SPRINT ~IMOENP_ID~ ~imoenp~
      OUTER_SPRINT ~IMOEND_ID~ ~imoend~
    END
    
    ACTION_IF GAME_IS ~bgt~ THEN BEGIN
      OUTER_SPRINT ~ImoenDV_ID~ ~imoen2~
      OUTER_SPRINT ~IMOENJ_ID~ ~imoen2j~
      OUTER_SPRINT ~IMOENP_ID~ ~imoen2p~
      OUTER_SPRINT ~IMOEND_ID~ ~imoen2d~
    END
    
    ACTION_IF GAME_IS "eet" BEGIN
      OUTER_SPRINT ~ImoenDV_ID~ ~imoen2~
      OUTER_SPRINT ~IMOENJ_ID~ ~imoenj~
      OUTER_SPRINT ~IMOENP_ID~ ~imoenp~
      OUTER_SPRINT ~IMOEND_ID~ ~imoen2d~
    END
    Und schwupps, muss man sich um nichts mehr kümmern und Imoen spricht in allen Spielen in ID wie sie soll. Jedoch gilt noch folgendes zu beachten:

    Achtung! Dadurch, dass BGT die Dialogstates aus ID an die Dialoge von "außerhalb" anhängt, habe diese in BGT andere Nummern als im original BGII-Dialog.
    So ist z.B. der erste Dialog von Imoen in ID in BGII, BGII:EE und EET der State "0" in ImoenJ.dlg. In BGT ist es jedoch die "48" in der Imoen2J.dlg.
    Der erste Kickout-Dialog-State in ID ist in BGII, BGII:EE und EET der State "0" in ImoenP.dlg. In BGT ist es jedoch die "12" in der Imoen2P.dlg.

    Breagar hat z.B. einen Einmischdialog, wenn Imoen eine Bemerkung zu den Duergar in der Schmiede macht. Der Dialogstate, bei dem das stattfinden soll, ist im Original die "26":
    IF ~~ THEN BEGIN 26 // from: 59.0
    SAY #38628 /* ~Duergar, I think. Kind of evil, I guess, so I'm not surprised they would be working for our captor.~ */
    IF ~~ THEN REPLY #38629 /* ~Quite the little setup down here. Got everything he needs, including smiths.~ */ DO ~SetGlobal("ImoenIlyich","LOCALS",2)
    ~ GOTO 27
    IF ~~ THEN REPLY #38630 /* ~He tolerates some company, or are they little more than skilled packhorses to him?~ */ DO ~SetGlobal("ImoenIlyich","LOCALS",2)
    ~ GOTO 28
    END

    In BGT, dies ist dann entsprechend die "74". Gelöst habe ich auch das über die Verwendung von entsprechend definierten Variablen:
    Code:
    ACTION_IF GAME_IS "tob bg2ee" AND !GAME_IS "bgt" BEGIN
      OUTER_SPRINT ~IMOENJ_ID_STATE26~ ~26~
    END
    
    ACTION_IF GAME_IS ~bgt~ THEN BEGIN
      OUTER_SPRINT ~IMOENJ_ID_STATE26~ ~74~
    END
    
    ACTION_IF GAME_IS "eet" BEGIN
      OUTER_SPRINT ~IMOENJ_ID_STATE26~ ~26~
    END
    In meinem .d-File verwende ich dann ganz einfach %IMOENJ_ID_STATE26% anstelle der Zahl, und der richtige State wird gepatcht:
    Code:
    INTERJECT_COPY_TRANS %IMOENJ_ID% %IMOENJ_ID_STATE26% ACIMOEN2J74
    ==ACBREB IF ~InParty("ACBRE")InMyArea("ACBRE")!StateCheck("ACBRE",CD_STATE_NOTVALID)~ THEN
    @128
    ==%IMOENJ_ID% IF ~InParty("ACBRE")InMyArea("ACBRE")!StateCheck("ACBRE",CD_STATE_NOTVALID)~ THEN
    @129
    ==ACBREB IF ~InParty("ACBRE")InMyArea("ACBRE")!StateCheck("ACBRE",CD_STATE_NOTVALID)~ THEN
    @130
    ==%IMOENJ_ID% IF ~InParty("ACBRE")InMyArea("ACBRE")!StateCheck("ACBRE",CD_STATE_NOTVALID)~ THEN
    @131
    END
     
    Zuletzt bearbeitet: 24. Januar 2020 um 09:00 Uhr
    Acifer gefällt das.
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden