Jump to content
LaunchBox Community Forums

Lahma

Members
  • Content Count

    131
  • Joined

  • Last visited

Community Reputation

51 Excellent

1 Follower

About Lahma

  • Rank
    32-Bit GPU

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Lahma

    LaunchBox Plugin Overhaul for 9.2-beta-3

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

    LaunchBox Plugin Overhaul for 9.2-beta-3

    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.
  3. That is really cool. No worries on trying the custom controller profiles... I'm sure they work as long as the Steam overlay is working (which it should be if you're launching the games through Steam with the plugin). I sometimes use a somewhat similar setup to play my desktop games remotely whenever I'm out of town (using either my phone or much more preferably my laptop).. except I usually use the open-source Moonlight client. As long as I'm on a good internet connection and somewhere regionally close by (like not traveling out-of-state), the experience is usually pretty decent (although I'm obviously not using it to play multiplayer fps games or anything).
  4. Oh nice... How do you like it (Nvidia Shield TV)? Do you use GeForce Experience to stream BB to it? When you stream BB and then you launch a game through Steam using the plugin, does everything still work ok (and can you still set custom controller profiles and stuff using the Steam overlay)?
  5. I really appreciate the kind words. It is surprising how motivating a simple "thank you" can be. 😋
  6. Turns out I was totally wrong about a Steam update having broken compatibility with the plugin... It was just a really, really strange quirk on my machine related to some terribly coded app making some stray registry modifications. So ya... just ignore that part of my previous post.
  7. SteamLauncher update to be uploaded shortly which will fix the problem introduced by the most recent Steam client update: Just wanted to let any users of the plugin know that it appears that the new Steam update that was pushed out a few days ago (oddly, my client only just updated yesterday) may have broken compatibility with the plugin. It appears that they probably changed some of the vftable offsets to such a degree that SteamLauncher is no longer able to calculate the updated offset properly. I should be able to provide a plugin update which fixes this issue very quickly, and I will make another post here when that "hotfix" update is uploaded. (Turns out, I was totally wrong about this... the plugin is still working just fine with the latest Steam client update.) Major SteamLauncher update coming soon which will add many new features (many of which users have been requesting for awhile): I'm actually in the middle of implementing some pretty fundamental changes to the plugin, mostly revolving around the ability to use the plugin to launch all games through Steam, by default, without having to select "Launch via Steam" in the game context menus. While this may seem like a minor change that would require a relatively small amount of work to implement, the reality is actually quite the opposite. I've been wanting to implement such a feature since basically the first release of the plugin, but due to limitations in the LaunchBox plugin API, it was not possible. With the latest LaunchBox update, some new features were added to the plugin API which I was hoping were going to allow me to implement such a feature, as well as some other nifty stuff. Unfortunately, it turns out that the API changes did not implement the features I was hoping for. When I created this plugin, the whole idea behind it was to eliminate the need for any type of intermediary/proxy executable to launch games through Steam, so when I say that the plugin API does not allow certain functionality to be implemented, what I really mean is that such a feature cannot be added without resorting to the use of such a proxy executable. So... I've now stated that the new API changes still don't allow for the implementation of a "launch all games through Steam by default" feature, and I've also stated that the plugin was created for the expressed purpose of eliminating the need for any complicated proxy executable. So, how am I adding such a feature then, you might ask? Well, it turns out that the new API changes add a couple of features that if used in a mangled/unintended way, combined with an EXTREMELY simple proxy executable (literally does nothing except create a hidden, zero size window that runs for the duration of the game), I can indeed implement such a feature in a less-than-ideal way. While it requires some hackish workarounds and trickery to implement, I have fully tested the concept in a new alpha branch of the plugin, and it does indeed work, and the feature can be easily toggled on/off with a simple click of a menu item in LB/BB. Surprisingly, this new method also comes with a few benefits in other areas, which depending on the user, may make a huge difference in regards to the usefulness of the plugin in their use-case. Here are just a few examples of some of the benefits the new plugin may provide: Support for LB/BB game startup/shutdown screens (when using SteamLauncher's new "launch all games via Steam by default" mode). Support for LB/BB's on-the-fly rom decompression functionality. When using the plugin previously, compressed roms were not supported unless the emulator itself handled rom decompression. This was due to the way the plugin completely bypassed LB's normal game launching procedure. Since this new feature is, in a sense, "hijacking" LB's game launching procedure (instead of bypassing it altogether), features such as on-the-fly rom decompression and cleanup should now work fine. Support for launching games via Steam using non-default emulators. This applies when you have multiple supported emulators or emulator launch configurations (such as multiple supported platform cores in Retroarch) for any given rom. Previously, only the default emulator/config was supported by the plugin due to the limitations of the LaunchBox plugin API's context menu, which did not allow you to create a variable number of context menu items (dynamically) at run-time. With all that being said, I can't provide any definitive release date for the new features, but I think something like 2-3 weeks is probably realistic. If I run into any problems which might push the release back further than that, I will be sure to post an update. Being that I have very little information concerning how many people are actually using my plugin, any input, suggestions, or feedback would be greatly appreciated (such as, will any of these major feature changes be of any interest to anyone?).
  8. Lahma

    LaunchBox Plugin Overhaul for 9.2-beta-3

    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.
  9. Lahma

    LaunchBox Plugin Overhaul for 9.2-beta-3

    How does LB currently handle cleanup of decompressed roms? Does it wait for the emulator/game process to end and then delete the decompressed rom, or does it delete all decompressed roms when LB is closed/shutdown? It would be great to still be able to do what I described even if the startup screens had to be disabled during such a use case. Just an idea, but monitoring the game/emulator exe for file locks would be one elegant way of detecting the start/end of gaming sessions (instead of monitoring a child process.) Basically, during your "PlayGame" method, you could wait a short period (say 5 sec) for a file lock to show up on the game/emulator exe, and if it doesn't, you would determine that the game failed to load, but if the file does get locked, then you know the game is running and simply wait until the file lock is removed to know the game has ended. I can't think of any instance in which this would not work since it extremely unlikely that anyone would be running multiple instances of any given game/emulator exe. A simple method such as the following could be used in combination with a timed loop to check if the file lock has expired: private bool IsFileLocked(string file) { FileStream stream = null; var fileInfo = new FileInfo(file); try { stream = fileInfo.Open(FileMode.Open, FileAccess.ReadWrite, FileShare.None); } catch (IOException) { return true; } finally { if (stream != null) stream.Close(); } return false; }
  10. Lahma

    LaunchBox Plugin Overhaul for 9.2-beta-3

    I was simply trying to make the point that instead of my plugin having to handle the launch process itself, I could simply hand LB a command line string for it to run itself. For example, if the OnBeforeGameLaunching method had a string parameter that contained the full command that LB is going to use to launch the game/emulator, my plugin could simply change that string inside of OnBeforeGameLaunching and allow LB to continue the game launching process (instead of cancelling the launch process and having to handle it myself in the plugin). This would have the added benefit of all of the startup/exit screens working as normal and it would allow LB to still handle rom decompression and everything on its own (although it would be helpful to have a path to the decompressed rom provided in one of the parameters to avoid the messy procedure of extracting it out of the [theoretical] "full command" parameter). As an example, lets say the OnBeforeGameLaunching method had a parameter named fullCmd, and it had a value of: "C:\RetroArch\retroarch.exe" -L "cores\snes9x_libretro.dll" "C:\roms\snes\Super Mario World (U) [!].smc" After my plugin is finished doing all of its background work to setup a hidden Steam shortcut, all it would need to do is change the value of fullCmd (inside OnBeforeGameLaunching) to a value such as: steam://rungameid/16354049154579693568 Then LB would continue on with its normal launch process passing that new fullcmd value to Process.Start() (or however you launch the game/emulator). The only potential problem I see with this is if LB is keeping track of when the newly launched process ends (in order to show the exit screen, call OnGameExited(), and/or clean up the decompressed rom), its going to think the process ends immediately since it would be launching an intermediate process that launches the game/emulator itself. If that would indeed be a problem, there are several relatively simple ways I can think of to get around this issue, but I guess its not worth crossing that road right now. Unfortunately, this won't work for me, because as described above, my plugin would need to use a completely custom command (ex: steam://rungameid/16354049154579693568). As it is right now, the overrideCommandLine parameter is being appended to the path to the emulator, which would result in something like: "C:\RetroArch\retroarch.exe" "steam://rungameid/16354049154579693568" And this clearly isn't what I need. Hopefully this hasn't give you a little better idea of what functionality I'm trying to achieve... Essentially, I just need some way to "hijack" the launch process. Let me know if there is any more info I can provide. Thanks again for taking thetime to try to understand my madness
  11. Lahma

    LaunchBox Plugin Overhaul for 9.2-beta-3

    Hey @Jason Carr , in addition to the questions I posted previously, I just thought I would let you know that the version # of Unbroken.LaunchBox.Plugins.dll is still set to 1.0.0.0 in the DLL properties. It is also referenced as 1.0.0.0 in the plugin API documentation that you added for the newly added methods. Example: ILaunchBoxMainViewModel Interface Provides plugin access to the LaunchBox interface. Added in LaunchBox and Big Box 9.2-beta-3. Namespace: Unbroken.LaunchBox.Plugins.Data Assembly: Unbroken.LaunchBox.Plugins (in Unbroken.LaunchBox.Plugins.dll) Version: 1.0.0.0 (1.0.0.0) Maybe you meant to leave the version # unchanged, but I just thought I would make you aware in case you didn't know.
  12. Lahma

    LaunchBox Plugin Overhaul for 9.2-beta-3

    Hey @Jason Carr , I got a couple of quick questions for you. I've only done a cursory glance over the new plugin features, so forgive me if I'm missing something obvious, but I figured it might be easier to just get a quick answer from you than to waste a lot of time with trial/error testing only to find out what I'm trying to do still isn't possible. Oh, and just for reference, in case a little more context would help, this is the thread where I initially requested some of these features in more detail: https://forums.launchbox-app.com/topic/44497-lb-api-additions-time-table/ Question #1: Do the new plugin API features provide any way for me to create a dynamic number of game/rom context menu items at runtime? In case its not clear, let me explain in a little more detail. Prior to the plugin API changes (and possibly still), I was only able to implement the IGameMenuItemPlugin interface at design time, so any changes made during runtime were not reflected in the context menu in LB/BB. This prevented me from being able to create my own context menu item similar to your "Launch With" menu item where I could create a dynamic number of "Launch via Steam (Emulator X/Y/Z)" context menu items based on the number of "Launch With" configurations available for that particular game/rom. Perhaps it is possible to get full access to change the context menu via ILaunchBoxMainViewModel, and I just missed it? Question #2: Does the new OnBeforeGameLaunching method/event provide any way to cancel the game from launching (such as many events that allow you to assign e.Cancel = true) so that the game launch can be intercepted and re-launched using a custom launch procedure (in my plugin's case, I am hooking the running Steam process and calling an internal function in steamclient.dll to launch a custom command line through Steam). If needed, I think I could actually do away with calling an internal Steam function to launch the game and instead pass a specific command line cmd/args to LB so that it could run the command itself, but as far as I can tell, this doesn't appear to be possible either. Question #3: In the new PlayGame function, is the overrideCommandLine parameter used for asking LB to run a given rom/game with a completely custom command line or is this just used to add additional parameters to the command that LB would already normally be running? Thanks in advance for taking the time to answer my questions, and thanks again for implementing these new features into the plugin API. Some of these new features look like they were implemented as a direct answer to some of these requests I made in the thread I referenced above. I know spending the time to implement this stuff is probably only valuable to a very small subset of your users, so it means a lot that you expend the effort to implement my/our requests. Hopefully I'm just misunderstanding/missing some of the functionality and the new features will allow me to implement the changes I've been wanting to make in my plugin for quite awhile (without additional changes/work needing to be done to the API). Thanks Jason!
  13. Hi @jmsulli, let me first repeat my apology that I just gave to the other person who posted a reply in this topic: sorry it took me so long to respond. I missed the emails notifying me of new responses here. Now, moving on... I've never used pcsx2 configurator, so I don't have any idea how it works. This is a LaunchBox plugin? Can you provide me with some additional info on how it works? Like how does pcsx2 configurator change pcsx2 settings on a per-game basis? Does pcsx2 itself support per-game configs or is the plugin actually swapping out the pcsx2 config file every time a game is launched through LaunchBox? Or does pcsx2 configurator modify the game's launch settings/arguments inside the LaunchBox game properties? If you can provide me with some more info in this regard, I can probably more easily determine if this is something that can be fixed or not. If I had to guess, I would say pcsx2 configurator is probably changing something outside of LaunchBox that my plugin won't be able to get access to due to limitations in the way the plugin API works. When launchign a game with SteamLauncher, it uses the path of the default emulator assigned to that game and any other custom arguments assigned to it in order to launch the game through Steam. Again, due to limitations with the plugin API, there is no way to assign a dynamic number of context menu items based on multiple supported "Launch with" configs being available, so my only option is to use the default "Launch with" setup when launching a game by clicking "Launch via Steam". I will check back on this thread frequently so I don't miss your reply. Hopefully we can get your issue sorted out. Thanks!
  14. Lahma

    LaunchBox Plugin Overhaul for 9.2-beta-3

    Thanks for implementing these new features into the plugin API @Jason Carr! I'm a little late to the game since I only just now noticed that you updated the plugin API, but I will definitely be diving into the new features ASAP. Hopefully these changes will allow me to implement some of the features I've been wanting to implement into my SteamLauncher plugin for quite awhile.
  15. Man.. I need to figure out a better way to monitor this thread... somehow I always miss the emails notifying me of a new post. Sorry it taken me so long to respond man. Due to limitations with the LaunchBox plugin API, this has not been possible to implement. However, I just saw that @Jason Carr updated the plugin API with some new features, so this MAY be possible to do now, but I won't know for sure until I further investigate the new features. Over the next few days, I'm going to try to update the plugin with some of the new API functionality, and if it is possible to implement this feature, you can be certain that I will implement it. Some of these new features are things I've been requesting for Jason to implement for quite awhile, so I'm excited to update the plugin with some new functionality. Thanks for your support and kind words!
×