After 571eeb6 and 44510f4 were applied, executables for some of my currently installed games are no longer detected correctly (though I'm pretty sure the changes from 44510f4 didn't really affect anything as it only affects games with no primary tasks… which probably don't actually exist). I believe most of them are some of the older GOG installers, as their tasks don't have a category field; due to which the app no longer can find the main executable, and tries to run whatever (which has no chance of working if the file it should run is in a subfolder… which is always the case for DOSBox/ScummVM games running via Wine). Other games have a launcher as the only primary task, which is rejected by this check and thus fallback logic is employed.
Affected games (in my current install list):
Aliens versus Predator Classic 2000 (runs language setup instead of the game)
Betrayal at Krondor (technically not tested but the fallback logic should fail as it's a DOSBox game)
Betrayal in Antara (fallback logic finds nothing because game executable is in uppercase)
Deus (technically not tested but the fallback logic should fail as it's a DOSBox game)
Diablo (has no primary game task due to being a 2-game pack; since launcher type is ignored, it tries to use fallback logic but all correct executables are in subfolders – so instead it finds the old game executable which demands a CD)
Die By the Sword (same here – the game task is not primary due to a launcher existing, and the fallback logic picks the video settings tool instead)
Disciples I (fallback logic finds nothing because all executables are in subfolders… also the game task is a shortcut file, .lnk)
Evil Islands (runs the video settings tool)
Hob (appears to try running the crash reporter… which isn't meant to be run this way so it fails silently instead)
Pilot Brothers II/III (fallback logic finds nothing because the executable is in a subfolder)
Quake I: The Offering (runs the video settings tool)
Rage of Mages I/II (tries to run map editor… but fails due to its 16-bit color profile)
Stonekeep (technically not tested but the fallback logic should fail as it's a DOSBox game)
The Elder Scroll Adventures: Redguard (fallback logic finds nothing because all executables are in subfolders …also it's a DOSBox game in the first place)
Wizardry VI (technically not tested but the fallback logic should fail as it's a DOSBox game)
These are also affected but still work due to fallback logic stumbling upon the correct executable (either because it's the only one in game folder or purely by chance):
Amid Evil (finds launcher)
Avernum (finds the game)
Blades of Avernum (finds the game)
Driftland (finds launcher)
Might and Magic VI (finds the game)
Neighbours Back from Hell (finds launcher)
Prince of Persia II: Warrior Within (finds launcher)
The Elder Scrolls III: Morrowind (finds launcher)
The Elder Scrolls IV: Oblivion (finds the game… instead of launcher)
Treasure Adventure World (finds launcher)
Warcraft II (finds the game… instead of launcher)
Wizardry VII (finds the game… instead of launcher)
Suggested fix (for games without category): either use task.get('category', 'game') in the loop check instead of skipping primary tasks without a category, or do a second run if the first one doesn't find anything.
In case of games that have a launcher as their primary task, you can opt to either detect it as well, or search for games among non-primary tasks (which is different from what was removed in 44510f4 as there are primary tasks in the list but none of them are games).
Also (or instead), there should probably be a task/executable selector, because for instance Diablo is a 2-game pack (with a launcher)… and I'd say being able to pick/set temporarily secondary executables like external video settings tool would be nice as well.
P.S. Incidentally…
This:
```python
if "playTasks" in info:
for task in info["playTasks"]:
if "isPrimary" not in task or not task["isPrimary"]:
continue
…
```
can be simplified like this:
```python
primary_tasks = [task for task in info.get('playTasks', []) if task.get('isPrimary')]
for task in primary_tasks:
…
```
(and the logic removed in 44510f4 would be `for task in primary_tasks or info.get('playTasks', []):`)
Oh wow, thanks for this really detailed bug report. That will help a lot with fixing this issue. I honestly think all playtasks should be shown to the user.
After 571eeb6 and 44510f4 were applied, executables for some of my currently installed games are no longer detected correctly (though I'm pretty sure the changes from 44510f4 didn't really affect anything as it only affects games with no primary tasks… which probably don't actually exist). I believe most of them are some of the older GOG installers, as their tasks don't have a
category
field; due to which the app no longer can find the main executable, and tries to run whatever (which has no chance of working if the file it should run is in a subfolder… which is always the case for DOSBox/ScummVM games running via Wine). Other games have a launcher as the only primary task, which is rejected by this check and thus fallback logic is employed.Affected games (in my current install list):
game
task due to being a 2-game pack; sincelauncher
type is ignored, it tries to use fallback logic but all correct executables are in subfolders – so instead it finds the old game executable which demands a CD)game
task is not primary due to a launcher existing, and the fallback logic picks the video settings tool instead).lnk
)These are also affected but still work due to fallback logic stumbling upon the correct executable (either because it's the only one in game folder or purely by chance):
```json { "clientId": "47282734206214863", "gameId": "1207665883", "language": "English", "name": "Aliens vs Predator Classic 2000", "playTasks": [ { "isPrimary": true, "name": "Aliens vs Predator Classic 2000", "path": "AvP_Classic.exe", "type": "FileTask" }, { "name": "Language Setup", "path": "language_setup.exe", "type": "FileTask" }, { "link": "http://www.gog.com/support/aliens_versus_predator_classic_2000", "name": "Support", "type": "URLTask" }, { "link": "http://www.gog.com/forum/aliens_versus_predator_classic_2000", "name": "Send multiplayer or launcher feedback", "type": "URLTask" } ], "rootGameId": "1207665883", "version": 1 } ```.info
-file for AvP (nocategory
)
Note: in many cases the game entry(-ies) included `"isHidden": true`. ```json { "buildId": "50707556912620595", "clientId": "49842418730375899", "gameId": "1300281766", "language": "English", "languages": [ "en" ], "name": "Hob", "playTasks": [ { "arguments": "skip_file_check", "category": "launcher", "isPrimary": true, "languages": [ "*" ], "name": "Play Hob", "path": "hoblauncher.exe", "type": "FileTask" }, { "arguments": "skip_file_check", "category": "game", "languages": [ "*" ], "name": "Play Hob (no launcher)", "path": "hob.exe", "type": "FileTask" }, { "languages": [ "*" ], "link": "https://support.runicgames.com", "name": "Support", "type": "URLTask" } ], "rootGameId": "1300281766", "version": 1 } ```.info
-file for Hob (launcher
as the primary task)Suggested fix (for games without
category
): either usetask.get('category', 'game')
in the loop check instead of skipping primary tasks without a category, or do a second run if the first one doesn't find anything.In case of games that have a
launcher
as their primary task, you can opt to either detect it as well, or search for games among non-primary tasks (which is different from what was removed in 44510f4 as there are primary tasks in the list but none of them aregame
s).Also (or instead), there should probably be a task/executable selector, because for instance Diablo is a 2-game pack (with a launcher)… and I'd say being able to pick/set temporarily secondary executables like external video settings tool would be nice as well.
P.S. Incidentally…
This: ```python if "playTasks" in info: for task in info["playTasks"]: if "isPrimary" not in task or not task["isPrimary"]: continue … ``` can be simplified like this: ```python primary_tasks = [task for task in info.get('playTasks', []) if task.get('isPrimary')] for task in primary_tasks: … ``` (and the logic removed in 44510f4 would be `for task in primary_tasks or info.get('playTasks', []):`)