Anstatt dem frequency-Tag könnten wir in <quest> ein neues Attribut einführen, dass angibt, ab wann die Quest erst wieder gestartet werden darf, also z.B.:

Code: Alles auswählen

<quest status="ended" withhold="20d" />


würde bedeuten, dass die Quest frühestens wieder nach 20 Ingametagen gestartet werden darf. Da kein frequency angegeben, hätte sie auch wieder die ursprüngliche Auftreten-Wahrscheinlichkeit.

Code: Alles auswählen

<quest status="ended" withhold="20D" />


würde bedeuten, dass die Quest erst wieder nach 20 RL-Tagen starten darf.

Code: Alles auswählen

<quest status="ended" withhold="12H" frequency="rar" />


würde bedeuten, dass die Quest erst wieder nach 12 RL-Stunden starten darf, aber mit geringerer WS als zuvor.

Klingt gut, oder?

Komfortabeler lässt sich aber auch mit einer variabele und expire machen. Gleiches Ergebnis mehr code.

Ich finde die Idee gut.

Askaian hat geschrieben:Komfortabeler lässt sich aber auch mit einer variabele und expire machen. Gleiches Ergebnis mehr code.

Mit dem kleinen, feinen Unterschied, dass die Quest erst gestartet wird um dann doch zu rejecten. In dem Fall könnte die Quest andere Questen verdrängen.

Askaian hat geschrieben:Komfortabeler lässt sich aber auch mit einer variabele und expire machen. Gleiches Ergebnis mehr code.

Nicht ganz. Die dann "rejected" Quest würde evtl. andere Questen verdrängen. Im schlimmsten falle rückte irgendwann gar keine Quest mehr nach.

edit: Der Zwerg hatte schnellere Finger.

Bei "rejected" wird doch nichts verdrängt, sondern es wird die nächste Queste genommen: viewtopic.php?p=247568#p247568

Ja, aber es werden maximal 5 Questen geholt. Wenn alle 5 rejecten, dann wurde durchaus verdrängt.
Abgesehen davon ist es auch eine Performance-Sache, denn für jede Quest muss die AOQML-Engine einen Context initialisieren, da entstehen viele Anfragen an den Server.


edit: withhold ist jetzt eingebaut. Erläuterung im Wiki: quest_(Tag)#withhold

Gaddezwerch hat geschrieben:Ja, aber es werden maximal 5 Questen geholt. Wenn alle 5 rejecten, dann wurde durchaus verdrängt.

10 waren es als ich das letzte mal reinsah.

Gaddezwerch hat geschrieben:Abgesehen davon ist es auch eine Performance-Sache, denn für jede Quest muss die AOQML-Engine einen Context initialisieren, da entstehen viele Anfragen an den Server.

Stimmt, das ist teuer. Das mit dem Withhold ist da schonmal ein guter Ansatz. Ein weitere Ansatz wäre, dass Quest-Variable erst bei <quest status="running"> wiedergeladen werden. Aber ich befüchte, dass die meisten Quests schon für die Abfrage, ob sie weiterlaufen sollen oder nicht, eben Quest-Variable bruchen - dann wäre das nutzlos.