Možná je to trochu varování - nezanedbávat domácí přípravu.
Na jedné multicachi jsme s kolegou s použitím Pocket Query posbírali všechny indicie a dospěli k závěrečnému výpočtu. Za pomoci už známých A, B, C, D, E a F bylo třeba vypočítat zbývající takhle:
G=B+FH=F+AI=B-EK=E+F+A
Počítali jsme, že se z nás nekouřilo jen kvůli té nechutné zimě, pořád nám to nevycházelo, pak už jsme začali pochybovat o již získaných indiciích, pak jsem vzteky zlomil tužku a schlíple a zmrzle jsme odešli. Doma jsem nahlédl do zadání na internetu a vida:
G=B+F
H=F+A
I=B-E
K=E+F+A
Co z toho plyne? Listing cache přenesený do GPS šetří místem a někdy se to trochu nepovede.
Neni to spis zaludnost oregonu/colorada?
Určitě, ale s používáním PQ to souvisí.
Jasne, co to bylo za kes? Kouknu jak se me listing zobrazuje v GSAKu…
Augustusburg (GCKDAV)
Zkusil jsem, jak to vypadá na WAPu a v HandyGC:
G = B + F H = F + A I = B - E K = E + F + A
Prostě konce řádků nahradí jen mezerami a v tvém případě tam nejsou ani ty mezery. Autor listingu nepočítal před těmi 4 lety s nějakým bezpapírovým odlovem. Napiš mu a požádej ho o změnu. Pomůžeš tím dalším hledačům.
Z mozigo do gpx ide toto
[i]<p>Jetzt rechnen wir ein wenig.
</p>
<p>G = B + F
<br />
H = F + A
<br />
I = B - E
<br />
K = E + F + A
</p>
<p>Daraus ergeben sich ganz zwanglos die Zielkoordinaten:
</p>
[/i]
Ak to pozriem v browseri tak je to toto
[i]Jetzt rechnen wir ein wenig.
G = B + F
H = F + A
I = B - E
K = E + F + A
Daraus ergeben sich ganz zwanglos die Zielkoordinaten: [/i]
Ale co s tym urobi colorado neviem, zial nemam ho, takze to ani neviem odskusat…
Hm, tu sa html kod vzdy interpretuje aj ked pouzijem code…