Allgemeines

Aufbau Event-Strings

Die einzelnen Handler eines Event-Strings werden durch ; voneinander getrennt. Jeder Handler besteht wiederum aus einzelnen Eigenschaften. Diese werden durch : separiert. Die ersten drei Eigenschaften besitzen eine feste Reihenfolge und müssen angegeben werden.

1	Bestimmt die User-ID, für die dieser Handler gilt. Ein * bedeutet, dass alle User gemeint sind. (Bei der Auswahl des Handlers wird ersteres gegenüber letzterem bevorzugt)
2	Bestimmt die ID des auszuführenden Scripts
3	Bestimmt, ob ein bestimmter Quest-Kontext verwendet werden soll. Hierzu muss entweder eine Quest-ID (wenn noch kein laufendes Quest hierzu existiert wird ein neues gestartet) oder die ID eines laufenden Quests angegeben werden (führendes r nicht vergessen!). Um keinen Quest-Kontext zu erhalten einfach diese Eigenschaft leer lassen

Zusätzlich gibt es einige optionale Eigenschaften:

%zahl	Bestimmt wie wahrscheinlich es ist, dass dieser Handler auch wirklich genutzt wird, nachdem er ausgewählt wurde (wenn er nicht genutzt wird, wird kein anderer Handler ausgewählt. Es wird schlichtweg kein Event ausgeführt). Die angegebene Zahl muss im Bereich von 1 bis 100 liegen.
n	Erzwingt, dass ein neuer Quest-Kontext verwendet wird statt nach einem bestehenden zu suchen und diesen zu verwenden.

Hinweis: Es wird grundsätzlich nur ein Handler pro Event-String ausgeführt.

Ein möglicher Event-String sieht also so aus:
*:1:5:%50:n;-99:2:

Dieser String würde bewirken, dass für alle User Script 1 mit einem neuen Quest-Kontext für Quest 5 mit einer 50%igen Wahrscheinlichkeit gestartet werden würde. Ausser für User -99, für den immer Script 2 gestartet werden würde ohne Quest-Kontext

Admin->Quests->Quick Quests

Dieser Questgenerator ermöglicht es schnell neue Quests-XMLs zu generieren, vorrausgesetzt das Quest passt in ein festes Schema. Die Eingabe der Questdaten erfolgt via DB->quests_quick. Damit die Questgenerierung funktioniert muss ein bestimmtes Namensschema für Start- und Zielscript-XMLs eingehalten werden (im Moment ausschließlich GTU-Posten).

Aufbau der GTU-Posten-Quest-XML-Dateinamen: gtu-posten-$schiffsid.xml (Der GTU-Posten mit der ID 12345 müsste somit die Quest-XML gtu-posten-12345.xml haben).

Dies gilt nicht mehr uneingeschränkt im Port. Dieser besitzt nun das Register #TARGETSHIP, welches die ID des angefunkten Schiffes enthält. Sofern im Posten-Script verwendet kann die ID beliebig sein.

Die Quest-XMLs von Quelle und Ziel müssen lediglich die Script-Targets "parameters", "menu" und "code" unterstützen. Diese sollten aber eigendlich von allen Quest-XMLs, welche sich für Quests eignen, unterstützt werden. Somit sollte es reichen beim anlegen eines neuen Quellen/Zielobjekts einfach eine andere Quest-XML von einem identischen Objekt zu kopieren (z.B. von einem anderen GTU-Posten)

Nehmen wir nun an, dass wir ein Transport-Quest vom GTU-Posten 12 zum GTU-Posten 34 anlegen wollen. Zuerst überprüfen wir, ob gtu-posten-12.xml und gtu-posten-34.xml vorhanden sind und kopieren falls eine fehlt die Quest-XML eines anderen GTU-Postens. Als nächsten Schritt legen wir eine neue Ziele in der Tabelle quests_quick an. Die ID spielt hierbei keine Rolle und sollte automatisch von der Datenbank festgelegt werden.

Bei der qid sieht es hingegen schon ganz anders aus. Hier empfiehlt es sich ein klares Namensschema zu verwenden, da das Quest hinterher innerhalb von Quest-XMLs mit dieser ID identifiziert wird. Diese ID muss eindeutig sein, d.h. sie darf unter keinem Umstand für mehrere Quests verwendet werden. Das Format $fraktion_$qname_$nummer wäre dafür gut geeignet. $fraktion wäre in unserem Fall die gtu, $qname könnte transport sein (der name sollte keine _ beinhalten, nicht länger als 10-15 Zeichen sein und wenn möglich klein geschrieben werden) und die $nummer können wir in diesem Fall weglassen, da diese nur bei Folgequests mit dem selben Namen sinn macht (z.B. "Rette Vasuda" 1-5 wo bei jeder Stufe etwas anderes gemacht werden soll). Die qid wäre also gtu_transport.

enabled sollte man nicht verändern. Wenn enabled einen Wert enthält sollte dieser stehen bleiben. Wenn man ein neues QuickQuest? anlegt, sollte der Wert immer 0 sein.

qname ist der Name, den Spieler hinterher sehen können. Daher sollte er klar verständlich und nicht zu lang sein. Auch die Nummern bei Folgequests mit dem selben Namen sollten weggelassen werden, da diese nur intern interessant sind. Für unser Quest wäre also "Eine wichtige Lieferung" ganz gut ("Warentransport" oder "Transportquest" sind nicht zu empfehlen, da die Namen schon spannend/interessant klingen sollten).

dependsOnQuest legt fest welche Quests der Spieler bereits gemacht haben muss um dieses Quest beginnen zu können. Das Format ist $dateiname1_ohne_endung:$quest1_id;$dateiname2_ohne_endung:$quest2_id (Beispiel: quest_gtu_postenverteidigung_3:gtu_postenverteidigung_3;quest_gtu_ammotransp:gtu_ammotransp - quest_gtu_postenverteidigung_3.xml würde dann das Quest gtu_postenverteidigung_3 beinhalten, welches zusammen mit gtu_ammotransp erst beendet werden müsste). Da wir in unserem Fall aber keine Vorbedingungen stellen wollen bleibt dependsOnQuest einfach leer.

moreThanOnce bestimmt, ob das Quest mehr als einmal gemacht werden kann. Wenn ja muss moreThanOnce einen Wert != 0 beinhalten (am besten eine 1). Da wir das in unserem Fall haben wollen muss da also auch die 1 rein....

head bestimmt die Kopfgrafik. Diese muss unter data/quests liegen. Da wir leider immer noch nur eine Grafik haben geht nur ars.gif für unser Quest einzutragen

desc beinhaltet die Beschreibung für unser Quest. Diese kann und sollte ruhig etwas Länger und seeehr RPG-Lastig sein. In unserem Fall also z.B. "Wir hatten auf unserem GTU-Posten XYZ eine Explosion im Hauptwarenlager. Dabei wurde ein Riesenloch in die Bordwand geschlagen und ein Großteil der Waren und Vorräte treibt nun im Weltraum! Wir konnten zwar inzwischen das Loch wieder Schließen, aber der Posten braucht ganz dringend nachschub usw....". Dieser Text wird angezeigt, wenn man sich entscheidet, ob man das Quest machen will oder nicht.

shortdesc ist das Gegenstück zu desc. Dieser Text sollte kurz und klar verständlich sein. Er wird hinterher in der Übersicht angezeigt und dient dazu, dass die Spieler sich errinnern, was sie machen sollen. In unserem Fall vieleicht sowas wie "Waren zum GTU-Posten xyz transportieren"

finishtext ist der Text, der angezeigt wird, wenn man das Quest erfolgreich beendet hat. Er kann wieder recht lang sein und auch sehr RPG-lastig. Sowas wie "Sehr gut! Sie haben uns gerettet. Endlich können wir uns wieder den Bauch vollschlagen. Sie glauben ja gar nicht wie schlimm es hier war usw...."

notyettext wird angezeigt, wenn der Spieler versucht das Quest vorzeitig zu beenden. Wenn kein Text angegeben ist, wird automatisch "Tut mir leid. Du hast die Aufgabe noch nicht komplett erledigt" angezeigt. Für unseren Fall also ausreichend (Der Text kann auch hier ruhig lang und RPG-Lastig sein)

source bestimmt die Schiffs-IDs, bei der man das Quest bekommt. Mehrere IDs werden per , getrennt. In unserem Fall wäre es 12.

sourcetype bestimmt den Typ der Startschiffe. Im Moment geht nur gtuposten (Bitte nicht mit den Typen-IDs verwechseln)

target und targettype sind das selbe die source und sourcetype für die Zielschiffe an dem das Quest beendet wird. In unserem Fall also 34 und gtuposten

startitems enthält einen Cargo-String, der bestimmt, welche Waren oder Items (es geht beides!) beim Start des Quests auf das Schiff des Spielers transportiert werden. Um ein Questgebundenes Item zu "erzeugen" einfach eine 1 an die betreffende Stelle eintragen. Wir wollen das in unserem Fall auch tun und 5 Questgebunde Datadisks ( item-id 8 ;; auch wenn das zum Questkontext nur bedingt passt :) ) auf das Spielerschiff transferieren. startitems sähe dann so aus: "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8|5|0|1"

reqitems bestimmt, welche Waren oder Items (auch hier geht beides) am Ende am Ziel vorhanden sein müssen. Diese müssen natürlich nicht mit den Startitems identisch sein. Auch hier bekommt man Questgebundene Items via verwenden einer 1. Da wir nur wollen, dass die 5 Datadisks am Ziel ankommen ist der Cargo-String identisch mit dem von startitems.

reqre bestimmt, wieviel RE am Ende vorhanden sein müssen. (NOT TESTED)

awarditems bestimmt welche Waren oder Items (auch hier...was gemeint ist dürfte ja inzwischen klar sein :) ) bei erfolgreicher Beendigung des Quests dem Spieler auf sein Schiff transferiert werden. Questgebundene Items sollte man hier natürlich nicht verwenden und die Sache mit der 1 funktioniert hier auch nicht. Da wir in unserem Fall 100 Deuterium und 500 RE (die kommen in der nächsten Spalte dran) dem Spieler geben wollen sieht der String so aus: "0,100,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,"

awardre bestimmt die RE, die der Spieler bei erfolgreicher Beendigung des Quests bekommt. In unserem Fall sind das 500.

loottable bestimmt, welche Loot-Einträge speziell für die Dauer dieses Quests hinzugefügt werden sollen. Das Format ist $shiptype,$owner,$wahrscheinlichkeit,$warenid,$menge,$maxmenge. Die einzelnen Einträge werden durch ein ; getrennt. $maxmenge ist optional und bestimmt wie oft dieser Looteintrag droppen kann. Beispiel für das Item 151 (15x mit Wahrscheinlichkeit 150 bei Schiff 17 und Besitzer -1): 17,-1,150,i151|0|0,15

Damit wäre das Quest soweit fertig. Jetzt kommt es darauf an, ob das Quest noch über die Möglichkeiten des Questgenerators hinaus modifiziert werden soll oder nicht.

Mit Modifikationen

Achtung: Dieser Weg sollte nicht mehr gewählt werden. Er ist umständlich, bescheiden zu warten und sehr fehlerträchtig
Achtung: Dieser Weg funktioniert nur, wenn es nur ein Start- und ein Zielschiff gibt

Nun muss es unter Admin->quest->Quick Quests aufgerufen werden und der so generierte Code in einer Datei abgespeichert werden (ACHTUNG: UTF-8 IST ABSOLUTE PFLICHT - und da macht windows enorme Probleme). Der Name der Datei sollte natürlich auch bestimmten Konventionen folgen, damit wir hinterher überhaupt die quests noch wiederfinden. Empfehlenswert ist die Benennung analog zu qid mit einem quest_ vorne weg. In unserem Fall also quest_gtu_transport.xml. Nun kann das Script editiert werden. Anschließend kann die Datei hochgeladen werden (Admin->Quests->Quest-XML). Die benötigten GTU-Posten-Scripte müssen jetzt bereits hochgeladen und installiert sein! Nachdem die Datei hochgeladen ist muss sie noch in dem selben Admin-Plugin installiert werden. Dazu muss der Dateiname MIT die .xml-Erweiterung in das Install-Feld eingetragen werden. Der Rest dürfte klar sein. Noch ein Rat: Das rote x für Löschen in diesem Admin-Plugin wenn irgendwie möglich nicht verwenden, da so die Quest-Daten nicht aus der DB entfernt werden. Es werden lediglich alle Hinweise darauf gelöscht (die .xml und .install-Datei auf dem Server werden entfernt) wo diese Daten in der DB stehen. Eine spätere Löschung ist also dann fast nicht mehr möglich.

Ohne Modifikationen

Alles was nun getan werden muss, ist im Admin unter quests->Quick Quests neben dem Questnamen auf "inaktiv" zu klicken um das Quest zu aktivieren. An dieser Stelle kann es auch jeder Zeit wieder deaktiviert werden (Wenn Spieler dieses Quest in dem Moment machen, wird dies dann jeweils beendet). Hinweis: Die verwendeten Quellen/Ziele müssen dieses Verfahren unterstützen (!GenerateQuickQuestSourceMenu, !GenerateQuickQuestTargetMenu und !HandleQuickQuestEvent müssen verwendet werden), da keinerlei XML-Dateien erzeugt oder installierte Scripte modifiziert werden. Einzig in der Tabelle quests wird das Quest eingetragen und enabled in quests_quick auf die ID dieses Eintrags gesetzt (Deshalb auch bitte nicht an enabled rumspielen)