Lahma

September 13, 2020

On 9/9/2020 at 10:52 AM, Jason Carr said:

@Lahma Sorry for the added difficulty for plugins with the 11.4 release. I understand the frustration. I do wish the .NET Core upgrade had been a smoother experience, but I still feel that it was necessary, even with it being the major challenge that it was.

Thanks for those helpful notes @JoeViking245. Let us know if they help you get back up and running @Lahma.

Thanks for responding to my post @Jason Carr. Unfortunately @JoeViking245s post wasn't helpful. He didn't understand what I was talking about. I can show the anti-debugger code in Unbroken.LaunchBox.Windows.dll in Dnspy. This has nothing to do with the Visual Studio problems. Obviously you can give more info than I can about the circumstances under which it is triggered, but no, this has nothing to do with the LaunchBox launcher executable exiting after launching LaunchBox.exe in the Core directory. I'm launching LaunchBox using "dotnet exec LaunchBox.dll" inside of the Core directory. Here is the anti-debugger code I am referring to:

// eJ8pBAv9gAr1FwnyGOP.cXM0gavBtCyXsWVqWP5
// Token: 0x06002E21 RID: 11809 RVA: 0x001521BC File Offset: 0x001503BC
internal static void rkhvpo29Ec0()
{
	if (Debugger.IsAttached)
	{
		throw new Exception("Debugger Detected");
	}
}

I'm not an amateur programmer. I'm aware that you can attach a debugger to a .NET Core process inside of a .NET Framework project by clicking "Attach to Process" and selecting "Managed (CoreCLR)" as the code type, but doing that causes the anti-debugger code listed above to be triggered and causes the LaunchBox process to exit. PLEASE do something to resolve this Jason. I would like to be able to fix my plugin and get a working version out to the many people who are waiting to use it again. Thanks for your help man.

September 9, 2020

Now another new problem... Whenever I try to debug my plugin now in Visual Studio 2019, I cannot set LaunchBox.exe as the debug application. It throws an error about it being a .NET Core application and my code being .NET Framwork. If I instead try to open LaunchBox and then attach to it with the VS2019 debugger, LaunchBox itself detects the debugger and closes the process (really? anti-debugger in an application that supports plugins?). This whole "upgrade" to .NET Core has been an absolute disaster for my plugin development which I've easily spent probably half a thousand hours on. Maybe I'm alone in this.. I don't know. It would be great to hear a response from @Jason Carr or @neil9000 and maybe some advice how to proceed? Seems this upgrade to .NET Core was maybe done too quickly without giving any thought to the developers who have spend thousands of hours developing plugins for your application. I've personally heaped nothing but praise on your application and have been personally responsible for probably half a dozen people or more buying licenses, but I'm just starting to get a bit worn out trying to deal with the many, many issues that have arisen since this major change implemented in 11.3. Can you please at least remove the anti-debugger code in your app so I can at least try to debug my plugin without having to resort to using dnSpy or some other app that will allow me to use driver-level anti-debugger bypass features?

September 9, 2020

Alright, I got the plugin fixed. Give me just a bit to compile a build and post it here.

Edit: Turns out I'm running into another problem now... This change to .NET Core in the 11.3 update has really wrecked a whole host of things in the plugin.. I'm working to get y'all a build as quickly as I can. I'm a bit frustrated at the moment, but I'll keep updating my progress here... If I can get something pushed out tonight I will.

September 8, 2020

So when y'all switched over to .NET Core, 'Unbroken.LaunchBox.Plugins.dll' was moved from the 'Metadata' directory to the 'Core' directory. Besides the Plugin API webpage not mentioning this change, all plugins that reference this DLL must be updated to point to this new path or compiling fails. Obviously it's not a big deal, but it would probably be helpful to new developers if you at least update the plugin documentation. Also, just as an aside, any plugins that get the LaunchBox directory by using something such as 'Path.GetDirectoryName(Path.GetFullPath(Assembly.GetEntryAssembly()))' are also broken by the new update as this now resolves to the 'Core' directory instead of the base LaunchBox directory. Again, not a huge deal, but I just thought I would mention it in case anyone else is having problems.

Edit: I'm also now seeing this warning whenever compiling my plugin (after LB moved to .NET Core):
Found conflicts between different versions of "System.Drawing.Common" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
Does not appear to be causing any problems at the moment though.

September 8, 2020

In the process of fixing the plugin (since the last LB update broke things). Hold tight and I'll post a beta in the thread soon.

August 29, 2020

If the new LB update did break the plugin, I will look into it as quickly as I can. I'm in the middle of trying to leave town but when I get to where I'm going, I will try to push out an update. If by chance you got the bad 11.3 update that broke all plugins, its possible that SteamLauncher could have poisoned one of your emulator paths. You might just double check to make sure your emulator paths are correct and then try the plugin again. I doubt that is the problem, but it's worth a try. As if keeping up with Steam updates breaking the plugin wasn't enough... now it appears I get the added fun of dealing with LB updates breaking it too

August 27, 2020

26 minutes ago, neil9000 said:

11.3 official was released and then pulled originally, so some people updated to it while it was briefly out. The revised 11.3 is either out now, or due out very soon, i cant really tell as i was one of the people who updated when it was originally pushed out, so there is nothing for me to update to.

Ah, that clears up a lot of confusion... Thanks for the info. I think I will just wait till LB notifies me that the 11.3 (non beta) update is available.

August 27, 2020

1 minute ago, hadrex83 said:

Thank you for your hard work making an invaluable plugin. I have 1167 PC games in my collection with varying degrees of controller support or no controller support this plugin is a godsend.

You're very welcome and I appreciate you saying thank you. I am of the opinion that the Steam controller configuration feature/overlay is of immeasurable value and that there is simply no alternative that offers even a fraction of its utility. Whether one is using a Steam controller or just a normal xinput/dinput controller, the level of customization possible is simply astounding.

I developed this plugin as a means of making it easier and more convenient to utilize Valve's brilliant utility and even if I was the only person using my plugin, I would continue to develop it for my sake alone as I legitimately value Steam's controller configuration functionality that much. The fact that others find it useful too is an awesome bonus and a great incentive to write cleaner, better code so that others might also make use of it if desired. Plus, it always feels great to hear someone say that they find your app/plugin/code useful... Makes it all feel more worthwhile.

I really wish I'd have had more time over the last year to keep the plugin/documentation/Github up-to-date but unfortunately that hasn't been the case. I know I've been saying for awhile now that the 1.0 release is incoming, but I really am very close now to having it complete. Once I'm finished with that, I'm going to completely revamp the plugin download page, its documentation, and my Github. I really appreciate everyone being patient!

August 27, 2020

Just now, neil9000 said:

The early 11.3 betas broke all plugins, that has been mostly fixed, but there are a few still having issues.

Ah.. Good to know. No wonder I didn't know an update was available.. I didn't know @hadrex83 was referring to beta updates. I have never opted into beta updates or really even paid much attention to them. You said most of the problems with plugins have been fixed.. do you mean in a newly released beta or have those fixes not been published yet? If there is a new beta that fixes the issues with plugins, could you give me a URL where I can download it to test it out or do I have to update directly from within LB? I appreciate you popping into the thread and clearing up some of the confusion for us @neil9000.

August 27, 2020

19 minutes ago, hadrex83 said:

After further testing it seems to be only LB 11.3 rolled back to 11.2 and SteamLauncher works. In LB version 11.3 the emulator application path is changed to "..\Plugins\SteamLauncher\SteamLauncherProxy.exe" sadly something with the update broke the functionality of the plugin.

I wasn't aware that a new LB update was out but even so, there should be little chance that a LB update would break the plugin. From what you've said though, it sounds like that may be the case. I will look into the problem right now, and I will try to post a new beta build of the plugin in this thread shortly. Also, thank you @hadrex83 for the report about the crash occurring when there is no 'config.xml' file in the SteamLauncher directory. Normally this wouldn't be a problem as the plugin would just generate a new default 'config.xml' file but there was a small bug that was causing the debug logging to try to access a config value before the new default config had been generated. I got that bug fixed already and I'm looking into the new LB update right now.

August 27, 2020

6 minutes ago, hadrex83 said:

Not sure if the LaunchBox 11.3 update broke something or if I'm just unlucky but decided to try this plugin today for the first time but with it active keep getting the error " The file you've specified for the emulator application path was not found". When i turn SteamLoader to off in the menu all my games launch just fine. Would be awesome if I could get this working it would streamline my control configuration between the emulators and the PC games in my collection. I've tried everything i can think of made sure to install correctly, turned of anti-virus, tried with a new install of LB.

You need to use this new alpha build that isn't publicly posted yet:
https://drive.google.com/file/d/1nsUnrk67ChsnvXxfoOUr-sM6GR12WgSm/view?usp=sharing

Let me know if you have any problems.

August 16, 2020

On 8/11/2020 at 9:32 AM, Shermer321 said:

Yeah that's what I used. Either way it was easier to use an ahk script to look for the window. Thanks though.

Hey @Shermer321, sorry I didn't respond immediately. I've been out of town for a funeral. I'd be happy to help you get the plugin working. The 1.0 final build is just about done, but I can send you the latest debug build I have and we can walk through whatever issue you're having. It would be much easier to do via Steam messaging, so if you could hit me up on there that would be great. My Steam contact info is on the plugin download page. I suspect whatever problem you're having can be resolved very quickly and easily as I'm very confident that the latest alpha I linked to in this thread is working just fine. Anyways, shoot me a msg and we'll get it figured out.

July 14, 2020

I should probably revise that line in the documentation as there really isn't a way to set a specific controller profile to automatically load when a given emulator is used. Any time you change any controller configuration settings in Steam, it saves those settings by associating them with the name of the currently running game. An example of a game name when launched using the plugin might be: Super Mario World (SNES). (Note: You can see the name of the currently running game in Steam by looking at your own name in your friends list.) If you've never played a particular game before using the plugin/Steam, it is not going to have any controller configuration tied to that game name, so it is simply going to pick the default "Gamepad" controller configuration.

If you want to use the same controller configuration for all games running under PCSX2 (or at least want to use a particular controller configuration as a "starting point" for all games running under PCSX2), the simplest way to accomplish this is as follows:

Run any game under PCSX2 using the plugin
Setup your controller configuration as you like
While inside of the controller configuration overlay screen, hit the 'Export' button (or press the 'Y' button if using an Xbox or Xbox-style controller)
Scroll down to 'Templates'
Select the 'Save new template binding' option

Enter an appropriate name (i.e. PCSX2 Template) and description
Click 'Save'

Now, any time you load up a new game under PCSX2, just pull up the overlay, select 'Controller Configuration', hit the 'Browse Configs' button (or press the 'X' button if using an Xbox or Xbox-style controller), and select your newly saved PCSX2 Template config. Takes all of about 3 seconds and you'll only have to do it one time whenever playing a new game. The nice thing is that you can now change any controller bindings (on top of your PCSX2 Template config) and they will automatically be reloaded the next time you run the game (and these changes won't affect/modify your PCSX2 Template config).

Hopefully this was helpful but if you have any additional questions or need any additional help, I'd be happy to assist in whatever way I can. If you need a quicker response, you're always welcome to hit me up on Steam as well.

July 7, 2020

For anyone else looking for the current alpha, you can download it here:

https://drive.google.com/file/d/1nsUnrk67ChsnvXxfoOUr-sM6GR12WgSm/view?usp=sharing

June 10, 2020

1 minute ago, coleroddy said:

My humble suggestion: just release it as it is. I don't think many people would care that much about a logo. But it's not hard to find someone that could do the art for you though. Thanks anyway for the hard work.

I can send you a current debug build if you'd like. Just shoot me a PM and I'll send you a link.

June 10, 2020

Is anyone here good at graphics/art design or know anyone who is who might want to help contribute to the plugin? I think I've decided that I'm going to go ahead and release the 1.0 version of the plugin, as I've put a whole lot of work into cleaning things up, optimizing code, fixing bugs, adding new features, etc, so I think the plugin is finally in a state worthy of calling it a non-beta release. Thing is, I'd really like to create a set of logo/icons for the plugin that give it that last bit of polish/shine, but unfortunately, I am miserably bad at art/creative-design. While I know my way around Photoshop to a fair degree, I just don't think I have the creativity needed to accomplish what I'm trying to do. What I've been trying so far is to create an amalgamation of both the Steam logo and the LaunchBox logo, but its not going so well... Thought it was at least worth asking around if someone in the community might be willing to contribute some of their talent to the project. Thanks!

May 11, 2020

Just an FYI, if anyone wants a debug build of the plugin (title problem fixed among other things) prior to the public release, hit me up on Steam, and I would be happy to send it to you. I'm getting close to finishing up with the changes I want to complete before pushing out a public build though, so it shouldn't be much longer.

April 23, 2020

3 hours ago, C-Beats said:

This was done intentionally to allow the numeric sorting to work. We take the SortTitle that game has been given via the user and then format it to make the sort appear correctly.

I knew there had to be a good reason for doing so I assume this is to prevent situations such as in Windows File Explorer where a file such as "pic11.jpg" will sorted/shown prior to "pic2.jpg"? Regardless, thanks for the input!

April 23, 2020

So it turns out that the issue with strange extraneous numbers being displayed in a game's title has nothing to do with any changes made by Valve. Instead, the culprit this time is LaunchBox. For a game's title, I was using the property named "SortTitleOrTitle" instead of the more obvious, "Title". For many games (at least previously), there was no difference between the 2. The only instance where they would be different is when a title started with "The", "A", or some other word that you would want to filter out as far as sorting goes. For example, the game "The Lost Vikings 2" would have the following properties:

SortTitleOrTitle: "Lost Vikings 2"
Title: "The Lost Vikings 2"

I can't remember now exactly why I switched over to using 'SortTitleOrTitle' instead of 'Title', but I do remember specifically changing which property I was using in a previous update. Again, I just can't remember why I did it now as using 'Title' certainly seems to be the more obvious choice. Anyways, moving on... For some reason, the LaunchBox devs have changed the way that 'SortTitleOrTitle' is formatted. They are now formatting any numbers inside of the title as some type of float value but padding out the values on the left hand side with zeros. It now looks like this:

Old 'SortTitleOrTitle': "Lost Vikings 2"
New 'SortTitleOrTitle': "Lost Vikings 0000000002.0000000000"

I'm not sure why they are doing this, but I'm sure they have a good reason for doing so. I doubt they ever intended for the sort title to be used for display anyways. Long story short, I'm going to change the plugin to go back to using 'Title' instead which should fix this problem.

Users should be aware though that this can result in any controller profiles previously customized/assigned to a specific title not to show up automatically when the game is launched using the new version of the plugin. Steam decides what controller profile is assigned to which game based on the title of the game so if you previously had setup a controller profile for "Lost Vikings 0000000002.0000000000" (or even "Lost Vikings 2"), whenever you go to launch the same game with the updated plugin the title will now be changed to "The Lost Vikings 2" and any controller assigned to the previous title will not be automatically loaded. I would suggest therefore specifically saving any controller profiles that you think might be affected by this change so that you can manually load them whenever you launch the game with the new plugin version.

I'm looking into some other reported issues as well as making some additional quality of life changes to the plugin before I release the update, but it should not be much longer (famous last words, right?).

March 25, 2020

On 2/20/2020 at 3:14 PM, coleroddy said:

WoW. Talk about coincidence. I was just testing exactly some ps3 games, and I came back to report just that I found the same issue on them. But the issue is not as I described earlier. It seems the numbers on names doesn't need necessary to be at the start or at the end of the name. They show a lot of zeroes if there are numbers in the middle of the name too. I tried "Persona 4 Arena Ultimax" and it showed the "4" in the name something like "Persona 0000004". Anyway, let's hope Lahma can solve the issue when he get time to do so.

I've also noticed this behavior and I will be fixing it in the next update. For more details see my previous post:

March 25, 2020

On 3/7/2020 at 1:14 PM, imbrock said:

Hello!

I've been using Big Box for a couple of months now, and was having a bit of trouble with it until I found this plugin. The Steam Launcher plugin is the cornerstone of my games integration and I absolutely love it! It lets me rebind controls in nearly every game I want to play across emulators and GOG and Origin games. Honestly it should be base functionality of big box its so good.

Hey @imbrock , I'm glad my plugin has proven to be so useful to you! We definitely don't have a large user base but the reason I made the plugin, and why I maintain it, is for the users who do find it so essential to their gaming "workflow" (including myself). I apologize for not having maintained it as well as I would like to these past months but hopefully with all the craziness going on right now in the world, I think I'm going to have a good chunk of time to commit to pushing out a new update.

On 3/7/2020 at 1:14 PM, imbrock said:

Bug 1 - Occasional glitch

PCSX2 emulator application path changes to Plugins\SteamLauncher\SteamLauncherProxy.exe when the plugin is enabled. Not all the time but randomly, sometimes I am able to use it at a few times before this happens sometimes it happens after the first play. I'm assuming that the plugin changes the target path after the emulator launches so that the proxy can target into steam and probably is supposed to change back after.

Your assumption about how the proxy works is mostly correct. The process by which the plugin accomplishes this is a bit complicated, containing many exceptions, edge cases, and workarounds, but I really thought I had eliminated the possibility of this happening... The plugin swaps the application path for only a matter of milliseconds and it stores the original application path in a file in case the plugin, Steam, and/or LaunchBox crashes within that millisecond window... If that happens, the plugin is supposed to restore the original path upon next startup immediately. Obviously there is something wonky going on there and this certainly isn't the 1st time that PCSX2 has caused problems not seen in any other emulator/game. I've added this to my list of bugs to resolve and as long as I can replicate the problem, I will have it fixed in the next update. Could you possibly give me a bit more info concerning the problem? Does it seem to occur occasionally regardless of the rom or does it seem to only happen with specific roms? Also, it might be helpful to get a debug log from you that records the bug occurring. I will try it out myself 1st though and if I'm having problems replicating the behavior, I'll ask you for a debug log then.

On 3/7/2020 at 1:14 PM, imbrock said:

Bug 2 - Effects limited number of games solvable by switching SteamLauncher off

So this probably isn't actually a bug, I'm pretty sure these games / the stores that they come from and the associated DRM are intentionally designed to not start up when the steam overlay is starting. So whats happening is if the SteamLauncher plugin is activated the games will just fail to load, in tetris effects case it plays two startup videos and then exits.

On the easy solutions side, having SteamLauncher detect windows store and epic store games and disabling itself automatically so they could start would be a work around so that users don't have to go flip the switch to play two or three games.

I'm not sure what the best way of detecting games running through those, maybe from the game shortcut that launchbox is using? I've included two examples from the games I've been having problems with.

Windows Store (UWP) games cause problems with everything.. and for a good reason.. The UWP architecture is complicated and bizarre in the way that it operates and it seems to be that way for no good reason at all. I use GlosC with a couple of Windows Store games but even that solution has some problems, so I generally just don't use the Steam overlay with Windows Store games. There are a number of ways we could accomplish what you desire (preventing the plugin from activating on specific titles only without having to turn it off globally). I could add an option for disabling the plugin with Windows Store games as it should be easy to determine which games are UWP titles as they don't point to an EXE but instead point to a Windows Store package name (such as "Microsoft.Patagonia_8wekyb3d8bbwe!App"). Additionally (or in place of), I could also implement a feature for adding specific game exceptions in the settings file which would always be ignored by the plugin (causing them to be run normally without the plugin intervening). The next release should have a GUI window for managing all of the plugin settings that you would normally have to manage by altering the settings file in a text editor. That would make it pretty easy to add exceptions if we went that route. If you have a preference on how you would prefer this be implemented, let me know (both options should be pretty easy so we might just do both).

Ramblings by me about how insane the UWP/Windows Store app architecture is (I moved it down here since nobody probably wants to hear me ramble on anyways):
Did you know that Windows Store games actually run/operate from a hidden virtual disk volume? Sure, you can see the game files in the WindowsApps folder (if you take ownership of it), but Microsoft actually mounts that data in a hidden volume prior to running the app. This has a lot of weird implications that can cause all sorts of problems. For example, if you run Windows Firewall in the mode where it blocks all outgoing traffic by default, allowing outgoing traffic only from apps you've specifically designated a rule for, you cannot create an allow rule for a Windows Store game by simply selecting its exe from the game directory inside of the WindowsApps folder... It simply won't work. Even stranger, Microsoft has implemented a feature in Windows Firewall for selecting UWP apps in a different way (by providing their package name) yet using this feature to add an allow rule for a Windows Store game will not work when your firewall is set to block all outgoing traffic by default. The ONLY way to create a working allow rule is to use a 3rd party disk management utility to mount the hidden virtual volume (called XVD) that is created by Windows to a drive letter and then create a rule using the game executable located within that volume.

March 25, 2020

Just wanted to update the thread and let everyone know I'm looking into the reported issues. The strange behavior where certain titles are having extra zeroes inserted into their title in Steam is definitely a new issue and it has to be related to something that Steam changed on their end. If I had to take a random guess, I would bet that it is related to Steam FINALLY fixing a unicode encoding bug that has been present in Steam for many, many years (maybe even a decade). I had to implement a workaround in the plugin in order to have certain strings properly encoded/decoded (Steam uses UTF8 internally) and if Steam did actually finally fix the bug, I suspect my workaround is what is now causing this strange behavior.

Being that I have some new additions to the plugin only partially implemented right now, its going to make it a little tricky for me to implement a quick fix for a bug like this as I would have to implement it in an older version of the source code and then when I finish the additions, I would have to port it forward to the current version. Ideally, it would be best to just finish these couple of additions and implement the bug fixes simultaneously and just do one release. Let me figure out if my assumption about the problem is correct and then I will decide what to do about pushing out a fix.

P.S. If there are any other fixes, additions, or suggestions you would like implemented in the next release, now is the time to speak up!

March 9, 2020

Hey guys, just wanted to write a quick post to let you guys know I am back online. I've been rebuilding my rig and have been out of commission for a few weeks. I've finally gotten things mostly back up and running and got Steam reinstalled a couple of days ago. @The_Keeper86 messaged me on Steam and notified me that there was some new activity on the plugin support thread (I swear I didn't get email notifications.. although I bet if I check, they will be buried somewhere amongst my much too numerous emails). I haven't even read the new posts since my last post yet as I am in a hurry to run do some service calls but when I get back, I will read the posts and personally respond to all of them. Talk to y'all a bit later this evening. Again, sorry for my extended absence. I promise I have not forgotten about the plugin!

I just wanted to add one thing: I encourage any of you having issues, suggestions, or think you might have any valuable insights for me to add me on Steam and shoot me a message. I'm always available for any of the users of my plugin and I would love talking with all of you. I think all of my Steam info is on the plugin download page but if you need further info to add me, just let me know. Its been a long day, but I'm still going to try to catch up on the thread tonight or possibly first thing in the morning.

November 21, 2019

11 hours ago, Nielk1 said:

Damn, tried my hardest not to

I will need to look into your latest SteamLauncher changes, I know you are/were dealing with a lot with the new Steam library.

Indeed. Unfortunately, much of the Library management API/storage has been moved into the java/web portion of the UI. The way they've done things is legitimately bat-shit insane but what can you do, ya know? Just 1 example (promise not to ramble here), all of the old IClientShortcuts API still exists and still modifies shortcuts.vdf as expected (user tags, hidden status, etc), but the Steam UI simply ignores the shortcuts.vdf file for many of the fields/values now (although not all of them... the primary fields are still stored in the shortcuts.vdf file, such as name, exe path, cmd line, etc). Furthermore, where all the new stuff is being stored (mostly values related to the new "Collections"), it looks like it is going to be really tricky to try to modify while Steam is running (due to it caching values and overwriting changes with the cache if you try to modify things live). I was pretty convinced that there had to be a new back-end interface/API for handling this stuff outside of the web code but if there is, I certainly haven't found it...

November 19, 2019

Damndest thing.. Thought I heard someone say my name..

Profiles

Forums

Articles

Downloads

Gallery

Blogs

Posts posted by Lahma