1.
XP-Anpassung geht z.b. übers Override-Script des entsprechende NPCs. Sowas hier funzt beispielsweise:
Code:
IF
InParty(Myself)
XPLT(Player1,1000)
Global("PWeliXPadjust","LOCALS",0)
!Global("EndOfBG1","GLOBAL",2)
THEN
RESPONSE #100
SetGlobal("PWeliXPadjust","LOCALS",1)
END
IF
InParty(Myself)
XPGT(Player1,1000)
XPLT(Player1,3000)
Global("PWeliXPadjust","LOCALS",0)
!Global("EndOfBG1","GLOBAL",2)
THEN
RESPONSE #100
SetGlobal("PWeliXPadjust","LOCALS",1)
AddXPObject(Myself,1000)
END
etc. pp.
2.
Zu 90% ist es wesentlich besser, wenn du einen Dummy benutzt für alles was außerhalb der Gruppe mit deinem NPC passiert. Wenn du z.B. eine erste Begegnung mit dem NPC in einer Kneipe hast und ihn dann verschwinden lässt, bevor die Spieler ihn zwei Karten weiter in die Gruppe aufnehmen können, dann benutz auf jedenfall einen Dummy. Das erspart dir viel, viel, viel Mühe und Ärger. Wenn du deinen NPC mitten drinne irgendwo hinschicken willst und die Gruppe ein Nebenquest ohne ihn machen muss, dann verschieb ihn in die Area, deaktiviere ihn und arbeite mit einem Dummy. Und so weiter und so fort.
Wenn du deinen NPC per Areapatching in die Area reinhaust, er da aber noch nicht joined, sondern irgendwo anders hingeht, würde ich auch hier mit einem Dummy arbeiten. Die Teile lassen sich mit fünf Zeilen in der TP2 erstellen und sind zum Verschleiß gedacht. ^^
3.
LOCALS sind so eine Sache. Erstmal ist es so, dass die IE nicht für riesige Massen an globalen Variablen ausgelegt ist. Auch mit modernen PCs gibt das Ruckelprobleme. Der Grund dafür ist, dass die diversen ständig aktiven Scripte immer alle globalen Variablen abfragen bis sie ein true bekommen. Wenn du 20000 GLOBALs hast, dann hast du gleichzeitig auch den Salat. ^^
Der Vorteil ist natürlich, dass die GLOBAL von allem und jedem abgefragt und gesetzt werden kann.
Lokale Variablen hingegen sind kreaturspezifisch. 100 Kreaturen können dieselbe LOCALS haben - in Spiel ist das z.b. die NumTimesTalkedTo, die immer lokal für die Kreatur inkrementiert wird, wenn man sie anspricht. Sie müssen exakt von der Kreatur gesetzt werden, für die sie gelten sollen und können
ausschließlich von der Kreatur ausgelesen werden, die sie hat. Wenn du also 789 lokale Variablen auf deinem NPC hast, ist das vollkommen uninteressant, weil kein anderes Script außer dein NPC-Override die durchackert.
Der Nachteil ist aber natürlich zum einen, dass alle Variablen weg sind, wenn die Kreatur weg ist. Unwiederruflich. Wenn also jemand durch nen Bug den NPC verliert und dann mit CLUAConsole:CreateCreature("blamuh") nen neuen erschafft, ist der gesammelte Spielfortschritt weg. Das ist natürlich ein Extremfall.
Viel wichtiger, einschränkender und aktueller ist allerdings die Tatsache, dass du mehr oder weniger ALLES über dein Override-Script lösen musst. Da niemand außer dem NPC seine Variablen abfragen kann, kann auch niemand mit denen irgendwas triggern. Das führt dann dazu, dass du manchmal recht abenteuerliche Scriptkonstruktionen basteln musst, die über 3 Ecken irgendwas auslösen.
Eine weitere Schwierigkeit kommt beim Programmieren dazu. Wenn du mit CHAINs arbeitest, werden lokale Variablen immer auf die Kreatur gesetzt, die die CHAIN eröffnet, nicht auf die Kreatur, hinter der das DO steht. Mit dem Abfragen war da auch irgendwas. Wenn du z.B. einen Banter von Imoen mit deinem NPC eröffnen lässt und mitten drinne eine Extrazeile kommt, wenn der NPC eine lokale Variable gesetzt hat, dann ging das nur du im String vorher schon auf dem NPC bist oder sowas in der Art. Ist schon ne weile her, dass ich mich mit den genauen Schwierigkeiten da beschäftigt habe. Alternativ müsste man die CHAIN halt aufsplitten. Oder an der Stelle einen normalen State reinquetschen oder sowas.
Gibt halt viele Möglichkeiten, aber sie alle sind irgendwie mit mehr Mühe und Tipperei verbunden als es nötig wäre, wenn man einfach GLOBALs benutzen würde. ^^
und natürlich kommen alle Helfer, wenn der Mod mal soweit kommt, dass er spielbar ist, in die Danksagungen.