Da es im Prinzip die Lotto Problematik (ziehen ohne rücklegen) ist, habe ich mal einen Beispielcode fürs Lotto geschrieben. Vielleicht hilft es dir weiter zu verstehen, warum ich mir retain arbeiten würde.

Code: Alles auswählen

<retain name="ziehung" id="1">
<set name="ziehung-nr" inc="1" show="none"/>
<store name="aktuelle-ziehung">ziehung<fetch name="ziehung-nr"/></store>   
<store name="${aktuelle-ziehung}">
   <random>
   <case>1</case>
   <case>2</case>
   <case>3</case>
   <case>4</case>
   <case>5</case>
   <case>6</case>
   <case>7</case>
   <case>8</case>
   <case>9</case>
   <case>10</case>
   <case>11</case>
   <case>12</case>
 </random>
</store>
</retain>

<!-- ziehung erste zahl -->
<set name="ziehung-nr" val="0" show="none"/>
<replay name="ziehung"/>

<!-- ziehung zweite zahl -->
<replay name="ziehung"/>
<switch name="ziehung2">
  <case val="ziehung1">
     <set name="ziehung-nr" dec="1" show="none"/>
     <replay name="ziehung"/>
  </case>
  <else>
  </else>
</switch>

<!-- ziehung dritte zahl -->
<replay name="ziehung"/>
<switch name="ziehung3">
  <case val="ziehung^1">
     <set name="ziehung-nr" dec="1" show="none"/>
     <replay name="ziehung"/>
  </case>

  <case val="ziehung2">
     <set name="ziehung-nr" dec="1" show="none"/>
     <replay name="ziehung"/>
  </case>

  <else>
  </else>
</switch>


Was genau ist eigentlich das Attribut "Traglimit"? Wenn die Tragkraft überschritten ist, landet man im gelben Bereich. Ist "Traglimit" überschritten, sobald man im roten Bereich landet?

Das Traglimit sollte eigentlich der Wert (in Korn) sein, bei dem der Held absolut keine Gegenstände mehr aufnehmen kann. Bisher hat es jedoch keine Relevanz. Das AOQML-Heldattribut werde ich mal entfernen.

Aha, dann ist es ja gut, dass ich gefragt habe, wir wollten das eigentlich schon benutzen.

Danke für die schnelle Antwort.

Code: Alles auswählen

<switch attribute="monat">
  <null>
    <p>Fehler, Attribut "monat" hat keinen Inhalt. (null)</p>
  </null>
 
  <case value="Lichtmond|Liebesmond|Ahnenmond">
     <!-- Fiomond: Vollmond -->
    <switch attribute="tag">
      <null>
         <p>Fehler, Attribut "tag" hat keinen Inhalt. (null)</p>
      </null>
      <case min="1" max="7">
         <!-- Mond: Neumond -->
      </case>
      <case min="8" max="15">
         <!-- Mond: Zunehmend -->
      </case>
      <case min="16" max="22">
         <!-- Mond: Vollmond -->
      </case>
      <case min="23" max="30">
         <!-- Mond: Abnehmend -->
      </case>
      <else>
         <p>Fehler, Attribut "tag" außerhalb der Definitionsmenge. (else)</p>
      </else>
    </switch>
  </case>
 
  <case value="Hoffnungsmond|Erdmond|Herdfeuermond">
    <!-- Fiomond: Neumond -->
    <switch attribute="tag">
      <null>
         <p>Fehler, Attribut "tag" hat keinen Inhalt. (null)</p>
      </null>
      <case min="1" max="7">
         <!-- Mond: Neumond -->
      </case>
      <case min="8" max="15">
         <!-- Mond: Zunehmend -->
      </case>
      <case min="16" max="22">
         <!-- Mond: Vollmond -->
      </case>
      <case min="23" max="30">
         <!-- Mond: Abnehmend -->
      </case>
      <else>
         <p>Fehler, Attribut "tag" außerhalb der Definitionsmenge. (else)</p>
      </else>
    </switch>
  </case>
 
  <case value="Maskenmond|Wassermond|Heilungsmond">
    <!-- Fiomond: Zunehmend -->
    <switch attribute="tag">
      <null>
         <p>Fehler, Attribut "tag" hat keinen Inhalt. (null)</p>
      </null>
      <case min="1" max="7">
         <!-- Mond: Neumond -->
      </case>
      <case min="8" max="15">
         <!-- Mond: Zunehmend -->
      </case>
      <case min="16" max="22">
         <!-- Mond: Vollmond -->
      </case>
      <case min="23" max="30">
         <!-- Mond: Abnehmend -->
      </case>
      <else>
         <p>Fehler, Attribut "tag" außerhalb der Definitionsmenge. (else)</p>
      </else>
    </switch>
  </case>
 
  <case value="Ehrenmond|Weisheitsmond|Feuermond">
    <!-- Fiomond: Abnehmend -->
    <switch attribute="tag">
      <null>
         <p>Fehler, Attribut "tag" hat keinen Inhalt. (null)</p>
      </null>
      <case min="1" max="7">
         <!-- Mond: Neumond -->
      </case>
      <case min="8" max="15">
         <!-- Mond: Zunehmend -->
      </case>
      <case min="16" max="22">
         <!-- Mond: Vollmond -->
      </case>
      <case min="23" max="30">
         <!-- Mond: Abnehmend -->
      </case>
      <else>
         <p>Fehler, Attribut "tag" außerhalb der Definitionsmenge. (else)</p>
      </else>
    </switch>
  </case>

  <else>
    <p>Fehler, Attribut "monat" außerhalb der Definitionsmenge. (else)</p>
  </else>
</switch>

Ich habe da mal ein kleines bisschen Code für Detailverliebte gebastelt. Damit ließe sich im Text eine Mondbeschreibung an die tatsächlichen Mondphasen anpassen, wie sie im Konzept bereits als fix gelten. Meine Frage dazu: Stimmt das alles so? (Wäre gut, wenn wer gegenprüft) Ansonsten: Viel Spaß damit, falls es jemand benutzen möchte. Leider kann man das innere Switch nicht auslagern - bzw. man kann schon, aber nicht in jedem Fall, dann würde man die Anzahl der Satzkonstruktionen, die man bilden könnte, doch massiv einschränken.

Was passiert eigentlich, wenn man so in einer Gruppenquest selektieren möchte

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

und niemand TalentA aktiviert hat? Muss man immer vorher erstmal abfragen, ob überhaupt jemand in der Gruppe das Talent aktiviert hat, bevor man auf diese Weise eine Heldenselektierung vornehmen kann?

Oder wird vielleicht jemand automatisch selektiert (Gruppenführer vielleicht?), wenn keiner das Talent aktiviert hat?

Man könnte das ja wohl in eine <has>-Abfrage packen und im success-Pfad dann obigen Tag reinpacken und im failure-Pfad einfach den Gruppenführer selektieren. Oder muss das nicht, weil's automatisch anders geregelt wird?

AFAIK ist der Gruppenführer immer der, den's erwischt, wenn's sonst auch keiner kann. Das muss man nicht abfangen.

Genau. Notfalls muss immer der Gruppenführer herhalten.

Zwei Fragen zu "restrict":

<restrict>
<set attribute="EP" inc="XXX" />
</restrict>

1) Wenn man das in Dungeons verwendet: Wirkt dieser "restrict" für die Dauer der Quest, oder so wie eine "hero"-Variable? Also wenn man das Dungeon verlässt und wieder betritt (die Quest also beendet und neu aufruft), wirkt der Tag dann immer noch? Denn wenn nicht, ist der Tag für solche Dungeons ja untauglich.

2) Ist er vollumfänglich gruppentauglich?

Und eine Frage zum "transfer"-Tag: Werden diese Behältniss bei "has"-Abfragen immer berücksichtigt werden? Und auch bei einem "drop"-Tag? Wäre wichtig in Bezug auf Questgegenstände.

Denn wenn jemand was in so ein Behältnis legt und es dann bei einer entsprechenden Abfrage nicht gefunden werden kann, wäre das ja unschön.

Pergor hat geschrieben:Zwei Fragen zu "restrict":

<restrict>
<set attribute="EP" inc="XXX" />
</restrict>

1) Wenn man das in Dungeons verwendet: Wirkt dieser "restrict" für die Dauer der Quest, oder so wie eine "hero"-Variable? Also wenn man das Dungeon verlässt und wieder betritt (die Quest also beendet und neu aufruft), wirkt der Tag dann immer noch? Denn wenn nicht, ist der Tag für solche Dungeons ja untauglich.

Dauerhaft. Restrict legt sozusagen eine hero-Variable an.

2) Ist er vollumfänglich gruppentauglich?

Gruppentauglich bisher eher nicht, bisher wird nur beim 'actingHero' (also selektierter Held bzw. Gruppenführer) nachgeschaut. Wir sollten uns nochmal darüber unterhalten, was das gewünschte Verhalten von restrict bei Gruppen ist. In etwa: Wenn ein Held den Code bereits ausgeführt hat, Code nicht ausführen?

Und eine Frage zum "transfer"-Tag: Werden diese Behältniss bei "has"-Abfragen immer berücksichtigt werden? Und auch bei einem "drop"-Tag? Wäre wichtig in Bezug auf Questgegenstände.

Ja, wird berücksichtigt. has durchsucht auch die Container und drop droppt aus Containern.

Danke!

Gaddezwerch hat geschrieben:Wir sollten uns nochmal darüber unterhalten, was das gewünschte Verhalten von restrict bei Gruppen ist. In etwa: Wenn ein Held den Code bereits ausgeführt hat, Code nicht ausführen?

Die EP werden ja nur an die selektierten Gruppenmitglieder vergeben. Und nur bei diesen dürfte "restrict" dann eigentlich zukünftig greifen, oder?

Denn es müssen ja nicht immer alle Helden für die EP selektiert sein. Zum Beispiel wenn man irgendwo eine Szene hat, in der man einen einzelnen Helden etwas ausprobieren lassen kann. So nach dem Motto "Held A soll da jetzt mal runtertauchen und nachsehen". Da kann/sollte es dann z.B. beim ersten Versuch für jeden Helden gleichermaßen EP geben, wenn jeder Held es mal ausprobiert. <restrict> würde das dann aber verhindern.

Wobei man in solche Fällen natürlich auch ohne <restrict> arbeiten und die EP-Vergabe über eine eigens gesetzte "hero"-Variable regeln kann.

Zudem: Kann man als Questautor eingeführte "hero"-Variablen nicht auch wieder löschen (bei Questende z.B.) ? Auf <restrict> hätte man ja eigentlich keinen Einfluss, oder?

Pergor hat geschrieben:Zudem: Kann man als Questautor eingeführte "hero"-Variablen nicht auch wieder löschen (bei Questende z.B.) ? Auf <restrict> hätte man ja eigentlich keinen Einfluss, oder?

Genau, restrict ist permanent, kann vom Autor nicht gelöscht werden, hero-Variablen hingegen schon durch <store name="var" scope="hero">NULL</store>.

Also gewünschtes Verhalten für Restrict bei Gruppen: Wenn mindestens ein selektierter Held den Code bereits ausgeführt hat, Code für alle selektierten Helden nicht ausführen? (Option 1)
(Ob selektiert oder nicht, hatte ich vorhin unterschlagen, aber es macht natürlich Sinn, bei der Ausführung von restrict nachzugucken, wer gerade selektiert ist.)

Alternativ: Der restrict-Code wird für all diejenigen selektierten Helden ausgeführt, für die er bisher noch nicht ausgeführt wurde. (Option 2)

Edit: Ich habe es jetzt als Option 1 eingebaut.

Fehlermeldung auf dem Testserver:

FEHLER: Szenen-Datei /var/www/Antamar_quest/includes/classes/aoqml/quests/764/../abbruch.xml ist leer oder kann nicht gelesen werden.

Wahlweise das gleiche bei lernen.xml. Allerdings konnte er das include sprachen.xml, das auf der gleichen Ebene liegt, problemlos laden, als mein Testchar selbige noch nicht beherrscht hat. Codierung ist UTF8 ohne BOM, also daran liegt's diesmal nicht.

Betroffenes Archiv:

Datei:Rezept-WasserDesAnglers.zip

Hab ich da irgendwo einen Fehler reingehackt, den ich jetzt einfach nicht finde? Und wenn ja: wo und was?

Der will einen Ordner zu tief gehen. Liegt eventuell an den doppelten quest status="running".

Alle anderen Möglichkeiten, das quest status="running" einzufügen, durchgespielt:
1. nur in der Weiterleitungs-start.xml.
2. nur in der eigentlichen start.xml im Ordner.
3. Gar keins.

Dann habe ich in der Weiterleitungs-start.xml ein quest status="continue" eingefügt, damit er auch wirklich in die andere Datei übergeht und damit die Ebene wechselt.

>> Alles nicht funktioniert. Ich glaube auch, dass es daran nicht liegen kann, denn:

Code: Alles auswählen

<include target="../sprachen"/>

in der start.xml im Ordner funktioniert!

Das Problem tritt nur mit den beiden choices auf:

Code: Alles auswählen

<choice target="../lernen">Rezept erlernen</choice>
<choice target="../abbruch">Abbruch</choice>

Aber grundsätzlich liegt es schon nahe, dass es irgendwie an der Weiterleitungsdatei liegt, die ist ja der einzige Unterschied zum Liveserver, wo die Konstruktion prima ihren Dienst verrichtet.