Lahma
-
Posts
404 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Articles
Downloads
Gallery
Blogs
Everything posted by Lahma
-
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).
-
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)?
-
I really appreciate the kind words. It is surprising how motivating a simple "thank you" can be. ?
-
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.
-
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?).
-
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.
-
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; }
-
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
-
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.
-
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!
-
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!
-
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.
-
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!
-
@Jason Carr Ya, I would love to see these changes implemented in the plugin API whenever you are able to get around to it. It would really open up a lot of possibilities when it comes to implementing additional functionality into my plugin. There is so much more I would love to do, but right now there just isn't a lot more I can do with the current limits of the API. I appreciate all the hard work going into LB. Hopefully we can get some updates to the plugin API soon, making it that much better. Thanks Jason!
-
Alright, I figured out the issues, and I think I got everything resolved. I just updated the plugin download page with the new version (0.9.0.5). If anyone has any problems with it, please let me know. Thanks! Here is a quick link to the new version if you don't want to download it from the official plugin download page: SteamLauncher_0.9.0.5.zip P.S. I also updated the GitHub page for the plugin.
-
Working on a fix. As has been pretty typical recently, I haven't fixed it as quickly as I intended, but I should hopefully have a fix uploaded soon.
-
Just see if any existing game/rom you have will launch using SteamLauncher. My LaunchBox is freezing right now when trying to use the plugin. I've been so overwhelmed the last couple of days that I haven't had any time to look into it in detaill. I did briefly attach a debugger to it, and it appears that the general Steam client API hooks are working fine, so that is what led me to believe that it could possibly be something on my system, rather than a problem caused by the recent Steam update. However, like I said, I just looked at it very briefly, so it may still have something to do with the update. If you right click on a game in LaunchBox and click "Launch via Steam", and your LaunchBox freezes, then I will at least know that it is something related to the Steam update. I may still have time to look at it tonight, but I may just wait till tomorrow. Whatever it is, I suspect it isn't going to be anything to complicated to figure out. Thanks for your help!
-
Can someone else confirm that they are having issues since the latest update as well? I'm fixing to start looking into it, and I just wanted to make sure it wasn't some unrelated issue specific to my system.
-
Looks like the Steam update last night might have broken something in the plugin. I'm looking into it. I'll try to post an update today if I can.
-
No problem. Thanks for helping me fix it!
-
Here you go buddy. Give this one a try. I think it should resolve the issues with relative paths. SteamLauncher_v0.9.0.4_Beta-DLL_Only.zip
-
Even if Steam did handle relative paths, the paths are relative to the LaunchBox directory, not the Steam directory, so they wouldn't work. So ya, the problem is definitely my plugin. In all instances other than the 'Root folder' ('Start in'), my plugin resolves all relative paths to absolute paths before feeding them to Steam, so its clearly just an oversight on my part (an oversight that I am a bit mystified as to how it hasn't been noticed or reported by anyone thus far). Regardless, I will fix it asap. In fact, I'm going to try to do it right now, and I will post a new release with the changes. I'll report back here as soon as I have the new release uploaded. Thanks for all your help man!
-
Right click on Sonic Heroes in LaunchBox, and click 'Edit'. Tell me what is the path inside of 'Application Path' under the 'Launcher' tab. Also, tell me what is the path inside of 'Root Folder' under the 'Folder' tab. It appears that my plugin isn't resolving the relative path of the "Start in" directory to an absolute path correctly. Its kind of wild I haven't heard any complaints about this problem previously if that is indeed the issue, but I guess maybe most people are using absolute paths for that particular entry in their pc games. Once you send me back those 2 values, if that is indeed the case, I will fix it asap and upload another beta. Thanks for working with me on this, and sorry my response has been a bit delayed... Just been a bit busy, not to mention I have a serious sinus infection on top of everything else.
-
I just checked, and all PC games are working fine for me. What exactly is it doing after you click "Launch via Steam"? Is anything happening at all? Go ahead and post your debug log, and I will take a look at it. One thing you can do to check if SteamLauncher is creating the temporary non-Steam shortcut correctly is to open your Steam game library, hover your mouse over "Library", click "HIDDEN", and look for a shortcut named after the last game you tried launching (it will likely be the only hidden Steam shortcut if you've never created any yourself.) By right clicking that shortcut and clicking "Properties", you can check the path, launch parameters, etc, to see if something is wrong. You can even try manually launching the shortcut. Anyways, post the debug logs, and I'll take a look. I gotta admit that I'm a little skeptical that this has anything to do with the plugin, as I haven't changed anything in regards to this functionality, but I suppose its not impossible. Hopefully we can get the problem fixed whatever it is.
-
Basically anything should launch using SteamLauncher since v0.9.0.2. Have you tried any other PC game besides Silent Hill 2? Its kinda hard to offer any kind of help when the only thing you've provided is "xxxx doesn't work" and you've not provided any debug logs or anything. Also, are you using the beta release I attached to my post 1 or 2 pages back? The release on the main plugin download page will not work currently. The beta release attached to my post should work fine though. One other thing to keep in mind when launching many PC games is escalated privileges. Just like if you try to add a non-Steam game shortcut to Steam manually, and that game requests privilege escalation as soon as it launches, but Steam isn't running escalated, the Steam overlay will not be able to attach to the game. I don't think I've actually come across a single PC game that actually needed admin privileges, but for some inexplicable reason, many publishers enable that flag on their game executables. Unless you want to run LaunchBox and Steam as admin, which I don't suggest, the easiest way around this problem is to launch your game using a command such as this: cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" "path\to\game.exe"" This will force the game to run with the same privileges as the process that starts it. Let me know if you have success using SteamLauncher (the beta release) with other games, and we can move forward from there to try to troubleshoot Silent Hill 2.
