Lovci a autoři challengí asi povětšinou o možnosti mít ověřovač ke konkrétní challengi ví. Ale i tak bych rád uvedl několik informací, které by se sem tam někomu mohly hodit. (často na ně odpovídám individuálně)
1) co je challenge cache? - na to zná odpověď geowiki
2) co je to ověřovač (checker)? - v tomto případě je tím myšlen nástroj, který poskytuje web project-gc.com. Tento nástroj vám ověří, že splňujete podmínky pro tu kterou konkrétní challenge. Seznam ověřovátek je zde: project-gc.com/Tools/Challenges
3) jak získat pro svoji (a nebo i cizí) challenge ověřovač? - zde se konečně dostávám k tomu hlavnímu, proč to sem píšu. Teoreticky si ho můžete vytvořit sami, ale jak se k tomu dostat vám neporadím. U mě to bylo tak, že jsem několikrát psal autorovi celého project-gc, že bych rád ověřovač pro svoji challenge, až mi jednoho dne poslal informace jak si ho udělat sám, udělil mi na to práva a bylo. Zatím stále nemám problém udělat ověřovač i pro druhé, takže nejlepší cesta je mi napsat. Jestli jsou přijímáni noví tvůrci a hlavně jak, vůbec netuším. V mě dostupných informacích o tom nic není.
4) co to všechno umí? - umí to hodně, ale ne všechno. Na webu existují dva druhy ověřovačů:
- Jedny jsou psány v PHP a jejich možnosti jsou téměř neomezené, včetně výběru toho, co je potřeba abych podmínky splnil. Umí pracovat s mapami. Bohužel takový ověřovač může připravit jen ganja1447 (aspoň co je mi známo). Takže je potřeba aby na tom měl on sám zájem, jinak ho asi nemá cenu s tímto otravovat, protože má dost starostí s tvorbou samotného webu. Ukázkou takovéhoto ověřovače je např. Challenge - 360 Degrees of Prague. Vzhled ověřovače je trochu jiný než toho zbytku:
- druhým typem je to co můžu programovat já a další dobrovolní tvůrci. Programuje se v jazyce LUA. Data pro zpracování se získávají prostřednictvím vlastního API několika málo způsoby a rozhodně zde nelze připravit ověřovač pro jakoukoli Challenge. Např. zde není možnost pracovat s trasanty. Do nedávna nešlo ani se suvenýry. API příkazy zde. Ověřovátko pak vypadá takto:
U LUA ověřovátek je důležité poznamenat, že jsou pevně svázána s konkrétními kešemi. Pokud jde o challenge sérii s rostoucí podmínkou, tak je možné mít jeden ověřovač a jenom v něm upravovat tu podmínku pomocí parametru (což se navenek projeví tím, že mají společný tučný název, např. Brdy Challenge).
Drobný problém je pak u nepublikovaných keší, protože já jako autor u ověřovače zadám jeho název a pak vložím GC kód keše (můžu teda ještě ty parametry, ty jsou na venek skryté) a název keše a stát si už project-gc vezme sám z vlastní databáze, což u nepublikované keše nejde. Takový ověřovač pak není v seznamu u konkrétního státu. Obvykle se tyto údaje doplní do jednoho dne od publikace, project-gc totiž není dílem Groundspeaku, ale získává data pomocí API Live, tak jako spousta programů třetích stran. Osobně si teda myslím, že by se měl ověřovač dělat až po publikaci a "padnutí bedny", tedy po ulovení FTF, STF a TTF, ať mají všichni stejné podmínky. Ne každý totiž musí být s project-gc kamarád, ale technicky to řešitelné je, byť polovičatě.
Tolik tedy informace co jsem měl potřebu sdělit ostatním. Pokud někoho napadne nějaký dotaz, klidně piště, když budu vědět, tak odpovím. Těm co dočetli až sem děkuji a snad jim to bylo v něčem přínosné.
PS: banýrek v úvodu používám u své challenge pro odkaz na ověřovač, pokud chcete, tak jej libovolně šiřte dál, oficiální přímo od project-gc není.
Ale zrovna moje vlastní challenge má z pohledu ověření podmínky dost složité a zvládá ověřit i takového werga, který se svými 30tis. nálezy "sežere" opravdu hodně paměti. 
GeoGet
URWIGO
CWG
Ještěrka zdarma
Významné stromy
publish
