Closed Infernio closed 5 years ago
get_plugin_cleanliness
has a second evaluateConditions
parameter that defaults to false, but you want to be passing True
, otherwise it sees that dirty and clean metadata exists.
Whoops, I missed that in the test script, Wrye Bash did set that second parameter. Doesn't seem to make a difference though, it still prints out PluginCleanliness.unknown
, even with the second parameter.
Oh, I see the bug now... Thanks for reporting that, I'll add some tests for get_plugin_cleanliness
and fix it.
Fixed in b17b531073e9d86b9f84e37926a1b247a0c591a3.
I was investigating why Wrye Bash no longer shows LOOT dirty / clean status for mods, when I noticed that
get_plugin_cleanliness
always seems to returnPluginCleanliness.unknown
in the debugger. I made a small script to reproduce this problem:Note: This is with loot-api-python v4.0.1 for Python 2.7, 32-bit.
This prints out
PluginCleanliness.unknown
, but the masterlist entry clearly shows that it's dirty (its CRC is7048C609
):LOOT itself also shows this correctly:![loot-correct-clean](https://user-images.githubusercontent.com/2845240/54841087-cc88c480-4cce-11e9-8e1f-9d38f8e5f775.png)