LB API additions time table?

[cammelspit]

Hey @Jason Carr I was just popping in here and asking if you have any update on a timetable for the API additions asked for the last time you streamed, I believe it was the last time you asked about the poll. You mentioned at the time that the additions that were asked for would be super easy and would not go onto the poll but would make your short list. I realize with the poll items and now LBN being worked on your time is likely stretched thin so you can just consider this a friendly reminder.

In case you forgot what was asked for I will try to explain but I am no coder so my understanding of this is limited.

steam launcher, the plugin for LB allows me to launch LB roms in steam to make Link streaming and per game Steam Controller configs much easier to do. The issue here is twofold. Firstly, the way LB does plugins, you can add context items on launch but those items cannot be added at runtime. For example, game versions can't be launched via Steam launcher because it would have to scan the whole thing before launch with a separate app. Secondly and more importantly, the launching process needs to be able to be passed on to the plugin after the double click or unzipping process. This would make the plugin single click and support zipped roms, which currently it can't do.

I don't pretend to know a whole lot about exactly what needs to be added to the API so I am going to tag @Lahma here in hopes he can get in here and explain it directly a little better. I know he has gotten a good few others asking for these features to be added to his plugin but unfortunately, he can't do it yet. Here is also a link to the plugin itself on the forums in case you want to check it out. It's super neat and really rounds off my whole LB build, at lewast it would if it could be tweaked and allowed to work a little more seamlessly. 

 

THANKS, Jason, I appreciate your work as always. Have a great day.

[Lahma]

Just wanted to touch base here and say that I will be responding to this thread and giving some more technical insight into what cammelspit is asking for a timeline on. It will probably take a good while for me to collect and organize my thoughts into a coherent response that will make it easy for Jason to understand (from a programming perspective) what cammelspit (and I) are hoping will be added into the plugin API in future releases. I will try to post a detailed synopsis tomorrow if possible, but I might not get to it until Monday. Thanks cammelspit and Jason!

[Lahma]

@Jason Carr Well, I didn't intend to take 6+ weeks to make this post, but I got busy and forgot about it until cammelspit recently reminded me of it. Let me try to briefly explain the reason why the plugin API in its current state can't accomplish what I would like it to be able to accomplish in order to fully realize the goals for my plugin, and then I will suggest some ways that the API could accomplish those goals in a relatively easy-to-implement way.

My plugin in its current state simply adds a single item to the bottom of the game context menu, and when clicked, it gathers all of the needed default game/emu/rom/arguments/etc paths for that particular title and then using a custom API I wrote, makes native calls into unexposed functions in the Steam client in order to create a temporary shortcut in Steam and subsequently launch the game through the newly created Steam shortcut. I won't go into any more detail, as I don't really think its relevant, but I will instead explain the problem the plugin currently faces.

Since you can only create/implement classes based on IGameMenuItemPlugin at design time, and additionally since any changes made to the properties of one of those classes during runtime are not reflected in LB/BB, it severely limits my ability to do things a dynamic way. The precise problem that I'm facing is that I would like to be able to create a submenu of additional "Launch via Steam" items at runtime based on how many non-default emulators/platforms a particular item has, almost EXACTLY like the "Launch with" menu item you already have implemented. The way the plugin API currently works though, this obviously cannot be done, so I'm forced to include only a single "Launch via Steam" menu item that uses the default emulator/launcher that is assigned to any particular title. 

One more quick issue that is relevant is that there is currently no way for my plugin to allow LaunchBox to handle the decompression of roms prior to launch, so I would either have to redundantly implement this behavior myself, or simply not support compressed roms that are handled by LaunchBox. 

In my opinion, there is a simple and elegant way to implement this functionality into the plugin API that would figuratively "kill both of these birds with one stone." By implementing a "LaunchGame" callback/event that can be subscribed to via the plugin API, a plugin could subscribe to this event and receive all of the launch parameters for a specific title (that would change depending on whether the default launch option was selected or one of the non-default 'Launch with' options), including the path to the decompressed rom (if LB was designated to handle that). Handling the event on the plugin side might look like something in my plugin's case:

static void launchGameEventHandler(object sender, LaunchGameEventArgs e)
{
  if (!this.LaunchViaSteamByDefault)
  {
    e.CancelLaunch = false;
    return;
  }
  
  IGame game = e.Game;
  IPlatform platform = e.Platform;
  string[] launchParams = e.LaunchParams;
  string appPath = game.ApplicationPath;
  [...etc and so on...]
  
  if (e.IsAppDecompressedByLb)
  {
  	if (!string.IsNullOrEmpty(e.DecompressedAppPath))
  	{
      appPath = e.DecompressedAppPath;
  	}  
    
    e.DeleteDecompressedAppOnLbExit = true;
  }
  
  e.CancelLaunch = true;
  this.LaunchGameViaSteam(game, platform, launchParams, [...etc..]);
}

This is of course an oversimplification designed only to give you an idea of what I had in mind, but does seem like it would not be very difficult to implement. If my plugin had something like this to use, then instead of having a context menu item labeled, "Launch via Steam", I might instead implement a checkbox context menu item labeled, "Use SteamLauncher by Default", and as long as this is checked, all games would by launched through my plugin rather than through LaunchBox itself. 

I would appreciate any feedback on the idea, and any indication of whether or not its something you might be willing to implement. I think it would make the plugin API much more diverse and capable, and a simple event/callback system like this could be used for a wide variety of things. Thanks for your time!

Edited June 10, 2018 by Lahma

[Jason Carr]

@Lahma All makes sense. I'm not likely to revamp the entire plugin system any time soon, but I should be able to add what you need for your plugin at least. It may take me a bit though because I need to focus on finishing up .Next here for a bit.

[Lahma]

@Jason CarrWow, that would be great! I would be happy to to write  some, or even a majority, of the code if that would help in taking some of the workload off your shoulders. Having worked with the plugin API a bit, I have a pretty good idea of the classes (or at least the exposed interfaces) that would likely be used in such functionality, so I could probably at least lay out a decent framework for the event handler and such. However, if you think that would be a waste because I don't have enough knowledge of the underlying (unexposed) code, or you would simply prefer to do write everything yourself, I completely understand. Its just a friendly offer on my part to help out if at all possible! Thanks for the quick reply and the willingness to help out Jason. Have a good one.

You can see an example of my C# by looking at the GitHub for my plugin. Nothing too fancy, and definitely not in a completed/finalized state, but its something:
https://github.com/lahma69/SteamLauncher

[Jason Carr]

I appreciate the offer @Lahma but these days I make it a point to pay for all development that goes into LaunchBox, for quite a few reasons. Feel free to send me your resume though if you're interested in a position for the future.

[Lahma]

@Jason CarrNo problem, I completely understand. I would be happy to send my resume your way. I have a Computer Information Systems bachelor's degree, and I currently run my own computer service/repair/consulting business, but I have enough free time (probably because I'm single ?) that I'm always interested in taking on interesting new projects/job opportunities. My background is primarily in reverse code engineering and bug hunting (exploit development), but I have extensive experience in C#, Python, and some Ruby (because for some perplexing reason, Ruby is the scripting language of choice for Metasploit). I'll send my resume your way just as soon as I get a chance to look it over and bring it up to date.

[cammelspit]

@Jason Carr Hi! I was just wondering if maybe now that Next is finished and you are gearing up the 9.0 release that perhaps we could expect the API additions sometime in the not so distant future? I know this plugin needs them and I know of one other person who has a plugin project on hold waiting for the same thing. Just a friendly reminder, Thanks Jason!

[Lahma]

@Jason Carr Ya, I would love to see these changes implemented in the plugin API whenever you are able to get around to it. It would really open up a lot of possibilities when it comes to implementing additional functionality into my plugin. There is so much more I would love to do, but right now there just isn't a lot more I can do with the current limits of the API. I appreciate all the hard work going into LB. Hopefully we can get some updates to the plugin API soon, making it that much better. Thanks Jason!