Fragtality / PilotsDeck

Directly control the FlightSim from your StreamDeck via FSUIPC!
Other
91 stars 6 forks source link

Publish to Stream Deck store #40

Open ChekTek opened 1 year ago

ChekTek commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 3 weeks ago

@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 commented 6 days ago

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 commented 6 days ago

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 commented 5 days ago

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 commented 5 days ago

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 commented 3 days ago

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?