What it says on the tin, there's nothing in the archives but the build still passes and there aren't any relevant warnings in the build logs.

I don't know exactly what to put for the AI. The main thing I was requesting was to add the ability to check ESL qualifications and whether or not the ESL flag is valid.

loot_api.check_esl_qualifications(parameter: filename) : returns True if the file meets Bethesda standards for a file to have the ESL flag. Should allow 0x800 to 0xFFF for Fallout 4 and once implemented for Skyrim SE also. : returns True or False
loot_api.check_eslexpanded_qualifications(parameter: filename) : alternative check if implemented to check range 0x000 to 0xFFF and a different command for 0x000 to 0xFFF : returns True or False
loot_api.is_eslflag_valid(parameter: filename) : Checks to see if the ESL flag is valid, returning true or false
loot_api.ismod_creationclub_esl(parameter: filename) : checks if the file extension is .esl and if both the ESM and ESL falg is set. This it mostly for mod sorting reasons as they are force loaded. : returns True or False

I don't know if loot or libloot has other things it checks that might be useful.

Suggested in wrye-bash/CBash#7, this would solve linking problems with standalone Wrye Bash executables and also simplify its usage of the LOOT API.

Greetings @WrinklyNinja, I am trying to update Wrye Bash to use the new loot-api v2.0.0 but I keep getting those runtime errors when calling any method of DatabaseInterface. A minimum working example is:

from loot_api import GameType
from loot_api import create_database

masterlist_path = u'C:\\Users\\daidalos\\AppData\\Local\\LOOT\\Oblivion\\masterlist.yaml'
game_path = u'D:\\games\\Oblivion'

db = create_database(GameType.tes4, game_path)

db.load_lists(masterlist_path)
tags = db.get_plugin_tags(u'Unofficial Oblivion Patch.esp')

the resulting output is:

E:\software\Python27\python.exe E:/wrye_bash/main_repo/wrye-bash/scripts/test_loot_api.py
[2017-09-28 22:43:28.060461] [0x000027c0] [info] Initialising load order data for game of type 0 at: > "D:\games\Oblivion"
[2017-09-28 22:43:28.061461] [0x000027c0] [debug] Loading file: "C:\Users\daidalos\AppData\Local\LOOT\Oblivion\masterlist.yaml"
[2017-09-28 22:43:28.260473] [0x000027c0] [trace] Testing condition syntax: active("Oblivion.esm") and active("Nehrim.esm")
[2017-09-28 22:43:28.260473] [0x000027c0] [trace] Checking to see if the path ""Oblivion.esm"" is safe.
[2017-09-28 22:43:28.260473] [0x000027c0] [trace] Active check result: false
[2017-09-28 22:43:28.260473] [0x000027c0] [trace] Checking to see if the path ""Nehrim.esm"" is safe.
[2017-09-28 22:43:28.260473] [0x000027c0] [trace] Active check result: false
Traceback (most recent call last):
File "E:/wrye_bash/main_repo/wrye-bash/scripts/test_loot_api.py", line 15, in
db.load_lists(masterlist_path)
RuntimeError: bad cast

Do you have any idea what could cause this?

Building the same commit on different branches (eg. after a merge) causes only the first deployment to succeed, as the others fail due to a filename conflict. Either name artifacts to be branch-specific or stop conflicts causing errors.

It would be useful if users could see which version of the LOOT API is being wrapped, and which version of the wrapper is being used.

This is intended as a possible solution to loot/loot#597, wrapping everything necessary to profile loot_get_plugin_tags() should be prioritised. Once that's done, the wrapper can be performance tested and we can see if it's worth pursuing.

Python unit tests that load the generated module and the API DLL and check all the bits work would be good, even if it's just making simple calls and checking that they're successful with the expected outputs, etc.

Tests added as per #1 should get run in a CI system, and the module built deployed to Bintray. Include the API library linked against in the deployed artefact.

The Python API needs to be documented, installation/usage instructions need to be provided, and it's probably a good idea to include the C++ API's documentation too.

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: