Store fetch: Unterschied zwischen den Versionen

Aus AntamarWiki
Wechseln zu: Navigation, Suche
K (pro Quest/Held-Kombination speichern: Relation zum Get-Tag erläutert)
K (Namen für mark)
Zeile 58: Zeile 58:
  
 
Anmerkung: Der AOQML-Editor wird das erst ab der Version 1.0 können.
 
Anmerkung: Der AOQML-Editor wird das erst ab der Version 1.0 können.
 +
 +
'''Namenskonvention''':
 +
 +
Zunächst einmal sind die Namen "Freitext". Schema ist aber:
 +
* wenn die Variable nur in dem Quest gelten soll: quest:pfad/questname/varname
 +
* region: bedeutet also, dass die Variable für alle Quests (für die sie relevant ist), in der genannten Region gelten soll
 +
 +
Man könnte auch noch sowas wie "npc:DukeVonXYZ/..." machen, und damit z.B. Beziehungen zu NPCs (kennt, befreundet, befeindet etc.) speicher, die auch in allen Questen ggf. abgefragt werden könnten.
 +
 +
Dieser Scope schränkt allerdings die Sicht nicht technisch ein. Theoretsch könnte jede Quest auf alle diese Variablen zugreifen.
  
 
[[Kategorie:AOQML]]
 
[[Kategorie:AOQML]]

Version vom 27. Juni 2009, 09:44 Uhr

pro Quest/Held-Kombination speichern

Das <store>-Tag speichert seinen (ausgewerteten) Inhalt persistent, z.B. zwischen verchiedenen Schritten eines Quests. Das Attribut 'name' gibt dabei an, unter welchem Namen es gespeichert werden soll. Der Inhalt selbst wird an dieser Stelle nicht ausgegeben. Das <fetch>-Tag ruft derart gespeicherte Inhalte wieder ab. Auch dabei wird das Attribut 'name' zum identifizieren verwendet. Sollte kein Inhalt unter diesem Namen gespeichert sein, und nur dann, wird der Inhalt des fetch-Tags ausgewertet, sozusagen als Default. Dies ist einer der Hauptunterschiede zum get-Tag. Beim get-Tag wird kein Default-Inhalt ausgewertet.

Beispiel:

<store name="Heimatort">Gareth</store>

Ich komme aus <fetch name="Heimatort"/>.

Ergibt:

Ich komme aus Gareth.

quest-unabhängig pro Held speichern

Während obiger Werte nur während eines Quests - wenn auch über pending-Unterbrechnungen hinaus - erhalten bleiben und pro Quest/Held gelten, kann man mit mark= auch etwas dauerhaft oder limitiert am Helden speichern und dies in allen Questen nutzen.

<p>get: <get mark="test"/></p>
<p>fetch: <fetch mark="test">nichts drin</fetch></p>

<p>has: <has mark="test">
  <success>hat test-Markierung</success>
  <failure>hat keine test-markierung</failure>
</has></p>

<p>switch: <switch mark="test">
  <null>hat keine test-Markierung</null>
  <case value="gespeicherter Wert">hat test-Markierung: 'gespeicherter Wert'</case>
  <else>hat eine andere test-Markierung</else>
</switch></p>

<p>if: <if mark="test" equals="gespeicherter Wert" 
    null="hat keine test-Markierung" 
    then="hat test-Markierung 'gespeicherter Wert'" 
    else="hat eine test-Markierung"/></p>

<store mark="test" expire="12h">gespeicherter Wert</store>

Da die Variable in dem obigen Beispiel erst am Ende gesetzt wird, ergibt das beim ersten Durchlauf:

 get:
 fetch: nichts drin
 has: [hat : [test: 0*vorhanden] ] hat keine test-markierung
 switch: hat keine test-Markierung
 if: hat keine test-Markierung

Und beim zweiten, wenn dann die Variable vom Ende des ersten, gesetzt wurde:


 get: gespeicherter Wert
 fetch: gespeicherter Wert
 has: [hat : [test: 1*vorhanden] ] hat test-Markierung
 switch: hat test-Markierung: 'gespeicherter Wert'
 if: hat test-Markierung 'gespeicherter Wert'

Für expire= kann man Tage ("5d") oder Stunden ("12h") angeben oder dies, für dauerhaftes speichern, auch ganz weglassen. Die Zeitangaben sind in-game, also derzeit 1d=4min.

Anmerkung: Der AOQML-Editor wird das erst ab der Version 1.0 können.

Namenskonvention:

Zunächst einmal sind die Namen "Freitext". Schema ist aber:

  • wenn die Variable nur in dem Quest gelten soll: quest:pfad/questname/varname
  • region: bedeutet also, dass die Variable für alle Quests (für die sie relevant ist), in der genannten Region gelten soll

Man könnte auch noch sowas wie "npc:DukeVonXYZ/..." machen, und damit z.B. Beziehungen zu NPCs (kennt, befreundet, befeindet etc.) speicher, die auch in allen Questen ggf. abgefragt werden könnten.

Dieser Scope schränkt allerdings die Sicht nicht technisch ein. Theoretsch könnte jede Quest auf alle diese Variablen zugreifen.