LaunchBox Plugin Overhaul for 9.2-beta-3

[Lahma]

9 hours ago, Jason Carr said:

Currently the extracted files are just deleted once the emulator closes.

The issue I can see with the file lock approach, is that LaunchBox doesn't necessarily know what file to check the lock of. If you check the lock on the ROM file, depending on the way the emulator is coded, that may or may not work (not every emulator is likely to hold a lock on the ROM file for the entire time that the game is loaded). So you'd need to check the lock on the emulator's EXE file, which would be a guaranteed way to do it, but in the case of Steam, we wouldn't necessarily even know the path to that EXE file. That is an interesting thought that I hadn't considered though.

Ya, I was referring to the EXE file specifically. I'm sure some emulators simply copy the entire rom into memory and remove the file lock (plus, there would probably be additional problems with emulators that support compressed roms). As far as the Steam game EXE paths go, I suppose that would be true for Steam games imported into LB using normal means. For the purposes of my plugin, since I am creating the Steam shortcut on-the-fly (my plugin creates a hidden shortcut when the user clicks on the 'Launch via Steam' context menu item and then deletes/recycles the shortcut the next time the user clicks the context menu item again), I obviously have the path to the EXE since I just used it to create the shortcut.

For normal uses outside of my plugin, it is not too difficult to retrieve the EXE path using the Steam appID (the X's in steam://rungameid/XXXXXX). For non-Steam shortcuts (user-created shortcuts in Steam that weren't downloaded or bought through Steam), you can get the path from shortcuts.vdf in the Steam userdata directory. For official Steam games bought/downloaded through the platform, you have to read the appmanifest_XXXXXX.acf files in the Steam/steamapps directory (the X's refer to the appID). When the Steam url only has a 6 digit value (6 of the 'X' values), it is an official Steam game. If it is more than 6 digits, it is a user-created shortcut. 

If you didn't want to mess with all that though (which I could totally understand), you could always just continue using whatever method it is you are currently using for Steam games (that you said doesn't always work so well), and use the file-locking method for everything else. I'm sure you are busy though and that is probably the last of your priorities. All I really want is some way to intercept/cancel/modify-exe-path of game launches in LB/BB, and I could really care less if startup/exit screens work with it or not. Since you said extracted files are deleted once the emulator closes, I guess that relies on LB being able to properly detect when the emulator process ends (as of now anyways), so maybe until you implement some other means of process start/end detection (that is, if you decide to), you could simply expose your decompression/cleanup methods to the plugin API so that plugin developers could handle it manually? Again, I know you're probably busy and the prospects of any of these changes being made quickly are probably pretty slim, but I hope you don't blame me for asking.  Thanks @Jason Carr.

[Jason Carr]

6 hours ago, Lahma said:

Ya, I was referring to the EXE file specifically. I'm sure some emulators simply copy the entire rom into memory and remove the file lock (plus, there would probably be additional problems with emulators that support compressed roms). As far as the Steam game EXE paths go, I suppose that would be true for Steam games imported into LB using normal means. For the purposes of my plugin, since I am creating the Steam shortcut on-the-fly (my plugin creates a hidden shortcut when the user clicks on the 'Launch via Steam' context menu item and then deletes/recycles the shortcut the next time the user clicks the context menu item again), I obviously have the path to the EXE since I just used it to create the shortcut.

For normal uses outside of my plugin, it is not too difficult to retrieve the EXE path using the Steam appID (the X's in steam://rungameid/XXXXXX). For non-Steam shortcuts (user-created shortcuts in Steam that weren't downloaded or bought through Steam), you can get the path from shortcuts.vdf in the Steam userdata directory. For official Steam games bought/downloaded through the platform, you have to read the appmanifest_XXXXXX.acf files in the Steam/steamapps directory (the X's refer to the appID). When the Steam url only has a 6 digit value (6 of the 'X' values), it is an official Steam game. If it is more than 6 digits, it is a user-created shortcut. 

If you didn't want to mess with all that though (which I could totally understand), you could always just continue using whatever method it is you are currently using for Steam games (that you said doesn't always work so well), and use the file-locking method for everything else. I'm sure you are busy though and that is probably the last of your priorities. All I really want is some way to intercept/cancel/modify-exe-path of game launches in LB/BB, and I could really care less if startup/exit screens work with it or not. Since you said extracted files are deleted once the emulator closes, I guess that relies on LB being able to properly detect when the emulator process ends (as of now anyways), so maybe until you implement some other means of process start/end detection (that is, if you decide to), you could simply expose your decompression/cleanup methods to the plugin API so that plugin developers could handle it manually? Again, I know you're probably busy and the prospects of any of these changes being made quickly are probably pretty slim, but I hope you don't blame me for asking.  Thanks @Jason Carr.

Makes sense. Not sure when exactly I'll get to it but I'll add plugin access to the extraction stuff to my list.

[Lahma]

Hey @Jason Carr, I've come across an issue with the new plugin API, and I was hoping you could let me know if it was intentional or possibly just an oversight that you might be able to implement a fix for. Since you implemented the new startup screens, there is now a new tab on the "Edit" game properties dialog labeled 'Startup' which has a checkbox labeled 'Override Default Startup Screen Settings', which if checked, allows you to override the emulator/LB's default game startup settings. The problem is, IGame does not expose any of the following properties (most of which are exposed in IEmulator) :

• OverrideDefaultStartupScreenSettings
• UseStartupScreen
• HideAllNonExclusiveFullscreenWindows
• StartupLoadDelay
• HideMouseCursorInGame
• DisableShutdownScreen
• AggressiveWindowHiding

This means that a plugin can tell if a given emulator overrides LB's default startup screen settings, but it is impossible for a plugin to tell if a given game overrides an emulator's/LB's default startup settings. I can't imagine that this was intentional on your part.. and if it is indeed just an oversight, can you expose those members/properties in the next LB update? 

One more thing.. Although IEmulator exposes most of these properties, there are a couple that are not exposed, seemingly with no good reason. The properties that IEmulator does not expose are:

• DisableShutdownScreen
• AggressiveWindowHiding

Perhaps you could expose these as well if you don't have any explicit reason for keeping them hidden? Thanks Jason and keep up the great work.

[Jason Carr]

@Lahma Thanks for pointing that out. I've added them in for the official release, which should be out today.

[Lahma]

1 hour ago, Jason Carr said:

@Lahma Thanks for pointing that out. I've added them in for the official release, which should be out today.

Wow... I definitely didn't expect the issue to be resolved that quickly! Thanks @Jason Carr!