Lahma
-
Posts
403 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Articles
Downloads
Gallery
Blogs
Posts posted by Lahma
-
-
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!
-
1
-
-
1 hour ago, percybuttkins said:
Thanks!
Looking forward to trying it out this weekend potentially!
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).
-
1
-
2
-
-
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.
-
1
-
-
6 hours ago, percybuttkins said:
I am curious though.... When you have the time.... What is steam doing that continually borks this though. Nielk had the same issue if I recall with steam changing how the shortcuts are handled... Just curious out of all the things steam needs to work on.. Why does the code regarding these shortcuts keep changing...
More curious than anything.... On a side note... I'm assuming I can block steam from updating... Once this works I'd like to keep it working ?
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.
-
2
-
1
-
-
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
-
1
-
-
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.
-
1
-
1
-
-
8 hours ago, The_Keeper86 said:
You're right I tried other consoles and they worked. Its something to do with PCSX2. It used to work though. I'll keep messing with my settings. Sorry I jumped ahead thinking it was the Steam update
*edit* change PCSX2 settings even launching it from Steam itself and still get a black screen for the overlay. Steam or PCSX2 devs must've messed something up.
At least you figured out exactly what was causing the problems.
-
2 hours ago, The_Keeper86 said:
Cool ok. No I haven't changed anything. Only thing I've done is move everything to a new HDD but I'm using the same drive letter for this drive and haven't had any other issues. No problem man hope you can find out what is going on
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!
-
7 minutes ago, Musungo said:
Yeah basically thought it'd be a fun coding project
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.
-
7 minutes ago, Musungo said:
I'm essentially trying to do what you described above with PCSX2 specifically, My goal is to take what game PCSX2 says it's playing and hand it to steam so you get per game configs from one exe. Also I love this plugin use it all the time and I guess it's partially my inspiration for tackling my project so thanks
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!
-
Just now, The_Keeper86 said:
I used it Thursday, Friday and Saturday night with no issues on the non beta.
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.
-
On 6/8/2018 at 10:38 AM, Lahma said:
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!
@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.
-
1
-
-
@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 -
@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!
-
9 minutes ago, The_Keeper86 said:
I see it now. I should've read the page. Sorry about that.
No problem man. I ain't mad at ya ?
-
1
-
-
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!
SteamLauncher
in Third-Party Applications and Plugins (Released)
Posted · Edited by Lahma
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