Nachrichten asynchron anzeigen mit einer Messag-Queue

Voraussetzung: "Der Einstieg in lua“

Abbildung 1: Wenn die Nachricht unpassend ist, wird sie später angezeigt

In diesem Beitrag geht es um asynchrone Nachrichtenverarbeitung. Klingt komplizierter als es ist, deswegen will ich es mal an einem einfachen Beispiel erklären:

Stellt euch vor in eurem Wherigo-Spiel geschieht gerade ein längerer Dialog. Der Spieler muss 3-4 Fragen beantworten auf die er jeweils direkt eine Antwort bekommt.

Dazu habt ihr einen Timer der im Hintergrund einmal pro Minute etwas prüft und gegebenenfalls eine Nachricht anzeigt "Die Löwen sind wieder hungrig und möchten gefüttert werden"
Nicht nur dass die Nachricht Umlaute enthält, nein sie würde auch im aktuellen schwierigen Dialog stören bzw. wichtige Informationen überlagern.

Stellt euch vor, der Spieler erhält gerade die dringende Nachricht "Gehe schnell zum Affengehege" als der Timer anspringt und sofort mit der wenig dringenden Löwennachricht überlagert. Da wüsste der Spieler gar nicht, dass er zuerst du den Affen soll.

Um dass zu verhindern nutze ich eine Mesage-Queue in die ich Nachrichten einstelle (Zeile 174), wenn sie gerade unpassend sind. Wenn sie gerade nicht stören, also hideMessage auf false steht können sie auch direkt angezeigt werden.
Die msgQueue besteht aus einer Tabelle in die mit table.insert ein Text sowie ein Bild eingefügt wird, um später die Nachricht darzustellen.
Zusätzlich hält das Array-Objekt noch einen Pointer, der auf die nächste darzustellende Nachricht zeigt.

Wenn dann die kritische Situation vorbei ist (Der Dialog ist beendet, oder immer wenn der Spieler eine Zone verlässt) wird printMessageFromQueue aufgerufen. Diese Methode prüft ob neue Nachrichten vorhanden sind (dann wenn mehr Nachrichten im Array sind als der Pointer groß ist) und gibt die Nachricht aus auf die der Pointer zeigt.
Nach Drücken von "OK" durch den Spieler wird der Pointer einen weitergesetzt und printMessageFromQueue rekursiv aufgerufen. Solange bis alle Nachricht abgearbeitet, also angezeigt wurden.

Abbildung 2: Während der Dialog mit dem Spieler etwas länger dauert, springt der Timer an und schiebt die Nachricht in die Queue

Abb. 2 zeigt uns die Anwendung im Code. Die Methode doLongDialog soll den komplizierten Frage-Antwort-Dialog simulieren. Bevor der Dialog startet wird hideMessage auf true gesetzt. Ab jetzt gehen alle Nachrichten in die Queue.
Zeile 206 bis 208 zeigen uns den Timerfall. Während der Timer anspringt ist hideMessage positiv und die Nachricht wird eingereiht.

Nachdem der Dialog vorbei ist, wird (!!! Im Callback des letzten Dialogs / MessageBox !!!) hideMessage wieder auf false gesetzt, damit ab jetzt wieder live angezeigt werden kann, da die kritische Situation vorbei ist.

Wenn es in eurem Spiel keinen festdefinierten Zeitpunkt gibt, wann die Nachrichten nachgeholt werden können, könnt ihr mit einem weiteren Timer arbeiten, der alle 60 Sekunden prüft ob hideMessage auf false steht und dann printMessageFromQueue aufruft.

Abbildung 3: Egal ob direkt oder später, die Nachricht erscheint als MessageBox

Doppelte Logeinträge mit GSAK finden

Wer kennt es nicht das Problem. Man hat 2-3 Wochen bzw. 50 Caches lang keine Statistik mehr generiert und dann nachdem man mal wieder die Graphiken aktualisert hat, kommt das Horrorszenario: 2047 Funde bei 2046 Caches.

Abbildung 1: Der Horror - Bei einem Cache hab ich aus versehen doppelt geloggt

OK, es müssen nicht genau 2047 Funde sein, aber das Problem hatten die meisten schonmal. Bei irgendeinem Cache ist doppelt geloggt wurden. Entweder hat der Groundspeak Server gehangen und man hat doppelt losgeschickt, man hat einmal vom Smartphone und einmal am PC geloggt oder beim nachträglichen Ändern des Logs (Text / Datum) ist was schiefgegangen.
Schlimmer als die Frage WARUM ist "WO habe ich doppelt geloggt?" Da kann es schon ein wenig mühselig sein die letzten 50 Caches durchzugehen. Vorallem wenn man zwischendurch ganz alte Einträge nachholt. "Ach ja, das Event von letztem Jahr muss ich auch noch nachloggen."

Abbildung 2: Sqlite Manager als Datenbank-Tool starten

Aber warum soll man selber suchen und nicht suchen lassen.

Anmerkung: Nach Veröffentlichung des Posts wurde ich durch Kommentare aufmerksamer Leser darauf hingewiesen, dass man das Problem mittlerweile durch GSAK-Bordmittel lösen kann. (Siehe Kommentare). Hier erfolgt der Ansatz über die Datenbank, der für das Doppelte-Logs-Problem etwas komplizierter ist, dafür aber einen guten Einstieg gibt, wie man Infos aus der zugrunde liegenden Datenbank sqlite ziehen kann
Wir werfen dazu einen Blick auf die Datenbank, genau genommen der Datenbestand, der alle Founds enthält und von wo aus die Statistik generiert wird.
Um einen direkten Datenbankzugriff zu bekommen nutzen wir das von GSAK mitgelieferte Tool Sqlite Manager. Dies ist über Tools in der Menüleiste zu erreichen.
Wer mit alternativem Tools wie z.B. DBVisualizer unterwegs ist kann auch direkt die Sqlite Datei .db3 öffnen aber das GSAK integrierte Tool tut es hier vollkommen.

Abbildung 3: Die richtige Datenbank auswählen

Wichtig ist, dass ihr die richtige Datenbank auswählt. Bei mir heißt die Datenbank für die Funde foundDB, folglich liegt die Datenbankdatei unter data/foundDB/sqlite.db3

Abbildung 4: Durch geschickten Select auf die Logs Tabelle bekommt man alle doppelten Einträge heraus

Sobald die richtige Datenbank geöffnet ist, geht es los.
Zuerst selektiert man alle Zeilen deren Log-Type Found it und deren Finder man selbst ist. Krolock müsst ihr natürlich durch Euren Nickname ersetzen, ansonsten sehr ihr nur, ob ich doppelt geloggt haben
Um nicht mit unnötig vielen Daten weiterzuarbeiten wird nur die Spalte lParent geladen. Dies ist der GCCode des Caches den ihr gefunden habt. Der SQL-Befehl lautet bisher
SELECT lParent FROM Logs where lType = 'Found it' and lBy = 'Krolock'
Es müssten nach unserem Beispiel 2047 Zeilen ausgegeben werden.
Jetzt kommt der entscheidene Schritt, die Gruppierung. Dazu ergänzen wir im select Part ein Count(*) und gruppiern auf lParent
SELECT count(*) c, lParent FROM Logs where lType = 'Found it' and lBy = 'Krolock' group by lParent liefert nun 2046 Zeilen bei dem überall die Zählspalte c den Wert 1 besitzt.
"Ganz Gallien?" - Nein in einer Zeile steht ein 2, das ist die gesuchte Zeile. Um die Einserwerte zu eleminieren bauen wir noch ein Select um das Zwischergebnis herum, indem wir mit where c > 1 nur die Mehrfachnennungen aufzeigen und -falls ihr so richtig Mist beim Loggen hinbekommen habt- sortieren wir noch nach c absteigend

Zu kompliziert?

Solltest du jetzt denken " .... HÄ ???? .... ", so kann ich dich beruhigen.
Nimm einfach folgenden Code und ersetzte Krolock durch deinen Nickname.
Drücke dann auf F9 und schon siehst du den GCCode der Caches bei denen du doppelt geloggt hast.
select * from (SELECT count(*) c, lParent FROM Logs where lType = 'Found it' and lBy = 'Krolock' group by lParent) where c > 1 order by c desc

Wegführung zu lang, so was geht aber nun wirklich nicht

Ich wußte gar nicht, dass man bei einer Mystery-Serie die Dosen immer so anlegen muss, dass man eine schöne Wegführung hat. In den 6 Jahren in denen ich nun cache und auch eigene Caches veröffentliche, dachte ich immer es ging beim Cachen darum raus zu kommen, tolle Locations zu entdecken und gerade bei Mysteries lustige Suche zu entdecken bzw. was zu lernen.
So hab ich dann letztes Jahr auch gutgläubig 12 lustige Rätsel zum Thema Fußballerzitate veröffentlicht. Olli Kahn und Poldi lassen grüßen. Nach gut anderthalb Jahren hab ich aufgehört zu zählen wie viele Logs ich von der Art bekommen habe, wie ich euch mal exemplarisch mal einen hier zeigen möchte. Er stammt von Fußballerzitate #01

Ja hätte ich das gewußt. Da wäre mir natürlich Naturverträglichkeit und Sinnhaftigkeit von Locations egal gewesen und bei der Abstandregel zu bestehenden Caches hätte ich ein wenig gefuscht.
Aber wenigstens hätte ich dann einen Rundweg gebaut, bei dem alle 161 Meter eine Dose liegt, die von weitem sichtbar ist und auch ohne Schlamm erreichbar wäre.
Ich glaube, um sicher zu gehen, werde ich bei der nächsten Runde einfach vorher alle Interessenten fragen, ob sie mir der geplanten Tour zufrieden sind. Kann ja nicht sein, dass Leute extra aus Hessen anreisen und dann am Ende des Tages 500 Meter zu viel gelaufen sind. Am Besten ich hänge alles an Straßenschilder, dann kann man auch direkt im Auto bleiben.
Oder Plan B: Ich leg einfach keine Dosen mehr. Dann muss auch niemand zu viel laufen oder sich ärgern, dass er keinen Rundweg hat.

Fußball zum mitdenken

http://www.der-postillon.com/2014/07/bitter-wm-aus-fur-deutschland-nach-nur.html?m=1

Am besten sind die Schimpf Kommentare der “Erleuchteten“

Herumirren im Frankfurter Parkhaus

Wer schon mal auf nem MEGA Event war kennt bestimmt das Bild von herumirrenden Cachern die Autos fotografieren, oder besser gesagt die TBs auf den Autos.
Hier in Frankfurt ist es noch ne Spur bizarrer, da das Cacher im Parkhaus stattfindet.
Man hat erst den Eindruck Leute habe sich verlaufen und suchen den Ausgang. Oder die würden für den Rückweg Fotomarken setzen. Ethisch gesehen ein großer Fortschritt gegenüber der Lebensmittelverschwendung wie Hänsel und Gretel es vollzogen.
Aber es ist die falsche Fährte.
Nein es geht um Statistik. Und die Leute sind alles andere als verwirrt. Sogar sehr nett wenn man ins Gespräch kommt. So zwischen 2 Autos, äh TBs.
Eine Steigerung findet man am Treppenhaus, hier ist ne Liste aufgehangen, damit man sich nicht die Mühe machen musst zu laufen.
Noch bizarr hab ich es in der Schweiz gesehen. Hier konnte man beim MEGA Schwitzerland direkt über nen FTP Server die Liste herunterladen. Natürlich im passenden Format für den TB-Logger.
In diesem Sinne, frohes sammeln.

In Frankfurt kracht es

"In Frankfurt kracht es" war die Meldung, die mich vorgestern in unserer Cache-Talk-WhatsApp-Gruppe aufschreckte.
Was war passiert? Nachdem ich schon oft gehört habe in Frankfurt würde kommerziell abgezockt hat das Announcement bzgl des Catering Zwangs das Fass zum überlaufen gebracht.
"Hilfe ich will mein Geld zurück", "Ich schalte meinen Anwalt ein", "Da würde ich nicht mehr hinfahren", NeedsArchive-Logs waren einige der heftigen Reaktionen.
In der Tat ist es schon merkwürdig, dass man neben dem --- bei MEGA-Events zum Usus gewordenen Eintritt --- an recht vielen Stellen erneut zur Kasse gebeten wird. Und dann kam halt noch die Meldung, dass man keine eigenen Speisen mitbringen darf und stattdessen dem Catering-Service ausgeliefert ist.
Ich habe nun so einige Megas miterlebt und auch schon mal über die Preispolitik geschimpft (siehe Zeltplatz-Abzocke bei den Geogames), ich kann mir aber auch gut vorstellen, dass sowohl in Leipzig als auch in Frankfurt das Orga-Team keinen einzigen Cent an der Geschichte verdient. Im Gegenteil: Ich denke eher die legen nicht nur Zeit, sondern auch Geld drauf.

Ich sehe eher eine andere problematische Entwicklung:
Dadurch dass alles immer besser größer, Mega, GIGA (keine Schreibfehler, sondern Unterstützung der Klimax :-) ) sein muss, wächst den Organisatoren oft die Arbeit übern Kopf hinaus.
Und da werden dann Aufgaben wie Bewirtung outgesourced. Und ne Catering Firma arbeitet natürlich auf Profit. Mir ist das schon in Leipzig aufgefallen.
Oder die Location hat zu viele Einschränkungen, wie jetzt wohl in Frankfurt.
Vielleicht sollte man bei MEGA Events wieder etwas zurück fahren oder Locations wählen wo man weniger Vorgaben hat.

Mega Switzerland war da nen gutes Beispiel. Abgesehen davon dass die Schweiz generell sehr teuer ist, fand ich es extrem fair und in den Details gut vorbereitet. Aber die haben auch mit vielen vielen Organisatoren zwei Jahre lang vorbereitet.

Dass man so seine 15 € Unkostenbeitrag leistet, dass sehe ich durchaus ein. Dafür weiß ich als ehrenamtlicher Helfer in örtlichen Vereine gut genug, was für Kosten entstehen, die keiner sieht. GEMA, Gestattungen, Technik, Auflagen hier und dort.
Aber muss es immer größer werden, muss es ein Fußballstation sein. Wäre nicht ein Mega außerhalb der Stadt auf freier Fläche mit angrenzendem improvisiertem Camping à la "Rock am Ring" nicht auch ausreichend.
Also liebe zukünftige Mega-Event-Orga-Teams, verzettelt euch nicht in Superlativen und liebe Eventbesucher, muss ich beim Campen immer nen 5-Sterne-Platz mit eigener Dusche pro Camper haben?
Ich persönlich finde an Events am wichtigsten mit vielen Cachern ins Gespräch zu kommen. Und da sind provisorische Bierbank-Farmen oft besser als die beste Fußballarena.

In Frankfurt konnte die Sachlage übrigens ein wenig entschärft werden. Die Preview-Preisliste für Verpflegung liest sich ziemlich fair und kontrolliert werden die Taschen beim Eingang auch nicht. In diesem Sinne, auf ein schönes entspanntes BigÄppel.

Finalkoors und Hint

Voraussetzung: Globaler Code - Teil II

Abbildung 1: Glückwunsch du hast gewonnen und bekommst die Koors auch angezeigt

In diesem Tutorial geht es darum, dem Spieler das Finden des Finals zu erleichtern. Es soll ja vorkommen, dass zwischen der letzten Aufgabe im klasischen "Multi-WIG" und dem Final mehr als 100 Meter und eventuell auch noch 4 x auf dem Wanderweg abbiegen liegen.
Auch bei einem dynamischen WIG wo die Reihenfolge der Aufgabe flexible ist, kann es recht schnell vorkommen, dass der Pfeil der "Final"-Zone nicht ausreicht um dorthin zu navigieren. Das zweite Problem stellt sich wenn dein WIG an mehreren Ort mit verschiedenen GC-Listings läuft und jede Dose nen anderen Hint hat.
Bei diesen Problemen haben sich folgende Schritte bewährt:
1) Gebt die Koors mit aus, damit der Spieler sie abschreiben kann ...

Abbildung 2: An der Zone Final kann man Koors und Hint jederzeit ablesen

... und 2) schreibt die Koors nochmal als Beschreibung der Zone Final rein. Für all die Spieler die es verpeilt haben die Koors beim ersten Mal abzuschreiben weil die Finger wieder schneller als die Augen waren.
Damit der Spoiler fürs Final genau zum richtigen Zeitpunkt bekannt gegeben wird könnt ihr ihn ebenfalls in die Beschreibung der Zone platzieren.

All dies kann man natürlich klassisch mit Urwigo machen. Es spricht auch nichts dagegen....
... es sei denn die Finallocation ändert sich (eine der beiden Stelle wo die Koors angepasst werden müssen vergesst ihr garantiert) oder die Geschichte mit verschiedenen Dosen / Hints kommt ins Spiel.
Wie können wir es also dynamisch mit lua lösen?

Abbildung 3: dreigeteilter Code für Initialisierung, Setzen der Werte nach Wahl der Location und Gewinnmeldung

Vorbereitung

Als erstes definiert ihr ein Array von locations und anschließend für jede reale Dose einen Eintrag.
locations[1] für die Dose in Hamburg, locations[2] für die in Berlin, locations[3] für München usw.
Was kommt in einen location-Eintrag? Bei mir sind es zwei Informationen:

• der Wegpunkt mit dem die Final-Zone versehen werden soll
• Eine Beschreibung des Finals bzw. der Hint

Spielstart

Das Spiel wird gestart, startGame (Zeile 7 ff) ausgeführt und eine der möglichen Locations ausgewählt. Dies kann per Multiple-Choice passieren oder voll automatisch, indem ihr die Location auswählt die am nächsten liegt.
Da dies in Dein WheriGo in Hamburg, München, Köln, Berlin .... behandelt wird, hab ich hier einfach die "1" gewählt.
Nun gilt es die Werte zu setzen. Dabei werden der Finalzone ihre benötigten Wegpunkte gegeben, nämlich dreimal loc.FinalPoint
Für die Ausgabe der Koors in einem lesbaren Format nutze ich die Helfermethode buildReadableCoorString (siehe Globaler Code - Teil II )
Danach wird die Beschreibung noch generiert (#1# wird mit N 50° 39.910, E 7° 28.092 ersetzt und an die Zone angeheftet.
Damit sind wir mit der Vorbereitung zu Spielstart fertig. Warum machen wir das nicht erst wenn das Spiel gewonnen ist und die Gewinnmeldung angezeigt bzw. der Final freigeschaltet wird?
Auch das wäre möglich, allerdings müsste man sich dann merken, welche location ausgewählt wurde. So können wir sie als local definieren und damit den Speicher entlasten. Es sind zwar nur geringfügige Performanceentlastungen aber wir wollen ja auch, dass die Geschichte auf den Garmingeräten läuft.

Spielende

Es sind alle Schiffe versenkt, alle Minen entdeckt oder alle Station gelöst und es geht nun zum Final. Sprich das Hauptspiel ist gewonnen und es folgt die Belohnung.
Das ganze hab ich in endGame() gekapselt. outWithMedia kommt wieder aus der global.lua und PFinal ist der Identifer des Schatzkistenbildes.
In der Erfolgsmeldung hab ich jetzt die Koors nochmals eingebaut. Da die Finalzone bereits fertig ist, muss sie nur noch aktiviert und sichbar gemacht werden.
(Achtung ! Damit die neue Description auf allen Playern übernommen wird muss sie an der Zone aktualisiert / gesetzt werden bevor Active und Visible aktiviert werden.

Das war's. Nun hat der Naturfreund beim Wherigospielen die Möglichkeit mit einem zweiten Gerät oder einer Unterbrechung des Wherigos auf der Karte nachzuschauen welchen Feldweg er am Besten nimmt um zur Dose zu gelangen.

Globaler Code - Teil II

Voraussetzung: "Globaler Code - Teil I“
Nachdem ich den ersten Teil des globalen Code hier im Blog vorgestellt habe, wollte ich mal eben schnell den nächsten Beitrag schreiben wo es um Convenience-Angebote für den Spieler geht. U.a sollen die Finalkoordinaten lesbar ausgegeben werden.
Es dürfte so gut wie jeder WIG-Owner sich schon desöftern über das für uns ungewohnte Dezimalgrad-Format (z.B 50.6651666666667N 7.4682E) bei der Koordinatenverarbeitung in Urwigo geärgert haben.
Als Geocacher ist man ja eher das Grad, Dezimalminuten-Format (N 50° 39.910, E 7° 28.092) gewöhnt sein.
Und wenn man dann noch Koordinaten in lua als Waypoint direkt definiert (Wherigo.ZonePoint(50.6651666666667, 7.4682, 0)) ist die manuelle Hin- und Herrechnerei ziemlich aufwändig. In manchen Fällen ist es empfehlenswert die Koordinaten lesbar auf dem Display auszugeben, z.B. wenn der Final etwas kompliziert zu erreichen ist. Damit man neben dem Wherigo-ZonePoint keine extra String-Version der Koordinaten im Dezimalminuten-Format im Code zu pflegen hat, empfiehlt es sich das ganze automatisch umrechnen zu lassen. Kommt vorallem gut, wenn sich die Location ändert, oder ne neue Location hinzukommt.

Abbildung 1: Koordinaten- bzw. Debug-Pretty-Print

Abb.1 zeigt uns mit buildReadableCoorString eine Helfermethode die genau dies macht. Zunächst wird in Zeile 71 und 72 der Waypoint in den Breiten- und Längengrad aufgesplittet.
Beginnend mit der latitude also dem Breitengrad werden mit math.floor der Vorkommateil, also die Gradzahlen abgeschnitten und abgezogen vom ganzen der Nachkommateil gebildet. (Zeile 74. lat - tmp).
Die Umrechnung des Nachkommateil der Dezimalgrad in Minuten und Dezimalminuten habe ich ausgeglieder da es später beim Längenanteil der Koordinaten wiederverwendet werden kann.
Dabei wird in Zeile 81 der Nachkommaanteil mit 60 multipliziert und auf drei Stellen hinterm Komma gerundet. N 50° 39.9100023347 sähe nicht so gelungen aus. Als Ergebnis würde N 50° 39.91 herauskommen was auch nicht zu 100% korrekt aussieht. Es fehlt die abschießende 0.
Dies geschieht in Zeile 82 wo mit string.format("%.3f", val) auf 3 Stellen hinterm Komma (bzw. Punkt) mit Nullen aufgefüllt wird.
Bleibt noch die Runden-Funktion, die gibt es in lua nämlich nicht fertig. Jedenfalls nicht für Dezimalzahlen. Man kann eine Dezimalzahl auf den Ganzteil abrunden (2.88484 => 2) oder aufrunden (4.127 => 5). Um mathematisch Runden zu können bedient man sich eines Trickes, indem man mit + 0.5 die Rundungsgrenze auf die ganze Zahl verschiebt und dann abrundet.
Bsp.: 2,6 + 0,5 ergäbe 3,1; abgerundet mit math.floor ergibt 3. Gegenbeispiel 2,3 + 0,5 ergibt 2,8; abgerundet auf den Ganzzahlanteil ergibt 2.
mult = 10 ^ (idp or 0) ergibt 1000, da idp mit 3 (Nachkommastellen) übergeben wird. In der Schule haben ja gelernt: Multiplikation mit 10 hoch x heißt das Komma um x Stellen nach rechts verschieben. Aus 0,9100023347 wird dann 910,0023347; das ganze addiert um 0,5 => 910,5023347; auf Ganzzahlanteil abgerundet => 910; Zum Schluss wird das Komma wieder um drei Stellen nach links verschoben, d.h. Division durch 10 hoch 3 = 1000 - ergibt 0,91

Wem jetzt der Schädel wegen zu viel Mathe qualt, der sei beruhigt, das war's mit Mathe, nun kommt nur noch eine Abkürzung für's Debug-Logging.
Wie ich bereits in Einen Wherigo debuggen beschrieben habe, ist es oft ziemlich hilfreich mit print den aktuellen Stand von Variablen auf die Simulatorkonsole zu schreiben.
Da der Informatiker faul ist, ergibt sich die "Notwendigkeit" das mit p abzukürzen.
pt hingegen bringt uns jetzt noch echten Mehrwert, indem vor die Logzeile die aktuelle Uhrzeit geschrieben wird. So kann man leichter zusammenhängende Aktionen erkennen und sich besser durch die Von-Oben-Nach-Unten Syntax des Logfiles wühlen. Es gibt übrigens keine Genauigkeit auf den Millisekundenbereich. Die Sekunde ist die kleinste Zeiteinheit, die ihr im Wherigo messen könnt.
Die Zeilen 95 - 99 beschäftigen sich mit dem Problem, dass man in lua keinen String mit nil oder nem Boolean verknüpfen kann. So ist gesichert, dass in Zeile 101 nur Zahlen und Strings konkateniert werden.

global.lua - Helperfile für oft wiederkehrende Codestellen

Voraussetzung: "Der Einstieg in lua“
Es gibt so manche Aufgaben, die einem ziemlich oft bei der Programmierung begegnen, bzw. man denkt "Diesen Teil müsste man doch abkürzen" können.
So ist z.B die Ausgabe eines Textes mit oder ohne Bild eine recht komplexe Sache wenn man die MessageBox direkt in lua schreiben möchte.
Vorallem wenn nach dem Klick auf OK noch eine weitere Aktion folgen soll.

Auch das Ersetzen von Variablen in Strings (z.B. bei der Übersetzung deines Cartridges in verschiedene Sprachen ist eine Sache, die man nicht bei jedem neuen Wherigo neu schreiben möchte.

Abbildung 1: Einbinden des globales Codes

Zu diesem Zwecke habe ich mir angewöhnt eine global.lua Datei anzulegen, die ich im überordneten Ordner aller Wherigo liegen habe und die von jedem WIG-Projekt genutzt werden kann.
Ein Beispiel:

• Im Ordner C:\Wherigos liegt die Datei global.lua
• Im Ordner C:\Wherigo\MeinTestWherigo liegt dann die Projektdatei test.urwigo
• Im Ordner C:\Wherigo\MeinZweiterWherigo liegt dann entsprechend zweiterWIG.urwigo

Beide Cartridges, sowohl test.urwigo als auch zweiterWIG.urwigo verwenden global.lua aus dem übergeordneten Ordner

Abbildung 2: Auszug aus _cartridge.lua (enthalten im gwz Archiv)

Beim "Bauen" des cartrigdes bzw. beim Erstellen des gwz Archives spielt der Pfad dann keine Rolle mehr, da der Inhalt der externen lua-Datei in die _cartridge.lua hineinkopiert wird

Abbildung 3: Boolean als Text oder Zahl

Nun aber zu den Methoden an sich. Den Anfang machen die Boolean Werte. Dabei ist es mir für debug Zwecke oft hilfreich, wenn der Wert als Zahl oder String zurückgegeben wird, da eine Konkatenation in lua mit verschiedenen Datentypen Probleme bereitet.
"Raetsel 1 geloest: " .. myBoolVar führt zu einem Laufzeitfehler da hier string und boolean nicht miteinander verknüpft werden kann.
"Raetsel 1 geloest: " .. bts(myBoolVar) hingegen funktioniert, da nun zwei Strings verknüpft werden. Die Ausgabe lautet dann "Raetsel 1 geloest: true"
Dass getBoolAsString als bts (boolToString) abgekürzt ist bzw. dass es mal value und mal condition heißt ist historisch gewachsen. Kein guter Stil, wie ich zugeben muss, aber eine Methode umbenennen wird im nachhinein schwierig, da man auch alle Aufrufe der Methode in zahlreichen Wherigo-Projekten anpassen muss.
Also lieber gleich sinnvolle Namen verwenden.

Die dritte Methode wählt zufällig true bzw. false, abhängig von einer Wahrscheinlichkeit.
Bsp: Bei meinem Fußball-Wherigo Heimspiel soll die gegnerische Mannschaft nur in einem von drei Fällen ein Tor schießen.
getRandomBool(33) löst diese Aufgabe. math.random(100) liefert eine Ganzzahl zwischen 1 und 100, also 5, 41, 87 ...
Ist diese Zahl kleiner als unsere Vorgabe 33 wird true zurück geliefert, ansonsten false. Korrekterweise müsste es kleiner gleich heißen, da nicht von 0 bis 99 sondern von 1 bis 100 gezählt wird.

Abbildung 4: Ausgaben vereinfachen

Im zweiten Block geht es um die Ausgabe in Form von MessageBoxen. Da die ersten drei Methoden nur Convenience-Wrapper für die vierte sind, beginnen wir auch bei letzerer in Zeile 38.
Hier wird eine MessageBox aufgebaut, die mit dem übergebenen Text m und einem optionalen Bildchen med gefüllt wird.
Als Callback wird der Teil bezeichnet, der ausgeführt werden soll, wenn der Spieler auf OK gedrückt hat.
Hier wird es jetzt spannend. Lua unterstützt nämlich hier das Konstrukt einer "closure". D.h. es wird eine Methode cf definiert (Zeile 35), die erst dann ausgeführt wird, wenn der MessageBox danach zumute ist.
Woraus besteht aber die Methode cf? Zunächst hat sie einen Parameter action. Ist dieser Parameter null, so geschieht ... rein gar nix. Ich konnte diesen Fall noch nie beobachten. Wahrscheinlich ein Sicherheitscheck, falls man die MessageBox nicht mit "OK", sondern mit dem Back-Button des Smartphones verlässt.
Ruft hingegen die MessageBox die Methode cf(anAction) mit einem Not-Null-Parameter auf, so wird die zweite innere Methode fun (wieder eine closure) ausgeführt.
Was aber ist denn fun ? fun wird von außen definiert, z.B. in Zeile 29, wo der Befehl "Zeige Mainscreen" übergeben wird. Auch hier gilt, in Zeile 29 wird Wherigo.ShowScreen(Wherigo.MAINSCREEN) nur definiert, aber noch nicht ausgeführt. Dies passiert erst, wenn der Spieler in der MessageBox (z.B. "Gehe nun zum Final") auf "OK" drückt.
Achtung: Vergesst nicht bei der Definition der Methode die Schlüsselwörter function() und end. Ansonsten habt ihr keine closure definiert, sondern es wird direkt der Mainscreen angezeigt!
Jetzt wird sich der gewiefte Leser/Entwickler denken "Wozu brauche ich den action Parameter?". Dieser dient theoretisch dazu weitere Informationen an die aufrufende Methode zu übergeben. Man könnte ne Zahl oder einen String reinschreiben. Trotz längerer Studie des von Urwigo kompilierten Codes konnte ich aber stets nur den action ~= nil Vergleich finden.
Man kann allerdings einer MessageBox mehrere Buttons geben und damit einen Quasi-Input generieren. Über action (enthält "Button1" bzw. "Button2") kann man dann unterscheiden welcher Button gedrückt wurde. Ein sinnvolles Szenario wäre "Du bist an der Zone Goldbergwerk angekommen. Die bereits abgebauten Goldklumpen wandern hiermit in dein Inventar", Button1 = "OK", Button2 = "Nachricht zukünftig nicht mehr anzeigen"

Abbildung 5: Debug-Ausgaben, Wegpunkt-Mittelung und String-Operationen

Nun aber genug der komplexen closure-Theorie. Zum Abschluss etwas leichtere Kost.
calcCenterZonePoint liefert euch die GPS-Koordinate, die genau zwischen point1 und point2 liegt. Ist ganz praktisch um die Hälfte der Laufstrecke oder den Mittelpunkt eines Fußballfeldes zu bestimmen.
printTable gibt beim debuggen den Wert einer Tabelle aus. Da jedes "Objekt" in lua als Tabelle definiert ist, kann das schon mal ganz hilfreich sein.
Die Werte einer Zone (Name, Koors, ob aktiv oder nicht...) sind ebenfalls als Tabelle gespeichert und können über getmetatable() abgerufen werden. Als Ergebnis seht ihr beim Debuggen alle Infos über eure Zone.

Zum Schluss noch ein Beispiel für Substitution. Hier wird in einem String "Gehe zur Zone #1# und warte", "Schmiede" der Wert "Gehe zur Zone Schmiede und warte" gebildet. Hilfreich bei Mehrsprachigkeit eures Wherigos.

MEGA Switzerland, wir kommen

MEGA Switzerland, wir kommen !!!

Nachdem es gestern abend noch Anflüge von Panik gab, da das seit November gebuchte Ticket nicht ausgedruckt und die Mail auf dem Rechner mit abgerauchtem Mainboard lag, kam heute morgen die frohe Botschaft: Ein Kopie der eMail mit allen Anmeldedaten und Bestellbestätigung.
Da kann ich nur sagen, tolle Orga.
So geht es in 40 Minuten los Richtung Eidgenossen. Und ein Cachopoly liegt nur wenige Kilometer entfernt....

Sprachausgaben übersetzten ohne vararg Parameter

Voraussetzung: "I18n - Einen Wherigo in verschiedenen Sprachen anbieten“

Abbildung 1: Die Übersetzungen mit mehreren Parametern ohne varargs

Im vergangenen Tutorial bzgl. der Übersetzung habe ich den vararg Parameter ... eingesetzt.
Es scheint aber so, dass manche WhereYouGo bzw. PiGo Player Version Probleme mit diesem Konstrukt haben.

Um dem vorzubeugen möchte ich euch folgende Lsg vorstellen, die mir schnuefelis als funktionstüchtig beschrieben hat.

Der Trick ist recht einfach. Anstatt mit ... eine unbestimmte Anzahl an Parameter zu definieren, baut ihr einfach mehrere Methoden, die einen, zwei, oder drei "replacements" akzeptieren.

Um nicht unnötig Code zu duplizieren, rufen diese Methoden alle die 4-Parameter Version auf, in der dann geprüft wird ob replacement1, 2 oder 3 nil sind und nur dann die Ersetzung starten.

Als Softwarentwickler tut eine solche Lösung zwar schon ein bißchen weh, aber bei der Vielzahl der Player mit all ihren Schwächen muss die Dynamik zugunsten der Stabilität leiden.

"13 Monate ist auch genug"

Heute mal nen ganz kurzer spontaner Beitrag:
Inspiriert durch die erste Notification des Tages
"[GEO] Notify: XXX archived YYY (Traditional Cache)", der Owner archiviert seinen eigenen Cache:

"Log Date: 3/20/2014 Der ist so oft weg, und 13 Monate ist auch genug. Mache wieder Platz für andere..."

Fand ich sehr interessant und brachte mich zum Schmunzeln.
"13 Monate ist auch genug".
Es soll keine Ketzerei gegen den Log oder den Owner sein, nein es zeigte mir einfach wie sich unser Hobby entwickelt hat. Schnell nen Tradi abgelegt, länger als nen Jahr muss er eh nicht halten. Da ich den Owner kenne, glaube ich zwar nicht, dass bei diesem Cache eine solche Überlegung ne Rolle gespielt hat, ich kenne aber genügend andere wo man bei der Publish Notification den Eindruck hat, dass die Dose bewußt so schnell und einfach gelegt hat, dass man gar nicht vor hat den Cache lange aufrecht zu halten.

Ich hoffe ich konnte den Schmunzelfaktor am Morgen an euch weitertragen.

Hier gibt es nix zu sehen

Wirklich, hier gibt es nix zu sehen:
http://muah.info

Grill & Kick Wherigo Event

Was haben Grillen und Kicken gemeinsam? Richtig, ab und zu muss man ganz schnell laufen. Man kann die beiden Freizeitbeschäftigungen aber anders verbinden:

Grill & Kick GC4ZTEV am Sonntag, 27. April 2014

Laufe auf einem echten Rasenplatz um einen virtuellen Ball in ein echtes Tor zu schießen und spiele dabei gegen virtuelle Gegner wie z.B. die deutsche Nationalmannschaft

Neugierig? Dann schau dir das Listing an, pack Grillfleisch und den Wherigo-Player ein

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.

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)