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

[Maus]

Frage zu den Komponenten (ich hatte bisher immer nur eine):
Wenn ich das richtig sehe, wird jede Komponente mit BEGIN ~Name~ (bzw. @Nummer für traified version) DESIGNATED Zahl begonnen. Und im Gegensatz zu dem gesamten anderen Code gibt es da kein END am Ende.

Also:

BEGIN ~Komponente 1~ DESIGNATED 0
Code für Komp. 1

BEGIN ~Komponente 2~ DESIGNATED 1
Code für Komp. 2 (mit vielen anderen BEGIN->END, APPEND->END etc. Blöcken)

BEGIN ~Komponente 3~ DESIGNATED 2

Muss ich das irgendwie im Header der tp2 noch irgendwie eintragen? Ich meine nicht...

edit: DESIGNATED noch hinzugefügt, weil ich das Muster übersehen hatte...

 

[Maus]

Und gleich noch etwas, das mir beim Lesen des WeiDU Tutorials zu tp2 aufgefallen ist:

Andere Version NPCs ins Spiel zu bringen mit ADD_GAM_NPC (hier ein Beispiel):
COPY ~mymod/mynpc.cre~ ~override~
SAY NAME1 ~Japh~
SAY NAME2 ~Japh~
// Do any other patching stuff here

ADD_GAM_NPC ~mynpc~ ~ar2600~ #123 #456 // die Zahlen sind x,y-Koordinaten

Damit könnte man sich doch die lästige Erstellung der NPC in Area-Skripten ersparen, oder? Sind weniger Variablen zu setzen und die Area-Skripte werden entschlackt. Ist natürlich etwas anderes, wenn ein NPC nur nach einer Bedingung erstellt wird. Und es könnte einen Unterschied machen, wenn der NPC Aktionen durchführt, die einen Timer haben und somit erst erstellt wird, wenn die Gruppe das Gebiet betritt und dann das Area-Skript ausgeführt wird.
Wenn ich es richtig verstehe, dann kann man damit auch Kreaturen in Areas platzieren, die schon im Spiel enthalten sind. Für die anderen muss halt der COPY-Befehl zuerst erstellt werden.

Arbeitet jemand schon mit diesem Syntax und hat da Erfahrungen?

 

[Jastey]

ADD_GAM_NPC ist für aufnehmbare NPC. Sie werden global erzeugt. Das würde ich nicht für Questcharaktere nehmen.
Wenn Du die Skripte entlasten willst, kannst Du cres auch direkt in die Atea patchen wie es z.B. Ascalons Questpack tut.

 

[Jastey]

Zur tp2: ALIEN hat hier mal einige aktuelle "Do's" zusammengetragen, die man gleich von Anfang an berücksichtigen könnte. Vor allem das Verteilen von LABEL zusätzlich zum DESIGNATED. Dein Beispiel für die Komponenten oben stimmt so ansonsten vom Prinzip her (die tp2 möchte natürlich noch mehr Sachen wie Ort für den Backup-Ordner usw. aber das war ja nicht Deine Frage).

 

[Maus]

ACTION_IF GAME_IS ~bg1ee~ BEGIN
          OUTER_SPRINT ~imoen_scriptname~ ~imoen~
END

ACTION_IF GAME_IS ~eet~ BEGIN
          OUTER_SPRINT ~imoen_scriptname~ ~imoen2~
END

ACTION_IF GAME_IS ~bgt~ BEGIN
          OUTER_SPRINT ~imoen_scriptname~ ~imoen2~
END

korrekter Syntax so?

Und aufrufen in den Dateien dann mit %imoen_scriptname% ?

 

[Jastey]

~bgee~, und das andere knsst Du zusammenfassen: ~bgt eet~.

Und aufrufen in den Dateien dann mit %imoen_scriptname% ?

Ja.
Aber veinfache Dir das und nimm die Definition aus den cpmvars.tpa Dateien. Die wirst Du spätestena brauchen, wenn Du Areascripte patchst.

 

[Maus]

Nope, sonst muss ich da suchen, wie die Areas benannt werden. Mache ich lieber meine eigenen...
Getrennt habe ich sie gerade wegen der Areanamen...

 

[Maus]

In state 1071, I expected one of these tokens:
  [0] EOF
  [48] BEGIN
  [227] LANGUAGE
Parse error (state 1071) at ACTION_IF

Produziert aber die obige Fehlermeldung. Interessanterweise steht das nicht in der DEBUG-Datei drin, sondern nur in der Konsolenausgabe. In der DEBUG (wie auch in der Konsole) ist dann noch:

[IMOENGONE/IMOENGONE.TP2] PARSE ERROR at line 14 column 1-9
Near Text: ACTION_IF
    GLR parse error

[IMOENGONE/IMOENGONE.TP2]  ERROR at line 14 column 1-9
Near Text: ACTION_IF
    Parsing.Parse_error
ERROR: parsing [IMOENGONE/IMOENGONE.TP2]: Parsing.Parse_error
ERROR: problem parsing TP file [IMOENGONE/IMOENGONE.TP2]: Parsing.Parse_error

dabei, was aus meiner Sicht weniger aussagekräftig ist.

Verwirrend ist:
vor dem ACTION_IF habe ich:

LANGUAGE ~English~ ~english~
    ~imoengone/tra/english/wsetup.tra~

Von daher die Frage: wieso vermisst er den LANGUAGE token??

edit: meine Vorlage war die tp2 von AjantisBG2

 

[Maus]

Ok, ich habe die Lösung:

LANGUAGE muss nach ACTION_IF kommen (hatte ich zwischendurch zwar schon mal, aber dann wahrscheinlich noch was anderes falsch; wahrscheinlich das mit ALWAYS); und ALWAYS muss mit einem END beendet werden.

2h für den Mist... puh...

 

[Jastey]

Nope, sonst muss ich da suchen, wie die Areas benannt werden. Mache ich lieber meine eigenen...

Ernsthaft? Es gibt einen Standard und Du machst lieber Deinen eigenen? Ich sag Dir was, Erg hat für Finch und Indira auch seine eigenen OUTER_SPRINT Crossmodvariablen definiert* und ich hab gekotzt, als ich in die Mods geupdatet habe, weil ich alles nachgucken musste obwohl ich seit Jahren(!) crossmodtauglich code. Meine Motivation, mich in Mods reinzufinden die glauben, sie müssten das Rad neu erfinden liegt bei Null.

*Er hatte aber die Ausrede, dass es damals den Standard so noch nicht gab.

 

[Maus]

Kommt darauf an, was man macht... Wenn du sagen wir mal <10 OUTER SPRINTS hast, dann ist das einfacher, wenn man die sich selber definiert. Man kann das auch später elegant umstellen. Aber wenn ich in den tpa's rumsuchen muss, kostet das viel Zeit. Wenn man die alle mal sowieso drauf hat, klar, dann läuft das einfach. Aber suche mal Fehler, wenn du dermaßen viele Dinge über include einbaust.

 

[Taimon]

LANGUAGE muss nach ACTION_IF kommen (hatte ich zwischendurch zwar schon mal, aber dann wahrscheinlich noch was anderes falsch; wahrscheinlich das mit ALWAYS); und ALWAYS muss mit einem END beendet werden.

Ersteres kann eigentlich nicht stimmen, denn wenn man sich die Beschreibung der TP2-Grammatik in der Doku anschaut, dann sieht man, dass eine TP2 folgende Syntax hat:

BACKUP directoryName
AUTHOR emailAddress
TP2 Flag list
Language list
Component list

Und "Component" ist so definiert:

BEGIN componentName Component Flag list
TP2 Action list

ACTION_IF ist eine Action, also Teil der "TP2 Action list".
Was bei dir gefehlt hat, ist sehr wahrscheinlich das BEGIN für die Komponente.

 

[Jastey]

Die cpmvars.tpa sind sortiert nach Areaname ähnlich wie in der IESDP Liste und der entsprechenden Areanummer. Die Areanummer (ARxxxx) hast Du eh vor Dir wenn Du entscheidest, wo Du was einfügen möchtest. Und dann heißt die Area von Beregost in OUTER_SPRINT z.B. %Beregost%.
Du wirst aber nicht <10 Variablen haben schlussendlich. Du musst Imoen definieren - Begrüßungsdialog, Joineddialog, Kickoutdialog Death Variable, dann planst Du, diverse Hinweise zu Imoen im Spiel zu platzieren, eine Kerkermeisterin die in einer Area spawnen muss, dann sollen vielleicht die anderen NPCs noch was sagen an irgendwelchen Stellen wofür die Joineddialoge gebraucht werden.
Da hast Du dann aber schon so viele eigene Variablen definiert dass Du das ganze System neu aufziehst. Ich versteh halt nur nicht, warum.

 

[Jastey]

LANGUAGE muss nach ACTION_IF kommen

Das verstehe ich auch nicht. Ich vermute, dass Du Dich an anderen Mods bzgl. des tp2-Headers orientierst? Ich habe vielleicht ein ACTION_IF im ALWAYS Block stehen, aber hinmüssen tut das vor LANGUAGE nicht.

 

[Maus]

Yup, der Header mit den üblichen Dingen ist mehr oder weniger derselbe. Aber z.B. bei AjantisBG2 ist es auch so, dass autotra vor den ACTION_IF kommt, aber LANGUAGE danach. Ich vermute, dass etwas mit der Struktur zu tun hat, mit der die tp2 geparsed wird.

 

[Taimon]

Wenn das ACTION_IF Bestandteil des ALWAYS-Blocks ist, dann kommt es zwangsläufig vor LANGUAGE, da ALWAYS ein TP2-Flag ist.
Ansonsten aber garantiert nicht.

 

[Maus]

Hm, ich hatte es am Anfang ohne ALWAYS probiert, da gab es dieselbe Meldung... Kann es sein, dass ACTION_IF einfach im ALWAYS Block sein muss? Der parse error saß immer auf dem ACTION_IF (gibt ja eine genaue Meldung von Zeile und Spalte).

 

[Taimon]

Nein, das ACTION_IF ist normalerweise Teil einer Komponente, die aber mit BEGIN eingeleitet werden muss.
(Das hat WeiDU dir im Prinzip auch in der Fehlermeldung gesagt.)

 

[Maus]

Ah, ok, so langsam komme ich dahinter:
ACTION_IF soll eigentlich bei den Komponenten kommen. Wenn ich z.B. die Variablen-Definition global für alle Komponenten haben will, dann muss sie in den ALWAYS-Block hinein, der als TP2-flag zählt und vor LANGUAGE kommen muss. Oder wieder falsch?

Ansonsten für Mitleser:
Man muss nicht AUTHOR benutzen beim Header der tp2; SUPPORT geht inzwischen auch. VERSION und README sind dann wohl wieder TP2-flags...

edit: und es war mir nicht klar, dass diese Auflistung tatsächlich eine Reihenfolge darstellt; und ich muss zugegeben, das Dokument noch nie in Gänze gelesen zu haben, sondern immer nur nach einzelnen Syntax gesucht zu haben.

 

[Jastey]

SUPPORT ist für Mods, die von anderen Lwuten übernommen wurden, dann statt AUTHOR.
Im ALWAYS Block steht alles drin, was vor jeder Komponente wiederholt wird, ja. Variablen müssen immer (neu) eingeleen werden