Wettrennen fair
Eine leichte Abwandelung des normalen Wettrennens.
Bewegt ein Cacher einen Trackable mehrmals, werden lediglich die km des ersten Logs dieses Cacher berücksichtigt.
Damit wird verhindert, dass ein Cacher einen Trackable ständig in Caches ein/ausloggt, ihn nicht weiter gibt und ihm so viele km beschert.
Ansonsten gelten die Regeln des normalen Wettrennens.

Weitsprung
Auch das ist eine Abwandelung des normalen Wettrennens.
Bewegt ein Cacher einen Trackable mehrmals, wird lediglich das Log mit der größten km Bewegung berücksichtigt – “der weiteste Sprung”.

Eine Beschreibung aller verfügbaren Renntypen findet Ihr hier.

Dickes Dankeschön an das Team ‘WantedDeadOrAlive‘ für Support und das Testen.

Bei Fragen oder Problemen mit den neuen Rennen bitte wie immer Feedback in die Kommentare oder an webmaster@tb-run.com.

Aber was soll ich sagen… eigentlich läuft auch so alles!

Ich habe das Gefühl, dass 90% der Fälle von „mein TB will nicht weiter“ mit tb-rescue abgedeckt sind.
Der Service scheint etabliert und alles läuft weitestgehend stabil.
Täglich gibt es neue Rettungsaufträge, der Server verschickt mehrere tausend Mails pro Tag an potentielle Retter in den „betroffenen Gebieten“ und ich glaube die westliche cachende Welt ist zum Großteil abgedeckt  – siehe Karte.
Groundspeak sorgt mit der Bannerwerbung auf gc.com für einen konstanten Strom neuer Interessenten – die Anzahl der registrierten User hat inzwischen die 8000 übertroffen.

Was gibt es also noch zu tun?

Nun, da wären erst einmal die Punkte, die am meisten von Euch gewünscht wurden:

• Mehrere Gebiete beobachten können
• Nette Statistiken über Eure Rennen

• Und dann die Sache, dass tb-rescue mit manchen Abläufen nicht so ganz klar kommt
  z.B. wenn ein TB Owner seinen TB nicht als vermisst markiert, obwohl ihm der Verlust von einem Retter „bescheinigt“ wurde (sigh! Schande!).
  In diesem Fall bekommt der Retter keine Punkte und die Rettungsaktion bleibt ewig offen.

Achso:„most Wanted“ ist immer noch das Einstellen von Rettungsaufträgen von TB’s die ein CACHER nicht rausrückt .

Wir bekomme zwar oft nette Ideen von Euch, wie z.B. das Konzept mit freiwilligen „RescueMans“ –lokale Cachergrößen, die viele Andere kennen und so auf Stammtischen Einfluss auf die Herausgabe nehmen könnten. Sind wirklich kreative Ideen dabei – Danke dafür, aber: nein!  Das wird es auf absehbare Zeit nicht geben.
Bitte lest dazu auch “TB retten, der bei einem Geocacher fest hängt“.

Vielleicht bauen wir mal irgendwann eine Funktion, bei dem man über tb-rescue dem Halter eines TBs eine nette Grußkarte schicken kann, und so versuchen kann die Herausgabe zu beeinflussen.  Aber ein „Russisch Inkasso für TBs“ wird es hier nicht geben .

Ja…. Ansonsten….bei tb-run.com sieht es sogar noch ein Stückchen besser aus: Eigentlich funktioniert alles.
Mittlerweile gibt es  über 500 Rennen mit 3800 Trackables.

Sogar Groundspeak liefert konstant korrekte „zurückgelegte  Entfernungen“ von Trackables.

Den Plan, noch viele verschiedene Arten von Rennen zu programmieren habe ich mittelerweise erstmal gaaaaaanz tief in die Schublade gelegt.
Der Aufwand steht in kaum einem Verhältnis zum Nutzen.
Offensichtlich seid Ihr mit den angebotenen Renntypen auch nahezu zufrieden.
Bei tb-run sind es eher die kleinen Dinge, die mich nerven, wie z.B. hässliche Formulare beim Anlegen eines neuen Rennens.

Aber wenn wir realistisch planen, werden wir in den nächsten Monaten auch kaum Zeit haben hier viel bewegen zu können.
Es gibt einfach zu viele andere Projekte, die auf absehbare Zeit eine höhere Priorität haben (sollen).

Stillstand herrscht nicht… iss halt einfach nur aufgeschoben…

In diesem Sinne, Eurer Sascha
(sitze grad im Flugzeug und hab ein bischen Zeit, die Gedanken schweifen zu lassen….)

Die Site bleibt während des Umzugs voll funktionsfähig (zumindest hoffen wir das :–) )

Lediglich die URL, die Ihr im Browser erscheint sieht etwas anders aus und endet auf “……..trackable.de”
Auch alle Links sollten intakt bleiben.
Sowie dann der Umzug komplett ist, wird auch die Domain trackable.de wieder verschwinden.

Wenn Euch Probleme auffallen, gern in die Kommentare oder direkt per Mail an webmaster@tb-run.com.

Wir haben daraufhin mit Groundspeak gesprochen und das offizielle OK zum Verlinken bekommen.
Die Reviewer sollen lt. Groundspeak auch darüber informiert werden, so daß es in Zukunft keine Probleme damit geben sollte.

Falls doch, sprecht uns gern an.

Bisher wurden die TB Bilder von gc.com genau einmal aktualisiert.. und dann nie wieder.
Mit dem neuen “Aktualisieren” Button könnt Ihr nun ein Update anfordern falls sich Euer TB Bild geändert hat.
Die Aktualisierung erfolgt dann beim nächste, nächtlichen Update Lauf.

Jaja.. ich weiß manch Einer würde so etwas einen Bug nennen aber wir können (bzw. wollen) halt nicht beliebig viel Last bei Groundspeak erzeugen.
Und wenn wir das Ganze automatisieren wollten, müssten wir jeden Tag alle ~3000 TB Bilder neu lesen um zu schauen, ob sie sich geändert haben.

Da das dann für gc.com wohl etwas viel wird, haben wir diese Lösung gebaut.
Wirklich nix weltbewegendes aber ein Schritt von Beta Richtung Version 1.0 .

Übrigens: Wenn bisher noch kein TB Default Bild auf gc.com hattet und eins anlegt, wird tb-run das auf jeden Falle erkennen. Aber halt nur einmalig. Wenn sich das Bild mal ändert müsst ihr den neuen Knopf in der TB Liste auf tb-run drücken.

Nach dem letzten Update auf gc.com soll lt. Release Notes der km Bug behoben sein.

So wie es aussieht weist gc.com nun wieder alle km hinter den einzelnen Logs korrekt aus.Wenn Ihr noch Fälle findet, bei denen das nicht der Fall ist mach bitte ersteinmal ein “Recalculate Distance” und wenn das nicht hilft schickt uns bitte Eure TB-Code (nicht die geheimen ) .

Wir werfen jetzt den update der Daten an und rechnen damit das spätestens Freitag morgen (2.Juli) alle Rennen aktuell sind.

———-

Hallo zusammen,

seit dem letzten Update von geocaching.com Anfang Juni bekommen wir recht viele “Reklamationen” von Euch, warum tb-run.com die km Eurer TBs falsch anzeigt.

Hier die kurze Antwort:
Aufgrund eines Bugs auf geocaching.com fehlen bei der Berechnung auf tb-run.com manchmal km einzelner logs. Meistens handelt es sich dabei um das jeweils LETZTE Log.
Kommt ein neues “placed” log hinzu, dann sollte das vorherige dazugerechnet werden. Das neue (nun das letzte log) dann nicht.

Im Detail:

tb-run.com verwendet nicht einfach nur die gesamten zurückgelegten km die gc.com angibt. Diese ist oft falsch und ausserdem enthält diese Summe ALLE km, die der TB bisher zurückgelegt hat.

Da wir aber nur die km nehmen müssen, die während des Rennens (also von Datum Start bis Datum Ende) zurückgelegt wurden, ist diese Zahl für uns nicht zu verwenden.
Aus diesem Grund sammeln wir die km ein, die hinter jedem “placed” log stehen und addieren sie. Der folgende Screenshot zeigt ein Beispiel:

Und genau hier kommt jetzt ein Bug auf geocaching.com zum Tragen.
Aus irgendwelchen Gründen fehlen nämlich bei der Anzeige einiger TBs auf gc.com die km des letzten “placed” Logs. (machmal leider auch mehr als nur das letzte).
gc.com rechnet das zwar in der Summe dazu und auch in der Google Maps Ansicht  (“View Map”) sind die km alle vorhanden.

Auf der TB Seite, die tb-run.com verwendet fehlen sie jedoch – siehe Screenshot:

Nach unserer Erfahrung hilft hier auch kein “Recalculate Distance”.

Aber:

Sobald ein neuer “placed” Log dazu kommt, erscheinen dann die km des nun vorletzten “placed” logs. Es fehlen dann wiederum die des nun letzten Logs (usw.)

Wir haben Groundspeak bereits über diesen Bug informiert und sie wollen sich darum kümmern das gc.com die Logs wieder korrekt anzeigt.
Bis dahin müssen wir allerdings mit diesem Problem leben.

Wenn Ihr ansonsten noch Tips habt oder Beobachtungen dazu gemacht habt, hinterlasst uns das gern in den Kommentaren zu diesem Beitrag.

tb-rescue: auch TBs in archivierten Caches erscheinen nun auf der Landkarte.

tb-run: Die Berechnung der zurückgelegten km sollte wieder vollständig funktionieren, obowhl es immer noch einen bug auf gc.com gibt (wir arbeiten da jetzt herum ). Beim nächsten update Eures TBs (neues Log) bekommen wir die aktuellen Werte.

wir hatten in den letzten Wochen echt ne Menge Stress mit tb-run und tb-rescue und da einige von Euch gefragt haben, war los war kommen hier die Details.

Vor ca. 3 Wochen hat Geocaching.com seine Seiten mal wieder geändert – Neue Layouts, Änderungen im HTML Code usw. eigentlich nichts Wildes.
Aber seit dieser Änderung gibt es die gc.com Funktion “Zeig mir alle Logs eines TBs” nicht mehr. Genau das war bisher die Grundlage für uns, um an die TB Daten zu kommen. *sigh*
Wir mussten also erst mal wieder diverses Umbauen bis es einigermaßen funktioniert hat.

Dann hat Groundspeak dieses tolle neu “throttling” System eingeführt. Wenn man mehr als 200-500 request pro …. keine Ahnung….. Stunde oder so….. absetzt, bekommt man eine Captcha-Seite in der man beweisen muss, dass man ein Mensch und kein Spider ist…… nun ja wir sind halt im Prinzip ein Spider.
Außerdem sorgt die fehlende “all Logs” Seite dafür, dass wir statt 1500 Requests nun täglich bis zu 30.000 für einen kompletten Abgleich absetzen müssen. Also Doppelt gemein!

Also haben wir Groundspeak kontaktiert. Die haben sich innerhalb weniger Stunden gemeldet uns versprochen und zu helfen. Tatsächlich haben sie kurze Zeit später einen Hotfix eingespielt der für uns das Lesen der TB Daten erlauben sollte.

Leider hat das erst einmal nicht funktioniert.

Die nächsten Tage haben wir auf unserer Seite täglich neue Einstellungen ausprobiert – aber immer wieder wurden wir geblockt. Also täglich neue Mails an Groundspeak. Von dort kam dann jeweils innerhalb weniger Stunden Rückmeldung mit neuen Konfigurationsvorschläge usw. Ein heiteres hin-und her… So richtig gebracht hat es aber erst einmal nicht.

Als letzten Freitag immer noch keine kompletter Datentransfer gelaufen war, haben wir uns auf Angebot eines Groundspeak Vice Presidents per Skype mit dem Webadmin Team zusammengeschaltet und gemeinsam die Kommunikation debugged. Nach Über einer Stunde wirklich ausgezeichneter Zusammenarbeit hatten wir den Fehler gefunden (es lag der Konfiguration von tb-run und tb-rescue – argh!).

Wir haben dann gestern einen kompletten Datentransfer erfolgreich abgeschlossen. Jetzt sollte wieder alles einwandfrei funktionieren.

Dickes Dankeschön und Lob an Groundspeak. Wir haben wirklich vorbildliche Unterstützung bekommen. 

Einziges Problem derzeit ist noch ein kleiner Bug auf gc.com: Die km des letzten Logs zeigt gc.com nicht an. Daher fehlen diese km bei tb-run.
Groundspeak hat den Bug bereits gefunden und er soll mit der nächsten Version repariert werden. Außerdem haben wir zur Sicherheit alle TBs temporär etwas limitiert, die mehr als 500 Logs haben (ein paar Experten haben TBs mit 4000 Logs und der Update für diese TBs allein dauert ne Stunde). Das wird aber auch bald wieder gehen.

Solltet Ihr noch Probleme feststellen so “freuen” wir uns über Euer Feedback

Liebe Grüße,
Sascha

Und die Daten sind nur so gut wie das, was geocaching.com und liefert. So werden hin und wieder die zurückgelegten km nicht korrekt berechnet. Maßgeblich ist übrigens für tb-run nicht die Gesamtsumme der km sondern die km,  die hinter den einzelnen Logs erscheinen. Und genau da vergiss gc.com ab und an die Anzeige.

Abhilfe schafft in 99% der Fälle ein “Recalculate Distance”. Wie geht das:

1. Ruft die Info Seite Eures TBs auf, z.B. http://www.geocaching.com/track/details.aspx?tracker=TBABCDE
2. Wählt aus dem drop-down Menü auf der rechten Seite welches “Mark Item Missing” zeigt, den Eintrag “Recalculate Distance” (siehe Bild)
   
3. Klickt auf den “Go” Button daneben
4. Jetzt dauert es zwischen 1 und 10 Minuten und geocaching.com sollte die zurückgelegte Entfernung neu berechnen
5. tb-run.com aktualisiert die Rennlisten 1x täglich von geocaching.com. Nach der nächsten Aktualisierung werden dann alle vorhandenen km gewertet.

Es sollte eigentlich wieder alles funktionieren und ab morgen früh auch aktuell sein.
Einzig das Einstellen neuer Rettungsaufträge auf tb-rescue.com dauert nun etwas länger als vorher (5-30 Sekunden statt 1-2 Sekunden), da wir nach den Änderungen bei Groundspeak mehr Daten lesen müssen.
Hier müssen wir demnächst nochmal ran und das Ganze optimieren.