Bekannte Dinge die den Wherigo Ablauf negativ beeinflussen ?

[austriaka]

In dem oben verlinkten Thread wird (weiter unten) genau diese Problematik angesprochen:

I have a problem when showing several dialog boxes and a message box (or only a message box). If the player doesn't confirm the windows by clicking on "ok" and the next dialog and/or message boxes appear, the cartridge crashes.

This happens in the Emulator as well as with the Oregon.

matejcik hat das ganz oben im Thread angeführte Author script dahingehend angepasst:
http://forums.groundspeak.com/GC/index.php?showtopic=214105&view=findpost&p=4146087

First tests in the emulator worked very well - many many thanks to matejcik!!!
This helps a lot and it will make the cartridge much more stable.

The behaviour is like that:
when there is a message or dialog box displayed and not yet confirmed (ok-button) and a new dialog or message box appears (for example "When the player enters a zone"), then the new one will be shown and the fist ones are canceled.

Ist das nicht schon die Lösung?
Oder ist das da genannte Author Script im Urwigo sowieso implementiert? (Habs jetzt nicht ausprobiert)

 

[bodenseepingu]

Also so stimmt das m.E. nicht. MessageBox und MessageBox gibt keinen Crash, sondern nur ein Cancel der vorherigen MessageBox. Ansonsten würden sehr viele meiner WIG's nicht funktionieren. Dasselbe dürfte eigentlich auch für Dialoge / Messagebox gelten.

Beim Geo-Memory z.B. gibt es per 1 Sekunden Timer eine Überprüfung, ob der User auf eine andere Karte gelaufen ist und wenn das der Fall ist ein Display der neuen Karte.

Hier geht es um einen Input-Dialog - der crasht reproduzierbar wenn eine Messagebox kommt und der Input nicht abgeschlossen ist.

Hier gibt's auch keine Lösung - da geht es ja genau darum ob der Urwigo-Programmierer hier einen Workaround einbauen will und kann.

Die angsprochene Pufferung kann man im Zusammenspiel zwischen Dialogen und Messagebox einstellen - für manche Dinge ganz gut geeignet - genau das ist im Urwigo implementiert worden, wenn man bei Dialog "gepuffert" auswählt.


Das genannte Author-Script ist in Urwigo implementiert !

 

[austriaka]

Also sollte man bei einem Input besser mit dem oben vorgeschlagenen Flag arbeiten, bevor eine Message box kommt?
Ich habe diese Situation im Spielablauf nämlich sehr oft, dass eine Input Box kommt, und wenn der Spieler das verpennt und noch minutenlang quer durch alle Zonen läuft, würde genau dieser Crash passieren. Der Urwigo-Emulator crasht hier aber nicht, vielleicht ist das saubere Schließen des Inputs ja doch schon vorgesehen?

EDIT:
Hab mir die Function nochmal angesehen, da werden auch die Inputs angepasst. Und du sagst, die Funktion wird von Urwigo automatisch implementiert? Ich hab sie im .lua File nicht in dieser Form gefunden, da ist nur das mit den gepufferten Messages/Dialogs drin.

 

[bodenseepingu]

....dann hab ich das verwechselt - das Script mit dem gepufferten dialog ist drin - das andere Script hab ich mir jetzt nicht so genau angeschaut - hab vielleicht die Antwort zu schnell geschrieben..

Wäre interessant, wenn jemand mit dem Author-Script experimentieren würde, ob man dann tatsächlich irgendwie einen Crash wie oben beschrieben (Benutzer bedient einen Input nicht sofort und dann kommt eine Meldung) verhindern kann.

Ich hab keine Ahnung, was das Author-Script dagegen tut oder tun kann - das Problem ist ja, daß zuerst der Input-Dialog kommt und dann eine Meldung - nicht anders herum - anders herum ist zumindest mit gepufferten Dialogen kein Problem.

 

[jonny65]

Also sollte man bei einem Input besser mit dem oben vorgeschlagenen Flag arbeiten, bevor eine Message box kommt?
Ich habe diese Situation im Spielablauf nämlich sehr oft, dass eine Input Box kommt, und wenn der Spieler das verpennt und noch minutenlang quer durch alle Zonen läuft, würde genau dieser Crash passieren. Der Urwigo-Emulator crasht hier aber nicht, vielleicht ist das saubere Schließen des Inputs ja doch schon vorgesehen?

Bei Eintreten in die Zone kommt bei mir immer irgendwas, so wie "Du hast die Zone erreicht ... blablabla" oder eine Multimessage "Hallo Fremder, wie ich sehe hast du den Zauberstab gefunden ..." Bei Verlassen nur, wenn was (wichtiges) vergessen wurde "Du hast die Flasche liegen lassen, geh nochmal zurück...". Jetzt könnte man die Enter Message nur 1 mal aufrufen, dann gäbs keine Probleme. Die Exit Message kann aber sehr wohl stören. Ich bin in der Zone, soll eine Bombe entschärfen mit einem Zahlencode (Input) und meine Koords springen oder ich geh bissl hin und her und verlass dann die Zone. DANN schlägt die Exit Message zu. Siehe mein Beispiel (hast das probiert im Emulator ? Das crasht doch).
Also, wenn du keine Enter/Exit Messages hast, passiert nix. Wenn du doch welche hast, würde ich das mal auf diese Verhalten abchecken. Ich bin da sehr anspruchsvoll an mich selber und kann sowas nicht haben, auch wenn meine beiden WIGs so 95-98% fehlerfreie Durchspielquote haben. Das reicht mir nicht. Und genau dafür sind solche "Workarounds".

Sind Zonen biss großzügiger (nicht so ein 5x5 Meter Käse) definiert und beherzigt der Spieler bei Betreten der Zone noch paar Meter weiter zu gehen, ist das "Zonenflattern", d.h. Enter/Exit/Enter/Exit... schon nahezu ausgeschaltet und nix passiert, aber wenn dann crasht es eben. Z.b will der Player grad was eingeben, da kommt plötzlich ein riesen Dobermann auf ihn zu, er rennt aus der Zone und der WIG stürzt ab. Wär doch ärgerlich

 

[austriaka]

So, habe nun ein paar Testläufe mit Emulator und Oregon gemacht.
1 Zone definiert, die beim Betreten eine Message und bei deren Bestätigen einen Input gibt. Beim Exit kommt wieder eine Message.

Szenario 1:
Im Input ist kein "on get input" definiert.
Kein Crash in Emulator und Oregon.

Szenario 2:
"on get input" definiert mit
[dödelcode]
if input is not empty then show message "danke"
else show message "nicht gut"
[/dödelcode]
Crash in Emulator und Oregon, spätestens nach dem zweiten Betreten der Zone

Szenario 3:
User Function aus diesem Thread kopiert
"on get input" definiert mit
[dödelcode]
if input is not empty then show message "danke"
else show message "nicht gut"
[/dödelcode]
Crash in Emulator und Oregon, spätestens nach dem zweiten Betreten der Zone

Szenario 4 (Lösung?)
Ohne o.a. user function
"on get input" definiert mit
[dödelcode]
if input is not empty then show message "danke"
else go to Main Screen
[/dödelcode]
KEIN Crash in Emulator und Oregon

Das heißt, beim Aufruf einer neuen Message Box wird der Input abgebrochen bzw. als Leerstring verarbeitet. Ist für diesen "Leer-"Fall eine Message hinterlegt, kollidiert diese mit der neuen Message und es kommt zum Stack Overflow.
Hinterlege ich für den Leer-Fall ein sauberes Schließen des Inputs durch Rückkehr zum Main Screen, ist alles in Ordnung.
Ich habe mal irgendwo gelesen, dass das auch für den Cancel-Button dringend empfohlen wird, vielleicht aus den gleichen Gründen.
Als Attachement noch die letzte (funktionierende) Variante als gezipptes Urwigo-File. Einfach die Zone und den Startpunkt anpassen, falls ihr es nicht in meinem Garten spielen wollt
Anhang anzeigen zonentest.zip

 

[bodenseepingu]

Interessant.

Zumindest der Emulator crasht nicht, wenn er einen leeren Else-Zweig beim Input bekommt - der Show-Mainscreen macht hier nichts aus - aber sobald im Else-Zweig eine Message-Box steht, gibt es einen Crash.

Was macht der Oregon? Crasht der oben genannte Code nicht ? Dann wär's das ja schon..

 

[austriaka]

ich habs nur im Garten getestet, aber soweit ich sagen kann, crasht der Oregon damit nicht

 

[jonny65]

Evtl. schon bekannt : http://www.earwigo.net/WWB/wiki/doku.php?id=tips_and_tricks
Das is so ne kleine Sammlung an "NoGos", wenn auch nicht erschöpfend.
Weiß jemand ob man da aktiv mitwirken kann nach dem Wikipedia Prinzip, da muss ja ein Kontrollorgan dahinterstecken.

 

[bodenseepingu]

Hab heute mal etwas getestet - bei Garmin gab es reproduzierbare Abstürze, Android lief ohne Probleme

- ich starte einen Timer im 1-Sekundentakt, in der Timer-Routine wird eine Messagebox aufgerufen (z.B. Darstellung durchlaufender Text)
- nach Ende der Sequenz wird der Timer gestoppt und ein 2. Timer gestartet, auch wieder im 1-Sekunden Takt, der macht genau dasselbe - eine Messagebox (z.b. Daumenkino)

Der Garmin OREGON crasht reproduzierbar genau nach Ende der ersten Timer-sequenz, vor Anzeige des ersten Bildes der 2. Sequenz.

Der erste Timer wurde von einem Item gestartet, der 2. Timer wurde vom ersten Timer gestartet.

Der Absturz liess sich beheben, indem nach der ersten Sequenz Show Mainscreen aufgerufen wurde.

 

[HowC]

was mir grade noch einfällt... ich hab Zonen die sind AKTIV aber unsichtbar....
Die sollen erst auftauchen, wenn der Spieler in der Nähe ist.

Android (Whereyougo) & Oregon macht das genau so wie es soll.
PiGo auf dem iPhone zeigt ALLE Zonen. (böses Feature :-( )

Programmiert in Urwigo, glaub nicht das das am editor liegen sollte. und ist ja nur ein problem für die Äpfel

 

[kansu_makugen]

was mir grade noch einfällt... ich hab Zonen die sind AKTIV aber unsichtbar....
Die sollen erst auftauchen, wenn der Spieler in der Nähe ist.

Android (Whereyougo) & Oregon macht das genau so wie es soll.
PiGo auf dem iPhone zeigt ALLE Zonen. (böses Feature :-( )

Programmiert in Urwigo, glaub nicht das das am editor liegen sollte. und ist ja nur ein problem für die Äpfel

Wenn das so ist, wäre das wirklich fatal! Ich bei meinem Wig auch an einer Stelle eine aktive aber unsichtbare Zone. Beim Testen auf dem iPhone ist mir das von dir geschilderte Problem aber nicht aufgefallen. Man achtet ja normalerweise nicht auf sowas, weil man eigentlich davon ausgeht, dass es der Player korrekt anzegit. Hab erhlich gesagt aber auch nicht drauf geachtet. Werde aber noch mal nachschauen. Wäre dann ja wieder ein Fall für den Pi-Soft Support.

 

[bodenseepingu]

Mir ist beim Testen meines neuen Wig's was aufgefallen.

- ich habe Zonen, die sind unsichtbar, aber aktiv - mittels Timer schalte ich die Zonen auf sichtbar nach einer bestimmten Zeit. Beim Oregon funktioniert das tadellos - beim Android bleiben die Zonen unsichtbar. Ich gehe davon aus, daß man hier beim Ändern von Visible auch zusätzlich die Zonen inaktiv und dann wieder aktiv schalten muss....

 

[bodenseepingu]

....aber Achtung, auch hier unterscheidet sich die Reaktion eines Garmin-Players von der eines Android-Players....bei Zone inaktiv und dann wieder aktiv schalten werden bei Android die entsprechenden Events (z.B. Proximity, Enter) ausgelöst, bei Garmin nicht
unbedingt...zumindest hab ich es geschafft, für Android eine Endlosschleife zu produzieren, indem ich bei nem Proximity-Event die Visibility geschaltet hab...bei Garmin gab's da keine Probleme...