Boolean Variable Bug auf WIG-Player für iOS ?

[Charlenni]

Da würde ich mal auf einen Programmierfehler tippen. Abgespeichert wird der boolean Wert als numerischer Wert, was so ja auch normal ist. Aber anscheinend wird er nicht richtig wieder ans Tageslicht geholt.

Abspeichern ist beim iPhone-Player so eine Sache. Ich habe auch schon den Author vor einiger Zeit angeschrieben. Aus der Antwort habe ich herausgelesen, dass er gerne etwas ändern würde, aber das Abspeichern mehrerer verschiedener Varianten weiter oben steht.

Dennoch würde ich, wenn ich Du wäre, mal bei Shawn nachfragen.

 

[Red_Family]

Mag sein das ich da gestern Nacht nach 12 noch "nen Bock geschossen" habe
Aber ich habe für mich jetzt entschieden auf boolean zu verzichten und auf Zahlenwerte oder strings abzufragen.

Zu dem Argument von Jonny65:
Die Wahrscheinlichkeit ist nicht so hoch, da mehrere Faktoren zusammentreffen müssen :
1.) Wer speichert schon den WIG ab,beendet ihn und macht später neu weiter ?
Die meisten spielen doch durch.
2.) Wie wichtig ist die gespeicherte Boolean Variable später nochmal im WIG ?
Eventuell wird die Boolean Variable während dem Spiel nochmal gesetzt, so das das gespeicherte Ergebnis egal ist. Hängt vom Spielverlauf ab
3.) Er muß mit IPAD oder IPHONE unterwegs sind.
Da werden es wohl mit der Android Konkurrenz auch wieder weniger.

Daher denke ich das dies sehr wohl sporadisches seltsames Verhalten bei WIGs auf Iphones zur Ursache haben könnte.
Was mich aber wundert ist, daß ich ja in meinem größeren WIG Gebrauch mache von Boolean Variablen und ich nachvollziehbar abspeichern und resumen kann und die Variablen danach den richtigen Wert hatten.
Da dies aber offensichtlich nicht hundertprozentig ist, werde ich zukünftig auf Variablen vom TYP Boolean verzichten.

 

[HKM]

@Charlenni
Einen Programmierfehler kann ich natürlich nicht ausschliessen.
Aber meines Wissens habe ich als Programmierer keinen Einfluss auf das "wieder ans Tageslicht holen" der Variablen, oder gibt es einen Trick?
M.E. bin ich komplett davon abhängig, dass der WIG-Player das schon richtig hinbekommt.
Wenn es sich um einen Programmierfehler handeln sollte, ist auch nicht ganz klar, warum dieser Fehler nur bei iOS, aber nicht auf Garmin, WhereYouGo und im Emulator auftritt.
Wie ich oben schon erwähnte, kann sich jeder die Urwigo-Datei hier herunterladen: iPoneTestVar.urwigo
Da es sich nur um ein paar Befehle handelt, müsste ein Programmierfehler schnell zu entdecken sein.

Gerne würde ich mit Shawn Kontakt aufnehmen. Leider bin ich noch nicht so lange dabei und weiß nicht, wer er ist und wie ich in Kontakt komme. Kannst du mir helfen?

@Red_Family
Dass das Problem bei dir auf dem iPhone4 mal auftritt und mal nicht, dafür habe ich überhaupt keine Erklärung, aber immerhin zeigt es mir, dass ich mir das Ganze nicht komplett einbilde

Auf meinem "großen" Wherigo mit 22 Boolean Variablen tritt es auf jeden Fall reproduzierbar auf. Habe ich auch nur durch großen Zufall bemerkt. Wer testet schon das Save und Resume zu verschiedenen Zeitpunkten auf jedem Gerät?

Deine Argumente zur Wahrscheinlichkeit sind durchaus schlüssig, zumal Wherigos ohnehin den zweifelhaften Ruf genießen, nicht sehr stabil zu laufen.

 

[Charlenni]

@HKM: Ich meinte nicht, dass es an einem Programmierfehler von Dir liegt, sondern der iPhone-Player Probleme hat. Und Shawn hat ihn nunmal programmiert, wenn er auch nicht mehr so schalten und walten kann seit Groundspeak ihn gekauft hat. E-Mail kann ich Dir natürlich zukommen lassen.

Ansonsten wäre ein Workaround, die Variablen kurz in der OnResume-Funktion zu überprüfen. Also im Sinne von

if myBoolVar == 1 then myBoolVar = true end
if myBoolVar == 0 then myBoolVar = false end

Damit können sie in der Cartridge ganz normal verwendet werden. Geändert wird dann auch nur auf dem iPhone, ansonsten ist ja der richtige Bool-Wert eingetragen. Auf alle Fälle besser, als ganz auf Bool-Variablen zu verzichten.

 

[Red_Family]

Imho stellt der Verzicht auf boolean keine große Schwierigkeit dar, kann ich diese doch ganz simpel mit normalen Zahlenwerten emulieren.

 

[AoiSora]

Sind booleans nicht eigentlich Relikte aus alten Zeiten, wo man versuchte so resourcenschonend zu programmieren wie es ging, da die Rechner vor 20-30 Jahren weniger Rechenkapazität hatten als heutige Armbanduhren. Da war es von Vorteil, wenn eine Zahl nur 2 Werte haben kann im Gegensatz zu einer float oder double mit 10^xxx möglichen Werten.
Aber heutzutage sollten selbst beim schwachen Oregon kaum Unterschiede zwischen den einzelnen Typen feststellbar sein.

Aber mal eine Frage:
Ist

zone1.Active = true

nicht auch eine boolean? Wenn ja müsste das bei Apfelprodukten dann nicht auch falsch gespeichert werden?

 

[Red_Family]

Zum ersten Teil : Ja, so ist es. Der Platzbedarf des Wertes einer Boolean-Variable ist 1 Bit, der eines Zahlenwertes vom Typ integer schon 16.

Zur zweiten Teil:
Könnte sein,muß aber nicht.
Selbst wenn ja: Ob das zu einem Fehler führt oder nicht ist nicht eine generelle Frage nach dem Datentyp sondern eher wie die Save und Resume Funktionen damit umgehen.
Der Import von Zonen-Stati (<-ich hoffe das ist richtig, Latein ist so lange her ) wird bestimmt anders behandelt wie der von Variablen.

 

[Charlenni]

Da muss ich Dich leider enttäuschen. Boolean werden beim Abspeichern (wenigstens beim Emulator) gleich behandelt es sind alles Bool-Werte, die genau ein Byte belegen. Dabei bedeutet eine 0 False und eine 1 True. Und ob dieser Wert nun eine Eigenschaft oder nur eine normale Variable ist, spielt keine Rolle.

 

[Red_Family]

Das mag bei Wherigo so sein, aber ich hatte die Frage allgemein verstanden.
Vor 20 Jahren gab es noch keine Wherigo's und da wurden Boolean Variablen mit 1 Bit gespeichert.

 

[AoiSora]

So da hätten wir 2 unterschiedliche Meinungen. Jedoch vertraue ich da lieber auf Charlenni. Sorry Red_Family. Charlenni ist schon etwas länger hier im Forum durch kompetente Kommentare aufgefallen

Also wenn Charlenni Recht hat, müssten dann die Stati von Objekten nicht auch falsch/fehlerhaft gespeichert bzw. falsch/fehlerhaft wiederhergestellt werden?

@Apple-Besitze
probiert den Save-Resume-Test auch mal mit Visibles und Actives von verschiedenen Objekten durch.

Denn ich glaube auch, wie Red_Family, dass die wenigsten Spieler speichern und später weitermachen. Und wenns so ist und die dann nicht mehr weiterspielen können, schreiben von den schon wenigen nochmal nur ein kleiner Teil ein DNF wodurch der Owner von den Problemen erfahren würde.

 

[Charlenni]

Der ist gut, "kompetente Kommentare". Das müsste ich mal meinen Kindern erzählen

Ich weiß es einfach deshalb, weil ich mir für eine andere Sache das Dateiformat der GWS-Dateien vom Emulator entschlüsselt und angeschaut habe. Ist übrigens das Gleiche, wie bei den Garmins. Rein theoretisch sollte es sogar möglich sen, GWS-Dateien vom Garmin im Emulator zu laden. Wenn da nicht der eine oder andere Stolperstein wäre

Das Sicherungsformat des iPhone Players habe ich mir allerdings noch nicht angeschaut. Deshalb habe ich da keinerlei Erfahrung.

 

[Red_Family]

Wieso unterschiedliche Meinungen?
Meine Antwort bezog sich allgemein auf Boolean und integer.
Zur Speichergröße bei Wherigo's habe ich mich ja gar nicht geäußert!
Da fehlt mir das Background-Wissen.
Aber ich werde mir mal so ne Save-Datei anschauen.

Was ich aber weiß ist das bei meiner Cartridge die Boolean-Variablen sauber gespeichert und geladen werden !!

Warum das bei diesem Trivial Programm nicht funktioniert ist mir auch ein Rätsel.

 

[HKM]

Ich habe jetzt einmal die Sichtbatkeit meines Debug-Items (itemDebug.Visible) getestet.
Mittlerweile hoffe ich fast schon, dass es an meinem alten iPad liegt, denn das Ergebnis ist wie folgt:

Zunächst einmal meine Abfrage:

Ich habe sie diesmal direct in Lua geschrieben, weil mich die KlickiBunti-Urwigo-GUI daran hindert, dass ich eine Boolean-Variable mit einem numerischen Wert oder String vergleiche.

Das Ergebnis also beim ersten Durchlauf:
Test itemDebug.Visible ergibt:
itemDebug.Visible = True

Das Ergebnis nach Beenden und Resume der Cartridge:
Test itemDebug.Visible ergibt:
itemDebug.Visible = 1 (Num)

Wenn sich das auf anderen Geräten bestätigen sollte, liefert auch das Abfragen eines Boolean-Attributs eines Objektes kein zuverlässiges Ergebnis!

Der Vollständigkeit halber sei erwähnt, dass das getestete Item sowohl vor als auch nach dem Resume tatsächlich die ganze Zeit sichtbar war.

 

[AoiSora]

Naja so langsam nähern wir uns ja dem Übel (oder wohl auch nicht). Zumindest lernen wir Peu à Peu wie die Booleans im iPhone so ticken.

Jedenfalls sollte am Ende irgendjemand Shawn mit unseren Ergebnissen kontaktieren. Auch wenn er viel zu tun hat wird er sicherlich froh sein neue detaillierte Infos zu erhalten. Denn wie wir WIG-Programmierer wissen gibt es nichts schlimmeres als Fehlermeldungen ohne Fehlerbeschreibungen a la "Ey dein Wherigo ist bei mir einfach abgekackt, mach da mal was!"

 

[HKM]

So, ich habe auf einem iPhone4 (iOS 6.1.3), das mir seit gestern Abend zur Verfügung steht, alle Tests noch einmal intensiv durchgeführt.
Sämtliche Abfragen habe ich direkt als Lua Code durchgeführt, um sicher den Inhalt der Variablen ermitteln zu können.
Die aktuelle Version der Testcartridge kann hier heruntergeladen werden: iPhoneTestVar.urwigo
Leider tauchen die Probleme auch auf dem iPhone auf.

Hier eine Zusammenfassung:
Solange man die Cartridge nicht beendet und nicht über Resume weiterspielt, tauchen keinerlei Probleme auf.
Nach einem Resume werden folgende Werte nicht korrekt vom iOS WIG Player zurückgeladen (oder nicht korrekt gespeichert):

true - Nach einem Resume haben sowohl Variablen (myBooleanVar) als auch Attribute eines Objekts (itemDebug.Visible), die vorher true waren, den numerischen Wert 1!!!

0 - Nach einem Resume haben numerische Variablen, die vorher den Wert 0 hatten, den boolean Wert false !!!

Boolean Variablen mit dem Wert false und Numerische Variablen mit einem Wert ungleich 0 verändern sich nach dem Resume nicht (immerhin )!

Workaround:
Wenn man eine Boolean Variable wie folgt auf false testet gibt es keinerlei Probleme (weder vor noch nach Resume):

Warum funktioniert das?
In den linken Zweig der Abfrage gelangt man nur wenn nur, wenn die Variable = false ist. Der false Zustand wird wie gesagt korrekt beim Resume zurückgeladen, also kein Problem.
In den rechten Zweig gelangt man ansonsten, d.h. hier spielt es keine Rolle, ob die Variable true (vor Resume) oder 1 (nach Resume) beinhaltet (Red_Family, könnte es sein, dass die Abfragen in deinem WIG so lauten und er deswegen funktioniert?)

Bei numerischen Variablen sollten Abfragen = 0 vermieden werden. Kommt man von der Programmlogik nicht drum herum, kann folgendes Konstrukt verwendet werden:

Warum ist das nötig, werden einige von euch fragen. false ist doch gleich 0 - scheinbar ja, aber nicht ganz. Wenn die Abfrage nur myNumericVar == 0 lautet, landet man im Else-Zweig, sobald myNumericVar nach dem Resume den Wert false enthält. Im Vergleich wertet also der Player false ungleich 0, obwohl false als 0 gespeichert wird (wie von dir, Charlenni, geprüft).
Dagegen ergibt myNumericVar + 0 im iOS WIG-Player immer 0, egal ob myNumericVar 0 oder false enthält.
Aber Achtung: Hier wird eine weitere "Schwäche" des iOS WIG-Players genutzt: Bei 0 + false crasht Lua normalerweise (und mit ihm alle anderen WIG Player), nur der iOS Player ist hier ein wenig toleranter.

Zusammenfassung der Zusammenfassung
Die oben erwähnten Probleme treten bei mir reproduzierbar auf iPad 1 und iPhone4 auf, sowohl in der Test-Cartridge, die ihr euch runterladen könnt, als auch in meinem "großen" WIG.
Wenn ich es richtig verstanden habe, hast du, Red_Family den Test mit der Test-Cardridge durchgeführt und kannst auf deinem iPhone4 die Probleme bestätigen, aber auf deinem echten WIG hast du diese Probleme nicht.

Somit bin ich bisher also der einzige, der bei einem "richtigem" WIG diese Probleme reproduzierbar festgestellt hat. Entsprechend mit Vorsicht sind natürlich meine Aussagen zu genießen.
Ich würde mich schon wohler fühlen, wenn jemand mit iPhone sein WIG daraufhin überprüft (sollte im eigenen Interesse sein ) und meine Aussagen bestätigt - oder eben nicht ...

 

[Red_Family]

(Red_Family, könnte es sein, dass die Abfragen in deinem WIG so lauten und er deswegen funktioniert?)

Nein, ich teste auf true :/

 

[jonny65]

Tja Kinder, was sind denn nun die Maßnahmen ? Ich verwende Booleans noch und nöcher, beim letzten sind es 78, grad mal gezählt, hat mich interessiert :/ Wichtig für den weiteren Verlauf bei einem Resume sind davon natürlich nur ein Bruchteil. Aber es köööönnte auch was globales dabei sein was später wieder abgerufen wird. Dann ist noch die Frage obs was ausmacht wenn die Variable Nil statt false ist. 2 Ifs macht man ja selten, also gehts immer in den Else Zweig und der passt dann vermutlich auch so. Ein Beispiel für ein konfuses Verhalten wäre eine Variable "Sound". Der Spieler wählt Sound=true, nach einem Resume steht Sound auf Nil. In einer Abfrage steht if Sound=true then Play(Klingel). Der Spieler hört aber nix. Wie schon weiter oben angemerkt müssten schon einige komische Situationen gleichzeitig auftreten, bis dieses Verhalten den Spielfluss durcheinander bringt. Ich hab jetzt bei 4 Wherigos über 1000 Found Logs und kann mich nicht erinnern, daß mal was "seltsames" beschrieben wurde, was ich jetzt durch diese Erkenntnis hier erklären könnte so "ah, JETZT weiß ich was der Spieler DAMALS gemeint hat...". Wenn was kommt, dann doch immer nur "...stürzte ab, nach einem Restore gings aber normal weiter"

Ich behalts mal im Hinterkopf und berücksichtige es vermutlich in einem möglichen nächsten WIG.

 

[Cacher AG]

Einige Spieler (und wir) haben auch einige leidvolle Erfahrungen bei unserem WIG (http://coord.info/GC2WWDC) mit Boolean Variables nach dem RESUME eines gespeicherten Spieles gesammelt. Wir benutzen EARWIGO, aber das spielt scheinbar keine Rolle.
Auf der Suche nach einem Work-Around kann man zunächst unterscheiden nach "lokalen" und "globalen" (Booleschen) Variablen in folgendem Sinn. "Lokale" Variablen werden innerhalb einer Zone (z.B. beim Betreten oder Beenden einer Unterhaltung) gesetzt und stellen kein ernsthaftes Problem dar, weil man die Zone nach einem RESUME neu betreten kann. "Globale" Variablen (z.B. ob ein Gegenstand des Spielers defekt ist oder nicht) werden zu Spielbeginn gesetzt (aber NICHT bei RESUME) und bei bestimmten Aktionen im Laufe des Spiels verändert. Wenn diese nach einem RESUME falsch gesetzt sind, dann geht meist nichts mehr. Als Abhilfe verwenden wir statt einer "globalen" Variablen jetzt eine (ggf. unsichtbare) Aufgabe und fragen ab, ob sie erledigt ist oder nicht. Bisher hat das funktioniert.

 

[Cacher AG]

Wir haben unseren WIG (http://coord.info/GC2WWDC) auch nochmal gründlich mit der iPhone App (Wherigo) unter die Lupe genommen und nach verlassen jeder Zone das Spiel gespeichert - und dann mit Resume wieder fortgesetzt. Das Ergebnis war deprimierend und reproduzierbar: Abfragen von Booleschen Variablen oder Ausdrücken (z.B. Item sichtbar, Task erledigt) die vorher als TRUE evaluiert wurden waren danach FALSE - und das Spiel ging nicht weiter. Als Workaround - der bei dem relativ komplexen WIG sehr aufwendig war - haben wir alle relevanten Booleschen Variablen durch numerische ersetzt und fragen immer ab, ob diese =1 sind. Jetzt klappt alles [].

Zum Nachprüfen haben wir einen Mini-WIG (mit Earwigo) erstellt, der über unsere Dropbox erhältlich ist: http://db.tt/qnXUCOdD.
Der ZIP-File enthält die kompilierte Cartridge für Pocket-PC (iPhone, Android-Smartphone) und Garmin Geräte sowie den LUA Code, den GWZ-File und den Earwigo-Code (TXT).
Die Story ist extrem kurz.
Nach dem Start bekommt der Spieler einen Dollar und zwei Variablen werden gesetzt:
DollarCount=1 (Numerical)
DollarReceived=true (Flag)
Ein Checker zeigt die Werte der Variablen und wertet folgende Ausdrücke aus
(DollarReceived == true),
(Dollar:visible == true),
die beide TRUE sind.
Nach speichern des Spiels und einer Fortsetzung (Resume) zeigt das iPhone die Variablen wie bisher an, aber die letzten beiden Ausdrücke werden jetzt als FALSE ausgewertet.
Aber auf dem Garmin (Oregon 550t) ist nach der Fortsetzung des Spiels alles wie vorher!
Vielleicht hat jemand Zeit und Lust, das mal auf einem Android-Smartphione laufen zu lassen.

Das Problem wird z.Zt. auch in der Earwigo-Googlegroup diskutiert, an der auch der Entwickler der iPhone-App beteiligt ist. Wir hoffen auf ein baldiges Update.

 

[HKM]

Ich habe deine Test-Cartridge auf iPhone4 (Wherigo v317), Samsung Tab (Android 3.2, WhereYouGo 0.6.0) und Garmin 450 laufen lassen.
Das - nicht überraschende - Ergebnis:
Garmin und Android: alles ok - auch nach Resume.
iPhone: TRUE ist nach Resume nicht mehr TRUE (streng genommen allerdings auch nicht FALSE, sondern 1 (Numeric) ).

Du hast ja Shawn bereits vor knapp drei Wochen per Mail über dieses Problem informiert.
Bleibt also zu hoffen, dass ein Update das Problem löst.
Solange ist es aber wichtig, dieses Problem überhaupt zu kennen und ggf. bei eigenen WIGs entsprechend darauf zu reagieren.
Wir leben ja bei der WIG Programmierung mit ganz anderen Workarounds - ist nur einer mehr