FRW files indeed are in the versions v1, v2 and v3, where v1 has no header and v2 and v3 do have. I havent encountered any v2 frw files so far because i only have frw files from or RCT3 vanilla (v1 files), or RCT3 with soaked+wild (v3 files).
Besides that v3 has the header (with extension) and v1 doesnt have a header, there are some more subtile differences. v1 files don't have the crc at the end as well, where v3 files do have the crc. Furthermore does the class-declaration in v1 frw files include all possible class declarations you could expect in any dat-type file (147 in total), where the v3 files only include the 3 class-declarations which are present in the file (ParticleBaseDesc, ParticleEmitterDesc & ParticleDesc for functional frw files, or only ParticleBaseDesc when you only have a base-emitter in your frw file).
On the hash algorithm you posted, absolutely no clue how i should read that script to understand what it does . My experience and knowledge on programming is mainly limited to that from an engineering perspective using mathematics on physics. When it comes to actual computer science I'm mostly limited to understanding at least that everything is stored in bits, bytes .
And indeed as you said, i will leave the checksum for what it is anyway. I got everything i need working and all work that is left for me to do is to write scripts which allow me to adjust color of other effects as well than just those of LED-lamps, but now I got all the tools I need to be able to do so.
And to give you a better view of what I'm doing atm: Now I'm working on some more advanced patterns in the LEDs with the colors. In the video below you see a piece of around 62 seconds. everything one LED does within these 62 seconds is now put into one frw file for that specific LED, resulting in around 400 rows of code to generate 196 different frw files for the LEDs for a field of 260 LEDs (some LEDs use the same frw file):