Freitag, 7. Februar 2014

To offer a wherigo in several languages

This is the english version of the article. It is also available in german

Good to know for this article: "Der Einstieg in lua“

In this tutorial you'll learn how to offer your wherigo cartridge in several languages.

Picture 1: Definition of the text outputs in three different languages
First we will define an array messages where we can define the outputs in different languages
Very important is to define the language parameter to to ZVariables because we want to save the value when we save and restore the cartrigde.
For each language (german, english and fresh in our example) we define a subarry like in row 5-7. After that we define the output strings.
How it works I can show you at the example for the key hello. Depending on the selected language we want to see "Herzlich Willkommen", "Welcome" oder "Bienvenue" in our display. Maybe you have noticed that for the key hi are no english value defined. For this case the program will use the defaultLanguage (see row 4) So if your language is set to en and no value for message.en.hi is defined the default value messages.de.hi => "Hi" (row 11) is used.
The next part is very important:
In row 13-18 you can see examples for using placeholders, e.g the name of the play inside the translated output string
At runtime the #1# will be replace with the name, e.g. 'Krolock'. You will have one of the following output:
  • de => Hallo Krolock, wie geht es dir?
  • en => Hi Krolock, how are you
  • fr => Salue Krolock, ca va?
Be careful with blanks! # 1# will not work, #1 # will not work and Hi#1#How are you will transformed to "HiKrolockHow are you".

During the start of your cartrigde you can offer an multiple-choice-input for the user where he can select the langauge. After the input you can set the variable language to the fitting value


Picture 2: Build the value fitting to the key and language
But how to use the resource strings. As shown in picture 2, row 21 we use an array access for the language in first and the key in second level. Using "de" as language and "hello" as key will deliver Herzlich Willkommen zum i18n Wherigo.
If no array value is available a new try with the default value is shown in row 23. So it is very import to define an entry for each key in the default value (de in our example)


Picture 3: Values for the placeholders
Now it is time to look to the parameter replacement. I is import to use a placeholder that will not be part of the "regular" strings. So I decided to use #1#.
As you can see in line 27 at picture 3 i use string.gsub to replace #1# with the first, #2# with the second parameter and so on. Picture 3 shows a updated version of getMessage with replacing the placeholders
The vararg argument "..." is a good way to be flexible.
The function getMessage can be called with only the key, with one or multiple parameters like the following examples show :
getMessage("hello")
getMessage("helloWithName","Krolock")
getMessage("openDoor","XYZ","A15N")

With #arg we can retrieve the number of the arguments stored in the array arg. With arg[1], arg[2] we can access to the first, the second parameter and so on

Picture 4: Example for calling the translation method
If you have more than one parameter you have to take care for the order. For the key openDoor you have different orders in the german and english version.
Picture 4 shows us an example how to call the translation method in Urwigo. He have an example for no, one and two parameters.

Last but not least I will show you how to seperate your code and your translations. In the concept of resource bundles you will define a own file for each language and each file hast the same key, excect the language part of the key.
You can use a file messages_de.lua containing the german, messages_en.lua for the english and messages_fr.lua for the french values.
All the three files can be bind with require "messages_de" and so on.
Development-Tool line eclipse or Intellij IDEA have plugins to manage your resource bundles.

To seperate the file is optional. It will also work if you write all the key-value entries in one file, but it is not a good practise.

Sonntag, 12. Januar 2014

Haben wir Geocaching endgültig kaputt bekommen?

Zum Abschluss des Wochenendes gab es heute wieder mal die Erkenntnis dass unser schönes Hobby kurz vor dem Exodus steht.
Ok das ist jetzt überzogen, aber nachdem 90 % meiner letzten Versuche nen Cache zu veröffentlichen abgelehnt wurden, werde ich es mir gut überlegen mir nochmal die Mühe zu machen, ne Dose vorzubereiten, auslegen und Arbeit und Zeit ins Listing zu stecken.
Sicherlich kennen viele (potentielle) T5-Owner das Problem das Stoff kurzem das Einverständnis sowie Kontaktdaten des Försters vorhanden sein muss um nen Klettercache zu veröffentlichen.
Heute hab ich nach nem langen Tag des Laternenkletterns die Erfahrung gemacht dass dies auch für Stadt und Gemeinde betrifft.
Sehr frustrierend. Wo darf man überhaupt noch klettern?
Wo noch ne Dose auslegen die vom langweiligen 1/1 er Standard abweicht?
Dies soll übrigens keine Anprangerung der Reviewer sein. Vielmehr sehe ich die Ursache in den a) überzogenen Regeln die diese befolgen müssen und in der Notwendigkeit die Regeln in der Vergangenheit verschärft haben zu müssen.
Vielleicht machen wir noch mehr Powertrails und noch mehr Fernsehberichte ohne zu recherchieren damit der letzte aus der Hinz- und Kunz- Menge mit dem iPhone loszieht um schnell mal paar Dosen zu suchen, äh kaputt zu machen.
Dann wird die öffentliche Wahrnehmung und unser Ruf bestimmt besser.
Ach und je mehr Apps Seattle verkauft desto mehr klingelt dort auch die Kasse. Was ja wohl zunehmend der entscheidende Faktor zu sein scheint
In der BWL heißt so was CashCow. Melken bis es umfällt. Danach bzw eng verbunden kommt Degenerationsphase (Rückgang)

Donnerstag, 7. November 2013

Fehlersuche und Codeanalyse mittels _cartrigde.lua

Voraussetzung: "Der Einstieg in lua“

Abbildung 1: Bei der Zonendefinition wird der Identifier des Steinbruchs mit kleinem s angelegt
In diesem Tutorial wollen wir uns mit Fehlersuche bzw. Codeanalyse beschäftigen. Genauer gesagt geht es darum sich anzuschauen welcher lua Code aus dem Urwigo Projekt generiert wird.
Dies kann uns in zweierlei Hinsicht nützlich sein.
  • Erweitern der lua-Kenntnisse sowie Analyse der Wherigo-API
  • Fehlersuche
Zunächst beschäftigen wir uns mit dem zweiten Punkt: Das Scenario ist folgendes:
Wir haben eine Zone Steinbruch definiert, die wir im Lua user functions Bereich ansprechen wollen bzw. der Aktivitätsstatus wir dort verändern möchten.
Abb. 1 zeigt das Anlegen der Zone. Erfahrene Wherigo-Entwickler werden auf den ersten Blick feststellen, dass wir neben Namen und Bild auch den Identifier festgelegt haben.

Abbildung 2: Im lua Teil wird das Objekt fälschlicherweise mit großem S angesprochen
Im Lua user functions Bereich nehmen wir unseren Steinbruch und setzen die Aktivät auf true.
Wer erkennt hier schon unseren Fehler? Kleiner Tipp: Bei diesem Code würde das Projekt gar nicht erst starten. Würden wir die Anweisung in einer Funktion verwenden, die erst während dem Spiel ausgeführt wird, z.B onStart würde die Fehlermeldung folgendermaßen lauten:
Lua method call failed. .../urwigo-src-23fd04e4-6177-45ca-a89a-2ffc8589ff08.lua:323: attempt to index global 'Steinbruch' (a nil value)

Abbildung 3: Wichitg für die Lesbarkeit im Testmodus ist Verschlüsselung sowie die Verschleierung der Identifier und Texte zu deaktivieren
Die Ursache der Fehlermeldung ist schnell erklärt: Während der Identifier in Abb.1 auf steinbruch mit kleinem s gesetzt wurde wird im lua Part versucht die Zone mit großem S anzusprechen.
Da der Code case-sensitive ausgewertet wird ist Groß- und Kleinschreibung wichtig. Schließlich befinden wir uns ja nicht im Windows-DOS-Modus.

Diesen Fehler erkennt man beim zweiten Mal sehr zügig. Was aber, wenn wir noch nicht so erfahren sind? Hier kann ein Blick in die lua Datei helfen, die von Urwigo aus dem Projekt erzeugt wird und neben den Bildern als zip Datei (oder besser gesagt als gwz Datei) zum wherigo.com Server hochgeladen wird.
Wir wollen also einen Blick in die generierte lua Datei werfen. Dazu ist es wichtig, dass wir wie in Abb.3 erkennbar ist, die Verschleierung und Verschlüsselung der Texte, Antworten und vorallem der Identifiers aufheben. Die Identifiers dürfen auf keinen Fall verscheiert werden, wenn wir eigenen lua Code schreiben. Die ersten beiden Kästchen dienen der besseren Lesbarkeit während der Testphase, sollten vor dem Hochladen zu wherigo.com aber wieder gesetzt werden.
(Nicht dass es euch so wie mir geht und ihr ein paar Minuten nach der Veröffentlichung des neuesten Wherigos eine eMail bekommt in der euch ein Cachingkollege mit breitestem Grinsen alle Antworten und Spoilerbild zuschickt, weil ihr vergessen habt die Verschlüsselung zu aktivieren...)

Abbildung 4: Das Bauen des package ist nicht neues und kennen wir schon als Vorbereitung für's Hochladen
Jetzt könnt ihr euch kurz entspannt zurücklehen, denn der Teil mit dem Erstellen eines Packets sollte euch wohlbekannt sein.
Für den weiteren Vorgang nehmen wir an, wir haben die gwz Datei ExtractLua.gwz genannt und in dem Ordner "C:\tmp\ExtractLua" abgespeichert.

Abbildung 5: Beispiel für das Entpacken der gwz-Datei mit 7zip
Um die lua Datei aus der gwz Archivdatei zu extrahieren, bedienen wir uns eines Zip-Programmes unserer Wahl. WinZip, WinRar sollten selbsterklärend sein. Ich habe 7zip verwendet, da es sich hierbei um ein kostenlos nutzbares Tool handelt, dass allen Ansprüchen der Extrahierung gerecht wird. Wenn man den Schritt "Packet bauen - auspacken - Lua Datei anschauen" mehrmals wiederholt (nach der Behebung des ersten Fehlers wartet der zweite) empfiehlt es sich den Extraktionsbefehl über die Kommandozeile abzusetzen, da er dort recht leicht wiederholt werden kann (z.B Pfeil aufwärts in der Konsole). Der Parameter e steht für Auspacken, während der Schalter y für das Überschreiben vorhandener Dateien steht. Deswegen sollte man die gwz Datei außerhalb des Projektordners auspacken.

Abbildung 6: In der von Urwigo erstellten lua Datei kann man gut sehen, woran der Fehler liegt: Groß- und Kleinschreibung des Identifiers stimmen nicht überein
Wie ihr eure gwz Datei entpackt ist aber euch überlassen. Wichtig ist, dass am Ende eine _cartridge.lua Datei herauskommt, die ihr dann mit einem Texteditor öffnen könnt. Ich habe dies mit dem vim Editor gemacht, da mir dann ein farbliches Syntax-Highlighting sicher ist. Wer bereits mit dem IntellijIDEA arbeitet (siehe Lua im externen Editor bearbeiten) kann natürlich sich dort die Datei anschauen.

Nun aber zur Fehleranalyse. In Abb. 6 erkennt ihr an dem oberen bzw. unteren roten Kreis, dass die Identifier sich in Groß- und Kleinschreibung unterscheiden und ihr habt den Fehler somit gefunden.

Ich hatte zu Beginn des Tutorial einen weiteren Nutzen der Codeanalyse angesprochen. Dies wird durch Betrachtung des mittleren roten Kreises deutlich:
Der Codeteil function objExtractLuaTest:OnStart() end enthält nämlich alle Codeanweisung, die beim Starten des Wherigo ausgeführt werden. Ich seht auch wie der Identifier des Cartridges gebildet wird, wenn er nicht von euch vorgegeben wird: Mit einem simplen Prefix obj der vor den Namen gesetzt wird.
Anstatt die Startanweisungen als lua Block aufwändig über Urwigo einzugeben, könnt ich auch einfach in euerer lua Datei diesen Codeteil verwenden.
Auf diese Weise hab ich mir nach und nach angeschaut, wir Textausgaben (MessageBoxen), Benutzeneingaben (Input), Timer, Zonen und Gegenstände verwendet werden, sodass ich heute nur noch die Objekte in Urwigo definiere (UUID-Erzeugung ist zwar möglich aber recht aufwändig) und alles andere direkt in lua schreibe, was sich bei aufwändigeren WherIGos wie Minesweeper, Cachopoly, Schiffe versenken... als wesentlich schneller herausgestellt hat und ihr habt die Codeanweisungen zentral in einer (später mehreren) Lua Dateien und könnt so euren Code besser nachvollziehen.

Samstag, 17. August 2013

IPhone Player Update erfolgreich

Wie ich mittlerweile von mehreren Feedbacks mitbekommen habe ist das aktuelle 1.4.2 Version des PiGo Player soweit daß auch kompliziertere  Wherigos wie Scotland Yard oder Minesweeper zu spielen sind. Also Update einspielen und los geht's. Um weitere Rückmeldungen bin ich immer noch dankbar

Sonntag, 28. Juli 2013

Buggy und T5er

Jaja kaum ist das Kind anderthalb kann es schon Buggyverschüsse öffnen. Aber da hat es die Rechnung ohne T5er Papa gemacht

Freitag, 26. Juli 2013

Minesweeper überall als PlayAnywhere spielen


Abbildung 1: Wenn du zu weit entfernt von vordefinierten Spielfeldern bist, kannst du dein Feld selbst aufziehen. Markiere ObenLinks ...
Minesweeper ist mit der Version 2.0 nun auch als PlayAnywhere verfügbar.

Dabei kommt ein neuartiges Lokalisierungverfahren zum Einsatz:

Beim Start des Spieles prüft das Gerät selbstständig ob es sich im 1-km-Radius zu einem vordefinerten Spielfeld (z. Zt Koblenz/Ehrenbreitstein - Emsland und Holland sind in Planung) befindet und wählt dieses automatisch aus.

Ist kein passendes Spielfeld in der Nähe, wird automatisch auf PlayAnywhere-Modus umgeschaltet und der Spieler wird zur Definition der Ecken LinksOben sowie RechtsUnten aufgefordert. Am Ende erhält er wie gewohnt Zahlen für die Buchstaben A, B, C und D, die er in die Formel im Geocaching.com Listing eintragen kann um die Tupperdose zu besuchen.

Abbildung 2: ... und danach UntenRechts und schon bist du fertig und kannst loslegen.

Minesweeper auch in deiner Stadt?

Du wohnst ein wenig entfernt von Koblenz und möchtest Minesweeper auch in deiner Caching-Homezone anbieten?
Schreib mir einfach ne Nachricht und ich kann ein vordefiniertes Spielfeld auch für deinen Ort eintragen, bzw. dir bei der PlayAnywhere-Formel helfen.

Donnerstag, 25. Juli 2013

Endlich dynamische Wherigos auf dem iPhone? Update für Apfel-Player PiGo erschienen

Es gibt ein neues Update für den PiGo Player. Und es gibt damit neue Hoffnung auf komplexere Wherigos wie Cachopoly, Schiffe versenken, Scotland Yard, Siedler oder Minesweeper


Abbildung 1: Die Auflistung von Cachopoly in den Beispiel-Wherigos auf der iTunes Seite lässt hoffen, dass nun auch dynamische Wherigos mit PiGo spielbar sind.
Wie auf der iTunes Seite verkündet ist das 1.4 Update für PiGo verfügbar und hat allerei Bugfixes dabei.
1) Various minor updates.
2) Improved audio playback.
3) Added active zones as possible command targets.
4) Allow selection of universal commands with no targets.
5) Consider active zones for command text.
6) All input/views allow timers, etc. to run normally.
7) Updated map display.
8) Reversed angle for: Wherigo.VectorToPoint
9) Changed action tracking for items.
10) Added geocache search!
11) Fixed restore of boolean values. Thanks Knut!
    


Besonders gespannt bin ich auf die Überarbeitung der Timer sowie die VectorToPoint Anpassung. Letzteres könnte die Ursache dafür sein, dass Minesweeper beim Project-Eck-Event nicht für Apfeljünger spielbar war.
Es gibt also Hoffnung. Da ich selbst (überaus zufrieden) auf der Android-Welle surfe, bin ich auf euer Feedback angewiesen und gespannt.

Schreibt eure Erfahrungen ruhig als Antwort zu diesenm Post