[Modding] Wie erstelle ich tp2-Dateien und sonstige Fragen zu diesem Thema?

[Maus]

Habs gerade mal bei arestorations nachgelesen. Der hat da zwar wenig Items gepatched, aber ich habs gefunden. Alle Hexzuweisungen sind mit "0x" initiiert. Ich habe noch WRITE_LONG gefunden: da müssen dann wohl beim Hex-Wert noch führende Nullen mitgeschrieben werden. Das könnte komplizierter sein.

Das BUT_ONLY ist halt im ConTEXT Syntax Highlighter nicht drin...

 

[Jastey]

@Maus hast Du das was ich gepostet habe mal ausprobiert für den Schlüssel?

 

[Maus]

Jein. Ich habs in die tp2 reingeschrieben, aber noch nicht installiert. Das mache ich, wenn ich mit der aktuellen todo-Liste durch bin

 

[Taimon]

Ich habe noch WRITE_LONG gefunden: da müssen dann wohl beim Hex-Wert noch führende Nullen mitgeschrieben werden. Das könnte komplizierter sein.

Nein, musst du nicht. Der Unterschied ist nur, dass WRITE_LONG einen 32-bit Wert schreibt, während WRITE_SHORT für einen 16-bit Wert verwendet werden sollte.
Immer den richtigen Typ für das entsprechende Feld im Dateiformat verwenden.

/Edit: Siehe ITM in IESDP:

0x001c

2 (word)

Item type

Hier steht, dass das Feld 2 Byte breit ist (word) und damit sollte man WRITE_SHORT verwenden. (Für Werte, die in ein Byte passen, könnte man auch WRITE_BYTE verwenden.)

 

[Maus]

Ach, da ist echt Long-Int und Short-Int damit gemeint? Cool. Das verstehe ich sogar

edit: ah, ok, keine Int, sondern word. Aber gut, das kann man ja wirklich gut im IESDP nachschauen.

 

[Maus]

So, das mit der Item-Änderung über die Zuweisung in der tp2 hat funktioniert. Sowohl Installation als auch die Rückänderung bei der Deinstallation.

 

[Maus]

Gut nächste Frage zur Königsdisziplin: Kompatibilität mit verschiedenen Versionen/Konversionen! Hat jemand eine Empfehlung für eine Mod, bei der man sich das mal grundlegend anschauen kann? Also nicht zu kompliziert (also nicht Breagar), sondern was einfacheres, wo man das mit den Variablen und den Abfragebedingungen sehen kann?

 

[Jastey]

Hmm... was einfaches. Wenn Du eine meiner BG1-Mods ansiehst, bgqe, bg1re, ebg1, auch die NPCs, alle machen Crossplatform Modding. Sag mal bescheid, ob Dir das was bringt. Eventuell kann ich einen kleinen Guide zusammenhauen für den Anfang.

 

[Maus]

/* check for a ready SoD - doesn't work for Windows */

ACTION_IF ((FILE_EXISTS ~dlc/sod-dlc.zip~) OR (FILE_EXISTS ~sod-dlc.zip~)) THEN BEGIN
  FAIL @5003 /* ~Modmerge is required before mods can be installed on this game. Check the readme for more information and a link to download Modmerge.~ */
END

Korrekt, dass das nicht für Windows funktioniert? Müsste es doch eigentlich, oder?

Die installierte Version abfragen würde dann so gehen:
ACTION_IF GAME_IS ~bgee eet~ THEN BEGIN
...
END

die anderen Kürzel wären dann noch: ~bg1 totsc tutu tutu_totsc bgt~ (wobei ich für meine Mods tutu weglassen würde, weil ich annehme, dass da zu wenige noch mit spielen und die auch noch Dinge separat benennen).

Dann kann man Dinge umbenennen, z.B.:
OUTER_SPRINT "NBaldursGate_BCS" "AR7300"
Da ist meine Frage: heisst das jetzt, dass alles, was in der tp2 NBaldursGate_BCS heisst bei der Installation dann als AR7300 interpretiert wird? Also NBaldursGate_BCS bekommt den Wert AR7300 zugewiesen? (weil die Variable halt für in dem Fall bgt eben den Wert (oder eigentlich ja String) AR7300 bekommt. Für ein anderes Spiel bekommt die Variable halt eine andere Referenz zugewiesen.

Und müsste es nach der WeiDU-Beschreibung nicht eigentlich OUTER_TEXT_SPRINT sein?

Vom Grundkonzept her: alle Dateien, die in den unterschiedlichen Versionen nicht gleich benannt werden, bekommen bei der eigentlichen Verarbeitung einen Variablennamen als Bezeichnung, z.B.
EXTEND_BOTTOM ~blabla~ ~morenco/areaskripte/bg4000.baf~

Und dann mache ich ein
ACTION_IF GAME_IS ~eet~ THEN BEGIN
OUTER_TEXT_SPRINT "blabla" "BG4000.BCS"
END

ACTION_FI GAME_IS ~bgee~ THEN BEGIN
OUTER_TEXT_SPRINT "blabla" "AR4000.BCS"
END

etc. halt für alle Version und in den ACTION_IF Block kommen halt noch viel mehr OUTER_TEXT_SPRINT rein. Und die ACTION_IF Blocks kommen natürlich vor der Erweiterung der Skripte. Richtig?

Und man kann es natürlich auch komplizierter machen, indem Sachen noch vorher ausliest und in Variablen packt etc. Aber würde für eine erste Basis das obige funktionieren? Und man muss natürlich für alle Versionen die Namenskonventionen kennen (na Klasse).

Gibt es irgendwo in einem Forum (oder ähnlicher Quelle) eine Liste der jeweiligen Unterschiede/Namenskonventionen für die verschiedenen Versionen? Und wenn nicht: könnten wir das hier sammeln und oben in einem Thread anpinnen?

Das mal nur so als ersten Aufschlag zu dem Thema. Ich glaube mal ich kann es kapieren, aber schwierig ist das schon... da bräuchte es eine Menge Tutorials (und das ist keine Aufforderung, dass jemand anders die gefälligst erstellen soll, sondern sehe ich durchaus auch mich in der Pflicht. Gerne mit Unterstützung anderer hier ). Weil die ganzen Infos nur in diesen Threads hier, wird nur bedingt helfen...

 

[Maus]

Was tpa sind, habe ich jetzt nicht gefunden. Ich tippe mal drauf, dass das Bibliotheken mit Befehlen oder sonstigen Variablenbelegungen sind, die für die verschiedenen Versionen des Spiels unterschiedlich sind und einfach (höhö) mal installiert werden, weil man sie möglicherweise benötigt und nicht immer prüfen will, was da jetzt tatsächlich bei der Installation benötigt wird?

 

[Acifer]

Was tpa sind, habe ich jetzt nicht gefunden.

tpa's sind im Grunde nichts anderes als ausgelagerte Installationsanweisungen für die WeiDU setup-mymod.tp2. Zum Einen, damit man sich Arbeit sparen kann (weil man in vielen Mods immer die völlig gleichen tpa's reinpackt) und zum Anderen, weil man dadurch seine Haupt-Installations-tp2 übersichtlicher halten kann.
Z.B. kannst Du alle cre-Installationsanweisungen in eine cre.tpa packen, alle Scripts in eine script.tpa usw. Oder Du verwendest die add_map_icons.tpa, um neue Icons für die Worldmap einzufügen.
Zu den cpmvars und vielen anderen Funktionen kann sicher Jastey eine Menge sagen.
Die Möglichkeiten sind unbegrenzt, und viele gleiche tpa's findet man immer wieder in vielen verschiedenen Mods wieder. Der Ordner für diese Dateien ist in den meisten Mods der "lib"-Ordner.
Die "Programmiersprache" zwischen tp2 und tpa unterscheidet sich nicht. Dabei beziehst Du die verschiedenen tpa's immer mit INCLUDE ~xxx.tpa~ in Deine setup-mymod.tp2 mit ein.

EDIT: Wäre eigentlich gut, wenn es irgendwo eine Liste mit allen "gemeinnützigen" tpa's geben würde. Bei vielen dieser nützlichen Dateien weiß man gar nicht, dass sie existieren.

 

[Jastey]

@Maus : die ganzen Listen mit den unterschiedlichen Areanamen etcpp sind in den cpmvars.tpa drin im Ordner /lib. Die von der EET stellt die EET selbst, da liest man die direkt ein (und hat immer die aktuelle).
Die tpa mit den Variablen liest man ein, z.B. im ALWAYS Block. Danach kannst Du z.B. für die Area Beregost entsprechend %Beregost% verwenden und die Dateien mit EVALUATE_BUFFER kompilieren.
Dann kriegst Du abhängig vom Spiel "AR3300" für BG:EE, "AR6700" für BGT und "BG3300" für EET in Deinen Dateien so wie es für das Spiel des Spielers gebraucht wird.

Und müsste es nach der WeiDU-Beschreibung nicht eigentlich OUTER_TEXT_SPRINT sein?

Ich nutze OUTER_SPRINT für alle meine Variablen die ich mit Text oder Zahlen (Stringref-Nummern) füllen möchte. Die cpmvars.tpa nutzen das auch.

 

[Maus]

Aber das Beispiel von mir mit der blabla Variable würde so funktionieren? Wäre ja für mich erstmal ok so... oder habe ich da falschen Syntax oder so?

 

[Jastey]

Vom Grundkonzept her: alle Dateien, die in den unterschiedlichen Versionen nicht gleich benannt werden, bekommen bei der eigentlichen Verarbeitung einen Variablennamen als Bezeichnung, z.B.
EXTEND_BOTTOM ~blabla~ ~morenco/areaskripte/bg4000.baf~

Und dann mache ich ein
ACTION_IF GAME_IS ~eet~ THEN BEGIN
OUTER_TEXT_SPRINT "blabla" "BG4000.BCS"
END

ACTION_FI GAME_IS ~bgee~ THEN BEGIN
OUTER_TEXT_SPRINT "blabla" "AR4000.BCS"
END

Vom Prinzip her ja. Die Definitionen natürlich vorher und dann wäre es
EXTEND_BOTTOM ~%blabla%~ ~morenco/areaskripte/bg4000.baf~

Genau so funktionieren die in den cpmvars.tpa angegebenen Variablen auch. Ich weiß nicht, ob überall die Areaskripte mit drin sind. Aber wenn Du Tutu weglässt, dann sind die Area- und Areaskriptnamen ja identisch. Dann ginge auch:
ACTION_IF GAME_IS ~eet~ THEN BEGIN
OUTER_TEXT_SPRINT "blabla" "BG4000"
END

ACTION_FI GAME_IS ~bgee~ THEN BEGIN
OUTER_TEXT_SPRINT "blabla" "AR4000"
END

EXTEND_BOTTOM ~%blabla%.bcs~ ~morenco/areaskripte/bg4000.baf~

 

[Jastey]

Korrekt, dass das nicht für Windows funktioniert? Müsste es doch eigentlich, oder?

Irgendwas mit weidu kann unter Windows kein so großen Dateien ekennen und bla. Ich weiß es nicht, aber der Check klappt unter Windows nicht.

die anderen Kürzel wären dann noch: ~bg1 totsc tutu tutu_totsc bgt~ (wobei ich für meine Mods tutu weglassen würde, weil ich annehme, dass da zu wenige noch mit spielen und die auch noch Dinge separat benennen).

bg1 und totsc würde ich an Deiner Stelle schnell rausstreichen. Das wäre original BG1 und original BG1:TotSC. Außer Du willst Dich mit der sehr beschränkten Engine herumschlagen. Ich sage nur: kein OR().

 

[Jastey]

Da ist meine Frage: heisst das jetzt, dass alles, was in der tp2 NBaldursGate_BCS heisst bei der Installation dann als AR7300 interpretiert wird? Also NBaldursGate_BCS bekommt den Wert AR7300 zugewiesen? (weil die Variable halt für in dem Fall bgt eben den Wert (oder eigentlich ja String) AR7300 bekommt. Für ein anderes Spiel bekommt die Variable halt eine andere Referenz zugewiesen.

Ja, genau. Die Variablen werden in %% aufgerufen. Also %NBaldursGate_BCS%. Und das kannst Du in den Dateien (d, baf) ebenfalls verwenden, wenn Du sie mit EVALUATE_BUFFER kompilierst.

 

[Maus]

Ich sehe schon: ich werde mich da langsam rantesten.

 

[Jastey]

Vielleicht hilft Dir bgqe oder bg1re als Beispiele mehr. Die Einzelkomponenten sind kleiner und Du kannst eventuell das Verwenden der Crossplatformvariablen besser nachvollziehen. Meine NPC-Mods sind insgesamt etwas unübersichtlich.

 

[Maus]

Ähm, ich hab mir das in bgqe angeschaut... ^^ Und aus anderen Gründen gestern noch ein paar andere tp2 (andere Autoren). Bleibt für mich dabei, dass ich mich da langsam vortaste.

 

[Jastey]

bgqe hat den Nachteil, dass es auch mit Tutu und Bg1:TotSC kompatibel sein möchte. Wenn Du die beiden raus nimmst, dann wird es plötzlich viel übersichtlicher. (Sag ich mal so. Ist in bg1re aber auch). In der Tutu heißen die Areas und ihre Skripte noch nicht mal gleich was die Definition der Variablen für das Patchen verkompliziert. Ich lasse bei meinen neueren Mods Tutu weg, wie Du schon sagtest wird es nicht mehr häufig gespielt und ich sehe auch keinen Vorteil. Wenn die Leute die klassische Engine haben möchten sollen sie BGT spielen, da können sie gleich weiterspielen und das ganze kontinuierlich erleben.
In BGT und EET musst Du beachten, dass alle Ressourcen die auch in BGII mit gleichem Namen auftauchen in BG1 umbenannt wurden. Siehe hier. Genau dafür sind dann auch die Crossplatfromvariablen wichtig. Wenn Du z.B. der Senai aus BG1 einen Einmischdialog geben möchtest, dann heißt die in BG:EE SENDAI, in EET SENDAI_ und in BGT BGSENDAI. Und in Crossplatformschreibweise einfach %tutu_scriptbg%Sendai%eet_var% über die Definitionen in den cpmvars.tpa.