alec100_94

Hi Guys, I have been working on the latest version of my PCSX2 Configurator plugin as some of you will know, and the good news is, it is looking pretty good and close to feature complete. Now I am trying to add images to my plugin, I am using WPF and this is my first time using WPF. I've managed to get it mostly up and running but there is one thing that is really stumping me and that is loading in external images and how that works with LaunchBox's Directory structure. I've done my research and found I want something like this <ImageBrush ImageSource="pack://siteoforigin:,,,/Assets/Images/PCSX2 Configurator Window.png"/> But that doesn't do what it looks like it should, as "siteoforigin" in this case point to the main LaunchBox Directory and not the plugins directory. There are of course other options, I could embed the images, but don't really want to inflate my dll size by several hundred KB, or I could assume the dll is in "/Plugins/PCSX2 Configurator Next", and hard code that before my path. I understand it's probably also possible to set it through c#, and not be able to visualise it in the editor. None of those alternatives seem great to me, and I really feel like there should be a simple way of making the path relative to the executing assembly but I cannot seem to figure that out. I was hoping there was a standard that is generally used to work around this for LaunchBox Plugins, or maybe just something dumb I'm missing.

If it's something to do with default colours, then I don't intend on using any in the final version, this is still very much a placeholder right now.

@Jason Carr @neil9000 Yeh, I am using WPF, and quite honestly my knowledge of it is rather limited at this point. The dialog is just a standard WPF window with an owner of the main LaunchBox window.

@Jason Carr Sweet, I'll Check it out later.

@Lordmonkus @Thornback In some ways it was a bit like that, I was on vacation and wasn't even thinking about it at that point (in spite of knowing it had issues), and I didn't realise that LB.Next was so close to being complete. I had literally only opened it about 5 or 6 times at that point, and wasn't sure I was even completely sold on it.

@Thornback I only started work on it this week, I also knew it was borked long before Lordmonkus said that. I thought I actually posted something official saying that I was developing a new version somewhere, though it appears not (There's so many of these threads now I cannot keep track). There are definitely some references to it in some post's on the forums. The reason a few member's knew is because we have a private chat with me, Zombeaver, Neil, Spectral and a few others, where we have been discussing the plugin for months, with me posting test builds from time to time. It good to know the old version still works to some extent in LB.Next although it is horribly implemented, Though I guess I can't say the now broken version was much better really. Anyway It's Official I am Developing a New version of PCSX2 Configurator from the ground up for the latest version of LaunchBox. Don't know what version number I am going to go with yet, but this will be a new thing with a new page, and all previous threads will be closed. I am really aiming for stability above all else this time around, and hopefully know what I'm doing a little more now.

@jayjay I sent you a PM trying to describe how to achieve what your doing. @Jason Carr Also realised I am being rather dumb with at least one thing, today I found the PluginHelper.StateManager.GetAllSelectedGames() which I had somehow glossed over before, though for some unbeknown reason that function seems to be returning null when a game is selected (I'm guessing it used to work in OG LB?), so if that can be re-implemented that issue is essentially solved. However on rethinking (again) the main thing I really want to see (in addition to that), is the introduction of an OnSelectionChange Event which was also essentially possible in OG LB through the GetIsValidForGame. These two things are really all I would absolutely need to ship a feature complete version of my plugin (though retaining the config path would still be a nice thing to have, if not really essential if I can add the values on selecting the game).

@Thornback Just got back from work to read this rather amusing conversation. The Much older version (from around December Last Year), possibly will still work to some degree as it uses LaunchBox's Config Path as opposed to overriding the configure event, although I would highly doubt it'd be particularly bullet-proof, and work well for creating new configs for games that never had one. Also that version is completely unsupported at this point, and not something I will be looking back at again.

Ok well, There is definitely a better way of doing that lol, Also AHK is actually a really good choice with LB if used properly (though I kind of despise the syntax). to check if the game is using retroarch you really only need something like this. I have shortened it to one line for easiness, it may be neater to split it up if this confuses you. public bool GetIsValidForGame(IGame selectedGame) { return PluginHelper.DataManager.GetEmulatorById(selectedGame.EmulatorId).Title.ToLower().Contains("retroarch"); } The rest of it doesn't look too bad on the surface. I don't know if it'll help you but I open-source all the LaunchBox stuff I do, so here is the github repo for the new version of my PCSX2 plugin I am writing, and here is the old version (which is pretty much over complicated and broken in places), and here's a link to an even older version of my plugin that was more stable and less complicated (even uses an AHK script for a lot of the logic). Hope that helps.

@jayjay don't sweat it, everyone has to start somewhere. I'm reasonably sure I know what I'm talking about here as I've been using this Api pretty much from the day it was released, have been coding for around 8 years, work as a full time web developer (mostly C#), and have a degree in Games Technology (Not really trying to show off, or anything). I'm guessing @Jason Carr probably did just misunderstand what you meant, maybe he can shed some light on this? Though if this is the feature you actually need, then you can probably see my frustration with it not being there. Just out of interest what is your overall goal? I might be able to help.

@jayjay You are along the right lines, but I fail to see how that actually achieves what I am trying to do. I want a surefire way of knowing what game is starting whenever any game is starting (and the "GameStarting" Event is fired), regardless of what was called before it or how the game was started. If a user open's LaunchBox and double clicks on a game, I want to know which game that was in the "GameStarting" event. As far as I'm aware the OnSelected Methods only trigger when the GameMenuItemPlugin is selected from the games context menu, and only returns the game that it was selected from. This would mean to get the selected game the user would need to click on my plugin from that games context menu first, and if a user then went to select another game the value would be wrong. This kind of defeats the point of the automation I am trying to create here, as if the user is clicking on the plugin anyway, we may as well do the logic there instead of when the game starts. Don't get me wrong, It's not impossible that I'm wrong, and if you think you have working code that does actually achieve what I describe then I would love to see it. Also after rethinking about the priority of the request's in the above list, I think Number 2 (Retaining ConfigPath Values) is actually more important to me at the moment, as I can easily release a version of my plugin without the automation, but having the ConfigPath being potentially cleared is always going to create a minor bug.

@Jason Carr Expanding on our conversation the other night in the thread about difference's in the plugin Engine Between OG LaunchBox and LB.Next, I would like to take this opportunity to list some of the minor changes I talked about, and had previously used hacks (such as reflection) to partially achieve. I am going to forward this list by saying I am in no means expecting any of these features to be implemented quickly (If half of these get implemented this year I will be very happy), and I think I speak for the whole LB Community by saying that everyone really appreciates the work that you do, and the fantastic job you have done with the new version of LaunchBox (LB.Next). If you disagree with any of these ideas feel free to completely veto them as you are, after all, the developer of LaunchBox, though if that is the case I would at least like a reason. There are only really two things on here that may potentially prevent me from making an awesome version of my current plugin, the rest are things I have thought would be nice in the past, and would make use of if available but are by no means absolute show stoppers. The list is ordered in terms of priority from my perspective of creating my current plugin, and I will use that as an example to why I would find these features useful. Also a fair warning to anyone else reading this the below list is quite technical. Access the game being started from the "GameStarting" event Don't know what the best way to expose this, in terms of the plugin Api would be, but this feature would help me out loads. For my plugin to work seamlessly (i.e. as little manual user setup as possible), it is going to need to make a GET Request to check if a config is present and pull down some data if it is, on a per-game basis. I initially thought about looping through all the games while LaunchBox starts, but the problem with this is that it's going to take time (especially if the user has a large PS2 Game Collection). So I eventually settled on the idea of doing this step when the user actually plays the game (There were various less than perfect work-around's to achieve this in OG LaunchBox). There is already the "GameStarting" event in the LaunchBox plugin Api, which in theory allows the plugin to execute logic before the game actually starts, the problem is we have no access to what game is actually starting so we cannot currently put game specific logic in here. Another less than ideal option for this that I had thought of was to launch an additional application to execute such logic (see Number 6), but that seems like jumping through more hoops than necessary and introduces additional problems. An on "SelectionChange" event (combined with knowing the selected game) would also be very welcome here, as a replacement for what used to be possible from the GetIsValidForGame Method. Retain Launcher tab strings (like Configuration Path), Even when emulation is on I mentioned this one the other night, though I understand this one is VERY specific to my own use case, I doubt it'd be particularly hard to implement either. Again There was a less than ideal solution to sort of simulate this in OG LaunchBox because of when the GetIsValidForGame method of a GameMenuItemPlugin was executed (Which was whenever the game selection changed, so these values could pretty much always be set if not already, before it became a problem). But this is not the behaviour I would like to see implemented as this is very much a less than perfect hack for something that should be relatively simple. If ConfigurationPath or ConfigurationCommandLine parameter is already set (Either in the XML file or by a plugin), I see no good reason why that shouldn't be retained when saving from LB's Edit Game Dialog, even with the setting to "Use an emulator..." enabled. The logic to make the button work is all already there and works perfectly, The field's could still very much be read-only and not editable from the frontend, so not to confuse the user. In my case it makes a lot of sense to use the built-in "Configure" option as a shortcut to open PCSX2 with the created Game Config for the given game. [The Suggestions below are really all just nice to have's and not super important for my current plugin] Option to Hide GameMenuItemPlugin completely if it is not valid for the game This one simply just annoys me as it seems so simple on the surface, this was the first plugin related problem I encountered that I turned to reflection to try and solve, I even made a thread about it at the time, which explains roughly how I achieved it. Picture this scenario a user has maybe 10-20 plugins installed, most of them only work on a rather small subset of games, they are going through their SNES library but for some reason still have a greyed out option for PCSX2 Configurator, I just don't see the point in this. I guess you could argue that it keeps the context menu consistent between games (which I'm guessing is part of the reason why it's the case for the rest of the menu), but I really don't feel that matters too much for things under the final (plugin) separator. I would understand if you wanted to leave in the option to disable (grey out) the plugin, but I really feel there should also be an option to hide it. Allow custom fly-out menu (and possibly more customisation's) for GameMenuItemPlugin This one might involve a reasonable amount of effort to implement and I can fully understand why it is not like this, this was one of the few thing's that reflection actually worked reasonably well for in OG LaunchBox, though I have no idea how one would achieve that in LB.Next with it's WPF based interface. But it would be really nice to have a way of customising the actual menu item, and to create custom sub-menu's with there own actions and options (Similar to "Image Group" and "Launch With") as opposed to pretty much always having to open a separate window to present a multitude of options, though a separate window does have some advantages from a visual/artistic perspective. In OG LaunchBox I would have suggested just exposing the underlying ToolStripMenuItem from Windows Form's and letting the user play with it as they wished (which could potentially solve Number 3 as well though not entirely sure on that), but I am still new to WPF and don't know what the equivalent control would be, or if it can be used in that way. Provide option to hide a custom field from the UI and provide nicer implementation This is a small issue, especially with the current build of LaunchBox.Next where custom fields are barely in the UI anyway (don't know if that is due to change in the future). But it would be really good to be able to use LB's built in custom fields for per-game plugin settings, and in that case you probably wouldn't want the user to be able to sort by "PCSX2Configurator_CheckForConfigUpdatesOnStartup". The ability to hide the field could be combined with a dictionary based implementation through the current plugin engine (as opposed to a basic collection like it is now), for a really killer and easy to use system. An alternative solution to this would be a separate system just for use by plugins, though honestly I'm not sure if that's really worth it as it's not super hard to roll your own for this, just a very nice feature that is essentially already there but awkward to utilise for that purpose currently. Provide an option to hide an Additional Application from the Context Menu This is quite a minor gripe, though would also be incredibly easy to implement, and if used in a smart way could have a reasonably positive impact on the user's experience. It is sort of similar conceptually to Number 1, but with the idea that the plugin could launch an external application before the game started (which LB already allows natively). If a script or action was to be executed in this way, then it's probably more of a utility and not something the user wants to see every time they right click on their game, and if it is placed there by the plugin itself as a means to an end then it is definitely not something the user should be able to easily click on, though that second use case would be pretty much completely redundant if Number 1 was implemented and at that point this one isn't really related to plugins, but just another option for the user. A big thank you for reading this mega long post (sorry about that), and hope that gives you an insight into some of the issue's I've been having with LB plugin development (some pretty much since the plugin engine was first launched) and my general mindset when creating plugins for LaunchBox, and why the features above are on this list. I just want to say thank you again for such an awesome piece of software with such a versatile plugin engine that really allows me to essentially create the perfect emulator frontend (Which was always my dream since I was like 12, also LB itself is pretty close to the mark). It's a shame I don't actually get that much time to use LaunchBox itself nowadays but it is still an incredibly awesome piece of software, and I have really enjoyed my time so far developing plugins for it, and hope to eventually have a definitive version of my PCSX2 plugins and develop more awesome plugins for LaunchBox. If anyone else (other than Jason) has any insights on any of the things said in this post, or faces similar issues with plugin development, please feel free to chime in.

Sure I fully understand, I'm not really pushing you to add anything right now, this is very much a free-time project for me and that's not actually something I have that much of nowadays (while working full time as a Web Developer). I probably won't get another chance to look at this properly until next weekend, and it's still likely to need more time than that before I can consider it even sort of releasable. As a developer myself I also know how simple a lot of these things generally are (usually just a boolean or if statement), which is why it can sometimes be a little frustrating when I can't do what I want. Though don't get me wrong when I fully figured out how reflection worked in OG LaunchBox I essentially abused it, by overriding internal events and the likes, and the result ended up being a bit of hot mess in terms of stability, and a real nightmare to maintain. Which is why I am glad to be rebuilding it from the ground up, with much more careful design this time around and trying to mostly work within what the current plugin engine allows, though I may still need a couple of minor things changed/added here and there, to give the best experience.

That's cool. I'm in no real rush to finish my plugin anyway, I'm just trying to figure out what I'll need to work to create the best possible experience for the user, without resorting to less than ideal hacks using reflection (which often tend to cause other issues), which the old version of the plugin very much relied on (and why the Next update broke most of it's functionality). Also not entirely sure how I'd even make that sort of thing work using LB.Next (or if it's even possible), as I'm not really familiar with how WPF displays it's menu items, handles events, etc. Also I'm not sure about hiding the plugin errors, I guess it makes sense for the user, But as a developer I like to see where things go wrong (or are simply not implemented), I noticed the latest Beta fails to show Not Implemented Exception in one case where I am throwing one, is it possible to turn all errors back on? Overall LB.Next is an awesome piece of software, and a massive improvement over older versions of LaunchBox, I've just got some minor growing pains while trying to migrate my plugin (most of which are my fault for building it poorly in the first place).

I appear to have found another slight difference in the plugin behaviour between OG LB and LB.Next, though am not sure if it's intentional or not. In OG LaunchBox the GetIsValidForGame function in the IGameMenuItemPlugin interface fired when a game is selected, but in LB.Next it seems to only fire when right clicking on the game. I personally preferred the way that OG LB handled this, as it allowed me to set a config path as soon as the game was selected, ensuring the ConfigPath was never cleared by LB (so all configure buttons would always work). Though I guess overall this isn't a big issue, and can probably be worked around, in most cases it is unlikely to make a difference. A possibly more sensible solution to this specific issue would be to have Launchbox never clear the configuration path and configuration command line (from the edit screen), if they have already been set (though still keeping the field's read-only unless it's a PC/Dos game).

Just to follow up on what @neil9000 said, this is pretty much correct. Though the current version of the plugin is far from perfect and I'm kinda glad it's being scrapped. The new version shouldn't take too long to develop (Maybe a few weeks) but might not be 100% feature complete from the get go. If anyone wants to help test the plugin while in development just send me a PM and let me know. As for the question about downloading the configs, although @neil9000 is right about the GitHub link, the plugin actually does a lot more than just downloads the configs, in the way of combining the users current config with the downloaded configs. So just downloading the configs from GitHub may not give expected results.

Cool, that makes perfect sense. I can easily work around these issues for now.

Ok, cool, it's working in the beta version. There another thing I noticed and that is that the "LaunchBoxStartupComplete" Event never fires in LB.Next, but the "PluginInitialized" does fire when LaunchBox pretty much appears to be ready, So I was wondering if this means that the "LaunchBoxStartupComplete" event is obsolete and all actions can be moved to "PluginInitialized" for LB.Next or whether the event simply hasn't been implemented yet? I am also curious about the reference to "LaunchBoxMainForm" in the PluginHelper class, will this eventually be updated to refer to the LB.Next Main View, or will it be removed completely?

Hi I am looking to get back into LaunchBox plugin Development, and make a LB.Next compatible (and hopefully better) version of my existing PCSX2 Configurator Plugin, but noticed that SystemEventsPlugin and SystemMenuItemPlugin do not seem to work at all in the latest build of Launchbox.Next. I made a very simple project with bare bones implementations of all three types of plugins (in a single dll), and it works just fine in OG LaunchBox but seems to crash LaunchBox.Next. In Particular it's the SystemEventPlugin That crashes LaunchBox.Next at startup, the SystemMenuItemPlugin just doesn't show at all in the tools menu. The GameMenuItemPlugin appears to be working as expected. Don't know if I'm missing something obvious here, but as far as I can see this is broken in LaunchBox.Next and has probably already stopped a lot of pre-existing plugins from functioning correctly. *Edit - I was able to fix my issue with the SystemEventPlugin, by running the message box in another thread (I have updated the code to reflect this), and all the events appear to report just fine, But there is still an issue the Issue with SystemMenuItemPlugin's not showing up at all (possibly not yet implemented?). It's a very simple project so I may as well just post the source code below. using System; using System.Drawing; using Unbroken.LaunchBox.Plugins; using Unbroken.LaunchBox.Plugins.Data; namespace PCSX2_Configurator_Next { public class GameMenuItemPlugin : IGameMenuItemPlugin { public bool SupportsMultipleGames => false; public string Caption => "PCSX2 Configurator"; public Image IconImage => null; public bool ShowInLaunchBox => true; public bool ShowInBigBox => false; public bool GetIsValidForGame(IGame selectedGame) { return false; } public bool GetIsValidForGames(IGame[] selectedGames) { return SupportsMultipleGames; } public void OnSelected(IGame selectedGame) { } public void OnSelected(IGame[] selectedGames) { } } } using System; using System.Windows.Forms; using Unbroken.LaunchBox.Plugins; namespace PCSX2_Configurator_Next { public class SystemEventsPlugin : ISystemEventsPlugin { public void OnEventRaised(string eventType) { Task.Run(() => MessageBox.Show(new Form { TopMost = true }, eventType)); } } } using System; using System.Drawing; using Unbroken.LaunchBox.Plugins; namespace PCSX2_Configurator_Next { public class SystemMenuItemPlugin : ISystemMenuItemPlugin { public string Caption => "PCSX2 Configurator"; public Image IconImage => null; public bool ShowInLaunchBox => true; public bool ShowInBigBox => false; public bool AllowInBigBoxWhenLocked => false; public void OnSelected() { } } }

I guess I will get around to looking at LaunchBox Next support when I have the chance, The last time I looked LB.Next was still very much in beta, and lacking features. Though I can give no real garuntee when that'll be as I really don't want to try and rush something out nor do I want this to eat up all my free time for the foreseeable future. There is quite a bit of work in getting the same experience in LB.Next due to it using an entirely different form system, not even sure if i'm using the most sensible approach for LB.Next.

@DjBlades That because it's not there, it's in @Zombeaver's config thread, my bad. Here's the link.

The file isn't missing, it isn't a part of the new version. If you had an old version installed you will probably need to use the cleaner DLL found in the comments section on the release page. I will include this functionality in the next release to avoid confusion. As for the use current settings, they basically just copy your current pcsx2 config files to the games config directory instead of starting afresh, this will make no difference to games that you have already created configs for, and won't affect any custom settings set by downloaded configs.

I really cannot say much I've not already said to be honest. Try using the "Cleaner" DLL from the previous page, completely deleting the plugin, then trying it again. The error implies it not recognising the currently selected game, though shouldn't be coming up under normal use. I put this plugin out as alpha as I know it has some problems. I wouldn't directly recommend that anyone use the previous version, but if that worked perfectly fine and this version has some issues for some people, then there is technically nothing to stop it from working.

Then you still have remains of the old version installed, Luckily I have a thing to fix that. First completely delete the "PCSX2 Configurator" folder from the plugins folder. Put "PCSX2 Configurator Cleaner.dll" in your plugins directory (you may need to unblock it) Run Launchbox after it loads up close it again Reinstall Plugin I would also advise you remove your downloaded configs and let the new version re-download them Just out of interest how are you running .7z files in PCSX2? PCSX2 Configurator Cleaner.dll

Probably won't help but can you post a screenshot of your library?