AOQML: Variablen-Geltungsbereiche (Scopes)

[Lowlander]

Moin Moin,
hier
ich bin dabei, das AOQML Variablen-Konzept (store/fetch mit name=/mark=) zu überarbeiten. Hier ein paar Vorab-Infos: Dafür wird mark= wieder entfallen und dafür kann man dann zum einen bei store einen Geltungsbereich (Scope) angeben und zum anderen auch für Varible mit name= eine Gültigkeitsdauer angeben.

Folgende Scopes habe ich dabei vorgesehen:

• scene:
  Die Variable wird gar nicht erst in der Datenbank gespeichert, ist nur bis zum Ende der Szene (aber auch über include-Grenzen hinweg) gültig. Damit sollen Seiteneffekte eingeschränkt und die Datenbank sauber gehalten werden.
• quest:
  Dieser Scope entspricht dem derzeitigen Scope für Variable, die mit name= angelegt wurden. Sie gelten nur für den aktuellen Helden und für das laufende Quest. Andere Helden sehen diesen Wert also nicht und bei Ende des Quests (nicht bei pending!) werden diese Variablen automatisch gelöscht.
• dungeon:
  Der Begriff 'dungeon' ist hier sehr weit zu sehen, eigentlich ist so etwas wie ein "Quest-Konfigurations-Ort" gemeint. Vielleicht fällt uns noch ein besserer Name ein. Diese Variablen gelten jedenfalls für eine eine Zeile in der Tabelle ant_quest. Sie können von allen Helden gesehen werden und bleiben auch nach Questende erhalten. Gelöscht werden sie explizit oder automatisch wenn die zugehörige Quest-Konfiguration gelöscht wird. Mit diesem Scope-Typ kann man z.B. gemeinsame Inventare abbilden (was der Held verliert oder ablegt, könnte ein anderer finden).
• hero:
  Diese Variablen entsprechen dem bisherigen mark=. Sie gelten nur für einen Helden, sind aber Quest-unabhängig. Gelöscht werden sie explizit oder automatisch, wenn der Held gelöscht wird. Damit kann man z.B. spezielles in-game-Heldenwissen abbilden, welches nicht weitergegeben werden kann.
• global:
  Diese Variablen gelten für alle Helden und alle Quests. Gelöscht werden sie nur explizit.

Ist der Scope einmal definiert, dann braucht er, z.B. bei Wertänderungen oder Abfragen nicht mehr angegeben zu werden. Es wird dann in obiger Liste von oben nach unten gesucht. Wird die Variable gar nicht gefunden, dann wird sie (wie jetzt) im Quest-Scope angelegt. Sollte ein Variablen-Name in mehreren der o.g. Scopes definiert sein, wird also immer der nach obiger Liste erste Scope, in dem sie gefunden wird, genommen.

Das Konzept erspart in den meisten Fällen, darüber nachzudenken, wie eine Variable nun gefunden werden kann (also ob mit name= oder mark= - und für die o.g. Möglichkeiten bräuchte man ja noch viel mehr davon). Nur beim Anlegen muss man über die Gültigkeit nachdenken. Die Scopes gelten auch z.B. für Inventare d.h. scope= gäbe es in <store> und <inventory>. Bei gespeicherten Proben sehe ich keinen Sinn darin, sie in einem anderen Scope als "quest" anzulegen. Vielmehr sind es meist eher die konkreten Folgen (geknacktes Schloss oder sowas) die ggf. in einem anderen Scope gemerkt werden - dann aber explizit.

Code:

<!-- ein Inventar definieren, dass für alle Helden gemeinsam gilt -->
<inventory name="GrosseSchatzkammer" scope="dungeon">

...

<!-- z.B. bei Gefangennahme die Ausrüstung des Helden in die gemeinsame Schatzkammer legen -->
<drop item="*" to="GrosseSchatzkammer"/>

...

<!-- jeder Held kann die Sachen dort finden -->
<take from="GrosseSchatzkammer"/>


p.s. Das folgende mehr für Entwickler: Ein Problem ist wohl nach wie vor, dass nicht jeder Seitenabruf in einer Datenbank-Transaktion stattfindet. Bei gemeinsam genutzten Variablen könnte es somit Inkonsistenzen geben (z.B. zwei Helden entnehmen einen Gegenstand). Evlt. kapsele ich wenigstens eine Szenen-Verarbeitung in eine Datenbank-Transaktion.

[Tommek]

Das entnehmen müsste aber doch absolut zeitgleich erfolgen um den Gegenstand zu vermehren, oder?
Bzw. bevor der DELETE Befehl durch ist, was ja fast aufs selbe rauskommt.

[Lowlander]

Das entnehmen müsste aber doch absolut zeitgleich erfolgen um den Gegenstand zu vermehren, oder?
Bzw. bevor der DELETE Befehl durch ist, was ja fast aufs selbe rauskommt.

Ja, zwei HTTP Requests die auf dasselbe Inventar zugreifen UND sich so überlappen, dass der Gegenstand bei beiden als vorhanden gilt und daher zweimal entnommen wird. Es reicht nicht aus, dass er als Auswahlliste angezeigt wurde, denn beim eigentlichen Entnehmen wird nochmals geprüft. Das könnte man auch alleine mit zwei Helden und zwei Computern und gleichzeitigem Klick erzwingen.

[Lowlander]

Das neue Variablen-Konzept ist nun online. Für Inventare funktioniert es leider noch nicht, weil ich da an einer Stelle im Programmcode der Engine den Scope kennen müsste, wo ich noch keinen habe. Da muss ich mir noch etwas einfallen lassen.

Ein paar Ideen, was man mit globalen Variablen machen könnte:
- Eine Top-Ten Liste, z.B. der schnellsten Chars von A nach B (besonders spannend, wenn es dabei durch Orkland geht und man die Strecke nicht mit dem Schiff oder einer Kutsche befahren kann
- Schiffbrüchige auf einer Insel, die gemeinsam an einem Flucht-Boot bauen.
- sobald es auch mit Inventaren funktioniert: Char A könnte die Ausrüstung finden, die Char B geklaut wurde

mark="..." gilt noch und wirkt wie mark="..." scope="hero", mark= fliegt aber demnächst raus.

Demnächst passe ich dafür dann die Quests im Verzeichnis quests/ an. Dabei räume ich dann auch mit Variablen auf, bei denen scope="scene" reicht - die also gar nicht erst gespeichert werden müssen. Denkt bei neuen Quests bitte gleich daran!

Und beim scope="global" und scope="hero" sollte man im Namen i.d.R. die Quest angeben (z:B. "quest:quests/orkhoehlen/schluessel") - außer die Var bezieht sich auf eine Region (z.B. Versklavung, dann z.B. "region:orkland/versklavt") - ähnliches kann man für NPC-Beziehungen machen. Der scope bezieht sich nämlich nur auf die Lebenszeit und nicht unbedingt auf die Sichtbarkeit!

Ich befüchte noch Probleme bezüglich quasi-gleichzeitigem Zugriff. Darüber müsste ich aber nochmal in Ruhe nachdenken.

[Gaddezwerch]

Ich glaube, die Scopes haben dazu geführt, dass bei der Wundheiler-Quest die Variablen "er" und "sie" nur für die Start-Scene gesetzt bleiben, und es daher zu folgendem "Fehler" (Nichtanzeige des Variableninhalts) in der zweiten Scene kommt:

Und nochmal das ganze - diesmal bei einer Geweihten (in der selben Stadt...):
"
Die Geweihte füllt Wasser in einen Becher und fügt dann einige Tropfen aus einer kleinen Ampulle hinzu. Dann reicht dir den Becher, den du sofort leertrinkst [+6 LEP => 22].
"

Personalpronomen "sie" fehlt...

Die Variablen "er" und "sie" werden in /lib/_medicus.xml bzw. /lib/pronomen-m.xml bzw. /lib/pronomen-w.xml gesetzt.

Soll ich da jetzt beim <store> -Tag ein scope="quest" angeben, oder wie?

[Tommek]

Japp, das sollte dann wieder klappen.

[proser]

Wäre toll, wenn jemand, der das hier genau versteht, die Wiki-Beschreibung (z.B. bei Store fetch) ändern/ergänzen könnte.

[Gaddezwerch]

proser, was verstehst du daran nicht? Wichtig ist nur dieser Teil.

Folgende Scopes habe ich dabei vorgesehen:

• scene:
  Die Variable wird gar nicht erst in der Datenbank gespeichert, ist nur bis zum Ende der Szene (aber auch über include-Grenzen hinweg) gültig. Damit sollen Seiteneffekte eingeschränkt und die Datenbank sauber gehalten werden.
• quest:
  Dieser Scope entspricht dem derzeitigen Scope für Variable, die mit name= angelegt wurden. Sie gelten nur für den aktuellen Helden und für das laufende Quest. Andere Helden sehen diesen Wert also nicht und bei Ende des Quests (nicht bei pending!) werden diese Variablen automatisch gelöscht.
• dungeon:
  Der Begriff 'dungeon' ist hier sehr weit zu sehen, eigentlich ist so etwas wie ein "Quest-Konfigurations-Ort" gemeint. Vielleicht fällt uns noch ein besserer Name ein. Diese Variablen gelten jedenfalls für eine eine Zeile in der Tabelle ant_quest. Sie können von allen Helden gesehen werden und bleiben auch nach Questende erhalten. Gelöscht werden sie explizit oder automatisch wenn die zugehörige Quest-Konfiguration gelöscht wird. Mit diesem Scope-Typ kann man z.B. gemeinsame Inventare abbilden (was der Held verliert oder ablegt, könnte ein anderer finden).
• hero:
  Diese Variablen entsprechen dem bisherigen mark=. Sie gelten nur für einen Helden, sind aber Quest-unabhängig. Gelöscht werden sie explizit oder automatisch, wenn der Held gelöscht wird. Damit kann man z.B. spezielles in-game-Heldenwissen abbilden, welches nicht weitergegeben werden kann.
• global:
  Diese Variablen gelten für alle Helden und alle Quests. Gelöscht werden sie nur explizit.

Also ist bei <store> immer ein scope="..." anzugeben. Meistens sollte wohl "quest" (Variable wird nur für diese Quest gesetzt) oder "hero" (Variable ist für den Helden questübergreifend gesetzt) zutreffen.

[proser]

Ich verstehe es schon prinzipiell, aber nicht so gut, dass ich das sinnvoll im Wiki erklären könnte, wo ich dazu nichts gefunden habe.

[janb]

Ich versuch es nachher mal zusammen zu fassen, einige andere der neuen Funktionen stehen auch noch nicht drin ....

Schöne Grüsse,

der Jan

[janb]

Ok ist überarbeitet, aber kann man es auch verstehen ? Store fetch

Schöne Grüße,

der Jan

[neonix]

Ich finds nicht schlecht.

[proser]

[Askaian]

Weil ich nicht weiß, ob es sich umsetzen lässt hier eine ziemlich ausgefallene Idee.

Scopes für einen Orden. Das heißt jedes Mitglied eines Ordens hat eine Variabele.

Wofür könnte man das Gebrauchen:
Eigentum in Ortsfesten Questen. Ein Orden könnte sich zum Beispiel einen Lagerplatz im Holzfällerlager kaufen, worauf jedes Ordensmitglied Zugriff hätte. Oder einen Teil einer Werkstatt, z. B. Schiffswerft, was für jeden Spieler zu teuer wäre.

Orden könnten zusammen eine Queste bestehen. Wäre doch einmal cool als Orden bei der Ferteidigung von Wangalen zur Hilfe gebeten zu werden.

Was anders fällt mir dafür nicht ein.