Lahma
-
Posts
404 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Articles
Downloads
Gallery
Blogs
Everything posted by Lahma
-
I can work around these problems by investing many, many more hours of time if I really have to, but I was really hoping that wasn't going to be required... It is looking like it might be though.. I WILL get a working version of the plugin out to y'all regardless. I am genuinely sorry it is taking so long.
-
You can follow my discussion with @Jason Carr in this thread if you would like. I'm trying to get these problems with LaunchBox fixed...
-
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.
-
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?
-
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.
-
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.
-
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.
-
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
-
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.
-
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!
-
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.
-
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.
-
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.
-
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.
-
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.
-
For anyone else looking for the current alpha, you can download it here: https://drive.google.com/file/d/1nsUnrk67ChsnvXxfoOUr-sM6GR12WgSm/view?usp=sharing
-
Try using the new alpha that I haven't posted publically. It should most likely fix any issues you have. If it doesn't, hit me up on Steam and I would be happy to help you out. You can find details on how to add me on Steam by looking at the plugin download page: https://drive.google.com/file/d/1nsUnrk67ChsnvXxfoOUr-sM6GR12WgSm/view?usp=sharing By the way, just for future reference, any problems should be reported in the plugin support thread as it is very easy for me to miss messages posted as comments and/or reviews. You can find the plugin support thread here: -
I can send you a current debug build if you'd like. Just shoot me a PM and I'll send you a link.
-
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!
-
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.
-
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!
-
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?).
-
I've also noticed this behavior and I will be fixing it in the next update. For more details see my previous post:
-
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. 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. 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.
-
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!
