Auftragsbörse allgemein

[Mitsune]

Ausgehend von dem Gedanken, eine Auftragbörse auch für Myakô anzubieten, habe ich mir die Auftragsbörse von Thalessa herunter geladen und habe sie im Editor geöffnet.
Schockschwerenot!
Aufrichtige Bewunderung für alle, die da durchsteigen. Die vielen Dateien (81) und die entsprechend zahlreichen Pfeile haben mich extrem entmutigt.
Am Ende bin ich zu der Überzeugung gelangt, dass es für mich einfacher ist das von vorn zu erstellen, als den für mich gordischen Knoten aufzudröseln.
Mit Hilfe von neonix bin ich mittlerweile soweit, dass ich einen ersten Ansatz fertig habe. Der ist noch weit entfernt von einer testbaren Version, aber man kann hoffe ich schon erkennen, wie die Struktur aussehen soll.
Mein Ziel ist es, den gesamten Programmablauf generisch zu halten, und alle Daten, die indviduell nur für den Standort der Auftragsbörse gelten, in einer Datei zu sammeln. Dadurch - so die Theorie - muss man nur eine Datei ändern und kann das ganze Konstrukt für jeden anderen Standort adaptieren.
Ich würde Euch bitten da schonmal kurz drüberzusehen, ob das ein zielführender Ansatz ist, oder ob ich mich da verrannt habe. Ich bin halt ein wenig PHP versaut und benutze da ab und an die Option Variablennamen dynamisch zu erstellen, oder sie aus Strings zusammenzusetzen.
Das habe ich auch in AOQML versucht, vor allem um zu erreichen, dass der Auftrag einer Börse den einer anderen nicht überschreiben kann. Daher soll der Standort der Börse in den Variablennamen auftauchen um die Sache eindeutig zu machen. Keine Ahnung, ob das so funktionieren kann. Manchmal schluckt der Editor das, manchmal gibt er eine Fehlermeldung aus. Aber das werdet ihr ja sehen, wenn ich die Quest im Editor öffnet. Jedenfalls wäre es so möglich Aufträge parralel zu spielen, auch wenn das IG vermutlich eine seltene Ausnahme darstellen wird.

Über Rückmeldungen und Vorschläge zu vereinfachung würde ich mich freuen.
LG

Dateianhänge

auftragsboerse.zip

(11.54 KIB) 150-mal heruntergeladen

[Gaddezwerch]

Die Idee, das Ganze mehr generisch zu halten, finde ich gut. Und ich fand die Überarbeitung der AB-Eisentrutz auch ein Horror und ich bin mir sicher, dass man es kürzer halten kann.

Das mit ${...} innerhalb von Variablen sollte eigentlich auch funktionieren, wobei ich mir nicht 100% sicher bin, bitte mal selbst testen mit einem Minimalbeispiel.

Ich würde auch ganz gerne die Beschreibung der Zettel generisch halten, sodass man sich hier nicht nur auf Farben fokussiert, sondern ggf. Adjektive wie 'vergilbt', 'fast zerfetzt', 'angerissen' usw. benutzen kann. (Intern kann weiterhin zwischen grün/gelb/rot unterschieden werden, aber nach außen hin könnten ja andere Adjektive verwendet werden).

Ein paar Anmerkungen, was mir so aufgefallen ist:

start.xml

Code:

<switch name="auftragsboerse_${auftragsboerse_standort}_initialisiert">
     <case val="TRUE">
     </case>
     <else>
        <include target="data_auftraege"/>
     </else>
     <p>Tatsächlich


Switch sollte vorher geschlossen werden, bevor Textausgabe erfolgt?!

gruen_annehmen.xml

Code:

<store name="auftrag_${auftragboerse_standort}_Ware"              scope="hero" >${auftragsboerse_${auftragsboerse_standort}_gruenWare}</store>


Bin mir unsicher, ob das mit dem $... in store so funktioniert. Wahrscheinlich wird der Inhalt dann erst beim nächsten Gebrauch ausgewertet, was unschöne Seiteneffekte haben wird. Besser mit <fetch name="auftragsboerse_${auftragsboerse_standort}_gruenWare"/> im store arbeiten.

Beim Löschen von Variablen das NULL bitte immer komplett groß schreiben, sonst wird's nicht erkannt.

Was mir noch fehlt: Möglichst auftragsbsbezogene Tagebuchtexte, wenn pending-Status gesetzt wird (kann meinetwegen später ergänzt werden, aber bitte nicht vergessen. Andernfalls lass ich sowas nicht live gehen, jetzt wo ich es erwähnt habe ).

Und noch eine Kleinigkeit in Anreise_Startort.xml, zur Frage:

Code:

<quest status="continue"/><!-- muss das hier hin?-->


Ein <quest status="continue"/> bewirkt, dass alles, was nach diesem Tag kommt, nicht mehr ausgewertet wird. Sprich, dieser Befehl teilt der Engine mit, das Laden der Szene an dieser Stelle abzubrechen, alles Folgende zu ignorieren. Die Anreise_Startort.xml ist eh überschaubar und man sieht deutlich, dass danach eh nichts mehr kommen würde (weil der else-Teil vom switch greift ja nicht) -> insofern ist die Angabe <quest status="continue"/> an dieser Stelle nicht nötig.


Ansonsten heißt es: Testen, testen, testen!

[flitzer]

Ich weiß nicht, was alles möglich ist, ich habe auch lange probieren müssen - vllt entwirfst du ja ein einfacheres Modell, wäre toll!

Bisher sieht das in meinen Augen nachvollziehbar aus. Bin aber auch kein AOQML-Profi!
Nur musst du noch einen random einbauen, ob er zu rot1 oder rot2 führt. Dafür müssten dann die Variablennamen sowieso angepasst werden.

Vllt sind wir mit der Version dann die mysteriösen leeren Variablen los

[Mitsune]

Wow, danke erstmal für die ausführlich Antwort und die Ratschläge. Dann werde ich das mal weiter verfolgen und weiter Schritte hier vorstellen.
Und mit den Tagebucheinträgen - so schnell schiessen die Preussen nicht

[Mitsune]

Ich blicke grade gar nichts mehr. Stimmt was mit der Testumgebung nicht oder bin ich völlig verbrettert und vernagelt?
start.xml

Code:

<?xml version="1.0" encoding="UTF-8"?>
<scene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://eisentrutz.antamar.eu/aoqml.xsd">

<!-- Hier bitte grundlegende Informationen zur Quest/ZB notieren. -->
<quest status="running"/>

<p>Test</p>
<store name="Foo" scope="quest" >NameFoo</store>
<p><fetch name="Foo" /></p>

<quest status="ended" frequency="rar"/>
</scene>

Fehlermeldung:

Code:

 'quests/230/start' kann nicht ausgeführt werden:

fetchVar() without name
in /var/www/Antamar_quest/includes/classes/aoqml/quests/230/start.xml//scene/p/fetch/


[neonix]

Vielleicht kann er das nicht in einer Szene speichern und ausführen? Versuch doch mal, die Auswertung in eine zweite Szene zu includen. Und das Questende in eine dritte.

[Mitsune]

Tatsache
Danke!

[Mitsune]

Und noch ne Frage:

Code:

<switch attribute="site">
  <null>
     <quest status="pending"/>
  </null>
  <case val="auftrag_${auftragboerse_standort}_Startort">
     <include target="Ankunft_Startort"/>
  </case>
  <else>
     <quest status="pending"/>
  </else>
</switch>
</scene>

Sind die Zeilen 2-4 nicht unnötig? Kann Attribut "site" überhaupt NULL sein. Irgendwo ist der Char doch immer, oder?

[neonix]

Nee, unterwegs gibt es keine site sondern nur weg_blah.

[Mitsune]

Verstehe - danke.
Und noch 'ne Frage:
Kann man Tagebucheinträge setzen, ohne die Quest zu beenden? In dem konkreten Fall wäre es ganz praktisch, wenn man dem Helden ins Tagebuch schreiben könnte:

Liebes Tagebuch. Ich habe heute einen Auftrag angenommen. Ich soll ANZAHL mal WARE von STARTORT nach ZIELORT bringen. Die Belohnung klang nicht schlecht für das bisschen Arbeit.

Das würde die Sache für den Spieler erleichtern, weil er nachsehen kann, was er eigentlich zu tun hat.
Das hier:

Code:

<store name="temp_tagebuch" scope="quest" expire="1d">Liebes Tagebuch. Heute habe ich einen Auftrag angenommen. Die Belohnung war verlockend. Ich soll <fetch name="auftrag_${auftragboerse_standort}_Warenmenge" /> mal <fetch name="auftrag_${auftragboerse_standort}_Ware" /> von <fetch name="auftrag_${auftragboerse_standort}_Startort" /> nach <fetch name="auftrag_${auftragboerse_standort}_Zielort" /> bringen. Klingt nach einer leichten Übung.</store>

<quest status="continue" note="${temp_tagebuch}"/>

scheint nicht zu funktionieren. Bei status="continue" wird vermutlich kein Eintrag vorgenommen?

[Xondorax]

Aber der Held sieht doch in jeder Stadt, welcher Auftrag gerade von ihm abgewickelt wird.

[Mitsune]

Wie kommst Du darauf?

[Xondorax]

Wenn du einen Auftrag in ET annimmst, also in der Auftragsbörse, dann siehst du doch was du machen musst, sobald du in einer Stadt bist oder werfe ich was durcheinander?

[Mitsune]

Ja, das mit dem Durcheinanderwerfen kommt hin.
Ich versuche die implementierte Auftragsbörse möglichst simpel und generisch neu zu bauen, damit man sie mit möglichst marginalen Änderungen für jeden anderen Standort einbauen kann.
Aber trotzdem ein guter Hinweis. Dann löse ich es analog.

[Gaddezwerch]

beim Queststatus 'continue' wird kein Tagebucheintrag gesetzt.

Und Xondorax hat Recht. Sobald du den Auftrag annimmst, ist die Quest ja noch aktiv. Die Quest wird durch den Spieler ja nicht beendet, sondern sie läuft die ganze Zeit. Bisher ist es so, dass der Auftragstext (was der Held zu besorgen/abzugeben hat) dann immer ausgegeben wird.

Code:

<p>Test</p>
<store name="Foo" scope="quest" >NameFoo</store>
<p><fetch name="Foo" /></p>

Das muss funktionieren. Was war da das Problem?