Lahma
-
Posts
404 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Articles
Downloads
Gallery
Blogs
Everything posted by Lahma
-
Just out of curiosity, does it also work while using SteamLauncher? Now that I understand RL a bit better, I don't think using RL really negates the usefulness or purpose of using SteamLauncher. RL, or no RL, it still serves the exact same purpose (that is, if the Steam overlay still works). I don't know if RL has some type of controller configuration options built in, but I can confidently say that NOTHING comes close to Steam in that regard. Then again, I'm a bit of a geek when it comes to setting up controller profiles (multi-layered radial menus, custom icons in radial menus, custom mouse click coordinates [for things such as 3DS games' touch menu items], custom gyro triggers, etc). I doubt most people make such thorough use of Steam's endless advanced controller configuration options (though some people even take it much farther - *cough* @cammelspit *cough).
-
I think maybe you've misunderstood the purpose of this plugin (or maybe not, its kinda hard to tell from your post). The description of the plugin explains it very thoroughly, but the whole idea of this plugin is to allow you to launch any game, emulator/rom combo, or really anything through Steam, without the need to explicitly add any non-Steam shortcuts to Steam. It allows you to right click any game/rom inside of LaunchBox and click "Launch via Steam", and it will automatically launch that game or rom/emulator through Steam with the Steam overlay enabled, at which point you can setup any controller bindings you want, and those bindings will be saved between gaming sessions (and your Steam game library will not be cluttered with hundreds/thousands of shortcuts for all the different roms you play, as the plugin transparently reuses only 1 hidden Steam shortcut for everything it does). You also get the additional benefit of having your Steam status automatically show whatever rom/game you are playing (again, without actually having an explicit non-Steam shortcut setup for that rom/emulator). For example, your status might show "MadK9 is playing 'Super Metroid (SNES)'". Maybe this helps explain a bit better why I was confused about HTPCei's use of RocketLauncher in combination with SteamLauncher. SteamLauncher requires you to click a context menu item for any given rom within LaunchBox itself, and then SteamLauncher handles the launching of games, roms/emus internally (it gets the proper emu/rom paths and command line arguments from LaunchBox, but then it actually utilizes a function in the Steam API to launch the newly reconfigured hidden Steam shortcut). For that reason, I'm not making the connection on how RocketLauncher fits into that equation in any way. I guess it could just be that you have RocketLauncher setup as your emulator within LaunchBox (and then it handles actually launching the correct emulator itself), and therefore SteamLauncher is actually launching RocketLauncher, which then launches the correct emulator/rom. However, if that is the case, I'm surprised with all of that redirection, that any emulator would still open through Steam and actually display the Steam overlay correctly. If it does though, then awesome! Or maybe I've totally misunderstood this whole thing ?
-
Being that I am not a user of RocketLauncher, and I know very little about it, I unfortunately probably cannot provide much help. As a result of my lack of knowledge concerning that topic, I don't really understand why you would want to use LaunchBox+RocketLauncher+SteamLauncher. Can you explain to me what the purpose of that workflow is? One thing I can state with certainty is that almost nothing has changed in SteamLauncher between the last release and this beta release. Quite literally the only change is that I'm forcing the code to use a static offset instead of trying to be "smart" about what offset to use. To the end user, the functionality is 100% identical, so if anything broke in your workflow, it should not have anything to do with SteamLauncher. Additionally, SteamLauncher doesn't use or create any environment variables such as "%default emulator%", so that error doesn't have anything to do with SteamLauncher. If there is anything else I can help you with, or any further clarifications I can make for you, just let me know, and I'd be happy to help out however I can.
-
Here is a quick beta release that should be working fine. It is the DLL only, so just replace your existing SteamLauncher.dll with the one in this zip. Let me know if you have any problems with it. SteamLauncher_v0.9.0.3_Beta-DLL_Only.zip
-
I just wanted to let y'all know I haven't forgotten about updating the plugin. I had some unexpected family matters arise that have taken priority above all else. I have actually fixed the plugin by manually changing an offset value, but it definitely is not the way I want to fix the problem for an official release. Instead, I want to fix the problem in a way that will prevent the plugin from breaking again in the future from similar changes in Steam client updates. However, if y'all would like me to post a pre-release/beta version of the the plugin with the simple offset fix, I would be more than happy to post it here on the forum. If you want me to do that, just post a reply here, and I will upload it asap. Again, sorry for the wait!
-
I have completely resolved the issue in the code that was causing problems. Specifically, the reason the logs were showing, "Searching {ridiculously.large.number} shortcuts to find all SteamLauncher shortcuts" is because my code was making an incorrect assumption about the length of a certain vtable corresponding to a certain offset in said vtable. I won't go into details, but basically, the code I wrote previously to make the plugin compatible with both the Steam beta and non-beta (which had different offsets on a particular vtable for quite a long time) was causing problems. I'm going to implement a different strategy in this release for dealing with potential future changes. Its definitely not infallible, but if the pattern of changes remains relatively consistent with what I've seen over the last couple of years, it should deal with future issues elegantly (though the "hackish" code for dealing with these potential changes is anything but elegant). I could expound on why I don't implement some other strategies that are effective in other situations (such as signature scanning), but I won't bore y'all with the details. I'm going to finish implementing this new code, and then I will push a new version of the plugin out to GitHub. I will let y'all know when the new version is available (though I definitely expect it to be sometime tonight).
-
Ok, I found the problem, and I'm working on a fix right now. The problem was indeed related to one of the virtual function table offsets changing. Although I did add code into the plugin to try to be resilient against these types of changes, it did not account for the type of change that occurred in this last update. I am going to be adding some additional code that will try to detect these types of changes in the future and automatically adjust the offsets appropriately. Hopefully I can get a new release pushed out tonight. I'll keep y'all updated.
-
The main problem stems from the fact that Steam does not implement a public/documented API for management of the Steam client shortcuts. As a result, any applications that modify the Steam shortcuts while Steam is running must hook into the native code of the Steam client and make use of code/functions that Valve never intended external applications to use. If they were intended to be used, these functions would exist in the app's export table and could be easily called by a published name and type signature that would never change and always point to the right piece of code. Since these functions aren't intended to be used by external apps, the means by which an app like mine uses to get a pointer to that functions can be easily broken by a Steam update changing the virtual function table offset, interface name, etc. You will find other utilities that manage Steam shortcuts by modifying the actual file that Steam stores its shortcut data inside of, but the major downside of this is that it must be done while Steam is not running (and therefore makes it impractical for things my plugin needs to accomplish). Shortly after releasing my plugin, I added some code which made it more resilient against Steam client updates, and it has actually worked relatively well so far, as I think I've only had to fix the plugin 1 time due to a Steam client change that broke its functionality. I'm assuming they made a pretty big change (such as changing the order of the virtual function table pointers or something) which is the reason it broke this time, but seeing as I haven't had a lot of time to take a detailed look into the problem, that is just speculation at this point. I wouldn't worry too much about Steam updates breaking the plugin frequently, since as of yet, that hasn't really been too much of a problem. I usually have the problem fixed in a day or 2, and at least up until now, its been pretty infrequent. Trying to prevent Steam from updating is a pain in the butt (unless you're ok with just blocking its internet access altogether). Hopefully I can look into the problem tonight. That is the plan anyways. I will keep y'all updated.
-
I just wanted to give you guys an update and let you know I've located the chunk of code that the problem is occurring in, but it is going to take some digging around in the new steamclient.dll inside of a disassembler to figure out what the exact problem is. I don't think its going to be anything too monumental, but unfortunately, I'm definitely not going to get a new build pushed out tonight. Hopefully I'll get things patched up tomorrow though. I will definitely keep y'all updated with my progress. I promise not to keep y'all waiting too much longer
-
Damn, I'm so sorry guys. I haven't checked my email in a couple of days cause I've been out of town, so I didn't even know y'all had posted here until percy messaged me on Steam. It appears that either a Steam update or a LaunchBox update has onced again broken something (part of the inevitable battle that has to be waged constantly when using undocumented Steam functions, as this plugin does). I will look into the problem here in just a couple of hours, or at the very latest tonight. Hopefully I can get a new build pushed out tonight that fixes everything. Check back here for an update later on.
-
At least you figured out exactly what was causing the problems.
-
After a lot of testing here on my end, I can't find any problems with the beta or non-beta Steam client (latest versions). I think its probably an issue on your end, but I'd be happy to help you figure out what the problem is. Have you tried using the Steam overlay on a Steam/non-Steam game that is launched straight through the Steam client (rather than through SteamLauncher/LaunchBox)?
-
I'm fixing to look into the problem. As long as nothing has changed on your setup (besides Steam updating) and you've launched this emulator/rom combination using SteamLauncher previously, it is most likely the Steam update that is causing the issue. If I need you to test/try anything, I will let you know here shortly. Thanks again.
-
I will look into it immediately and get back to you asap. Thanks for the heads up! Oh... one question though. Are you running the beta Steam client or non-beta?
-
No problem, and good luck!
-
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.
-
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!
-
So you're saying you basically want to use the "Launch via Steam" functionality directly in PCSX2 without using LaunchBox as the frontend?
-
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!
-
Cool, thanks for the info. Looks like it might just be an issue on cammelspit's end.
-
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!
-
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.
-
@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. ?
-
@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.
-
@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
