[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.

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í :-)