Nielk1

@wyzrd That's perfect! To make a plugin all you need to do is start a library project and reference LaunchBox's Metadata\Unbroken.LaunchBox.Plugins.dll library. There's a few interfaces in the Unbroken.LaunchBox.Plugins namespace that you can implement that will be automatically detected. Though, I feel like people are putting too many things into plugins that work better as side programs; things you want to do when LB does certain actions or displaying custom information in LB/BB is of course best done via plugins. Check the plugin API docs here.

If anyone has cases of Steam games that are installed listing as uninstalled in the importer or in LaunchBox/BigBox please let me know. I've had a report and I'd like to collect a few more. I might create a logging build to try to get to the bottom of it. Note that the plugin is configured to automatically fix the installed status of a game by asking Steam either once per hour (this rate can be changed in the Steam Tools Options menu item), when selected in BigBox, or when displaying the Install with Steam menu item. Note also that the CarbyneSteamProxy instance used by the plugin is far more stable in version 0.3.0.0 onwards. If somehow it remains open, you can safely close it from your windows tray icon area. If there is more than one server running feel free to close them all. If the plugin looses track of the server it will re-open it when needed.

@percybuttkins I do need to rewrite the proxy. It's funny because I was working on that before the plugin feature came around and the code base for that shifted into the plugin. You'll note the collection of DLLs in this that are prefixed with "Carbyne". That's because the middleware I am working on is called "CarbyneMiddleware", though it's a bit on hold due to the plugin stuff. I should be able to make a 3rd party game detector into this when I get to recoding the shortcut management section of my Steam layer.

I'm hearing reports that the in BigBox 'Install with Steam' button is already broken in version 0.3.0.0 due to a Steam update, but I can't seem to replicate that here. I'm still working on trying to work around this issue. That is the only function I use that is a moving target that can break, everything else is safe (and sometimes a crazy complex workaround to be safe).

@pdavis I wrote my own little server but I spent all my time on the websocket portion to notify the client of events. It was quite tough to find a good websocket set and I nearly ended up coding my own before I found a small little library I could fork. I can see we both went for very different methods, where I went for a tiny little server wrapping the API and you went for a bit more of a structured wrapper with a sub-process. I'm not really feelin' it on this project though, and while I'm not sure if what I've done is compatible with your code I'd be glad to toss it to you to see if it can help. I feel like a tighter more reduced embedded system is the way to go, personally. If you're interested shoot me a PM and I'll throw you a zip of the code. This probably wasn't a waste on my part since I think I am going to switch to either custom UDP/TCP or websocks very similar to this for my 32bit interproc I currently use a named pipe for. Web requests are just so much easier to work with than blocking streams. I've attached a screenshot of what little I have so far.

Changes to the interfaces can range from stable to unstable. .net is interesting. If it was C we'd have to make sure we only put new externs on the bottom of the existing externs for backwards compatibility, but this is C#. Under C# if you grab an instance of a type defined in a remote DLL, and that instance comes from that remote DLL, you won't crash unless you try to call a function that doesn't exist. The only problem will be for the plugin interfaces where the plugins need to implement every function/method. The fix for that is to make all the current plugin interfaces end in 001 and when you make a change bump the number up and make a new inteface. Thus, you'd have IGameMenuItemPlugin001, and you'd have IGameMenuItemPlugin002:IGameMenuItemPlugin001, and you'd have IGameMenuItemPlugin003:IGameMenuItemPlugin002 and so on. By doing that you ensure that future plugins can use the newer interface and older plugins can still use the older one. You could use a thin-adapater instance to encapsulate the manual polymorphism on on these various interfaces. The assembly redirects will help with plugins that do more complex operations like SteamTools which loads BigBox.exe as an assembly so it can access the static root view to inject its modal dialog. Even though you added that to the plugin interface I still need references to non-plugin libraries to be able to cast the games view to TextGamesViewModel so I can call RefreshGames(). I can rebuild my SteamTools for every single release you make if I need to so it doesn't crash on people, but that is a bit rough. I can also write my code to dynamically rebind to later versions, but other people aren't that knowledgeable. SteamTools is in beta though and there's a lot of crashes I need to insulate against and things I need to fix anyway that I won't push on you. Also, in reference to what was discussed in the stream, I have a rough prototype working of a thin-server plugin:

The simplest way to do this is checking a custom field on a game in the theme and using it to insert an image. A plugin might be needed.

@Jason Carr I found something useful you might want to put into your app.config (launchbox.config / bigbox.config) that will allow you to not only update the version number on the plugin API DLL in the future safely without breaking old plugins (provided the needed functions, properties, and classes are still there, .net is very permissive) but allow plugins to reference the other DLLs in the rare cases it's needed without needing to be recompiled for every LaunchBox/BigBox version. (Even though bindings in .net say "any version" for some reason it doesn't work very well, I think that just allows for this binding redirect.) <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="LaunchBox" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="BigBox" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Unbroken" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Unbroken.LaunchBox" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Unbroken.LaunchBox.Library" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Unbroken.LaunchBox.Wpf" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Unbroken.LaunchBox.Plugins" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.0.0.0" /> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

I think this is intended. If you are merging 2 games, yes, the main one becomes the primary, but it makes sense that in the extended list of options you'd have "Play Version 1.0" and "Play Version 2.0" even if "Play" would start 2.0 anyway, as the 2 additional options are being descriptive but the Play option is just a quick launch sort of option.

@Jason Carr My Add/Update Metadata and Media issue appears to finally be resolved. Will need to do some more testing of course to be sure but my test case works as expected.

@wirtual82 My area is Steam. For that someone else would have to do it. I'm already equip to build a data set from Steam's data, it's just about sorting what I need and where and how much of the data I can make naively come from Steam so I don't have to maintain it..

@Jason Carr The metadata and media fix seems to be half-working. The metadata for the example problem game of mine, Colin McRae Rally (2014) was indeed preserved and did not change to the incorrect game, however, media for the incorrect game still downloaded. It appears you have prevented the metadata overwrite since the DatabaseID was attempting to change when it was already set, but that incorrect DatabaseID was still carried into the media download step rather than using the DatabaseID already attached to the game. I have no use for it personally, yet, but if you make another iteration after this it would probably be worth adding IPlatformCategory:GetAllPlatforms() . EDIT: Also @Jason Carr it looks like IBigBoxMainViewModel is in the wrong NameSpace; it's in Unbroken.LaunchBox.Plugins instead of Unbroken.LaunchBox.Plugins.Data

@wirtual82 Eventually, though I'm more working on trying to get the GamesDB scrape to be accurate (it's really not right now) and submitting the Steam store data to the GamesDB.

@jchasa It's stored the full paths to the source code used to build it so when it reports an error on a specific line number like that it also includes the full path to the file on the machine that compiled the DLL (my machine). These are DEBUG DLLs after all, so while I'm not sure if Release DLLs do that these certainly do.

@Jschmuck2 It looks like it's failing to find and start CarbyneSteamProxyServer.exe for some reason. Very interesting. I'll need to try to figure that out. It's supposed to detect Steam and start up the proxy exe and when it detects steam disappear it's supposed to shut down the proxy exe.

@jchasa I coded it so it should handle the Steam client being opened after LaunchBox is already running, but I never tested it.

@jchasa The importer talks to the Steam Client and gets a list of all games. It will list games already in your library but as you can sort the list and check all selected items you can easily order by "In Library" last, and then scroll to the section where they are all "no". The Importer is still in beta, so it might have some bugs that will need to be reported so I can fix them.

@neil9000 Updated description with simple instructions. Hopefully this early beta will be stable.

Steam Tools Plugin View File This is a test release of Steam Tools for LaunchBox. To install, unzip the contents of the ZIP into LaunchBox's Plugins folder. This plugin now supports being in a subfolder. Current Features: Basic Steam game import functionality Options Menu Automatic custom field if using LB Premium for use in playlists Optional automatic Hiding of uninstalled Steam games Optional automatic Un-Hiding of installed Steam games Background task for automatic updating of Installed/Uninstalled fields Basic loading of Metadata from Steam Option to download Clear Logos, Steam-Grid, and Header (as Fanart) images from Steam Source Code: https://github.com/Nielk1/LaunchBoxSteamToolsPlugin Submitter Nielk1 Submitted 05/19/2017 Category Third-party Apps and Plugins  

@Andrewnintendo It should be safe to delete LaunchBox/Metadata/Metadata.xml and let it regenerate. That file is one of the local files for the GamesDB and shouldn't contain any of your custom data. I'd make other suggestions but I think removing the Metadata.xml file is a good first step to limit the possible causes of the playlist caching error. If you want to be safe you can rename the file to Metadata.xml.bak just in case.

Cleaner System MenuItems View File Simple optional plugin that organizes ISystemMenuItemPlugin plugins. A plugin that would like to use this feature must add one of two properties: // C# 6.0 lambda property initialization public Type CleanerSystemMenuItems_ParentPluginMenuItem => typeof(ClassNameOfParentISystemMenuItemPlugin); public string CleanerSystemMenuItems_ParentMenuItem => "stocknameOfToolStripMenuItem"; // classic property initialization public Type CleanerSystemMenuItems_ParentPluginMenuItem { get { return typeof(ClassNameOfParentISystemMenuItemPlugin); } } public string CleanerSystemMenuItems_ParentMenuItem { get { return "stocknameOfToolStripMenuItem"; } } Possible values for CleanerSystemMenuItems_ParentMenuItem: installDosGameToolStripMenuItem editDefaultToolStripMenuItem manageEmulatorsToolStripMenuItem managePlatformsToolStripMenuItem editAutoHotkeyDosBoxToolStripMenuItem editAutoHotkeyScummVmToolStripMenuItem editAutoHotkeyWindowsToolStripMenuItem selectRandomGameToolStripMenuItem downloadToolStripMenuItem downloadPlatformThemeVideosToolStripMenuItem scanForAddedRomsToolStripMenuItem scanForRemovedRomsToolStripMenuItem importToolStripMenuItem auditToolStripMenuItem consolidateRomsToolStripMenuItem createMissingArcadePlaylistsToolStripMenuItem cleanUpImagesToolStripMenuItem refreshImagesToolStripMenuItem refreshSelectedImagesToolStripMenuItem optionsToolStripMenuItem Source Code: https://github.com/Nielk1/LaunchBox_CleanerSystemMenuItems Submitter Nielk1 Submitted 05/17/2017 Category Third-party Apps and Plugins  

I do still have some rare crashes I can't seem to pin down a repo case for. They seem to be related to concurrent image loading somehow but it seems to be something that only I really get and it's not the focus of this current beta-series. So far plugins seem to be working well but I'll know more as I keep working with this. The plugin I am working on is turning into several plugins all together using the same static API so it's probably one of the most complex uses of the evolving Plugin API. And really now, the K is important people; "Nielk" not "Niel". Like "Teal'c" from Stargate, "Niel'k" if you must. Niel'k One

((O__________O))