Store fetch: Unterschied zwischen den Versionen

Aus AntamarWiki
Wechseln zu: Navigation, Suche
K (→‎quest-unabhängig pro Held speichern)
(Beschreibung überarbeitet)
Zeile 1: Zeile 1:
−
=== pro Quest/Held-Kombination speichern ===
+
===Store===
 +
Das '''<store>'''-Tag speichert seinen (ausgewerteten) Inhalt persistent, z.B. zwischen verschiedenen 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.
 +
Der folgende Code speichert '''Inhalt der Variable''' unter dem Namen 'VariablenName' für die Dauer des laufenden Quests:
 +
<code xml>
 +
<store name="VariablenName" scope="quest">
 +
    Inhalt der Variable
 +
</store>
 +
</code>
  
−
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.
+
===Scopes/Geltungsbereiche===
−
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.
+
Den Zeitraum über welchen eine Variable gespeichert wird kann man über das Attribute '''scope''' festlegen.
 +
Im Moment gibt es hierbei fünf verschiedene Möglichkeiten.
 +
 
 +
====scene====
 +
Die Variable wird nicht in der Datenbank zwischengespeichert.
 +
Sie kann nur innerhalb derselben Scene verwendet werden.
 +
<code xml>
 +
<store name="VariablenName" scope="scene">
 +
    Inhalt der Variable
 +
</store>
 +
</code>
  
−
Beispiel:
+
====quest====
−
<code xml><store name="Heimatort">Gareth</store>
+
Die Variable wird innerhalb dieser Quest gespeichert.
 +
Sobald die Quest beendet wurde wird die Variable gelöscht.
 +
Durch eine über den [[quest|Queststatus]] pending unterbrochene Quest werden Variablen mit dem Scope quest '''nicht''' gelöscht.
 +
<code xml>
 +
<store name="VariablenName" scope="scene">
 +
    Inhalt der Variable
 +
</store>
 +
</code>
  
−
Ich komme aus <fetch name="Heimatort"/>.</code>
+
====dungeon====
−
Ergibt:
+
Die Variable ist für alle Helden die diese Quest erleben zugreifbar.
−
Ich komme aus Gareth.
+
Die Variable bleibt erhalten auch wenn ein Held die Quest schon beendet hat, bezieht sich aber im Gegensatz zum Scope 'hero' auf die Quest und nicht auf den sie absolvierenden Helden.
  
−
=== quest-unabhängig pro Held speichern ===
+
<code xml>
 +
<store name="VariablenName" scope="dungeon">
 +
    Inhalt der Variable
 +
</store>
 +
</code>
  
−
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.
+
====hero====
 +
Die Variable wird an den Helden gebunden, solange dieser existiert, kann auf sie zugegriffen werden.
  
 
<code xml>
 
<code xml>
−
<p>get: <get mark="test"/></p>
+
<store name="VariablenName" scope="dungeon">
−
<p>fetch: <fetch mark="test">nichts drin</fetch></p>
+
    Inhalt der Variable
 +
</store>
 +
</code>
  
−
<p>has: <has mark="test">
+
====global====
−
  <success>hat test-Markierung</success>
+
Die Variable wird unabhängig von Questen und Helden gespeichert.
−
  <failure>hat keine test-markierung</failure>
+
Sie wird nur manuell von Hand gelöscht.
−
</has></p>
 
  
−
<p>switch: <switch mark="test">
+
<code xml>
−
  <null>hat keine test-Markierung</null>
+
<store name="VariablenName" scope="global">
−
  <case value="gespeicherter Wert">hat test-Markierung: 'gespeicherter Wert'</case>
+
    Inhalt der Variable
−
  <else>hat eine andere test-Markierung</else>
+
</store>
−
</switch></p>
+
</code>
  
−
<p>if: <if mark="test" equals="gespeicherter Wert"
+
===expire===
−
    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>
+
Über das Attribut '''expire''' kann der Zeitraum angegeben werden in welchem diese (unabhängig vom scope) Gespeichert wird.
 +
Folgendes definiert eine Variable die nach 4 Ingame-Tagen wieder gelöscht wird.
 +
 
 +
<code xml>
 +
<store name="VariablenName" scope="global" expire="4d">
 +
    Inhalt der Variable
 +
</store>
 
</code>
 
</code>
  
−
Da die Variable in dem obigen Beispiel erst am Ende gesetzt wird, ergibt das beim ersten Durchlauf:
+
Expire kann in zwei Formaten angegeben werden "4d" für vier Ingametage, "12h" für zwölf Ingamestunden.
 +
Anmerkung: Der AOQML-Editor wird das erst ab der Version 1.0 können.
 +
 
  
−
  get:
+
===Namenskonvention===
−
  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:
+
Die Variablen können zwar technisch frei benannt werden, damit man aber schnell erkennen kann woher eine Variable kommt gelten folgende Namenskonvention: An erster Stelle der Variable steht ein Oberbegriff der den zur Variable zugehörigen Typ beschreibt.
  
−
  get: gespeicherter Wert
+
Also z.B. quest: für eine Variable die nur in einer Quest steht oder region: für eine Variable die für alle Questen einer bestimmten Region steht.
−
  fetch: gespeicherter Wert
+
Danach folgt der Pfad unter dem die Quest oder ZB abgelegt ist, der Questname und am Ende der Variablenname.
−
  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.
+
also:  Oberbegriff:PfadZurQuest/QuestName/Variablenname
  
−
Anmerkung: Der AOQML-Editor wird das erst ab der Version 1.0 können.
+
Beispiele:
 +
quest:/quests/deralteleuchtturm/hoehedesturms
 +
npc:derHerzogVonSonstwo/Name
 +
 
 +
Diese Konvention soll sicherstellen das einzelne Variablen sich nicht gegenseitig überschreiben, da die Scopes zwar die Art der Speicherung, nicht aber den Zugriff auf die Variablen regeln.
  
−
'''Namenskonvention''':
+
===fetch===
  
−
Zunächst einmal sind die Namen "Freitext". Schema ist aber:
+
Das '''<fetch>'''-Tag ruft derart gespeicherte Inhalte wieder ab.
−
* wenn die Variable nur in dem Quest gelten soll: quest:pfad/questname/varname
+
Das Attribut 'name' dient hier zum identifizieren der richtigen Variable.
−
* region: bedeutet also, dass die Variable für alle Quests (für die sie relevant ist), in der genannten Region gelten soll
+
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.
  
−
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.
+
Folgendes liefert zum Beispiel die Variable mit dem Namen "VariablenName" zurück.
 +
<code xml>
 +
<fetch name="VariablenName"/>
 +
</code>
  
−
Dieser Scope schränkt allerdings die Sicht nicht technisch ein. Theoretsch könnte jede Quest auf alle diese Variablen zugreifen.
 
  
 
[[Kategorie:AOQML-Tags]]
 
[[Kategorie:AOQML-Tags]]
 
[[Kategorie:AOQML]]
 
[[Kategorie:AOQML]]

Version vom 4. Dezember 2009, 20:20 Uhr

Store

Das <store>-Tag speichert seinen (ausgewerteten) Inhalt persistent, z.B. zwischen verschiedenen 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. Der folgende Code speichert Inhalt der Variable unter dem Namen 'VariablenName' für die Dauer des laufenden Quests: 

<store name="VariablenName" scope="quest">
     Inhalt der Variable
</store>

Scopes/Geltungsbereiche

Den Zeitraum über welchen eine Variable gespeichert wird kann man über das Attribute scope festlegen. Im Moment gibt es hierbei fünf verschiedene Möglichkeiten.

scene

Die Variable wird nicht in der Datenbank zwischengespeichert. Sie kann nur innerhalb derselben Scene verwendet werden. 

<store name="VariablenName" scope="scene">
     Inhalt der Variable
</store>

quest

Die Variable wird innerhalb dieser Quest gespeichert. Sobald die Quest beendet wurde wird die Variable gelöscht. Durch eine über den Queststatus pending unterbrochene Quest werden Variablen mit dem Scope quest nicht gelöscht. 

<store name="VariablenName" scope="scene">
     Inhalt der Variable
</store>

dungeon

Die Variable ist für alle Helden die diese Quest erleben zugreifbar. Die Variable bleibt erhalten auch wenn ein Held die Quest schon beendet hat, bezieht sich aber im Gegensatz zum Scope 'hero' auf die Quest und nicht auf den sie absolvierenden Helden. 

<store name="VariablenName" scope="dungeon">
     Inhalt der Variable
</store>

hero

Die Variable wird an den Helden gebunden, solange dieser existiert, kann auf sie zugegriffen werden. 

<store name="VariablenName" scope="dungeon">
     Inhalt der Variable
</store>

global

Die Variable wird unabhängig von Questen und Helden gespeichert. Sie wird nur manuell von Hand gelöscht. 

<store name="VariablenName" scope="global">
     Inhalt der Variable
</store>

expire

Über das Attribut expire kann der Zeitraum angegeben werden in welchem diese (unabhängig vom scope) Gespeichert wird. Folgendes definiert eine Variable die nach 4 Ingame-Tagen wieder gelöscht wird. 

<store name="VariablenName" scope="global" expire="4d">
     Inhalt der Variable
</store>

Expire kann in zwei Formaten angegeben werden "4d" für vier Ingametage, "12h" für zwölf Ingamestunden. Anmerkung: Der AOQML-Editor wird das erst ab der Version 1.0 können.


Namenskonvention

Die Variablen können zwar technisch frei benannt werden, damit man aber schnell erkennen kann woher eine Variable kommt gelten folgende Namenskonvention: An erster Stelle der Variable steht ein Oberbegriff der den zur Variable zugehörigen Typ beschreibt.

Also z.B. quest: für eine Variable die nur in einer Quest steht oder region: für eine Variable die für alle Questen einer bestimmten Region steht. Danach folgt der Pfad unter dem die Quest oder ZB abgelegt ist, der Questname und am Ende der Variablenname.

also: Oberbegriff:PfadZurQuest/QuestName/Variablenname

Beispiele: quest:/quests/deralteleuchtturm/hoehedesturms npc:derHerzogVonSonstwo/Name

Diese Konvention soll sicherstellen das einzelne Variablen sich nicht gegenseitig überschreiben, da die Scopes zwar die Art der Speicherung, nicht aber den Zugriff auf die Variablen regeln.

fetch

Das <fetch>-Tag ruft derart gespeicherte Inhalte wieder ab. Das Attribut 'name' dient hier zum identifizieren der richtigen Variable. 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.

Folgendes liefert zum Beispiel die Variable mit dem Namen "VariablenName" zurück. 

<fetch name="VariablenName"/>
Abgerufen von „https://wiki.antamar.eu/index.php?title=Store_fetch&oldid=44956“