loot / libloot-python

A Python module that wraps libloot.
GNU General Public License v3.0
6 stars 1 forks source link

get_plugin_cleanliness always returns PluginCleanliness.unknown #10

Closed Infernio closed 5 years ago

Infernio commented 5 years ago

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 return PluginCleanliness.unknown in the debugger. I made a small script to reproduce this problem:

from loot_api import create_game_handle, GameType, initialise_locale

initialise_locale(u'')
game_path = u'G:\\steam\\steamapps\\common\\Oblivion\\Data'
masterlist_path = u'C:\\Users\\Infernio\\AppData\\Local\\LOOT\\Oblivion\\masterlist.yaml'
game_handle = create_game_handle(GameType.tes4, game_path)
loot_db = game_handle.get_database()
loot_db.load_lists(masterlist_path)
print(loot_db.get_plugin_cleanliness(u'DLCBattlehornCastle.esp', True))

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 is 7048C609):

- name: 'DLCBattlehornCastle.esp'
  group: *dlcGroup
  after:
    - 'Unofficial Oblivion Patch.esp'
    - 'Oblivion Citadel Door Fix.esp'
    - 'UOPS Additional Changes.esp'
    - 'UOP Vampire Aging & Face Fix.esp'
    - 'DLCShiveringIsles.esp'
    - 'Unofficial Shivering Isles Patch.esp'
    - 'USIPS Additional Changes.esp'
  dirty:
    # version: 1.2.0.416 GOTY
    - <<: *quickClean
      crc: 0x7048C609
      util: '[TES4Edit v4.0.0](https://www.nexusmods.com/oblivion/mods/11536)'
      itm: 10
      udr: 72
    # version: 1.2.0.416 GOTY, after second pass of quick clean.
    - <<: *quickClean
      crc: 0x991F07A3
      util: '[TES4Edit v4.0.0](https://www.nexusmods.com/oblivion/mods/11536)'
      itm: 3
  clean:
    # version: 1.2.0.416 GOTY
    - crc: 0x92E3710E
      util: 'TES4Edit v4.0.0'

LOOT itself also shows this correctly: loot-correct-clean

Ortham commented 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.

Infernio commented 5 years ago

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.

Ortham commented 5 years ago

Oh, I see the bug now... Thanks for reporting that, I'll add some tests for get_plugin_cleanliness and fix it.

Ortham commented 5 years ago

Fixed in b17b531073e9d86b9f84e37926a1b247a0c591a3.