Mods Tab Refresh

[RMWChaos-duplicate]

The mods tab does not always refresh properly when changes are made to a mod.

Example:

1. Open Wrye Mash, go to Mods Tab, leave it open throughout test
2. Place plugin with masters out of sync in \Data Files
3. Check Mash Mods Tab - verify it sees the mod and marks the mod as Yellow (out of sync with masters)
4. Use command line "tes3cmd header --synchronize --hide-backups [mod name]"
5. Confirm in "[mod name]-cleaned.log" that the masters were updated
6. Check Mods Tab - verify it still marks the mod as Yellow (out of sync with masters)
7. Close and reopen Mash, go to Mods Tab - verify that the mod is now marked as green

Research:
How does Mash decide when to refresh the mods tab?

• CRC check?
• Last modified date of file?
• Other?

Possible Fix #1
Type: Manual
Difficulty: moderate (new code)
Impact: none

Add a manual "Refresh All Mods" option in the Mods Tab menu code (right click on menu bar) and/or a "Refresh Mod" option in the plugin menu (right click on individual mod).

Possible Fix #2
Type: Automatic
Difficulty: easy (copy & modify existing code from Installers Tab)
Impact: may slow Mash performance

If Mash uses "last modified date" of the file, this will generally not be changed by modding tools, which intentionally are written to maintain the mod date for load order purposes.

However, Mash always does update after MLOX reorders plugins, which intentionally changes mod dates (last modified date). This tells me that Mash most likely checks the "last modified date" and would therefore not refresh if a change to the mod left the date unchanged.

This could be corrected by adding a check to "on window focus" (that's HTML/Javascript terminology; not sure what its equivalent would be called in python) to look at the size of the mod.

The Installers Tab does some kind of CRC and other checks, but that takes a while with all the files in the packages/projects. Might be worth looking at to see if the same code could be used to look only at ESP and ESM files in \Data files.

[Yacoby]

I think the issue is that the tes3cmd synchronise command doesn't change the size of the plugin. I did have a think about this today and thought that the best possible method would probably be to compare the crc of the first record in each file (TES3). That way we aren't reading a lot of data (Which takes ages) but we are comparing the data that tes3cmd changes. I would have to look at the code to have a better idea of what would need to happen.

(As you may have noticed I also keep hitting "Comment and Close" rather than "Comment" :P)

[RMWChaos-duplicate]

That makes sense. The CRC of the TES3 record would change if the headers are updated with new masters.

Doesn't the file size change if records are removed? I suppose it might not if only the masters or record count is updated.

Actually, I checked on the size issue, and I don't think Mash does check that. My batch file adds a "Cleaned by tes3cmd on %date%" comment in the plugin description; so the file size definitely should change even if tes3cmd makes no other changes to the plugin at all. Changing the size was my fist thought, too, which is why I added the comment to the description to begin with, but this did not make a difference in forcing the Mods tab to refresh.

So the CRC of the TES3 record is probably the best approach for anything that modifies the header, but it might not catch other changes to the file.

Technically, if a plugin is cleaned, and records are removed, the header record count should be updated, but tes3cmd doesn't do that unless you run the "tes3cmd header ..." command with either the --synchronize or --update-record-count options. My batch does --synchronize, which does both --update-masters and --update-record-count together.

So maybe a check of the file size is still the best approach? In DOS this can be done with "%~z1".

[Yacoby]

If records are removed, the file size would change, however the description is a fixed length in the esm file, so updating the description doesn't alter the size of the file.

I am not sure that it matters that much about other changes to the file anyway as mash doesn't use the information but when it does I think it has to load it from the disk to it isn't cached in any way (I may be wrong about that though)

[RMWChaos-duplicate]

Fixed length!? Those bastards! Ok, I see why that didn't work then.

Well, then your CRC check of the header plus file length check would probably cover everything, I would think - changes to the header (updated masters, updated description, updated records-count), as well as removed records from cleaning.

[Sharlikran]

I am updating things and there is a chance this may work itself out in the update. If not there is a chance it could be looked into.