Bei der Umfrage wurde öfter genannt, dass ihr euch echte Schleifen wünscht. Kann mir bitte jemand ein Beispiel geben, wo sowas hilfreich wäre (ich vermute, beim Durchgehen von Gruppenmitgliedern??) und hat eventuell schon eine Vorstellung wie das AOQML-mäßig aussehen könnte?

Gaddezwerch hat geschrieben:Bei der Umfrage wurde öfter genannt, dass ihr euch echte Schleifen wünscht. Kann mir bitte jemand ein Beispiel geben, wo sowas hilfreich wäre (ich vermute, beim Durchgehen von Gruppenmitgliedern??) und hat eventuell schon eine Vorstellung wie das AOQML-mäßig aussehen könnte?

http://forum.antamar-community.de/viewtopic.php?f=77&t=9748&p=271116&hilit=schleifen+aoqml#p270945 nennt zwei Beispiele: Für alle (ich vermute mal gemeint war für alle ausgewählten) Eigenschaften und für alle (hier wohl wirklich alle) Helden. Gleich im Beitrag danach geht es dann um eine Zählschleife (für 5 Wölfe versuche nacheinander eine Kürschner/Gerben-Probe).

Für letzuteres würde ich vorschlagen:

Code: Alles auswählen

<for name="wolfNummer" from="1" inc="1" to="5"> ... </for>

Für die anderen Fälle müsste AOQML erst einmal mit Mengen, Arrays oder Listen umgehen lernen. Ich könnte mir so etwas in der Art vorstellen:

Code: Alles auswählen

<for all="sys:heroes">... </for>

Aber eigentlich müsste AOQML dann erst einmal mit Mengen oder Arrays bzw. Listen umgehen lernen. Und mir fällt noch nichts ein, wie man dann z.B. die (xsd-) Prüfung auf gültige Fertigkeits-Bezeichnungen beibehalten sollte, wenn die einfach in einer String-Liste landen. Vermutlich fällt das dann unter den Tisch, wie ja auch, wenn man einen (1) Fertikeits-Bezeichner in einer Variable speichert und darüber in einer Probe verwendet.

Skizze:

Code: Alles auswählen

<set name="fertigkeiten">
    <element>Athletik</element>
    <element>Geländelauf</element>
    <element>Körperbeherrschung</element>
</set>
<for all="fertigkeiten" name="fertigkeit">
    <challenge talent="${fertigkeit}">...</challenge>
</for>


Was dann aber fehlt

Alternativ könnte man auch alles eine Abstraktionsebene verschieben, also im all keine Variable, sondern direkt die Menge zu erwarten:

Code: Alles auswählen

<for all="${sys:heroes}" name="hero">... </for>

oder:

Code: Alles auswählen

<for all="Athletik|Geländelauf|Körperbeherrschung" name="fertigkeit">... </for>

Doch wie wollte man dann verschiedene Modifikatoren unterbringen? Dann landet man schon bei weiteren Datenstrukturen, die AOQML noch nicht kennt.

Kurzum: Wenn man allgemeingültige Schleifen für AOQML entwerfen will, muss das Feature gut überlegt werden. Gaddezwerchs Frage nach Anwendungsfällen ist daher sehr wichtig.

Persönlich gefällt mir dein erster Ansatz ganz gut, also AOQML - Mengen beizubringen. zB. mit

Code: Alles auswählen

    <set name="fertigkeiten">
        <element>Athletik</element>
        <element>Geländelauf</element>
        <element>Körperbeherrschung</element>
    </set>
    <for all="fertigkeiten" name="fertigkeit">
        <challenge talent="${fertigkeit}">...</challenge>
    </for>


danach schreibst du "Was dann aber fehlt" - Ist hier dein Beitrag unvollständig oder meinst du die fehlende XSD-Validierung auf gültige Fertigkeits-Bezeichnungen, die du im Absatz davor erwähnst?

Das Problem sehe ich auch, und ggf. kann man es noch einmal umgehen, indem man beispielsweise "typisierte Mengen einführt. Bspw.

Code: Alles auswählen

    <fertigkeiten-set name="fertigkeiten">
        <element>Athletik</element>
        <element>Geländelauf</element>
        <element>Körperbeherrschung</element>
    </fertigkeiten-set>


oder

Code: Alles auswählen

 <set t="Fertigeit" name="fertigkeiten">
        <element>Athletik</element>
        <element>Geländelauf</element>
        <element>Körperbeherrschung</element>
    </set>


Was vielleicht eine Überlegung Wert ist, wenn AOQML jetzt immer komplexer wird: passt die Abbildung der Sprachdefinition überhaupt noch in eine XSD, oder brauchen wir einen richtigen Parser?

Gruß
Enno

Enno hat geschrieben:danach schreibst du "Was dann aber fehlt" - Ist hier dein Beitrag unvollständig oder meinst du die fehlende XSD-Validierung auf gültige Fertigkeits-Bezeichnungen, die du im Absatz davor erwähnst?

Keine Ahnung, was ich da sagen wollte. War vielleicht auch ein begonnener und nicht beendeter Gedanke.

Enno hat geschrieben:Das Problem sehe ich auch, und ggf. kann man es noch einmal umgehen, indem man beispielsweise "typisierte Mengen einführt. Bspw.

Code: Alles auswählen

    <fertigkeiten-set name="fertigkeiten">
        <element>Athletik</element>
        <element>Geländelauf</element>
        <element>Körperbeherrschung</element>
    </fertigkeiten-set>


Sorry, aber das fände ich richtig hässlich.

Enno hat geschrieben:oder

Code: Alles auswählen

 <set t="Fertigeit" name="fertigkeiten">
        <element>Athletik</element>
        <element>Geländelauf</element>
        <element>Körperbeherrschung</element>
    </set>


Im Ansatz schon deutlich besser. Aber wie du schon selbst im Folgenden schreibst, ist das nicht mehr mit XSD prüfbar:

Enno hat geschrieben:Was vielleicht eine Überlegung Wert ist, wenn AOQML jetzt immer komplexer wird: passt die Abbildung der Sprachdefinition überhaupt noch in eine XSD, oder brauchen wir einen richtigen Parser?

Was dann aber auch bedeutet, dass jedes kleine Attribut einen neuen Editor erfordert und es nicht mehr ausreicht, die XSD auszutauschen. Und es besteht die Gefahr, dass der Editor immer mehr Antamar-spezifisch wird, was mir nicht gefällt, solange nicht das Grund-Regelwerk frei verwendbar ist.

Da es auch eh viele Abhängigkeiten gibt und durch Indirektionen (Variable) an vielen Stellen die statischen Prüfungen nicht möglich sind, wäre eine Ausführungsumgebung direkt im Editor viel effektiver. Wie ich sehe, hat an der neuen Engine keiner was gemacht. Das ist gut, denn ich bin mir nicht sicher, ob der Ansatz gut genug ist. Ich mache dafür mal einen neuen Thread auf.

Ich hätte gerne erstmal einen (oder mehrere) echte(n) Anwendungsfall/-fälle. Sich ein Set aus Fertigkeiten zusammenzustellen mag zwar technisch schön sein, aber wenn danach nur eine Probe ausgeführt werden soll, könnte man das genauso gut sequenziell machen.

Nach wie vor vermute ich den größten Bedarf bei Gruppen-ZB/-Quests, um da durch alle Helden durchzuiterieren, damit jeder Held was macht oder damit jeder Held auf etwas bestimmtes geprüft wird. Ein paar "handfeste" Beispiele wären schön.

Gaddezwerch hat geschrieben:Nach wie vor vermute ich den größten Bedarf bei Gruppen-ZB/-Quests, um da durch alle Helden durchzuiterieren, damit jeder Held was macht oder damit jeder Held auf etwas bestimmtes geprüft wird. Ein paar "handfeste" Beispiele wären schön.

Was genau mit "Schleifen" gemeint ist, weiß ich nicht vollumfänglich, von mir kam das in der Umfrage auch nicht. Insofern Verzeihung, wenn ich jetzt Dinge einwerfe, die hierfür eher weniger relevant sein sollten. Wenn ich das richtig verstanden habe, soll es darum gehen, auch jenseits von retain einfache Möglichkeiten zu bieten, die Helden z.B. nacheinander etwas machen zu lassen?

Ein Punkt sind natürlich Proben, die nacheinander abgelegt werden sollen. Beispiel: Die Gruppe öffnet eine Kiste, in der lauter vergammelte Lebensmittel liegen. ->Probe auf Selbstbeherrschung für jeden einzeln, die, die es vergeigen, übergeben sich und erleiden etwas Schaden. Oder die Helden müssen unter einem Durchbruch durchtauchen. -> Probe auf Tauchen für alle Helden. Derzeit nur mit Retain möglich (aber immerhin möglich). Beispiel:

Code: Alles auswählen

<?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">

    <retain name="tauchenprobe_einzeln" id="tauchenprobe_einzeln-1">
    <set name="aktuelle_nr" inc="1" show="none"/>
     
    <!-- Held selektieren -->
    <store name="heroAttr">nr_1<fetch name="aktuelle_nr"/></store>
    <select hero="${heroAttr}"/>

<challenge talent="Tauchen">
 
   <success>
   <include target="tauchen_bestanden_1_sf4"/>
   </success>

   <failure>
    <include target="tauchen_nicht_bestanden_1_sf4"/>
   </failure>

</challenge>
   
    <!-- gibt es noch weitere Gruppenmitglieder? -->
    <switch attribute="anzahl_gruppenmitglieder">
    <case name="aktuelle_nr">
    <!-- Unsere Variable 'aktuelle_nr' entspricht jetzt dem Attribut 'anzahl_gruppenmitglieder'.
      Daher wurden alle Gruppenmitglieder einmal aufgerufen.
      Daher nichts weiter machen. -->
    </case>
    <else>

    <!-- sich erneut aufrufen -->
    <replay name="tauchenprobe_einzeln" />
    </else>
    </switch>
    </retain>
     
    <store name="aktuelle_nr">0</store>
    <replay name="tauchenprobe_einzeln"/>

</scene>

Auch solche Sachen, wie dass jeder Held einmal durchgegangen werden soll, um ihm einige LeP abzunehmen. Auch mit retain machbar, aber umständlich, insb. auch in Hinsicht auf Trefferzonen und Berücksichtigung des RS.

Oder Abfragen, ob bestimmte Sachen im Inventar sind. Beispiel: Hat die Gruppe fünf Seile dabei? Oder hat die Gruppe genug Geld für eine ganz bestimmte Sache? Fünf Seile zum Beispiel: Ich kann leicht abfragen, ob ein Held fünf Seile im Gepäck hat. Was ist aber, wenn ein Held vier Seile hat und ein anderer eins? Auch damit wäre die Auflage erfüllt. Umständlich.

Beim Geld ist es ähnlich, wenn man das Gesamtvermögen der Gruppe haben will und wenn man dann bestenfalls auch den zu zahlenden Preis möglichst fair aufteilen will. Machbar, aber ein extrem schwieriger Klotz. Ich kann abfragen, ob ein Held 100 Gulden hat. Aber alle zusammen?
Auch die Serverbelastung spielt da beim fairen Bezahlen z.B. mit rein, bei einem ersten Versuch auf dem Testserver fror dieser erstmal für eine halbe Minute ein, weswegen das untauglich war. Inzwischen haben wir dafür allerdings ein ökonomisches Skript. Aber das zu schreiben ist schon etwas für Fortgeschrittene. Dabei müsste sowas eigentlich "basic" sein bei Gruppenquesten.

Für mich ist das größte Problem bei Gruppenquesten - hier weiß ich allerdings nicht genau, ob das unbedingt zu diesem Thema passt - derzeit allerdings die Selektierung bei Gruppenquesten. Selektierung nach bestimmten Kriterien. Auch hier: Man kann nahezu alles irgendwie hinbiegen durch einen Workaround mit retain, aber teils ist das extrem umständlich. Und man braucht das eigentlich überall. Das fängt schon bei so einfachen Sachen an wie "Alle außer Gruppenführer selektieren" oder "Einen Nicht-Gruppenführer selektieren". Da muss man via retain zufällig drei (oder eben einen) Helden selektieren, bis eben alle außer dem Gruppenführer erwischt wurden.

Wenn ich alle kampffähigen Helden selektieren will, ist das umständlich. Oder nach irgendwelchen anderen Kriterien alle Helden selektieren will, die das Geforderte erfüllen.

Anderes Beispiel: Ich habe einen Helden selektiert und möchte im Anschluss einen anderen Helden nach bestimmten Kriterien selektieren. Beispiel: Ein Held ist selektiert. Jetzt möchte ich von den anderen drei Helden den stärksten selektieren. SEHR umständlich. Oder wenn ich einen Zwerg selektieren will. Wieder das gleiche Spiel: Zufällig einen Helden selektieren, bis es eben ein Zwerg ist. Und das trifft auch auf alles andere zu, wenn ich z.B. einen Helden selektieren will, der einen bestimmten Gegenstand im Gepäck hat.

Härtefälle sind solche Sachen, wo man z.B. für einen bestimmten Zeitraum einen Helden "außenvorlassen" will. Beispiel: Ein Held hält einen Hebel fest, damit sich eine Tür öffnet. Im folgenden muss man bei jeder Kleinigkeit berücksichtigen, dass der Held am Hebel nicht berücksichtigt werden darf. Wenn eine Probe abgelegt werden soll, irgendwas gemacht werden soll, etc. Bei jeder Selektierung muss man das berücksichtigen.

Sicher sind das alles Sachen, die man sich als Questautor nicht antun muss. Das hat man ja selber in der Hand. Aber in Sachen Gruppenquesten tun sich derzeit oft Probleme auf und es wird schnell kompliziert. Insofern sind Gruppenquesten, zumindest wenn man das vernünftig machen will, etwas schwieriger zu schreiben. Man muss fast schon einen erfahrenen Programmierer an Bord haben, um (größere) Gruppenquesten überhaupt schreiben zu können.

Wofür sich nun möglicherweise Lösungen finden lassen und wo eher nicht, kann ich nicht sagen. Wie gesagt: Alles, was ich hier aufgeführt habe, ist derzeit zumindest wohl lösbar mit retain. Aber teils eben sehr schwierig. Wenn da Vereinfachungen gefunden werden können, wäre mir das durchaus Recht.

Das nur mal so ein paar Gedanken eines Laien, der sich allerdings schon eine Weile mit Gruppenquesten rumplagt.

Danke, ein sehr wertvoller Beitrag!

Was das Abfragen von den 5 Seilen oder der Geldmenge angeht, ist wohl eher etwas, das man direkt bei has nachrüsten sollte ... komisch, dass das erst jetzt auffällt. Mit <has item="Seil" min="5"> fragt man derzeit ab, ob EIN Held 5 Seile dabei hat. Ich könnte mir da soetwas vorstellen:

Code: Alles auswählen

<has item="Seil" group-min="5">

Beim Tauchen-Beispiel: Wieso nicht Tauchen-Probe für alle ablegen, und diejenigen, die die Probe verhauen werden mittels <failure select-heroes="true"> selektieren?


Nichtsdestotrotz bedarf es wahrscheinlich neuen Lösungen mit for wie oben vorgeschlagen. So ein

Code: Alles auswählen

<for all="sys:heroes">... </for>

erscheint mir da ganz logisch, wobei man hier vermutlich immer EIN Held im Rumpf der Schleife selektiert haben möchte und dieser implizite Select geht schon etwas über eine reines "for" hinaus.

Code: Alles auswählen

<for all="sys:heroes" name="heldid">
  <select hero="${heldid}"/><!-- einzelner Held wird selektiert -->
</for>
<!-- jetzt ist noch der zuletzt selektierte Held selektiert -->


Ist halt ein bisschen unintuitiv. Aber generalistisch.

Ich wäre auch für eine <foreach-hero>...</foreach-hero> Lösung zu haben, wo im Rumpf ein implizites Select stattfindet und nach der Schleife der vorherige Select wiederhergestellt wird.

Code: Alles auswählen

<foreach-hero>
  <!-- hier genau ein Held selektiert -->
</foreach-hero>
<!-- hier wird automatisch vorheriger Select wiederhergestellt -->

<foreach-hero only="selected">
  <!-- hier ein Held selektiert, der zuvor auch schon selektiert war -->
</foreach-hero>

<foreach-hero only="non-selected">
  <!-- hier ein Held selektiert, der zuvor nicht selektiert war -->
</foreach>

<foreach-hero role="Kämpfer">
  <!-- hier ein Kämpfer-Held selektiert -->
</foreach>


Gaddezwerch hat geschrieben:Beim Tauchen-Beispiel: Wieso nicht Tauchen-Probe für alle ablegen, und diejenigen, die die Probe verhauen werden mittels <failure select-heroes="true"> selektieren?

Wie gesagt: Man kann sich das Leben bei solchen Sachen beliebig einfach oder schwer machen, je nachdem, wie detailverliebt man ist.

Beim Tauchen zum Beispiel hat man so die Möglichkeit, für jeden einzelnen Helden einen eigenen Text auszugeben, in dem dann der Schaden berechnet wird, der Name ausgegeben werden kann usw.

Beispiel: Vierergruppe taucht einzeln, zwei schaffen es nicht. Dann ist es ja schön, wenn man im folgenden dann schreiben kann "Held A hat Probleme beim Tauchen und muss viel Wasser schlucken". "Held B schafft es ohne Probleme". "Held C muss... " Und so weiter eben.

Wenn man nur "select heroes="true" bemüht, weiß man in der Folgeszene nicht, welche Helden und vor allem wieviele die Probe vergeigt haben, man kann den folgenden Text also nur sehr schwer passend an das Probenergebnis anpassen. Oder man muss halt komplett darauf verzichten. Dann würde im Folgetext ggf. einfach nur die Anzeige von abgezogener LE stehen, ohne Namen, etc. Ist doch viel atmosphärischer, wenn die Ergebnisse etwas näher durchleuchtet werden können und sich auch im Text wieder finden. Das ist bei einer Soloquest kein Problem, weil man nur einen Helden hat, aber in der Gruppe wird es gleich viel komplizierter.

Es gibt auch noch andere Kriterien. Wenn die Gruppe zum Beispiel über eine Grube springen will, kann man die Proben z.B. für Zwerge und Halblinge stärker erschweren, weil die es mit ihren kurzen Beinchen etwas schwerer haben. Für solche Sachen braucht man dann einfach solche Schleifen, in denen jeder Held einzeln abgefragt wird. Es wird ja glaube ich von den Spielern immer gerne gesehen, wenn Rasse, Kultur etc. sich auch bemerkbar machen, sei es zum Guten oder zum Schlechten. Retain macht da ja im Prinzip alles möglich. Es ist nur eben manchmal ein bisschen umständlich.

Ok, leuchtet ein, das individuell zu gestalten.

Gibt es abgesehen vom "Durchgehen der Helden der Gruppe" noch andere Anwendungsfälle wo man "Schleifen" gebrauchen kann?

Gaddezwerch hat geschrieben:Was das Abfragen von den 5 Seilen oder der Geldmenge angeht, ist wohl eher etwas, das man direkt bei has nachrüsten sollte ... komisch, dass das erst jetzt auffällt. Mit <has item="Seil" min="5"> fragt man derzeit ab, ob EIN Held 5 Seile dabei hat. Ich könnte mir da soetwas vorstellen:

Code: Alles auswählen

<has item="Seil" group-min="5">

Eher müssten die selektieren Helden abgefragt werden, oder? Sonst fangen wir noch an und erweitern nach und nach jedes "zweite" Attribubut um eine group-Variante.

Gaddezwerch hat geschrieben:

Code: Alles auswählen

<for all="sys:heroes">... </for>

erscheint mir da ganz logisch, wobei man hier vermutlich immer EIN Held im Rumpf der Schleife selektiert haben möchte und dieser implizite Select geht schon etwas über eine reines "for" hinaus.

Code: Alles auswählen

<for all="sys:heroes" name="heldid">
  <select hero="${heldid}"/><!-- einzelner Held wird selektiert -->
</for>
<!-- jetzt ist noch der zuletzt selektierte Held selektiert -->


Ist halt ein bisschen unintuitiv. Aber generalistisch.

Mir gefiele das so.

Gaddezwerch hat geschrieben:Ich wäre auch für eine <foreach-hero>...</foreach-hero> Lösung zu haben, wo im Rumpf ein implizites Select stattfindet und nach der Schleife der vorherige Select wiederhergestellt wird.
[code]
<foreach-hero>
<!-- hier genau ein Held selektiert -->
</foreach-hero>

Das dahingegen ist mir zu sehr Sonderlösung.

Grüße
... Lowlander

Gut.

Code: Alles auswählen

<for all="sys:heroes" name="heldid">
  <select hero="${heldid}"/><!-- einzelner Held wird selektiert -->
</for>
<!-- jetzt ist noch der zuletzt selektierte Held selektiert -->


ist für mich völlig in Ordnung.

Dann könnte man ja zusätzlich noch sys:selected-heroes und sys:unselected-heroes zur Verfügung stellen.


Als Separatoren für Array-Elemente könnte man das | akzeptieren, wie oben bei den Fertigkeiten beschrieben.

Gaddezwerch hat geschrieben:Dann könnte man ja zusätzlich noch sys:selected-heroes und sys:unselected-heroes zur Verfügung stellen.

Als Separatoren für Array-Elemente könnte man das | akzeptieren, wie oben bei den Fertigkeiten beschrieben.

Zu ersterem: Ja.

Du meinst das mit all="Athletik|Körperbeherrschung|Geländelauf"? Zu letzterem, dann müsste es aber all="${sys:heroes}" heißen, also mit dem ${...}.

Grüße
... Lowlander

Jo, ist jetzt implementiert und nutzbar.

Code: Alles auswählen

<for all="${sys:heroes}" name="heldid">
  <select hero="${heldid}"/>
  <p>HeldID: <fetch name="heldid"/>, Name: <get attribute="name"/></p>
</for>


Code: Alles auswählen

<for all="Singen|Schleichen|Schwimmen" name="talent">
  <challenge talent="${talent}">
  </challenge>
</for>


Auch im Wiki dokumentiert: For


@Pergor: Gib mir mal bitte Rückmeldung, ob das den Umgang erleichtert und was noch fehlt.

Übrigens ist mir aufgefallen, dass du mit der Gruppe auch die Funktion <function name="ermittle-item-anzahl" param1="%seil"/> benutzen kannst, wenn du wissen willst, wie viele Seile die Gruppe dabei hat.

Gaddezwerch hat geschrieben:@Pergor: Gib mir mal bitte Rückmeldung, ob das den Umgang erleichtert und was noch fehlt.

Ich? Besonders viel kann ich im Moment glaube ich nicht beisteuern, so gerne ich auch würde.

Wenn die Helden einzeln geprobt werden sollen, ist das natürlich viel einfacher, klar. Hab damit auf dem Testserver mal ein bisschen rumprobiert, mir gefällt das gut. Ansonsten weiß ich nicht, ob der "for"-Tag noch für andere von mir angesprochene Punkte benutzt werden kann. Außer vielleicht noch beim Gesamtvermögen einer Gruppe, das kann ich damit natürlich auch abfragen. Aber das wolltest du ja glaube ich eh irgendwie noch bei "has" nachrüsten. Und auf die von mir angesprochenen Probleme bei der Selektierung ist dieser Tag ja glaube ich nicht ausgerichtet. Oder ich unterschätze den Tag jetzt, das kann natürlich sein, wie gesagt bin ich in Sachen Programmierung ein Vollpfosten.

Zu der Sache mit <for all="Singen|Schleichen|Schwimmen" name="talent"> kann ich so nicht viel sagen. Soweit ich das sehe, muss man hier ja einen einzigen Failure-Pfad anlegen und der liefert dann immer das gleiche, egal welche der drei Proben man nun verhauen hat, oder? Und kann ich die Proben mit verschiedenen Erschwernissen versehen? Wenn, dann sehe ich nicht, wie. Vielleicht können dazu lieber die etwas sagen, die das haben wollten. Ich glaube, ich werde das eher nicht benutzen. Es funktioniert aber auch in Gruppen gut, wenn man das denn braucht, angeguckt habe ich mir das wohl.

Übrigens ist mir aufgefallen, dass du mit der Gruppe auch die Funktion <function name="ermittle-item-anzahl" param1="%seil"/> benutzen kannst, wenn du wissen willst, wie viele Seile die Gruppe dabei hat.

*nachguck*

Stimmt... dass das auch gruppentauglich ist, wusste ich nicht. Aber steht ja wohl dabei.

Okay, während des Editierens ist wohl die Editzeit abgelaufen (die ist in diesem Forum schon arg niedrig). Also Doppelpost.

Vielleicht lässt sich das mit dem sys:heroes, sys:selected-heroes, sys:unselected-heroes ja irgendwie auch anderweitig verwenden, vielleicht kann man so ja eine Umgebung erzeugen, in der diese Angabe alles andere "overruled". Beispiel: Ich selektiere einen Helden und öffne dann mit einem passenden Tag eine Umgebung, in der mit der Angabe sys:unselected-heroes alles, was in dieser Umgebung passiert, nur die bis dato nichtselektierten Helden betrifft, also z.B. auch sowas wie

Code: Alles auswählen

<store name="besterHeldID"><hero select="best" by-quality="ST" output="id" /></store>
      <select hero="${besterHeldID}"/>

Das würde - denke ich - viele Möglichkeiten bieten. Dann kann ich erstmal nach einem bestimmten Kriterium einen Helden selektieren und dann selektiere ich unter den verbleibenden nach weiteren Kriterien. Anwendungsmöglichkeiten hätte das viele.

Beispiele: Mutigster Held, der nicht Gruppenführer ist, Bester Held in Talent B, der nicht bester Held in Talent A ist, Held mit zweithöchstem IQ und so weiter und so fort, die Liste wäre endlos.

Auch der von mir angesprochene Härtefall. Ich verpasse dem Helden, der den Hebel hält, eine Variable und kann ihn jedes mal selektieren, ehe ich mich dann in diese Umgebung stürze, in der ich dann unter den verbliebenen Helden selektiere.

Auch hier gilt wieder: Alles mit retain lösbar. Vereinfachungen aber gerne gesehen. Denn die Interaktion der Helden miteinander ist bei Gruppen ein ganz zentrales Ding. Da hilft es natürlich, dem Autor das Leben zu erleichtern. Man hat das halt immer wieder, das ein Held was bestimmtes macht und dann ein anderer Held reagiert. Auch im Dialog, ein Held in einer Gruppe soll ja nicht mit sich selber sprechen.