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.