What
are checksums and validation codes ?
J.C.Spooner
2002
| Introduction |
| This page explains how checksums and validation codes work, it is the simplest system in the world to understand and program, and very effective. Problems with checksums and validation codes come about with different versions of venues and the overwriting and changing of files. The explanation below, doesn't give any accurate information as this would be silly, but a theoretical description of how they work and how they are calculated, the actual calculations are different from the ones described. |
| Simple checksum | |
Imagine the following .ven file
below :
If this were distributed in an unscrambled form, then it wouldn't take a rocket scientist to work out that by changing the Level value from 5.0 to 1.0 would make the venue easier. The non-rocket scientist then, goes for a fish on the venue, and lands a record carp, which is definately not fair, on the previous record holder, who caught his with the Level set to 5.0. Therefore some sort of system has to be implemented to check that each catch submitted has been caught with the correct information set in the relevant files. Which requires some form of checking to be made, this is in the form of a "checksum". All a checksum is, is the "sum" of all relevant values added together, eg in the case above, lets say the level is definately a relevant value, along with the TempModel, TempFact, and StartTemp. These values added together give 5 + 1 + 1 + 14 = 21, that's the checksum for the venue file. If Mr non-rocket scientist trys to submit his carp now, then his checksum will be 1 + 1 + 1 + 14 = 17 ( incorrect ). That really is about as simple as a checksum is ! Well nearly anyway, that's not the exact implementation, as that would be still easy to crack, for example, by changing the level to 1, and the TempFact to 5, this would give the correct checksum (21), with incorrect data ! so a bit more simple math is applied to get around this, the exact details of that are not being released for obvious reasons. Everytime a venue or peg record is caught, the checksum at the time of the catch is recorded with the record and is used to calculate the validation code for the catch. This prevents anyone changing the level to 1.0, catching a fish, then changing it back before getting the validation code. The reasons why checksums change and records aren't accepted are not complicated to understand, given this information. 1) A common practise is to release Beta versions of venues to friends to test before releasing them. If them friends catch a record fish, and then you subsequently change any of the information and distribute the venue, there original fish catches won't be accepted. 2) If a "patch" or "fix" is bought out for a venue, and prior to this someone caught a record, then that too won't be accepted. 3) If a file is changed by another addon, that will affect the checksums also. 4) If the catch is a gudgeon. This is a known problem, and will never be solved, gudgeon are going to have to be one of those species that are fished for fun. The reason why there is a problem is that there was an error in an sp and stk file right at the start of FS2, the SP file was fixed early on, however the stk file with the error still continues to propergate around in different venues, there is a fix for it, but the original venue JR2's are still out there which contain the incorrect stk files, and will overwrite the fix if imported again. So this is one species which will most probably always fail. In version 2.08 and higher, any user can type .c which will send there checksum information out as a message to everyone, giving a mechanism where people can check against each other. Also, in all versions of FS2 after 2.04, there is an optional line, that creators can include in the .peg files for a venue. If the Vcode = 9999 ( where 9999 is replaced for the peg checksum ) line is added to the [Files] section of the .peg file before the venue is distributed, then the user can use the F9 key to check there checksum against the one that you state in the VCode line they should have. If the users checksum comes up in a Cyan ( light blue ) colour, that indicates, that there is no VCode line in the .peg file. If it comes up in Green, then there checksum matches the number in the VCode line for the peg. If it comes up in Red, then they have not got the correct checksum and will need to look into correcting the problem for record submission and matches. |
| Conclusion |
| Without a shadow of a doubt the
validation system works, there have probably been in
excess of 5000 fish submitted and accepted, since the
start, also during online matches checksums are displayed
in the wsock.txt file. These have been monitored silently
for months now, and very rarely is there a difference
between users, and if so this will be down to some other
factor, eg missing fish or different versions etc.
Therefore the only correct checksum is the ones which
FSKingfisher displays, if you've got something different
to this then you should contact the creator of the venue
( by email ). Imagine what things would be like without a checking system though, I can guarantee now, that you wouldn't be interested in submitting record catches at all, after the FS1 experience and viewing the logs for some records that didn't go through :) |
(c) J.C.Spooner