Co jsou kontrolní součty a validační kódy ?
J.C.Spooner 2002 ( česká verze - Jerry 2008 )

Úvod
Na této stránce je popsáno jak fungují kontrolní a validační kódy, je to nejjednodušší systém na světě a velmi efektivní. Problémy s kontrolnímy a validačními kódy nastávají při různých verzích revírů a při přepisování a měnění souborů. Vysvětlení níže Vám nedá žádné přesné informace, což by byla hloupost, ale teoreticky popíše jak tyto kódy fungují a jak se přibližně počítají, aktuální výpočty jsou trochu jiné než v ukázce.
Jednoduchý kontrolní součet
Představte si níže uvedený .ven soubor :
[DETAILS]
Name = River Lot
Ref = LOT
Desc = venues/lot/fsb/page1.fsb
Dir = venues/lot/*.peg
LastPeg = venues/lot/last.dat
Creator = Teresa Morris
Date = 24 September 2000
Records = venues/lot/
Level = 5.0
Regcode = 786868

[WEATHER]
Weather = data/ukwthr.dat
LookUp = venues/lot/temps.dat
TempModel = 1
TempFact = 1
StartTemp = 14

Pokud byl tento soubor distribuován v nezakódované (unscrambled) formě, určitě spousta "rybářů odborníků" okamžitě změnila obtížnost "Level" z hodnoty 5.0 na 1.0 aby měli revír jednodušší. Tito "taky rybáři" potom chytají rekordní úlovky nefér a v rekordech by neprávem přepsali úlovky rybářů kteří je chytili na Level 5.0. Proto byla implementována část systému, která kontroluje, jestli byl úlovek chycen podle správného nastavení v určitých souborech. Což vyžaduje aby byly prováděny kontrolní součty, tohle je ve formuláři "checksum".

Checksum je v podstatě pouze součet určitých hodnot, například ve výše zmíněném příkladě - dejme tomu že "ty určité" hodnoty jsou Level, TempModel, TempFact a StartTemp. Když tyto hodnoty sečteme 5 + 1 + 1 + 14 = 21, dostaneme checksum pro tento .ven soubor.

Pokud náš "taky rybář" bude chtít zapsat on-line svůj rekord bude mít odlišný checksum 1 + 1 + 1 + 14 = 17 ( což je špatně ).

Toto je ukázka toho jak jednoduše fungují kontrolní součty ! Ve skutečnosti je to trochu odlišné, ale na stejném principu, nelze spoléhat jen na to, co bylo v příkladu, protože by bylo velmi jednoduché tento způsob kontroly obelstít, třeba změnou hodnoty Level na 1 a změnou hodnoty TempFact na 5, což by dalo správný kontrolní součet (21) i se změnami v souboru ! takže v reálu funguje výpočet trochu složitěji, ale z jasných důvodů nelze podrobnosti zveřejnit.

Vždy, když je uloven venue record nebo peg record tak se vypočítá kontrolní součet v čase úlovku a uloží se, potom se použije k výpočtu validačního kódu úlovku. Toto zabrání změně Level na 1.0 ulovení rekordní ryby, změně Level zpět na 5.0 před obdržením validačního kódu.

S těmito informacemi není složité pochopit, proč se kontrolní součty mění a rekordy nejsou uznány.

1)Je běžná praxe, že se šíří mezi známými beta verze revírů při testování. Pokud někdo uloví rekordní rybu a vy změníte potom ve finální verzi nějaké hodnoty a vypustíte do světa hotový revír, původní úlovky nebudou akceptovány, protože budou mít jiné kontrolní součty a validační kódy.

2)Pokud je vydán patch nebo oprava k revíru, taktéž nebudou akceptovány úlovky z verzí bez tohoto patche nebo opravy ( již zapsané úlovky zůstanou ).

3)Pokud je soubor změněn nějakým add-onem, kontrolní součet se taky změní.

4)Pokud chytíte hrouzka (gudgeon). Tohle je známý problém, který nebude nikdy vyřešen, hrouzci se tak musí lovit pouze pro zábavu. Problém je v tom, že v době vypuštění FS2 byla chyba v .sp souboru a v .stk souboru hrouzka. Soubor .sp byl brzy opraven, ale .stk soubor s chybou se objevuje neustále v revírech. Sice je k dispozici oprava, ale originální revíry v jr2 jsou stále v oběhu a obsahují .stk soubor s chybou a vždy když si je naimportujete tak přepíšete opravu, která je v systému. Takže hrouzek je druh, který bude pravděpodobně pořád vykazovat tuto chybu.

Ve verzi 2.08 a vyšší může kterýkoliv uživatel napsat .c což pošle informaci o kontrolních součtech jako zprávu všem ( na serveru ), což umožňuje vzájemnou kontrolu při závodech.

Ve všech verzích FS2 od 2.04 je volitelná proměnná v souboru .peg, kterou může tvůrce revíru použít. Pokud je v sekci [Files] souboru . peg použita proměnná Vcode = 9999 ( kde 9999 nahradíte kontrolním součtem pro peg ) před distribucí revíru, může si každý uživatel zkontrolovat pomocí F9 kontrolní součet oproti tomu, který je zadaný v hodnotě Vcode.

Pokud bude mít uživatel kontrolní součet Cyan ( světle modrou ) barvou, tak to znamená, že hodnota Vcode není obsažena v souboru .peg. Pokud bude Zelená, pak je kontrolní součet shodný se součtem zadaným v hodnotě VCode pro daný peg. Jestliže bude Červená, potom nemá uživatel správný kontrolní součet a měl by zjistit proč, jinak nebude moci zapisovat on-line své rekordy.

Závěr
Bez vědomí toho, že validační systém funguje bylo od začátku zapsáno přes 5000 rekordů a taktéž během on-line závodů byly zobrazovány kontrolní součty v souboru wsock.txt. Toto bylo tajně sledováno několik měsíců a velmi zřídka se objevily nesrovnalosti a když se nějaké objevily většinou šlo jen o odlišné verze revírů, chybějící rybí druhy a podobné faktory. FSKingfisher zobrazuje pouze správné kontrolní součty, pokud máte nějaké jiné kontrolní součty, kontaktujte prosím (e-mailem) tvůrce revíru.

Představte si jak by to vypadalo bez kontrolních součtů, můžu Vám nyní zaručit, že by jste určitě nechtěli zapisovat rekordy radši vůbec, po zkušenosti s FS1 a kontrolou logů některých rekordů které neprošly validací :-)

(c) J.C.Spooner, (cz) Jerry 2008