Lahma

Thanks for sharing your work @Benuno. I will take a look at it as soon as I get a chance. Hopefully there are other SteamLauncher users who will find it useful as well.

Hey @fromlostdays! You are absolutely right. There are many games that won't run unless they are launched via the game store launcher they were purchased from.. Just depends if the game dev configured the game to require this or not. The reason many of these games won't run without the parent launcher is the result of licensing checks which require communication via an API between the game and the platform launcher. These licensing checks (and therefore the requirement for the game to be launched via the game launcher) can often be bypassed by replacing a DLL (steam_api.dll/steam_api64.dll [Steam], EOSSDK-Win64-Shipping.dll [Epic], uplay_r1.dll/uplay_r164.dll [Uplay], etc) in the game's directory (or subdirectory) with one of a number of launcher/platform emulators that have been designed by talented scene programmers. These emulators are often created and designed to do a wide variety of different things (allow games to be run without game store launcher being installed, piracy, emulation of online/multiplayer services so non-official servers can be used, unlocking of DLC, etc) but one of the things that they can enable is bypassing all of the checks that the game performs on startup that verifies that the game store launcher is installed and running. While I'm certainly not endorsing the use of any of these emulators (nor am I saying you shouldn't use them.. if you bought the game, do whatever YOU want to do with it as long as it isn't hurting others and their experience of the game), especially for the purposes of piracy, I just thought it would be worthwhile to mention them in the course of explaining why many of these games can't be launched without their parent game store launcher being installed and running. As for importing other game's launchers into Steam and running them that way, I'll address that in response to @Benuno below. I don't think I followed everything you were trying to say @Benuno, but if you're just talking about using Steam to launch another launcher (such as Epic) so that whenever Epic launches a game Steam is able to inject its overlay, then yes, this is possible in a lot of instances... I never stated or suggested that this wasn't possible in my post. The point of my post was to make the point that I cannot add in launcher-specific support for every game launcher, their custom URL handlers, and perform process management on the game and their launchers. Again, I'm not going to go down the rabbit hole again of giving a long-winded explanation of why all of this isn't feasible (search this thread for my previous posts and you'll find lot of discussions about it) but the TLDR is that there is a LOT more going on behind the scenes with this plugin than I'm sure any sane person or programmer would imagine... Most of the reason for this complexity is due to the fact that LaunchBox/BigBox don't have a built in way for plugins to intercept/hijack a game's launch process and parameters (as I mentioned previously). To highlight just one of the issues that would come up if I tried to implement support for game store launchers by launching the game's launcher which then subsequently launches the game: Whenever you launch a game with LB/BB, it messes with window focus/priority to ensure that the game process ends up with focus and after a game exits, it tries to ensure that focus is given back to LB/BB. Furthermore, with LB startup/shutdown screens, this adds even more complexity as LB/BB is also managing these windows' focus/priority over an extended period of time. Now, understand that with the way SteamLauncher works, the exe which LB/BB thinks is the actual game exe, is no longer the actual game exe (it is a proxy exe which doesn't even have a real window).. so whenever LB/BB tries to switch window focus to ensure that the game or startup/shutdown screen becomes the active window, this isn't actually possible because LB/BB believes that the proxy exe is the game which doesn't even have a real window.. SteamLauncher has to fight against LB/BB to ensure that all of these window focus/order issues are ultimately resolved such that whenever Steam launches the game, the game actually ends up as the topmost active window, while also dealing with the startup/shutdown screens and ensuring that they get window focus when necessary... Now imagine adding another game store launcher into this mix... can you see where I'm going with this? And this is just ONE of many, many things the plugin is doing silently in the background to ensure that things just appear to "work". If one wanted to, they could make a wrapper exe/launcher which handles: ensuring the game store launcher isn't running launches the appropriate game store launcher exe with the appropriate game URL parameter to start the game after the game exits, kills the game store launcher process and then use that within LB/BB, which would work fine with my plugin... Hell, I've even added features into the plugin that make this process much easier to do ("Launcher to EXE Relationships").. But as I'm sure you can see, this isn't something that is just "easy" to do or something I can implement willy-nilly to make sure my plugin works with all of these game store launchers. Furthermore, creating a wrapper/launcher exe to do this would STILL require you to edit the game properties within LB such that it points to your launcher/wrapper exe instead of the original game URL as it was originally imported.... which kind of defeats the point of doing it in the 1st place (well.. I guess not for the games that require the game store launcher to be running to launch the game... but I think you see what I'm saying.) So while I appreciate you pointing out that someone has seemingly solved this problem, I can assure you that it unfortunately is not as simple as you may think. Trust me, I wish more than anyone else there was an easy-to-implement, universal solution to this problem. At the end of the day, could I add a feature into my plugin that would allow Epic game URLs in LB/BB to be ultimately translated into the action of Steam launching the game launcher which then launches the game? Yes.. it could probably be done... with hundreds of hours more programming and an ENDLESS number of more bugs/problems/issues... and it could all ultimately stop working when Epic changes a single thing in their launcher... Not to mention, this wouldn't do anything to solve the problem with custom game URLs for Origin, GOG, Uplay, Battle.net, etc and so on... They would all have to be implemented via custom logic too so that the launcher process for each could be appropriately started/killed (and to ensure their window doesn't mess up the window order priority, etc and so on).. which would all have to be maintained individually as well. I created and maintain this plugin by myself with zero financial support and even if I quit my career and dedicated myself full time to the plugin, there still wouldn't be enough hours in the day for me to implement and maintain all this functionality. See what I did now? I said I wasn't going to go into a long-winded explanation again... and what did I do? Exactly that... typed out a long winded explanation that accomplished very little in actually explaining the many, many hurdles and technicalities of why implementing support for such features is not just impractical but totally infeasible.. I can't tell you the number of people who contact me or msg me on Steam telling me how easy it would be for me to implement support for these types of things when they have absolutely no clue how the plugin actually works.. And I'm not even mad nor do I blame them.. From the outside looking in, there is no way to understand all the complicated intricacies and nuances that go into making this plugin work... I think most people just assume that the plugin is just some simple wrapper script or something that just magically makes any LB/BB game launch via Steam with a few hundred lines of simple code... I really, really, really wish it was that easy.. I would have several thousand hours of my life returned to me if that was the case... I really hope this post isn't coming off as me looking like I'm trying to sound like I'm some elite programmer who accomplished voodoo magic or something... While I wish that was true, unfortunately it isn't.. No.. instead the plugin has a large, complicated code base simply because the plugin is trying to do something which, for a whole lot of reasons, is just a messy problem to solve with no real elegant solutions. I just happened to be the idiot that decided to take on such a thing and waste inordinate amounts of my time doing so. Ugh... now I feel like I wasted way too much time writing this post and still didn't confer what I was trying to... Oh well.. Let me know if y'all have any more questions or experience any problems with the latest release. I'm always happy to help however I can!

I've gone into very in-depth explanations of why imported games for other launchers don't "just work" a countless numbers of times in this thread and in private conversations with people who've messaged me. I really don't have the time, energy, or willpower to go over it all yet again.. The long and short of it is that any games that LaunchBox imports and launches using custom URL handlers (i.e. com.epicgames.launcher://XXXXXXXX) are impossible for my plugin to intercept and proxy through Steam. It isn't a "feature" that I can add and it isn't something I can "fix". The way you can easily assess this is by trying to manually add a non-Steam shortcut to Steam and launch your game using one of these URLs (instead of pointing to the game exe). If formatted correctly (start "" "com.epicgames.launcher://XXXXXXXX"), you'll be able to get Steam to launch the game but no matter how hard you try, you won't ever get a working Steam overlay because it is literally impossible for Steam to know what executable it is supposed to inject its overlay into. Steam has no way of correlating between some custom URL handler that is has no understanding of and an actual game executable.. And since at the end of the day, my plugin relies on normal non-Steam shortcuts (that are added in a very roundabout way with lots of workarounds and tricks since Steam doesn't expose these features in their public API and because LaunchBox has no built in means for plugins to intercept and modify a game's parameters mid-launch) and has absolutely no influence over the way Steam injects its overlay into external processes, there is nothing I can do to change the way this functions. You as a user however, can fix the way your games are stored in LB and make the vast majority of your games work just fine with SteamLauncher... You just need to change the game's properties such that instead of launching the game via an abstract URL it is instead pointing to the game's EXE on your machine. It takes maybe 15-20 sec to change.. Give it a shot.

The version of the plugin that was available on the plugin download page was simply broken and wasn't working. I've been very busy lately and simply hadn't gotten around to uploading a new, working build. I've been privately sharing a working build of the plugin with scores of people for quite a while now but just hadn't posted it publicly. However, that is no longer the case now. Just a few minutes ago, I went ahead and uploaded a new, working build of the plugin on the plugin download page (v0.9.7.7). For anyone who has gotten the working build from me privately, the build I uploaded to the plugin download page is no different and there is no reason to download it. For everyone else though, just download the new version and replace all your old files with the new ones, and everything should work perfectly fine. My suggested way of upgrading is to do as follows: Extract all the files in the package, overwriting any old/existing files in "LaunchBox\Plugins\SteamLauncher" Run LaunchBox and leave it running for 30-60 sec but do not launch any games Exit LaunchBox and after it has fully exited, start LaunchBox again The reason I suggest you do things this way is that it gives SteamLauncher a chance to update its vtables.xml file online in case a Steam update has made any breaking changes with its vtable offsets.. After it updates, LaunchBox has to be restarted for the updated offsets to be used. Anyways, please give the newly posted build a try @bryantjs6 and report back here if you have any issues (you shouldn't.. there are a pile of people using this build without any issues).

Sorry @51mm5, I literally just saw that I had a msg here. I'm not sure I'm understanding what you're asking. Every game that my plugin launches is a "non-Steam" shortcut/game. Are you asking if my plugin can be used outside of LB?

Hey Everyone, just wanted to apologize for taking so long to get this update out. I've just been really overwhelmed with other stuff and I'm implementing a lot of really big changes in the next update.. Kind of stuck between a rock and a hard place now since I'm in the middle of implementing these big changes, which makes it really hard to put out a release until I'm finished implementing everything. However, I do have a perfectly working old build which I would be happy to share with anyone who sends me a msg on Steam. There are a lot of people using this build right now without any issues, so if you'd like to use it in the meantime until I'm able to release the update, I would be happy to share it with anyone. My Steam contact info is on the plugin download page. Thanks for bearing with me and having patience!

Quick update: I've got both LB and BB fixed now. I'm working on cleaning up a few other things before I post the new update but if anyone wants to test a debug build of the update right now, hit me up on Steam. It would actually be helpful to have a few people test it out before I post the update officially just to be sure there isn't any major bugs or anything (since I actually had to change quite a bit of code as well as migrate to a new library for this update).

Just wanted to update everyone. I'm still pretty sick (haven't been this sick since I was a kid) but I finally figured out the issue with BigBox. The recent LB/BB update changed the version of a DLL it was using which has caused some unforeseen issues the plugin. I can't really explain why this DLL was updated while none of the other related .NET dlls were (they've been using v4.7 for a very long time and now, only this single DLL has been updated to v5.0 which causes issues because the v5.0 dll expects its own dependencies to be the same version but they aren't.) Regardless, I know what I need to do to fix the problem and I'm working on it now. The entire reason I was relying on the DLLs included with LB/BB instead of including them with the plugin was to save space and so I wouldn't have to start including a bunch of dependencies with the plugin itself. I guess in retrospect it really doesn't make that much of a difference anyways... whats a couple of more files in the zip package (and another couple of MB), right? While I'm at it, I think I'm going to go ahead and port my code to use Microsoft's newer version of this particular dependency. Previously I was using 'System.Management' (WMI) whereas Microsoft now recommends using Microsoft.Management.Infrastructure (MMI). Since I'm having to put the work in anyways, I'm going to go ahead and update things to use this new library. I'll try to get the update out in the next few days if I can. Sorry about the long wait... I definitely wasn't planning on being sick for over a week (I missed this entire week of work and it remains to be seen how much I'm going to miss next week). Thanks for your patience. P.S. If the majority of you use only LaunchBox (as opposed to BigBox) and it would be helpful to have an update the fixes only LB, let me know. I would be happy to share a temporary update that will at least allow y'all to use LB until I get the update out that fixes both.

FYI everyone: I'm aware that the plugin is broken and I've already got LB fixed. Now I'm working on getting BB fixed. I am super sick right now.. Got a fever, sinus infection, etc.. I'm trying to get an update out as quick as possible though.

Hey @rfj831@gmail.com and @JedExodus, sorry for the long delay in responding. I'm looking into the issue with BigBox right now. I have no idea why a minor LB/BB update would break the plugin (and only in BB) but what's new, right? Story of my life... I'll update this post when I know more. Oh, and clearly something has gone wrong if reverting back to the previous version doesn't fix your issue with BB @rfj831@gmail.com... What steps did you take to revert to the previous update?

Hey @51mm5, sorry about the long delay in responding. I've been super busy lately and just haven't had time to check the thread. On the plugin download page, there is info on how to contact me on Steam. I think that would be the easiest and most efficient way to try to figure out what issue you are having. Hit me up and we'll get it sorted out. Being a new user, I suspect the problem is something minor or just a misunderstanding in how things work. Here is a link to the plugin download page which has my Steam contact info:

Hey @rfj831@gmail.com, I tested out Retroarch with the Duckstation core and I'm not having any issues with the Retroarch window losing focus. It is really hard for me to say what it could be without doing some further investigating some of which will require some info from you. For one, do you have "Prevent Steam Focus Stealing" enabled in the SteamLauncher options? Also, are you using Startup, Shutdown, and/or Pause screens in LB? I do all of my testing without Startup/Shutdown screens enabled. When you try other cores in Retroarch, you said you don't experience this same issue, right? You can try enabling debug logging, then run a game with the Duckstation core, then close Retroarch, close LB, and then upload the debug.log file to pastebin and send me the link. Honestly, I'm not sure how much help that will be but it is worth a try. Additionally, if anyone else watching this thread could maybe try out the Duckstation core on Retroarch and let us know if you are or are not having issues with the Retroarch window losing focus, that would be super helpful. Maybe @JedExodus might offer to try it out? Thanks!

Really!? Damn... I already addressed that issue once in the past and it was a total bitch. The reason it was so problematic to fix was because of a bug in Steam's handling of unicode characters. Essentially, Steam would mishandle its interpretation of Windows paths from UTF-16 (which WIndows paths use) to UTF-8 (which Steam uses). As a result, I had to intentionally mangle the path data into an incorrect value so that Steam would then interpret it correctly. Perhaps Steam has finally fixed their bug (after a couple of decades) when they made all of the significant changes to the Steam library and UI. I've moved this issue to the top of my 'to-fix' list along with the issue reported by @rfj831@gmail.com about the Duckstation Retroarch core. Btw @JedExodus, did you ever get the issue resolved that you reported concerning changing your Retroarch core to Beetle? If not, can you give me some additional details? Does changing the core back to the previous core make it start working again? How about trying a different core? I assume you tried restarting LB and Steam and you double checked your emulator and rom paths? Any additional info you can give me that would make it easier to look into would be appreciated.

Hey @rfj831@gmail.com, just wanted to let you know I haven't forgotten about you. I'm going to download that core and try to implement a solution for you just as soon as I get a chance. I'm incredibly busy with work stuff at the moment but I will get to it just as soon as I can.

Thanks for the confirmation on that @C-Beats. I couldn't imagine any scenario where that would not be the case. Now that we know that, I can't imagine why the tray icon launch game feature wouldn't be working with the plugin as there should literally be no difference. Guess I'll have to check it out and see what is going on...

Hey there @rfj831@gmail.com, the problem you're experiencing isn't unheard of. No joke, I've probably spent over 40-50 hours working on/tweaking the code for handling window focus. The core of the issue is that I am fighting against LB/BB which is also trying to manage which window is active/focused for both its startup/shutdown windows and the actual game/emulator window. Currently, there is no way to deal with this type of issue in the LB plugin API so I am having to work with/around LB doing its own thing. For the most part, the code as it currently is deals with most situations pretty well but there are certainly edge cases as you've found. One thing that would be really helpful for you to try in order to give me a little more info is trying Retroarch with that same core but without using SteamLauncher. When you do this, is the window focus being handled correctly? I've come across a few instances where LB won't focus the game/emulator window after it starts running and if this happens, it is even less likely that it will work correctly with SteamLauncher. The win32 API for handling window focus/active/z-order is a mess and it can do strange things and work in ways that are simply baffling. If the window focus is working correctly when not using SteamLauncher, I will download the Retroarch core and see if I can fix the issue for you. Just out of curiosity, in Retroarch, are you using windowed mode, windowed fullscreen mode, or fullscreen mode? Also, do you know what video driver you are using?

Hmm... I can think of a possible cause for this.. Let me take a look at the code and I'll get back to you.

Ah ok.. I understand now. Unfortunately, if the plugin isn't working when you click the system tray option to launch one of your recently played games, I doubt there is going to be anything I can do about that. My plugin hooked into LB's 'PlayGame' (can't remember exactly what its called off the top of my head) so if that function and its related callbacks aren't being called by LB, there probably isn't anything I can do about it. I can't conceive of any reason why launching a game through the tray icon wouldn't call the same exact function as double clicking a title in LB itself or why doing so wouldn't invoke the plugin API callbacks but it sounds like that is likely the issue. I will check it out to be sure and if it is indeed the case, I will shoot a msg to the devs and see if we can't get it fixed. Thanks for letting me know about the new feature (and the problem with it) @Nokiaman. @fromlostdays, I will try to reproduce the issue according the instructions you supplied. Thanks for the info.

Tray icon? Obviously I'm not up to date on this new feature. Care to explain how it works? Also... why would you want to launch a game via LB through a tray icon? Surely I must be missing something...

Hey @fromlostdays, I am really sorry that I am only just now getting back to you. Despite reading your msg the day you posted it, it has been a very crazy week for me, and I just haven't had a chance to respond. I'm not really sure what to make of your issue as my plugin never even reads the game's 'Version' field so it doesn't know what is in this field or that it even exists. I have an extensive Wii U library and while most of my imported Wii U games have the string 'code' in the version field, some games have different strings in that field such as 'USA v1.20', '[APKE01] [USA] [Loadiine]', and '[ARME41] [USA] [Loadiine]'. All of those games work fine. I even tried modifying some of my games to have different content in the version field and experienced no issues (which is completely expected since the plugin literally has no knowledge that this field even exists.) The only conclusion I can come to is that you were possibly experiencing a different issue that that you inadvertently and unknowingly fixed and erroneously attributed the fix to changing the data in the version field. If that is not the case, then I do not have any viable explanation as I have never had anyone else report a similar problem or experienced it myself... and again, I wouldn't even know how to explain it if it did actually happen since the plugin never reads or has any concept of what LB game version field is. If you can provide a concrete explanation on how to reproduce the issue then I would be happy to look into it further but otherwise, I'm kind of at a loss. Sounds like you at least got things working now though so hopefully you're not having any other issues. Sorry I couldn't be of more help.

Good news! @C-Beats saw my previous post and sent me a PM. He said that they would be open to me posting a new issue on the BitBucket page with my desired plugin API changes. Obviously he isn't promising anything but I think it is worth the time/effort to give it a shot. As soon as a I get enough time, I'm going to write up a detailed proposal and submit it. Hopefully the LB devs and I can collaborate to get the needed functionality added to the API. I'm looking forward to seeing how the changes could optimize/streamline the plugin. Hopefully everything works out! I love the pic of your dog @JedExodus! He reminds me of a dog my grandma used to have named Fuzz.

@mrdead and @Corgana, I sincerely appreciate the kind words. You all are too kind While I doubt I will be getting a job offer from Jason any time soon (I believe he just hired 1 or 2 talented devs in the last couple of years), I would certainly love to contribute to LB in a more official capacity. I'm sure Jason and the current devs have many plans for LB already and a very long list of to-do's as it is though, so I won't be holding my breath One thing I would love to see however (and perhaps is a bit more realistic) is further development of the plugin API which would allow MUCH easier integration with LB and eliminate the need for a TON of workarounds and ugly hacks that I am currently using to get around the fact that the LB plugin API does not support a lot of functionality that I really need it to. I've actually spoken with Jason about this in the past and he did actually implement some additionally functionality into the plugin API. However, either due to a miscommunication on my part, a misunderstanding on his part, or possibly just a lack of time amidst many other plans (at the time, I believe Jason was still the lone developer of LB), the new plugin API functionality fell short of what I actually needed it to do. I believe the amount of code and time that it would take to integrate these few features into the plugin API would be relatively minor so perhaps there is some hope that it may be implemented at some point in the future... (?) When I have some extra time on my hands, perhaps I will write up another detailed proposal for the desired plugin API functionality and propose the changes to the dev team in a new thread. Perhaps with enough upvotes from the user base of SteamLauncher, we might be able to get the proposed changes implemented. Not really sure since it is entirely out of my hands but I think it is more likely the desired features will be implemented into the API if the developer know those features are going to be useful to a significant portion of their users. It would make me VERY happy to be able to remove all of the hacks/workarounds code currently in the plugin and it would significantly clean up the code base and make it much easier to read and comprehend. Hopefully at some point this will become a reality.

@JedExodus Thanks man. You've been around since I can remember and I always appreciate your support.

@Aetavicus: Restarting on the day when you tested the issue wouldn't have caused the updater to download anything new because I hadn't yet updated the online DB. It wasn't until your post that I was aware that the Steam update had broken compatibility with the plugin. Once I saw your post, I looked into what the problem was and discovered that Steam had altered the IClientEngine vtable offsets again. Although it is not really important to understand that means, basically the plugin wasn't able to locate the correct address for a function within "steamclient.dll" that it needs to call in order to operate correctly. Once I figured out what the issue was, I was then able to update the online db with the new, correct offset values. Only after I updated those values would the auto updater be able to retrieve those new values and therefore fix the issue. Hopefully that clarifies things a bit.

Awesome, thanks for the response @Corgana