Publish to Stream Deck store

[ChekTek]

Hi!

PilotsDeck looks awesome! We'd love to get this published in the Stream Deck store, to make it easy for new users to find. Please let me know if there is anything I can do to help get this into the store.

https://docs.elgato.com/sdk/plugins/packaging
https://docs.elgato.com/sdk/plugins/distribution

[Fragtality]

Thanks!! Really appreciated! 😃

Publishing it on the Store is not as straight forward as it seems:

The Upload Process is additional Workload - sure I could script/template the Mail, but still I would have to invest Time setting that up. And then there is Delay associated with that because it is a manual Review Process - where in comparison GitHub and Flightsim.to I just "drop" the Package and Users get immediate Access (and Information, if subscribed).

Then it is a Question of Reason - sure "new" Users could find it easier. Who are these Users or more specific what is "new" to them? PilotsDeck does nothing on its own after it is installed. You have to setup (either completely manually or get a premade Profile) the Buttons, Switches, Gauges of the Plane. PilotsDeck makes it (mostly) easy to define that, IF the User has the Knowledge how a specific Aircraft can be integrated with. I don't really know, but my Assumption is that these Type of Users hardly exist - someone knowing this Stuff but never seen or searched anything on the different FlightSim Communities to discover my Plugin but instead using the Store to search for a Plugin for such a specific Use-Case? 🤔

But really the biggest Problem and Showstopper are Dependencies! One can't just download and especially run PilotsDeck on any Machine.
First it requires .NET 7 installed to even start at all.
Then, for P3D Users, they need FSUIPC installed for the Plugin to be actually able to connect and talk to the Sim. For MSFS they need an additional Module installed in the Simulator.
That is why I wrote my own little Installer for the Plugin: People not reading (and thus not having) the Requirements or installing them Wrong where the most Support-Requests I had.
And a Distribution through the Store only solves the easiest Problem (dropping/extracting the Plugin in the right Folder so StreamDeck can find it).

[ChekTek]

That makes sense! We do however host quite a few plugins that require external dependencies, typically a FAQ or setup guide can be linked from the store and/or the property inspector to help users find what they need (even if the requirements are quite technical in nature).

In the end it is your decision, but it was pointed out to me as a great potential candidate for the store, so I had to reach out! 🙂

[Fragtality]

We do however host quite a few plugins that require external dependencies, typically a FAQ or setup guide can be linked

Hmm, interesting! Do you have Examples?

or the property inspector

What exactly do you mean by that? Like hardcoding a Link in PI HTMLs? 🤔

but it was pointed out to me as a great potential candidate for the store, so I had to reach out!

Sounds intriguing, tell me more 😅

Well I guess I could do something like a special Build / Mechanic for the Store Version. A special manifest that loads the Installer on first start or something like that 🤔

[ChekTek]

Sure! Here is an example of using the external window built into Stream Deck in the Multi OBS Controller plugin: https://share.chektek.com/y9BMr4PL

In this scenario it is mostly used for advanced settings that would not fit in the PI.

Reference: https://docs.elgato.com/sdk/plugins/style-guide#external-window

If you want to open a URL in the user's default browser, you can use the openURL event: https://docs.elgato.com/sdk/plugins/events-sent#openurl

This would be pretty ideal for sending them to download & install external dependencies. You can also bundle premade profiles in the plugin with preconfigured actions, if that would improve the user experience.

https://docs.elgato.com/sdk/plugins/manifest#profiles
https://docs.elgato.com/sdk/plugins/events-sent#switchtoprofile

If you need some hardware for testing purposes of course, please reach out to streamdeck.elgato@corsair.com

[Fragtality]

@ChekTek

It took a while, but with all the great Changes the upcoming Version will bringt, I thought it might be a good Idea to pick that Topic up again ^^

I have made a Package with the Distribution-Tool: https://github.com/Fragtality/PilotsDeck/blob/master/Marketplace/com.extension.pilotsdeck.streamDeckPlugin
The easiest Compromise for me was to make a "fake-package" which actually contains the Installer and a Manifest to let it start by the StreamDeck Software.

One Downside I found out is that the SD Software's Upgrade-Process is absolutely not compatible to how the Plugin works. The Software deletes all Contents of the Plugin Directory which also means custom Images, Scripts, Settings and Mappings from the User are deleted. So once installed through the Marketplace, the User needs to Update via the Installer (I've added that in the Description).

What do you think about the current Approach? Would that be something eligible to be published on the Marketplace?

[ChekTek]

Unfortunately, we don't really allow installers within plugins, as they need to be self-contained to the single folder, as you discovered, since the update process is essentially disposing of the previous folder and replacing it.

Typically, my recommendation for something like this would be to have the plugin and installer separate. Then we can link and direct users to the installer from Elgato Marketplace. So user can install the plugin from marketplace and then get the installer from wherever you can host it from.

[Fragtality]

I'm not sure if this really would work out, giving my Experience on Users. I mean the whole Installer has grown / changed so much over Time, because they can't be trusted to do anything for their self. Not all, but most. Especially when talking about putting it on a Marketplace so average-Joe can accidentally stumble over it.

If we "just" write it down for them to get the Installer before they can do anything useful with the Plugin, you can be assured there will be reports of "it doesn't work" because Users did not get and run the real Installer as instructed. I have to "slap it" into their Face.
You know, I have a dedicated Channel in the GSX-Community Discord for my Fenix2GSX Tool. Stating in the very Description that the Channel is only about that Tool and linking the GitHub Page of it which exact first sentence says what it is. On an almost daily basis you have Users asking what it is or just completely ask/write something off Topic "because it has Fenix in the Name!".

So when Elgato is not allowing an Installer, I would need to build some kind of "fake Package" that tells the User all over the (Plugin) Place to come to Github for the Installer. So basically building a Plugin that is only an Instruction - or put differently, implementing a "brick". The changes for the current Approach where at least just adding a special Condition to the existing and useful Stuff and ensures that there are only two Outcomes: it is properly installed or gets removed.

Together with the Problem that the Update-Process via Package and the Plugin are inherently incompatible, I start to doubt if we really should put it on the Marketplace.
I mean I don't earn/gain anything with a wider Audience (especially when the Audience targeted here only eventually is interested in Flight Simulation) and the "Fight" to get the Attention of the real target Audience is already lost anyways because of Flight Panels.

[ChekTek]

We typically encourage 1-2 version of compatibility between software and plugin, this way things don't break as users get updates at different times.

In the end publishing a plugin is totally up to you! We do have plans to offer paid plugins in the future (currently in an experimentation phase), so it could potentially make more sense at that time?

Having just given a little talk at the flight sim expo, I KNOW the community would be excited for this to be readily available in marketplace. Many of the flight sim connections to Stream Deck are a bit tricky for a more general audience to get working, personally I'd love to see something that is very user friendly for the Stream Deck community.

[Fragtality]

We typically encourage 1-2 version of compatibility between software and plugin, this way things don't break as users get updates at different times.

You mean like StreamDeck Versions and 1-2 Versions until a deprecated Item in the SDK gets removed? Not that this already saved my A**, but that isn't relevant here. 😂

In the end publishing a plugin is totally up to you! We do have plans to offer paid plugins in the future (currently in an experimentation phase), so it could potentially make more sense at that time?

That isn't relevant. I don't do that for Money and not for Fame. I just wasn't happy with any of the Solutions and thought "How hard can it be?" and made what I wanted 😅
All I care is that People know what the Solutions are, what their Alternatives are before making a Decision.

Having just given a little talk at the flight sim expo, I KNOW the community would be excited for this to be readily available in marketplace. Many of the flight sim connections to Stream Deck are a bit tricky for a more general audience to get working, personally I'd love to see something that is very user friendly for the Stream Deck community.

Oh, that is interesting!
Well user friendly to a degree^^ Even when especially the upcoming Version makes some things simpler (like the Profile Installation) and more user friendly, the Plugin is still only a Toolbox / a Canvas - you still need to know Sim/Platform specific Stuff (like the 3000 MSFS Variables) or want to learn it when there is no premade Profile.

Yeah the "to get working" Part is exactly my Concern. That is why I put so much Effort in the Installer: it ensures every Requirement is there so that the Plugin can actually run and can actually connect to the Sim (anything but XP).
Not being allowed to run/package the Installer and just instructing the User to get the Installer from GitHub before anything can even work doesn't improve the user friendliness or their experience. I mean it would be easier for everyone if it would just be like an "Ad" in the Marketplace directing to the Github Page directly instead of downloading/installing a "placeholder" Package.
Distributing only the Plugin just doesn't make sense. Depending on the System it won't even start because the Installer could not ensure the correct .NET Runtime is installed.

[Fragtality]

So I thought of this a bit more.

When the current Approach to distribute the Installer is not allowed - what about that "placeholder" Approach? I mean just making a bit of manifest and PI for one "Install" Action giving Instructions and linking the Installer is not that much work. Also it is clearer for me Code-Wise since I don't have a "special install condition" in the Installer and Plugin.
Also it would ensure the User is guided to get a working Installation, and not some maybe half working, maybe not working state because he/she missed something in the Description?

So what do you think about that?

[Fragtality]

Any Thoughts / Feedback on this @ChekTek ?

I've played around a bit with the SDK and created a JavaScript/TypeScript based Placeholder Plugin as a Proof of Concept - offering an "Installer" Action where the User can start the Installation in the PI of that Action. (The Installer will be downloaded from GitHub and run for when the User clicks on the Button)

[ChekTek]

I think the main issue is that when the plugin is uninstalled by Stream Deck, the files installed by the installer built-in to the plugin will remain behind, compared to just linking to the separate installer from marketplace the user would be fully aware that they are installing something external and they would have to uninstall it in another step. There is an internal meeting to chat about these types of dependencies tomorrow. I'll double back here after a chat with the team. 👍

[Fragtality]

I think the main issue is that when the plugin is uninstalled by Stream Deck, the files installed by the installer built-in to the plugin will remain behind

I just tested that: when I deinstall the Plugin in the StreamDeckUI, the whole Plugin-Folder gets deleted - so I'm not sure what you are referring that is left behind?

compared to just linking to the separate installer from marketplace the user would be fully aware that they are installing something external and they would have to uninstall it in another step

Hmm, in "PoC" I described above there is only one Action called "Install" with a "Install" Button in the PI. Sure there can be some additional explaining Text around - but how would that not be clear to the User?
And I don't fully understand how just linking the Installer is easier than just download and run it for the User? (After he/she "opted in" by clicking the Install Button in the PI)

[ChekTek]

Hi @Fragtality

I may be a bit confused as to what the installer is for if they files are all still inside of the plugin folder itself, couldn't you include the "installed" files in the plugin folder and skip the installation step? I was under the impression that the installer places files outside of the plugins folder, if that is not the case, then I think the plugin would be ready to go to marketplace!

In any case, we've had a discussion internally about plugins and their dependencies. While we'd like to discourage plugins installing extensions/dependencies that land outside of the plugins folder, if it is a nice somewhat guided user experience as you mentioned potentially displaying some information/install button within the PI etc. then we should allow it into marketplace. Our discussions were largely about keeping our users safe, and if the installer is bundled inside the the sdPlugin folder, then we have at least had the opportunity to review it as compared to an external installer listed in a remote location.

That being said our documentation may have moved since I originally posted the issue! Here is the updated information:

https://docs.elgato.com/makers/general/creating-a-product/before-you-submit

TLDR: we now have a portal for publishing! https://maker.elgato.com/signin

Best,
Zack

[Fragtality]

I may be a bit confused as to what the installer is for if they files are all still inside of the plugin folder itself, couldn't you include the "installed" files in the plugin folder and skip the installation step? I was under the impression that the installer places files outside of the plugins folder, if that is not the case, then I think the plugin would be ready to go to marketplace!

Well, the first "Challenge" with the Plugin is that it is compiled against new .NET Versions which require the Installation of the according Runtime before the Plugin can even run (executes at all). So just throwing the Plugin in the Plugin Folder would easily lead to diffuse "not working Situations". As the manifest and PI-Files are there it would seem okay on first Glance, but there is no actual Binary/Plugin that could be executed and everything would run into the void.
Skipping the Plugin Extraction isn't the Problem, it is losing the "forceful" Guidance of the User by the Installer - ensuring the Requirements are there for it to run at all and do something useful. The Installer is there to make it easier for the User and improve the Experience. 😃

In Terms of installing the actual Plugin, it roughly does the same as the StreamDeck Software only in a more targeted Way: deleting the old Plugin Binaries only and extracting the new ones in the Plugin Folder - without deleting User Customizations like Images or Scripts.

So Plugin-wise, nothing is placed outside of the Plugin-Folder - even the new Action Designer and Profile Manager are all contained there.
The only Stuff that is outside of the Plugin Folder are the Requirements (.NET Runtime, StreamDeck Software, FSUIPC, MobiFlight Event Module, vJoy Driver) which surely no one wants them to be in the Plugin Folder 😉

if it is a nice somewhat guided user experience as you mentioned potentially displaying some information/install button within the PI etc. then we should allow it into marketplace. Our discussions were largely about keeping our users safe, and if the installer is bundled inside the the sdPlugin folder, then we have at least had the opportunity to review it as compared to an external installer listed in a remote location.

Just to make sure that we are on the same Page: my last Proposal to initiate the Installation in the PI would mean two Things:

• The Plugin which would get published is more or less a Placeholder, serving the sole Purpose of downloading & running the Installer. It does not do anything else.
• That would also mean the Plugin-Installer would not be distributed and would remain on its remote location here on GitHub

In my Opinion this only has Benefits:

• The Marketplace Plugin/Placeholder would hardly every need an Update, since it just downloads the latest Installer.
• Thereby eliminating the Problem that an Plugin Update via the Marketplace (Streamdeck Software) would destroy User Customizations.
• The Installation is only initiated when the User manually starts it. So not an "annoying" Installer popping up as with the last approach.

So my Proposal for going ahead: I implement/switch to this new Approach and make a .streamDeckPlugin Package from that. Which you and your Folks could then pre-check if it something that could go through.