Is there any guidance on how the MD5 of the various files is used in scenarios? I'm fully aware of what and MD5 is; it just seems that the implementation of it here isn't standard and I'm trying to puzzle it out. Take for example a simple example scenario: ScenarioProperties.xml contains an MD5 XML tag of B657F8F034FDF9009D8CAB84B0B8FDE2. However, the MD5 hash of that file is actually 2F0BEDCF040F74BFD18E69F071C42CD1. Additionally, no other file in the scenario folder has a MD5 hash that matches the XML tag, including a conversion of ScenarioProperties.xml to ScenarioProperties.bin. Additionally, there's ScenarioProperties.xml.MD5. Reading that binary file as hex gives us a value of DE26895DB721A22B6C4F47B9A692221C. Once again, not only does this not match the MD5 hash of ScenarioProperties.xml, but it matches neither any other scenario file nor the MD5 in the XML tag. Which raises the obvious question: Where are the hashes coming from? They seem completely disconnected from the files used to drive scenarios instead of being used to verify file integrity.
Been delving into this, and indeed you are correct. Don’t know what the they are using but it’s not MD5. The MD5 hash below is for a ScenrioScript.luac.MD5 whose MD5 according to RW is: 1e 3d 35 1e ee 9c 5f 8f 65 8b 97 e1 9a 1e cb f1 Nothing like the hash generated by the plethora of online MD5 tools or the MS .NET MD5 function I’m using. The correct MD5 for that .luac file is: e7 ef 86 5c 63 60 bf 32 a6 82 67 0a c0 00 10 f6 Couldn’t find any other obvious hashing mechanism that fits either... These (alleged) MD5s as far as I can tell are only really used for Scenarios (though they do gen MD5’s on their internal caches SDV/RVDB etc.), though it seems that actually RW in fact takes no notice of the MD5 files it generates. In fact you can delete all the xxx.MD5 files in a Scenario folder and it all still works fine (including ScenarioScript.luac.MD5) even after a reset and rebuild of the TSC/RW caches (SDB/RVDB etc.). Now, I’ve been creating and modifying scenarios for years (independant of TSC/RW) without touching the MD5s and everything works. There was a query with the ScenarioScript.luac.MD5 (compiled script), which is what I’ve been specifically testing for, and I’m going to do more testing, but it seems to be the case also. The MD5 is irrelevant, even on ScenarioScript.luac. And the same is true for other MD5 hash values generated by TSC/RW (ScenarioProperties.xml.MD5 and Scenario.bin.MD5 etc.), in that all have hash values that are not legitimate MD5. In some ways, this is all a bit of a joke as the main usage for MD5 (should be) to verify the contents of downloaded Workshop scenarios (say), but TSC/RW can’t even (usually) manage the simple installation of these files (copying from the download folder on your system to the Routes/Scenarios folder) without corrupting them, so it’s all rather moot. I suspect either the checking of these (alleged) MD5 files, which is an overhead, has either been junked at some point in an effort to speed up overall processing, or they were only ever really used for Workshop downloads etc. which they screw-up anyway. So If the hash they’re using and calling MD5 isn’t actually MD5, then what the hell is it? Though it’s probably rather irrelevant now, as they don’t seem to be actually using them anyway (apart from maybe on actual downloads.... before messing up the copy), only generating them. Hey ho. Note: All my testing has been done using 77.6b and 75.8a
