Jump to content
LaunchBox Community Forums

Lahma

Members
  • Content count

    110
  • Joined

  • Last visited

Community Reputation

38 Excellent

1 Follower

About Lahma

  • Rank
    32-Bit GPU

Recent Profile Visitors

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

  1. 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
  2. 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!
  3. 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.
  4. 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.
  5. 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.
  6. 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).
  7. 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 😄
  8. 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.
  9. 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
  10. 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!
  11. 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).
  12. 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.
  13. 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.
  14. 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
×