Regarding BLT 2.x updating system

[BigSky7]

Hello James, I would like to ask something about the updating behaviour regarding BLT 2.2 (I'm assuming that's the latest stable release?).

I installed BLT 2.2 a week ago, after a near 2 month break from the game, and I noticed that the mod manager detects a "new" version of the BLT available, even after I tested re-updating it trough the BLT's download manager. After that it still detected a "newer" version available, making it an endless process.

I didn't find anything related to this on the Steam/Mod Workshop forums or reddit, so I decided to ask here to try to find a solution for the issue.

Thank you for your time.

[luky92]

I think it's because it uses a little extra system and instead of checking version number like the rest of the mods it also checks the checksum of files in base folder if you modified them it will detect the "update" all the time

[BigSky7]

Indeed, now the BLT compares the server and the local mod hash, which makes the updating process very repetitive (which is of course, pointless, if the mod is already updated).

Another change that I've seen is that before, modders defined the mod's version number in the version string (which was independent from the updates' revision number) before the updates string, for example:

"version" : "1.0",
"updates" : [
{
"revision" : 1,
"identifier" : "ID"
}

Whereas now, the version number is defined in the first string, and not the revision string, for example:

"version" : "1",
"updates" : [
{
"identifier" : "ID"
}

I know that not all the mods updated to work with BLT 2 have received this change, but I do know that various mods did, and that's the reason for me to point it out. Though, I didn't fully tested this syntax change in all the current mods that I have, so I might be wrong on that.

And like you said, all the hash verifying system is kind of a pain for me because, I tend to edit mods myself in case I need to translate some strings or disable log entries that I don't need, for example.