Jump to content
LaunchBox Community Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

21 Excellent

1 Follower

About Lahma

  • Rank
    16-Bit Artificial Intelligence

Recent Profile Visitors

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

  1. While I'm not sure exactly what the final app would look like in such a project (like, do you want to make like you're own little mini game launcher for PCSX2 that would allow you to add all your roms into it, or simply have just like a command line proxy exe that you could use to launch a specific rom in PCSX2 which would then show the Steam overlay and such?), it sounds like it would be fun project, and I suspect you could use the Steam API I wrote for my plugin as almost a drop-in solution since you would need essentially the exact same functionality that my plugin uses.
  2. Oh, and I really appreciate the compliment on my plugin! I put a lot of time and effort into it, so its always great to hear from others that they get as much use out of it as me!
  3. So you're saying you basically want to use the "Launch via Steam" functionality directly in PCSX2 without using LaunchBox as the frontend?
  4. I wish there was a quick and easy answer I could give to you, but it just isn't a simple task. I can give you a quick overview of the process, but the difficult part involves calling undocumented native functions over IPC in the steamclient.dll/steamclient64.dll libraries. If you're really serious about tackling the problem and are committed to spending the time required to reversing the Steam client DLL in a disassembler (I would suggest IDA Pro) and gaining a good understanding of how it works, then it is definitely doable. However, even for the relatively simple tasks that I wrote my custom API to accomplish, I spent weeks, if not months, learning the in's and out's of the Steam client. You can try to use one of the available open source Steam client API wrappers that are available, such as Steam4Net, but that route is unfortunately not simple or free of heartache either. They don't seem to be actively updated by the authors (although there are some forks that seem to be updated at least several times a year), so when a Steam update changes the API and subsequently breaks the API wrapper (which happens pretty damn frequently), your application will cease to function until someone fixes it. My project is open source, so you are free to look at the API I wrote and use it as you see fit. Since I don't know what it is that you are trying to accomplish, I can't say whether it will work for your purposes, but if it does, you can count on me keeping it functioning and fixed usually within a day or so after a Steam update. The general process looks like this: User clicks on "Launch via Steam" in the LaunchBox context menu Plugin gathers all the information about the specific game Plugin API sets up an IPC connection with the Steam Client Calls native Steam client functions to create/recycle a hidden Steam shortcut Launches the newly created/modified Steam shortcut That is a overly-simplified explanation of the process, but if you look at the source code, you can get a better idea of the specifics. There are of course other ways that you can go about managing "non-Steam" shortcuts in Steam, such as modifying the file where Steam stores all of that data (shortcuts.vdf), but that unfortunately requires you to shutdown/close Steam and then restart it after making those modifications. The only way to do it while Steam is open and running is to interface with the Steam client dll. If there is any additional information I can help you out with, just let me know. Good luck!
  5. Cool, thanks for the info. Looks like it might just be an issue on cammelspit's end.
  6. Ok, so I've tried every both the beta and non-beta Steam clients as well as beta and non-beta LaunchBox, and I've encountered zero issues so far. When cammelspit gets back online I will talk with him directly and see if I can figure out what is going on, but in the meantime, if anyone else is having any problems with the plugin, please let me know so I can look into the issue further. Thanks!
  7. I got a message from @cammelspit saying that there is a problem with the plugin. I've been gone all weekend and just got home, so I will look into the problem immediately. I just tried using the plugin on non-beta Steam and it appears to still be working fine, so I'm guessing the problem might be with the latest Steam beta release. I am going to boot up my VM that has Steam beta installed and look into it right now.
  8. @Nielk1Hey Nielk, just in case you did not already see this, I thought I would tag you to let you know I FINALLY uploaded the source onto GitHub. Do be aware however that I have not implemented (into my custom Steam Client API) any (well, hardly any) of my WIP code to help increase resiliency against code-breaking Steam Client updates. I'm still trying to workout what method, or combination of methods (such as pattern matching or MSVC runtime type information parsing), is the best approach, especially in a use-case such as my plugin where so few classes/methods are actually needed. The only code present in its current form that does anything to work around future updates is in SteamClient-> SteamContext -> InitClientEngineInterface(), and this is just a very simple loop that tries to work around IClientEngine's version # being updated in future beta or non-beta releases. IClientEngine is by far the most commonly updated class (or the vftable entry to retrieve an instance of the class), at least in my experience, and this simple loop has actually already prevented the entire plugin from breaking due to Steam updates at least 1 time, and perhaps 2 (I can't remember at this point). The Steam API should be mostly self explanatory and easily duplicable once you have vtable/vftable offsets for the classes/methods you need (I can give you any of these straight from the latest Steam client dll.. just let me know). The only part that might be a bit tricky to follow is SteamInterfaceWrapper which is present mostly to allow shorter, easier-to-read delegate declarations in the main client interface implementations such IClientShortcuts. Additionally, it caches delegate instances once they've been resolved in order to speed up subsequent calls. Or, you might find it easier to just continue using whatever API you currently are (since it likely has all of the Steam interfaces implemented rather than only select ones such as mine) until I implement some of the WIP code designed to increase resiliency against updates. I'm not really sure mine would provide much benefit as of now... although to be honest, the IClientEngine-related vtable offsets are the only ones (out of the interfaces I use often) that I've seen change in quite awhile, so using something like the simple loop I implemented to test for increases in the version # might help you out if you're experiencing the same. Note: I wrote this post after a few drinks while I was very sleepy and after being awake entirely too long, so I apologize if I droned on and on. 🙄
  9. Lahma

    LB API additions time table?

    @Jason CarrNo problem, I completely understand. I would be happy to send my resume your way. I have a Computer Information Systems bachelor's degree, and I currently run my own computer service/repair/consulting business, but I have enough free time (probably because I'm single 😉) that I'm always interested in taking on interesting new projects/job opportunities. My background is primarily in reverse code engineering and bug hunting (exploit development), but I have extensive experience in C#, Python, and some Ruby (because for some perplexing reason, Ruby is the scripting language of choice for Metasploit). I'll send my resume your way just as soon as I get a chance to look it over and bring it up to date.
  10. Lahma

    LB API additions time table?

    @Jason CarrWow, that would be great! I would be happy to to write some, or even a majority, of the code if that would help in taking some of the workload off your shoulders. Having worked with the plugin API a bit, I have a pretty good idea of the classes (or at least the exposed interfaces) that would likely be used in such functionality, so I could probably at least lay out a decent framework for the event handler and such. However, if you think that would be a waste because I don't have enough knowledge of the underlying (unexposed) code, or you would simply prefer to do write everything yourself, I completely understand. Its just a friendly offer on my part to help out if at all possible! Thanks for the quick reply and the willingness to help out Jason. Have a good one. You can see an example of my C# by looking at the GitHub for my plugin. Nothing too fancy, and definitely not in a completed/finalized state, but its something: https://github.com/lahma69/SteamLauncher
  11. Lahma

    LB API additions time table?

    @Jason Carr Well, I didn't intend to take 6+ weeks to make this post, but I got busy and forgot about it until cammelspit recently reminded me of it. Let me try to briefly explain the reason why the plugin API in its current state can't accomplish what I would like it to be able to accomplish in order to fully realize the goals for my plugin, and then I will suggest some ways that the API could accomplish those goals in a relatively easy-to-implement way. My plugin in its current state simply adds a single item to the bottom of the game context menu, and when clicked, it gathers all of the needed default game/emu/rom/arguments/etc paths for that particular title and then using a custom API I wrote, makes native calls into unexposed functions in the Steam client in order to create a temporary shortcut in Steam and subsequently launch the game through the newly created Steam shortcut. I won't go into any more detail, as I don't really think its relevant, but I will instead explain the problem the plugin currently faces. Since you can only create/implement classes based on IGameMenuItemPlugin at design time, and additionally since any changes made to the properties of one of those classes during runtime are not reflected in LB/BB, it severely limits my ability to do things a dynamic way. The precise problem that I'm facing is that I would like to be able to create a submenu of additional "Launch via Steam" items at runtime based on how many non-default emulators/platforms a particular item has, almost EXACTLY like the "Launch with" menu item you already have implemented. The way the plugin API currently works though, this obviously cannot be done, so I'm forced to include only a single "Launch via Steam" menu item that uses the default emulator/launcher that is assigned to any particular title. One more quick issue that is relevant is that there is currently no way for my plugin to allow LaunchBox to handle the decompression of roms prior to launch, so I would either have to redundantly implement this behavior myself, or simply not support compressed roms that are handled by LaunchBox. In my opinion, there is a simple and elegant way to implement this functionality into the plugin API that would figuratively "kill both of these birds with one stone." By implementing a "LaunchGame" callback/event that can be subscribed to via the plugin API, a plugin could subscribe to this event and receive all of the launch parameters for a specific title (that would change depending on whether the default launch option was selected or one of the non-default 'Launch with' options), including the path to the decompressed rom (if LB was designated to handle that). Handling the event on the plugin side might look like something in my plugin's case: static void launchGameEventHandler(object sender, LaunchGameEventArgs e) { if (!this.LaunchViaSteamByDefault) { e.CancelLaunch = false; return; } IGame game = e.Game; IPlatform platform = e.Platform; string[] launchParams = e.LaunchParams; string appPath = game.ApplicationPath; [...etc and so on...] if (e.IsAppDecompressedByLb) { if (!string.IsNullOrEmpty(e.DecompressedAppPath)) { appPath = e.DecompressedAppPath; } e.DeleteDecompressedAppOnLbExit = true; } e.CancelLaunch = true; this.LaunchGameViaSteam(game, platform, launchParams, [...etc..]); } This is of course an oversimplification designed only to give you an idea of what I had in mind, but does seem like it would not be very difficult to implement. If my plugin had something like this to use, then instead of having a context menu item labeled, "Launch via Steam", I might instead implement a checkbox context menu item labeled, "Use SteamLauncher by Default", and as long as this is checked, all games would by launched through my plugin rather than through LaunchBox itself. I would appreciate any feedback on the idea, and any indication of whether or not its something you might be willing to implement. I think it would make the plugin API much more diverse and capable, and a simple event/callback system like this could be used for a wide variety of things. Thanks for your time!
  12. I'm a total ass for taking so long to post the source code, but its finally uploaded on my GitHub. Sorry about the delay... My OCD/perfectionism gets the best of me at times (though the source code is far from perfect). I did do my best to comment/document the source code in as detailed a manner as possible. Enjoy! https://github.com/lahma69/SteamLauncher