Fiese Falle mit <countdown ...>

[Lowlander]

Ich hatte (auf dem Rückweg von Der Räuberhöhle nach Burg Birca) eine Verzögerung eingebaut:

Code:

      <store name="rueckweg-orientieren" expire="4h">true</store>
      <countdown name="rueckweg-orientieren" class="">
         <!... Zufallsimpression anzeigen und evtl. EP vergeben ... --> 
         Und nun <choice target="rueckweg">weiter</choice>
                      oder <choice target="westliche-schneise">doch zur Höhle</choice>?
    </countdown>


Das funktioniert auch. Dann aber habe ich vermutlich beim finalen Code-Review, dass ich immer auf meine Änderungen mache, gesehen, dass die Variable `rueckweg-orientieren? ja nur in der Szene verwendet wird, also

Code:

scope="scene"

hinzugefügt. Gut gemeint, es war jedoch fatal.

Zwischen scene-Scope und allen anderen gibt es jedoch einen wesentlichen Unterschied: die Variable landet gar nicht erst in der Datenbank! Bei allen anderen Scopes schon. Da ist auch gerade der Vorteil, weil man sich seinen Variablen-Space nicht zumüllt und z.B.

Code:

<var-dump/>

beim Debuggen übersichtlicher wird.

Dummerweise liest aber die Countdown-Anzeige die in name=... angegebene Variable wohl aus der Datenbank, so dass die dann null ist und der Countdown nur noch dauerhaft steht und der Block dazwischen gar nicht mehr angezeigt wird.

Zudem war bei mir die Variable ja bereits einmal in der Datenbank und abgelaufen, so dass der INhalt immer angezeigt wurde, wenn auch ohne Zähler. Aber da der lokal in meiner Config eh schneller läuft, war mir das gar nicht aufgefallen.

Zack, der Held, der in so eine Situation reinlief, ist gefangen, weil er die weiter-Links nicht klicken kann.

MIt DB-Zugriff leicht reparierbar, evtl. sogar wenn man dem Spielder per Screensharing, Audio- und Textchat (für Copy+Paste) helfen könnte, aber sonst hilft wohl nur befreien lassen.

[Lowlander]

Ach ja, fix ist auf dem master committet und Tommek zur Übernahme ins Spiel informiert.

[Lowlander]

Manchmal wünschte ich mir Möglichkeit, durch einen angehängten Code das "aus dem Cache geladen" zu umgehen, ggf. inkl. Weiterleitung auf eine neue Szene. Damit könnte man manchen Helden ohne Serverzugang befreien, und sogar ohne diesen ganz aus der Quest zu werfen.

[Tommek]

Du meinst einen URL-Parameter mit dem man ein neuladen forcieren könnte? Öffnet natürlich auch Missbrauchspotential.

[Lowlander]

Du meinst einen URL-Parameter mit dem man ein neuladen forcieren könnte? Öffnet natürlich auch Missbrauchspotential.

Im Prinzip ja, aber natürlich verschlüsselt. Z.B. im Code hinterlegte public-Keys derjenigen, die das nutzen wollen+dürfen und der verschlüsselten Szenen-URL. Vielleicht geht's auch noch einfacher ohne Missbrauch zu leicht zu machen.

Zudem am besten gleich mit neuem Szenen-Namen, weil Replay manchmal auch zu doppelter Beute etc. führt.

Ich weiß aber auch gar nicht, wie oft das eine Lösung wäre, Helden zu befreien, ohne ihn gleich aus der ganzen Quest zu schmeißen. Mir geht's vor allem um Reaktionsgeschwindigkeit und dass es nicht immer an dir, Tommek, hängenbleibt.

[Tommek]

Ja an die Belohnungen, EP Vergabe etc dachte ich auch. Wobei wir ja wissen wem wir geholfen haben in der Queste.

Wir könnten evtl einbauen, dass wenn das gespeicherte XHTML in der DB leer ist, die Szene neu ausgewertet wird.
Wenn ich dann den Fix auf den Server spiele, muss ich nur alle fehlerhaften Szenen in der DB leeren und alle Spieler könnten weiter machen.

[Lowlander]

Ja an die Belohnungen, EP Vergabe etc dachte ich auch. Wobei wir ja wissen wem wir geholfen haben in der Queste.

Wir könnten evtl einbauen, dass wenn das gespeicherte XHTML in der DB leer ist, die Szene neu ausgewertet wird.
Wenn ich dann den Fix auf den Server spiele, muss ich nur alle fehlerhaften Szenen in der DB leeren und alle Spieler könnten weiter machen.

Das hilft aber auch nur wenn du online bist und Zeit dafür hast. Zudem könnte es in includes sein. Ok, spätestens bei retain/replay haben wir bei solchen Fixes eh verloren.

Ansonsten wäre es aber schon ein Fortschritt.