-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Cachewolf 1.0 Release Candidate 1 erschienen
- Ersteller MiK
- Erstellt am
Wenn Zähler Teil der Cachebeschreibung sind, dann werden diese vom Spider wie Bilder behandelt und es wird ein "Bild" mit der Endung "pl?" angelegt, daß dann vom Cachewolf nicht dargestellt werden kann und eine entsprechende Fehlermeldung auslöst.
Bsp: GC1BX3J
Da diese Zähler für die Beschreibung keine Bedeutung haben, wäre es gut, wenn erst gar keine Bilddateien für Zähler angelegt würden. Ich nehme an, man könnte sie am "pl?" erkennen.
Bsp: GC1BX3J
Da diese Zähler für die Beschreibung keine Bedeutung haben, wäre es gut, wenn erst gar keine Bilddateien für Zähler angelegt würden. Ich nehme an, man könnte sie am "pl?" erkennen.
pfeffer
Geowizard
hmm - ich denke, man kann nicht zuverlässig erkennen, ob es ein Zähler ist, obwohl Du in 90% der Fälle sicher recht hast.
Es ist ein Bug im spider, dass er nicht den richtigen Dateinamen erzeugt,
Die Leute, die den Spider programmieren, können mal beim OC download gucken, wie das richtig gemacht werden muss (http-redirect-Dateinamen übernehmen) - das habe ich schon mal geschrieben.
Vielleicht kümmert sich diesmal jemand drum.
Griß,
Pfeffer.
Es ist ein Bug im spider, dass er nicht den richtigen Dateinamen erzeugt,
Die Leute, die den Spider programmieren, können mal beim OC download gucken, wie das richtig gemacht werden muss (http-redirect-Dateinamen übernehmen) - das habe ich schon mal geschrieben.
Vielleicht kümmert sich diesmal jemand drum.
Griß,
Pfeffer.
OP
MiK
Geoguru
SKG hat jetzt eingebaut, dass nur direkt verlinkte Bilder geladen werden. Ist das unsere Lösung für 1.0 oder bauen wir stattdessen noch die Namensauflösung wie bei OC ein? So kompliziert wird das nicht sein. Allerdings müsste ich mich da erst noch genauer einlesen.pfeffer schrieb:
salzkammergut
Geomaster
Hallo Mik,
Mir ist noch nicht ganz klar wo das Problem des redirect liegen soll. Z.B. läßt sich der Cache GCTARB, der seine Bilder umleitet, problemlos laden. Das erste Bild hat die Url "http://gctarb.de.tt/images/01.gif" und wird auf "http://geocaching.msdomain.de/gentleman/gctarb//images/01.gif" umgeleitet. Damit hat CW keine Probleme.
skg
Mir ist noch nicht ganz klar wo das Problem des redirect liegen soll. Z.B. läßt sich der Cache GCTARB, der seine Bilder umleitet, problemlos laden. Das erste Bild hat die Url "http://gctarb.de.tt/images/01.gif" und wird auf "http://geocaching.msdomain.de/gentleman/gctarb//images/01.gif" umgeleitet. Damit hat CW keine Probleme.
skg
OP
MiK
Geoguru
Es geht darum, wenn der Link nicht auf ein Bild zeigt, sondern erst mal auf eine serverseitiges Skript, dass dann das Bild liefert. Wie eben bei einem Counter. Das könnte ja aber auch ein normales Bild sein. Ich weiß aber gar nicht, ob wir in diesem Fall wirklich mit dem OC-Code an den wirklichen Dateinamen kommen würden. Ich zweifle mittlerweile daran.
salzkammergut
Geomaster
OK jetzt habe ich's kapiert. 
Nur: Wie oft kommt das wirklich vor? Das ist sicher extrem selten. Gibt es dazu Beispiele, damit ich das mal testen kann?
skg
Nur: Wie oft kommt das wirklich vor? Das ist sicher extrem selten. Gibt es dazu Beispiele, damit ich das mal testen kann?skg
OP
MiK
Geoguru
Das Problem ist natürlich auch, dass man später beim Einsetzen wieder erkennen muss, dass es ein Bild war, dass heruntergeladen wurde.
Wenn ich das richtig sehe, bauen wir die Bilder ja auch einfach in der Reihenfolge ein, wie wir sie geladen haben, ohne, dass wir uns eine Beziehung zwischen dem Link in der Beschreibung und dem gespeicherten Bild merken, richtig?
Wenn ich das richtig sehe, bauen wir die Bilder ja auch einfach in der Reihenfolge ein, wie wir sie geladen haben, ohne, dass wir uns eine Beziehung zwischen dem Link in der Beschreibung und dem gespeicherten Bild merken, richtig?
salzkammergut
Geomaster
Ja, Du hast recht. Wir machen es einfach über die Reihenfolge. Der Code, der die HTML-Beschreibung nach Bildern analysiert, existiert derzeit dreifach in sehr ähnlicher Form: Im Spider, im DescriptionPanel und in ShowCacheInBrowser. Das sollte künftig nur mehr einmal vorkommen.
Zurück zu den über Scripts umgeleiteten Bildern: Das ist normalerweise nur für Counter üblich - die interessieren uns aber nicht. Die Frage ist: Für wie viele Caches wird über Skripte ein echtes Bild geladen, das für den Cache relevant ist. Ich glaube dass das ganz selten ist und würde das Thema daher als erledigt sehen. Ausser jemand kann durch einige Beispiele zeigen, dass das doch noch für die Rev. 1.0 eingebaut werden sollte.
salzkammergut
Zurück zu den über Scripts umgeleiteten Bildern: Das ist normalerweise nur für Counter üblich - die interessieren uns aber nicht. Die Frage ist: Für wie viele Caches wird über Skripte ein echtes Bild geladen, das für den Cache relevant ist. Ich glaube dass das ganz selten ist und würde das Thema daher als erledigt sehen. Ausser jemand kann durch einige Beispiele zeigen, dass das doch noch für die Rev. 1.0 eingebaut werden sollte.
salzkammergut
SurfaceCleanerZ
Geocacher
Hi,
Ich hab jetzt endlich rausgefunden, warum meine Kartendownloads zwar vorhanden waren und am PC gingen, aber auf dem PDA nicht: In der pref.xml hatte er mich beim 1. Start der PC Version zwar gefragt nach dem Speicherort für das Profil, da er c: nicht finden konnte, aber der Kartenpfad war auch falsch. Und bei den späteren Versuchen kam zwar immer, dass er die Karten nicht finden konnte (3x übrigens, jeweils zum Bestätigen, das dürfte auch ein Bug sein) und dann hat er die leere nicht referenzierte Karte genommen. Nun hab ich in der pref.xml den richtigen Pfad eingestellt und es klappt!
Etwas Anderes: Eine Funktion zum Abgleich der Daten auf dem PDa durch die Win Version wäre noch cool. Also dass man die statisch verlinkte X86 Version auf dem PC startet und dann ihr sagt,sie soll den am USB hängenden eingeschalteten PDA über Active Sync updaten (also das Profil auf dem PDA durch das des PC ersetzen (Ordner mit Profilnamen und den maps-Ordner). So würde man sich das lästige, da extrem langsame Ersetzen aller schon vorhandenen Dateien auf dem PDA über AS sparen. Da die meisten PDAs ja nur USB1.1 geschwindigkeitsmäßig unterstützen. robocopy funktioniert ja leider nicht dafür, da es nicht auf den PDA zugreifen kann. Das Synctoy soll gehen. Das könnte mann dann ja dafür nutzen.
So dauert ein Abgleich immer sehr lange....
(Win Mobile 5 und 6 können ja NICHT MEHR über WLAN syncen, 2003 konnte das noch).
mfG,
Stefan
Ich hab jetzt endlich rausgefunden, warum meine Kartendownloads zwar vorhanden waren und am PC gingen, aber auf dem PDA nicht: In der pref.xml hatte er mich beim 1. Start der PC Version zwar gefragt nach dem Speicherort für das Profil, da er c: nicht finden konnte, aber der Kartenpfad war auch falsch. Und bei den späteren Versuchen kam zwar immer, dass er die Karten nicht finden konnte (3x übrigens, jeweils zum Bestätigen, das dürfte auch ein Bug sein) und dann hat er die leere nicht referenzierte Karte genommen. Nun hab ich in der pref.xml den richtigen Pfad eingestellt und es klappt!
Etwas Anderes: Eine Funktion zum Abgleich der Daten auf dem PDa durch die Win Version wäre noch cool. Also dass man die statisch verlinkte X86 Version auf dem PC startet und dann ihr sagt,sie soll den am USB hängenden eingeschalteten PDA über Active Sync updaten (also das Profil auf dem PDA durch das des PC ersetzen (Ordner mit Profilnamen und den maps-Ordner). So würde man sich das lästige, da extrem langsame Ersetzen aller schon vorhandenen Dateien auf dem PDA über AS sparen. Da die meisten PDAs ja nur USB1.1 geschwindigkeitsmäßig unterstützen. robocopy funktioniert ja leider nicht dafür, da es nicht auf den PDA zugreifen kann. Das Synctoy soll gehen. Das könnte mann dann ja dafür nutzen.
So dauert ein Abgleich immer sehr lange....
(Win Mobile 5 und 6 können ja NICHT MEHR über WLAN syncen, 2003 konnte das noch).
mfG,
Stefan