Das wäre im vorliegenden Fall eher nicht sinnvoll. Es passiert
Wenn in Szene X die Variable Y einen bestimmten Wert hat, dann soll das Flag Z gesetzt werden und sonst eben nicht. Der (leere) Else-Zweig ist durchaus kein Fehler.

Dann lass else einfach leer. Ansonsten dürfte es einen Fehler geben. So habe ich schon mehr als eine Queste abgewürgt.

Am besten du testest es einfach in der Testumgebung. Dann weißt du, ob es klappt.

Ah, du verwendest den Else-Zweig er ist nur leer. Das ist eine völlig andere Situation als „Die Variable muss ja den Wert 3,5 oder 9 haben also frag ich nur die ab und lass den Else-Zweig weg.“ Damit sind schon einige auf die Schnauze gefallen.

Im Wiki ist ein Beispiel ohne <else/>. Abgesehen davon, dass es vielleicht besserer Stil ist, im Zweifelsfall ein leeres <else></else> zu setzen (jedenfalls im Sinne von Aoqml), sollte im Wiki eindeutig stehen, was erlaubt ist und was nicht. Wenn man andere Programmiersprachen gewohnt ist, ist es einfach verlockend, das <else/> wegzulassen.

ambermoon hat geschrieben:Wenn man andere Programmiersprachen gewohnt ist, ist es einfach verlockend, das <else/> wegzulassen.

Eigentlich ist es ein guter Programmierstil dafür Sorge zu tragen, dass es immer einen funktionierenden Exit gibt. Dafür ist else gedacht.

Das <switch/> ist u.a. ein Ersatz für IF-THEN-ELSE bzw. in diesem Fall IF-THEN der meisten gebräuchlichen Programmiersprachen. Dass es schlechter Programmierstil sein soll, z.B. in Java das else nach einem if wegzulassen, wäre mit neu.

Abend, ich mal wieder.

Mit dem Befehl set kann ich ja auch eine Variable erstellen, die praktisch als eine Art Counter fungiert.
Dazu das Beispiel aus dem Wiki:

Code: Alles auswählen

<set name="questEP" inc="5" show="none"/>

Ich nehme aufgrund des Beispiels an, dass in so einem Fall eine Variable mit dem Startwert null erstellt wird und man diese dann über die Quest hinweg mit inc/dec="x" (wobei x=ganze Zahl) modifizieren kann. Laut Wiki kann ich mit has auch Variablen abfragen. Daraus schließe ich, dass eine Abfrage der Form:

Code: Alles auswählen

<has name="questEP" min="5">
    <success>
        <include target="gespraech1"/>
        <quest status="continue"/>
    </success>
    <failure>
        <include target="gespraech2"/>
        <quest status="continue"/>
    </failure>
</has>


theoretisch funktionieren könnte. Oder kann ich damit wirklich nur den konkreten Inhalt einer Variable Abfragen? Das würde meine Pläne signifikant verkomplizieren. Sofern bei einem Counter wie diesem eine Abfrage der Form

Code: Alles auswählen

<has name="questEP" val="5">
    <success>
            <include target="gespraech1"/>
            <quest status="continue"/>
    </success>
    <failure>
        <!-- Erneute Abfrage um eine Reichweite von möglichen Werten, die zu gespraech2 führen würden, zu prüfen. -->
    </failure>
</has>


funktioniert, könnte ich sie aber zumindest noch umsetzen, wenn auch nur sehr, sehr unelegant.

Das mit has sollte funktionieren. Ansonsten kannst du das auch mit switch machen. Das hat den Vorteil, dass du mehrere unterschiedliche Inhaltsbereiche abfragen kannst.

neonix hat geschrieben:Das mit has sollte funktionieren. Ansonsten kannst du das auch mit switch machen. Das hat den Vorteil, dass du mehrere unterschiedliche Inhaltsbereiche abfragen kannst.

Prima Idee. Ich werde mir morgen ein Testprogramm schreiben um die Abfrage mit has auszuprobieren (denn eigentlich muss ich für die aktuelle Quest nur wissen ob ein Grenzwert überschritten wurde) aber die Abfrage über switch ist auch nicht schlecht, macht die Sache variabler.

In jedem Fall signifikant eleganter als meine Lösung.

Wahrscheinlich liegt der Bug nicht bei mir, sondenr in der Engine. Bei einer Grupprnreise kam folgende Fehlermeldung:

FEHLER: 'quests/schattenkuppen-kampagne/Orklager_Eisentrutz/berichten-g' kann nicht ausgeführt werden:

trying to get undefined attribute 'ort_ziel'
in /var/www/includes/classes/aoqml/quests/schattenkuppen-kampagne/Orklager_Eisentrutz/berichten-g.xml//challenge/success/p/get/ (Zeile 19)

weiter im normalen Spiel

Die Zeile 19 siehr für mich aber sauber aus.

Code: Alles auswählen

<p>Es wird immer dunkler, während ihr auf der Suche nach Soldaten Richtung <get attribute="ort_ziel"/> rennt. Damit ihr die Information schneller überbringen könnt, trennt ihr euch kurzzeitig. <get attribute="name"/> ist deutlich schneller als der Rest und setzt sich ab. Nach einer Weile trifft <get attribute="name"/> auf eine kleine betrittene Patrouille. Volkommen außer Atem hält <if attribute="gender" equals="male" then="er" else="sie"/> an und beginnt die wichtigsten Informationen weiterzugeben.</p>


Nun ergeben sich zwei Vermutungen: Das Ziel wird bei Gruppenreisen entweder anders gespeichert oder es korelliert mit den Fehlermeldungen bei der Rastfunktion, die kurz vor Ende der Strecke auftreten.

Aus jedenfall werde ich die entsprechende Abfrage vorerst aus dem Text nehmen.

Gesehen habe ich die Fehlermeldung schonmal, ich glaube auf dem Testserver, als ich der Einfachheit halber eine ZB als Quest in einer Stadt ausprobiert habe, um leichter die Varianten testen zu können. Wäre es denkbar dass einer der Charaktere schon in einer Stadt angekommen war und entsprechend das Attribut Zielort nicht mehr hatte?

Ich gestehe, ich bin zu faul im Wiki zu suchen: Gibt es eine Möglichkeit den aktuellen Ort auszulesen? Also nicht Ziel oder Start, sondern für ortsfeste Quests den Ort.

Theoran hat geschrieben:Ich gestehe, ich bin zu faul im Wiki zu suchen: Gibt es eine Möglichkeit den aktuellen Ort auszulesen? Also nicht Ziel oder Start, sondern für ortsfeste Quests den Ort.

Ortsfeste Quest werden nur in dem bestimmten Ort eingebaut. Dazu benötigt es keinen separaten Code in der Quest.

<get attribute="site" /> siehe Held Attribute#In_Orten

Bei ortsfesten Questen, die in mehreren Orten gleichzeitig laufen, ist das sogar sehr nützlich (Tempel, Söldnerlager, Mietstall ...).