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

[HKM]

Hallo,
ich habe folgendes Problem:

Ich lege in Urwigo (1.) eine Boolean Variable myBooleanVar an, die ich per Default auf True setze.
Anschließend frage ich ganz simpel diese Variable ab. Dazu erstelle ich (2.) ein Item, das ich "Debug" nenne, erstelle hier eine Schaltfläche "Check myBooleanVar", die per Klick (3.) eine entsprechende Abfrage aufruft:

        if myBooleanVar == true then
                _Urwigo.MessageBox{Text = "myBooleanVar is TRUE"}
        else
                _Urwigo.MessageBox{Text = "myBooleanVar is FALSE"}
        end

Visualisiert unter Urwigo sieht es dann so aus:

Viel simpler geht es wohl kaum. Trotzdem gibt es mit dem WIG Player v317 für iOS (und nur dort, Garmin und WhereYouGo ist ok) ein massives Problem (zumindest bei mir):

Ich kompiliere also die Cartridge (egal ob per Urwigo oder per Online Compiler von wherigo.com) und lade die .gwc Datei auf mein iPad.

Starte ich nun die Cartridge und klicke den Button "Check myBooleanVar", so erscheint die Meldung "myBooleanVar is TRUE". So soll es natürlich auch sein.

Beende ich nun aber die Cartridge und spiele anschließend über "Resume" weiter, so erscheint beim Klick auf den Button "myBooleanVar is FALSE"!!! Das ist eigentlich unglaublich, aber wirklich wahr.

Ich besitze "nur" ein iPad1 (3G), also schon etwas älter. Kann es daran liegen?
Könnte bitte jemand das Problem auf seinem iPhone einmal testen?

Danke und Gruß,
HKM

 

[AoiSora]

Bin mir jetzt nicht sicher aber irgendwas war da mal mit Probleme durch boolean.
Nimm doch einfach eine ganz normale variable und setz die auf 0 (=false) und auf 1 (=true).

 

[HKM]

Das könnte ich natürlich machen, würde aber bedeuten, dass alle WIGs, die eine Boolean Variable verwenden, nicht vernünftig auf iOS laufen. Das wäre schon ein ziemlicher Hammer.
Ich vermute, so etwas wäre dann sicherlich auch z.B. bei Dinge, die vermieden werden müssen ... vermerkt. Aber ich habe nichts zu dem Thema in diversen Foren etc. gefunden.

Vielleicht könnte deswegen einmal jemand versuchen, das Problem auf seinem iPhone nachzuvollziehen. Das wäre sehr nett

 

[Red_Family]

Aaaaaaahhhh,
ich habe es nach programmiert und auf einem Iphone4 ausprobiert.
Gleiches Ergebnis! Ich bin geschockt da ich diese Boolean Variablen in meinem Wherigo benutzt habe.

 

[Charlenni]

Wenn Du es schon programmiert hast, dann schau doch bitte mal nach, ob es in der Lua-Datei eine Zeile "CartridgeName.ZVariables = { }" gibt und ob in der geschweiften Klammer die boolean Variable steht. Nur dann wird sie nämlich auch abgespeichert. Sonst nicht.

 

[Red_Family]

Bin schon auf Arbeit.
Werde ich heute abend schauen.
Kannst du mir erklären wie ich nachschaue ? also wie ich an den Lua Code komme.
Bin noch neu mit der Wherigo Programmierung.

 

[Charlenni]

Erstmal "Code obfuscation" ausschalten, sonst ist der Quellcode nur schwer zu lesen. Dann eine GWZ-Datei erzeugen lassen und umbenennen in .ZIP. Dann einfach einen Doppelklick auf die Datei (oder den Entpacker Deiner Wahl bnützen) und aus den Dateien die Datei mit dem Namen "_cartridge.lua" wählen. Diese mit einem Textedito öffnen.

 

[HKM]

Meine Test-Cartridge enthält folgenden von Urwigo generierten Lua-Code:

-- Cartridge Variables --
myBooleanVar = true
...
cartIphoneTest.ZVariables = {
	myBooleanVar = true,
	...
}

Die Variable ist also in der ZVariables table enthalten.
Kann eigentlich auch nicht anders sein, da es ja auf Garmin und Android/WhereYouGo funktioniert.

Dass es auch auf einem iPhone 4 nicht läuft, bestätigt allerdings meine schlimmsten Befürchtungen.
Vielen Dank an Red_Family fürs Testen.

 

[Red_Family]

Ok, dann brauch ich ja nicht mehr nachzusehen.
Ich werde das Verhalten bezüglich boolean Variablen mal bei meinem Wherigo ausprobieren.
Ich benutze nämlich einige boolean Variablen und wenn die nach dem Speichern nicht korrekt eingelesen werden, wäre das blöd.
Muss ich dann einges ändern !

 

[Red_Family]

Das ist echt seltsam

Bei meinem eigenen Wherigo wurde jetzt die Boolean Variable korrekt gespeichert und wieder eingelesen.

 

[HKM]

Hmm, das ist einerseits seltsam, hat aber eventuell folgenden Grund:

Wenn die Variable den Inhalt False hat, funktioniert die obige Abfrage sowohl vor als auch nach dem Resume korrekt.
Genauso wenn die Abfrage in Urwigo wie folgt lautet:

also ein Test auf False, nicht auf True wie oben.

Nur wenn die Variable True enthält und auf True getestet wird, dann gibt es scheinbar ein Problem. Kannst du deine Cartrdge dahingehend noch einmal überprüfen?

Aber es kommt noch dicker (zumindest bei mir).
Ich habe einen ähnlichen Test mit einer numerischen Variable durchgeführt.

Diese habe ich wie zu sehen ist in Urwigo auf 0 gesetzt und folgende Abfrage eingebaut:

Beim ersten Durchlauf erscheint die Meldung "myNumericVar is 0"
Nach Beenden und Resume erscheint "myNumericVar is NOT 0"
Ich bin echt sprachlos.
Setze ich die numerische Variable jedoch auf 1 und ändere meine Abfrage entsprechend funktioniert wiederum alles ...

Kannst du das eventuell bei deinem iPhone auch einmal testen?

Gruß, HKM

 

[jonny65]

Kommt mir (trotzdem ?) sehr unglaubwürdig vor. Würde heißen, daß weltweit kein einziger Wherigo mehr nach einem Resume funktioniert auf iPad und iPhone, wenn er Variablenzuweisungen benutzt, die im Verlauf des Spiels entscheidend sind. Und in vielen Logs würde man von solchen Poltergeistern lesen.

Also mal bissl genauer analysieren...was ist denn, wenn man die Variable explizit setzt beim Start, also nicht nur den default Wert auf den Wert X setzen, sondern tatsächlich Set var=x.
Dann mal den Wert der Variable ausgeben. Bis jetzt wurde sie immer nur abgefragt auf 2 Zustände, aber welchen Wert hat sie denn, ist NumericVar jetzt 1 oder 23 oder 147 wenn nicht 0 ?

Und dann das ganze nochmal probieren mit einem Speicher Kommando statt einem Beenden mit Speichern, also ein Item anlegen mit dem "Save" Befehl als Kommando. Dann Save klicken, WIG beenden OHNE Speichern und anschließend Restore.

 

[Red_Family]

Bei meinem wherigo funktioniert beides.
Abspeichern mit false und mit true.
Vielleicht liegt es tatsächlich an dem was Johnny sagt:
Ich weisse den Variablen ja per set Befehl Werte zu und du benutzt bei deinen Beispiel Wherigos Variablen mit voreingestellten Werte.
Schreib doch mal dein Programm so um das du der Variable per Kommando Werte zuweist und speicher dann ab und lade erneut zum testen.

Ich glaube auch es liegt daran das die Default Werte bei der Deklaration nicht gehen. Sobald du aber eine Variable mittels set einen Wert zuweist wird sie gespeichert.

 

[HKM]

Ich habe jetzt alle eure Vorschläge durchgetestet - keine Veränderung.

Ich habe die Variable explizit gesetzt, ich habe per Command gesichert und ohne Sichern den WIG Player beendet (d.h. ich habe ihn im Task Manager gekillt, da der iOS WIG Player ja immer beim Beenden speichert, ob man will oder nicht)

Mir kommt es - wie ich oben schon erwähnte - auch sehr komisch vor und eigentlich fast unglaublich, aber es ist wie es ist . Ihr könnt meine Urwigo-Datei hier herunterladen: iPhoneTestVar.urwigo (Mausklick rechts -> Ziel speichern unter). Bitte testet sie auf eurem iPhone oder sagt mir wo mein Fehler liegt. :hilfe:

 

[Red_Family]

Probier das mal aus

 

[HKM]

Gute Idee
Es erscheint die Meldung: "Nix von Beidem"
Wie gesagt: erst nachdem ich über Resume die Cartridge neu gestartet habe. Beim ersten Durchlauf erscheint "myBooleanVar is TRUE". Schon kurios.
Vielleicht kannst du morgen einmal meine Cartridge testen. Wenn es auf deinem iPhone läuft, muss es wohl an meinem iPad 1 liegen. Ist dann eben so, muss man nicht verstehen.
Wenn es auf deinem iPhone auch nicht laufen sollte ... tja, dann weiß ich auch nicht

 

[Red_Family]

Ich habe das gleiche Fehlerbild wie du auf dem Ipad.

Seltsamerweise funktioniert das bei meinem "richtigen" Wherigo ohne Probleme.

 

[jonny65]

Also jetz aber .... in den else Zweig mal :



Der Variablen natürlich einen festen Identifier (in dem fall "test") geben)
Jetz sag nicht, es kommt Trulse

Ich würd sagen iPad verschrotten

 

[Red_Family]

Also Trulse kommt nicht aber etwas was ich erwartet hatte und mein Iphone werf ich nicht weg

 

[HKM]

Also bei mir erscheint: test = 1
(Eventuell hast du, Red_Family, den Identifier nicht auf "test" gesetzt? Dann kennt der WIG Player die Variable "test" nicht und hat somit einen nil Wert.)

Ich habe noch folgende Tests auf meinem iPad durchgeführt:
tostring( true ) ergibt "1" (auf Garmin, WhereYouGo und Emulator ergibt es "true")
tostring( false ) ergibt "0" (auf Garmin, WhereYouGo und Emulator ergibt es "false")

Diese Ausgaben (also 0 und 1) erscheinen auch beim ersten Durchgang, wo noch alles korrekt funktioniert. Es sieht so aus, als wenn der iOS WIG-Player damit arbeitet, also False = 0, True = 1 .

Eventuell ist das Resume im iOS WIG Player nicht sauber programmiert, so dass er beim Laden der Variablen aus einer Boolean Variable eine Numeric oder String Variable macht (ist natürlich hypothetisch, wäre aber eine Erklärung)

Leider, leider ist die Lua Basic Function type nicht im iOS WIG Player implementiert (in allen anderen Playern funktioniert sie), so dass man einfach type( test ) hätte abfragen können.
So kann man einer 1 nicht ansehen, ob sie eine Zahl, ein String oder ein verkappter Boolean-Wert ist.

Das hat mich auf die Idee gebracht, folgenden Lua-Code auszugeben:

Gem. Lua Spezifikation muss das einen Runtime-Error auslösen, kann man hier testen: http://www.lua.org/cgi-bin/demo, indem man print( true + 1 ) eingibt
Garmin und der Emulator crashen an dieser Stelle, WhereYouGo zeigt gar nichts an (ich vermute hier greift eine Fehlerbahndlungsroutine, die ein Abstürzen verhindert).
Was aber zeigt mein iOS WIG Player an? 2 !!!

Vielleicht ist das ja wie gesagt alles nur ein Problem meines iPads.

Dein Einwand, Jonny, dass es dann auf vielen WIGs dieser Welt Probleme geben müsste, ist mehr als berechtigt. Allerdings ist es schon so, dass es immer wieder Probleme mit Iphones gibt, z.B. hier: iPhone: Some devices have reported trouble registering one of the zones after saving their game.

Eventuell bekomme ich heute Abend ein iPhone4 zum Testen, dann schaue ich weiter ...