[Modding] Unterschiede Vanilla BG2 (classic) -> BG2EE

[Acifer]

Ich möchte meine Mod neben Vanilla BG2 nun auch für BG2EE spielbar machen.

Folgende Dinge müssen meines Wissens nach für die Enhanced Editions angepasst werden:

• tis-Dateien müssen durch NearInfinity in PVRZ-Dateien umgewandelt werden, um die horizontalen Streifen im Spiel zu vermeiden. Idealerweise liefert eine Mod nur die PVRZ-Dateien und konvertiert diese dann für VanillaBG2 zurück ins Ursprungsformat, z.B. durch https://github.com/InfinityTools/tile2ee ; ein Workaround hierzu findet sich in der Beispielmod https://github.com/Gibberlings3/RealMod/blob/master/real_mod/real_mod.tp2
• mos-Dateien für die Minimaps sind überflüssig
• die Wasser-Overlays nutzen eine andere Kodierung, weshalb vor der Umwandlung in PVRZ-Dateien das Tool tis2ovl verwendet werden muss: https://github.com/InfinityTools/tis2ovl/releases/tag/1.0
• Videodateien liegen nicht mehr als mve-Dateien, sondern als WBM-Dateien vor; die Umwandlung kann z.B. durch das Tool https://handbrake.fr/ erfolgen.
• Description-Bams sollten als PVRZ-Dateien vorliegen und möglichst direkt in NI von png nach PVRZ konvertiert werden, um den Alphakanal zu berücksichtigen
• Die EE stellt im Inventar nur das große Bam-Icon dar
• Die Area-Sounds müssen nicht mehr in den Override-Ordner kopiert werden
• Animationen können durch Nutzung von ini-Dateien unter Umgehung von Infinity Animations direkt integriert werden
• Journal-Einträge werden anders erfasst
• Alle Dialog-und Journal-Dokumente müssen in UTF-8 anstelle von ANSI-Kodierung vorliegen und konvertiert werden

Habe ich etwas vergessen? Im nächsten Schritt werde ich zu den einzelnen Themen viele Fragen posten…

 

[Jastey]

Kits müssen bei der Installation noch eine Zusatzfunktion durchlaufen (fl#add_kit_ee?), und es gibt noch eine neuere, bessere Funktion dafür von argent77 mit der ich mich nicht auskenne.

Features:
- in der EE können Cutscenes vom Spieler mit der Esc abgebrochen werden, wenn sie entsprechend vorbereitet sind. Mein HowTo dazu hier.
- die Item Beschreibungen unterscheiden sich im Stil und der Verwendung der Fachbegriffe (im Englischen, im Deutschen weiß ich es nicht)

Link zu CamDawg's Tutorial: Conversting Existing Mods to the EE Engine (deckt leider nicht alles ab und ist nicht mehr 100% aktuell)

 

[Acifer]

@Jastey : Vielen Dank, das hatte ich gar nicht auf dem Schirm!

Eine erste Frage zu der Konvertierung ANSI -> UTF-8.

Ich habe es bisher so gemacht, dass ich meine tra-Dateien in ein separates Verzeichnis kopiere und konvertiere...

ALWAYS
  /*
   * Copies tra files into the autotra-folder (to leave the originals untouched)
   */
  DEFINE_ACTION_FUNCTION autotra_workaround BEGIN
    COPY ~silverrealms/tra/%LANGUAGE%~  ~silverrealms/tra/autotra/%LANGUAGE%~
  END

  LAF autotra_workaround END

  LAF HANDLE_CHARSETS
    INT_VAR
      infer_charsets = 1
    STR_VAR
      tra_path = EVAL ~silverrealms\tra\autotra~
      noconvert_array = fl#noconvert
      reload_array = fl#reload
  END

    //TRAs declared in LANGUAGE must be reloaded
  LOAD_TRA ~silverrealms/tra/autotra/%LANGUAGE%/setup-silverrealms.tra~

...ist das noch zeitgemäß?

Wäre es möglich, auch Original-d-Dateien (ohne tra's) zu konvertieren? Damit hätte ich besser die Möglichkeit, Dialoge nachträglich zu ändern.
Wie sähe in einem solchen Fall der Code aus?

 

[Jastey]

...ist das noch zeitgemäß?

Ich habe das Kopieren in einen "autotra"-Ordner mal eingeführt, weil man die installierten und in utf8-umgewandelten tra-Dateien nicht editieren kann (z.B. wenn man beim Spielen Rechtschreibfehler entdeckt), bzw man kann editieren aber nach der Deinstallation der Mod sind die Änderungen dann wieder weg, weil weidu die alten tra-Dateien zurückkopiert - ist mir mehrmals passiert... Ich nutze das also nach wie vor.
ANSI vorzulegen und in utf8 umzuwandeln war der Standard bisher und ich werde das aus Gründen auch weiterhin nutzen. AL|IEN hat vorgeschlagen, dass man es andersrum macht: utf8 vorlegen und in ANSI bei der Installation umwandeln, sein Tutorial dazu ist hier. Ich habe mich damit noch nicht beschäftigt. Der Vorteil von utf8-Format ist, dass jede Sprache leicht über copy&paste verarbeitet werden kann und auch alle dasselbe Format haben (nicht ganz spezielle ANSI-Kodierungen z.B. für Russisch, Chineisch etc). AL|IENs Vorgehensweise ist also für die Übersetzer einfacher, vor allem, um Zuarbeiten über GitHub zu akzeptieren usw.

Wäre es möglich, auch Original-d-Dateien (ohne tra's) zu konvertieren? Damit hätte ich besser die Möglichkeit, Dialoge nachträglich zu ändern.
Wie sähe in einem solchen Fall der Code aus?

Puh, keine Ahnung. Die Frage ist, ob der Installer damit zurechtkommt. Habe ich noch nie probiert. Du kannst es prinzipiell mal ausprobieren indem Du eine d-Datei in utf8 konvertierst, es installierst und schaust, ob es im Spiel alles klappt.
Ich würde vermuten, dass man die automatische Konvertierung nutzen könnte, indem man einen tra_path entsprechend setzt.
Dann besteht aber dasselbe Problem wie oben beschrieben: die (konvertierten) d-Dateien wären dann tabu, solange die Mod installiert ist. Außer Du arbeitest da auch nochmal mit einem "autotra"-Ordner oder editierst ein zweites Set oder bist schlauer als ich und machst jedes mal ein Backup von den Änderungen, bevor Du die mod deinstallierst.

 

[Acifer]

Ich würde vermuten, dass man die automatische Konvertierung nutzen könnte, indem man einen tra_path entsprechend setzt.

Ich habe jetzt am Wochenende versucht, einen weiteren d-tra_path zu integrieren, bin aber leider bisher gescheitert. Ich werde weiter experimentieren und dann wieder berichten.

Dann besteht aber dasselbe Problem wie oben beschrieben: die (konvertierten) d-Dateien wären dann tabu, solange die Mod installiert ist. Außer Du arbeitest da auch nochmal mit einem "autotra"-Ordner oder editierst ein zweites Set oder bist schlauer als ich und machst jedes mal ein Backup von den Änderungen, bevor Du die mod deinstallierst.

Da ich die Mod "nur" in einem separaten Vanilla-BG2-Ordner weiterschreibe, besteht in diesem Fall keine Gefahr, dass mir bei der BG2EE-Installation durch die Konvertierung Daten verlorengehen.

Der Vorteil von utf8-Format ist, dass jede Sprache leicht über copy&paste verarbeitet werden kann und auch alle dasselbe Format haben (nicht ganz spezielle ANSI-Kodierungen z.B. für Russisch, Chineisch etc). AL|IENs Vorgehensweise ist also für die Übersetzer einfacher, vor allem, um Zuarbeiten über GitHub zu akzeptieren usw.

Das ist interessant! Dieser Vorteil war mir gar nicht bewusst.

 

[Acifer]

Ich habe eine einfache Möglichkeit gefunden, Dialog-Dateien für die Enhanced Edition zu erstellen, ohne die Dialoge in tra-Files konvertieren zu müssen.
Mit Windows lassen sich ganz einfach mehrere Textdateien zu einer einzigen Datei zusammenfassen, die man dann mittels Notepad ++ mit einem Klick in UTF-8 konvertieren kann.

Das Vorgehen:
- Die Windows-Kommandozeile öffnen
- zu dem Pfad mit den Dialogdateien navigieren
- Folgenden Befehl eingeben: copy *.d dialogues-ee.d
- Windows erstellt dann aus sämtlichen im Ordner vorhandenen D-Dateien eine einzige, zusammenhängende d-datei
- Diese wird in Notepad ++ geöffnet
- Unter "Codierung" wird dann der Befehl "Konvertiere in UTF-8" angeklickt
- in der Setup.tp2 kann man dann ganz bequem auswählen, dass für die EE die zusammenhängende d-Datei im UTF-8 Format verwendet wird

Dadurch verliert man nicht die Möglichkeit, direkt die Dialoge ungetraified zu editieren und kann die Mod in zwei, drei Mausklicks für die EE kompatibel machen.

 

[Jastey]

Raffiniert! Ich wollte auch die Erfahrung posten - hab's dann wieder vergessen - dass eine in utf-8 umgewandelte d-Datei zu installieren fehlerfrei funktioniert. Du hast da für Deine Mod eine noch elegantere Version gefunden. Bei mir würde das Verschmelzen nicht unbedingt funktionieren, da ich entweder schon unterschiedliche tra-(Teil)Dateien habe oder bei ganz viel Pech in d-Dateien dieselben Namen für die States verwendet haben könnte. Letzteres sollte nicht häufig vorkommen, ist aber möglich.