Hm, es funktioniert. Mindestens ist es richtig durchgelaufen. Ich schreibe es unter CodeSnippets rein, bevor ich es vergesse.

Das nächste Problem. Wie bekomme ich heraus, welcher Item, den der Held bei sich hat, weniger als 100 Wert ist? Kann man den irgendwie automatisch mit "drop" wegnehmen? Oder wie muss man tricksen?

Kann man bei "random" ein "count" mitgeben, der größer ist als die Anzahl der "case" Zweige? Werden dann zufälligerweise die Zweige mehrmals durchlaufen?
Beispiel:

Code: Alles auswählen

<random count="4">
            <case>
              <store name="zufallsding"><item freq="oft" must="werkzeug|handwerk|spielbar|tragbar" cost_max="100" /></store>
              <take item="${zufallsding}"/>               
            </case>
            <case>
              <store name="zufallsding2"><item freq="oft" must="werkzeug|handwerk|spielbar|tragbar" cost_max="100" /></store>
              <take item="${zufallsding2}"/>               
            </case>
          </random>


Bekommt der Held dann 4 Gegenstände?

telor hat geschrieben:Wie bekomme ich heraus, welcher Item, den der Held bei sich hat, weniger als 100 Wert ist? Kann man den irgendwie automatisch mit "drop" wegnehmen?

Hmm, sollte notfalls über eine direkte SQL-Abfrage im Code machbar sein, auch wenn ich das bei AOQML nicht so schön finde. Dann irgendwie sowas:

Code: Alles auswählen

<drop item="${ware_id FROM ant_ware WHERE preis -lt 100}"/>


oder so ähnlich. Habe es nicht ausprobiert.

telor hat geschrieben:Kann man bei "random" ein "count" mitgeben, der größer ist als die Anzahl der "case" Zweige? Werden dann zufälligerweise die Zweige mehrmals durchlaufen?

Für sowas bietet sich retain + replay an. Einmal in retain definiert, kann der Code via replay beliebig oft abgespielt werden.

Gaddezwerch hat geschrieben:Für sowas bietet sich retain + replay an. Einmal in retain definiert, kann der Code via replay beliebig oft abgespielt werden.

Das habe ich mir auch schon angeschaut, aber mehrmals hintereinander den gleichen Befehlt zu schreiben kam mir ein bisschen "unschön" vor. Oder kann man "replay" mit "count" benutzen?

Bei AOQML mit sql zu arbeiten? Auch eine Möglichkeit, aber richtig schön finde ich es nicht. Wäre es nicht besser, wenn bei drop die item Attribute auch abgefragt werden könnten? Schließlich hat item bereits "cost_min" und "cost_max" in seiner Syntax.

Weiß jemand warum ich mit folgenden code auf der Testumgebung keinen Eintrag ins Questtagebuch bekomme. Oder klappt das nur nicht auf der Testumgebung, weil die gleiche Queste sofort wieder startet?

Code: Alles auswählen

<store name="note" scope="quest">In <get attribute="site"/> hat ein Haus gebrannt. Ich hab das Löschen den dortigen Bürgern überlassen.</store>
<quest status="ended" frequency="selten" note="${note}"/>

jo in der Testumgebung klappt das nicht, weil die Quest gleich wieder startet

telor hat geschrieben:Bei AOQML mit sql zu arbeiten? Auch eine Möglichkeit, aber richtig schön finde ich es nicht. Wäre es nicht besser, wenn bei drop die item Attribute auch abgefragt werden könnten? Schließlich hat item bereits "cost_min" und "cost_max" in seiner Syntax.

Ja, das SQL ist auch nicht schön, aber sonst müsste man im Endeffekt SQL nachbauen, was auch nicht schöner wäre. Jedenfalls habe ich keine wirklich bessere Idee. Man könnte es ab er vielleicht noch besser integrieren, so dass man in der Regel nicht direkt SQL benutzt, sondern meistens auf so etwas wie einen Satz Makros zurückgreift.

Guten Rutsch!
... Lowlander

Kann man bei victory das takeproedweapons="true" bedenkenlos in GruppenZBs benutzen, weil die Waffen automatisch nur einmal an den Anfüher gehen, oder sollte man das deaktivieren, damit nicht das gleiche Säbel vier mal verteilt wird?

Theoretisch sollten die Waffen nur an den Anführer wandern.

Danke gut zu wissen, dass ich mir die Hosen nicht mit der Kneifzange anziehen muss.

Mein Problem ist, dass ich verhindern will, dass sich bei einer Gruppenkampagne die Gruppe zwischen den einzelnen Teilquests auflöst, die Mitglieder sich jeweils neue Gefährten holen und dann die Kampagne mit einer eigentlich anderen Gruppe weitermacht.

Fällt jemanden auf die schnelle ein, wie man die ID's der Gruppe speichern und dann wieder auslesen kann? (Eine Gruppen-ID, die beim Erstellen einer Gruppe automatisch zugewiesen wird und beim auflösen der Gruppe wieder gelöscht wird, wär ein nettes Feature. )
Falls nicht, dann nehm ich einfach die Idee, die Gaddezwerch hatte.

Gaddezwerch hat geschrieben:Du könntest aber bspw. via <has name="..." hero-quantity="all"> abfragen, ob alle eine bestimmte hero-Variable haben.

Auch wenn man sich da rein theoretisch trotzdem ne andere Gruppe suchen könnte, indem man sich Leute holt, die die gleiche Quest schonmal hatten.
Aber darüber kann ich auch hinweg sehen.

Das Merken der GruppenID würde nicht verhindern, dass 3 Leute in der Gruppe ausgetauscht werden könnten.

Dann musst du die Namen oder besser IDs der Helden in Variablen speichern. Etwas aufwändig aber machbar.

neonix hat geschrieben:Dann musst du die Namen oder besser IDs der Helden in Variablen speichern. Etwas aufwändig aber machbar.

Ja, aber wie stelle ich sicher, dass die dann in der nächsten Quest auch wieder richtig ausgelesen werden?

Beispiel:
In Variable A speicher ich die ID von Held 1, Variable B speichert 2 und Variable C 3.
Jetzt komm ich in die neue Quest rein aber wie frage ich da ab?

Steh grad aufm Schlauch. Egal, ich mach das einfach mit Gaddezwerchs Methode.

Und weil ich grad aufm Schlauch stehe, erlaube ich mir folgende (hoffentlich nicht allzu blöde) Frage: Muss man Gruppenquesten eigentlich besonders einleiten?