search

Fragtality / PilotsDeck

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

Stream Deck+ support #15

Closed florisporro closed 1 year ago

florisporro commented 1 year ago

The new StreamDeck+ has rotary buttons and a separate LCD . The possibilities that brings with it are awesome, from autopilot to comms control. Just wanted to open up an issue to start conversation on support of this new device.

https://www.elgato.com/en/stream-deck-plus

Fragtality commented 1 year ago

Don't know when I find Time for that, but support it planed - let's say Q1/2023 😉

My SD+ has arrived today and it is even worse than I thought it would be ... yes it has Rotaries, but besides it is a "suboptimal" design imho. The primary Reason I bought it is to add to support, not because I like the design 😐

florisporro commented 1 year ago

Hmm, too bad about the poor quality! I would try to help you build support but my C# is rustier than the Wright Flyer...

Fragtality commented 1 year ago

I've obviously not used very long, but I think Quality won't be an Issue!

It is the Design: it has roughly the same Area as the XL, is way taller, costs nearly as much and still it has only 8 Normal Buttons and only 4 Rotaries with all that space available.

Zofren commented 1 year ago

It perfectly fits my setup but I see what you mean. A 3x4 buttons grid would have been ideal.

Anyway, Q1 of the Q1 or Q4 of the Q1 ? :)

Fragtality commented 1 year ago

Yeah, exactly - that way I would never thought longer than a Second about getting the Plus. With 12 Button is could easily migrate my SD (15-key) Profiles to it, because I'd have enough Buttons for the Num-Keys (GSX, XPDR).

When it's done 😝 Edit: I have not much time at the Moment and want to get the 0.7.7 Version out first as well as updating the various Profiles (that benefits all Users).

Cookizza commented 1 year ago

Really excited for this as my + came today. I've got some things setup and got the FCU addon memory scanner running.

Would it be possible to release an interim version that gives a simple button style control for the rotary knobs? If we can assign to the left/right that would be a start. I understand the LCD integration and options there are probably quite large features and may take some time.

I'll pull the project and see if I can help, although I'm really not hugely familiar with stream deck.

edit: maybe im ignorant but could the controllers property be added to the manifest to allow the plugins actions to be used for the dials? - https://developer.elgato.com/documentation/stream-deck/sdk/manifest/#actions

Fragtality commented 1 year ago

Would it be possible to release an interim version that gives a simple button style control for the rotary knobs? If we can assign to the left/right that would be a start. I understand the LCD integration and options there are probably quite large features and may take some time.

Nope. The LCDs and the Knobs are tied together.

maybe im ignorant but could the controllers property be added to the manifest to allow the plugins actions to be used for the dials? - https://developer.elgato.com/documentation/stream-deck/sdk/manifest/#actions

Not ignorant, but not familiar enough 😅 Yeah, that is one of the things which needs to be done. The easiest thing. The Library has to be updated to understand the new Events. I have to create new the Plugin Actions (in the Code) to handle these Events, the Drawing and the Value Handling. If it would just be adding something to the json, the SD+ Support would have been done by now 😉

Just leave it to me, I think it is more efficient when I invest my Time in working on the Code than to explain it ^^

Fragtality commented 1 year ago

A little bit of Progress-Report 😃

The Library is extended, the Plugin should now be able to receive the new SD+ Events. Pressing the Dial is already working, since I have routed that Event to the normal KeyDown/KeyUp Event-Handling. The "Display Value with Switch" Action is showing up on the SD+ Encoder. But it still has to be seen if I can maintain the Approach of having the same SD-Action being able to support Keypad and Encoders or if I have to create dedicated Encoder-Only SD-Actions.

Now I to invest some time on the Image Rendering for basic rewrites. Before the SD+ everything was Square with a Resolution of either 72px (SD) or 144px (XL) (respectively the same Scalar which is applied on everything). But now there is a Rectangle and I can not only go after the StreamDeck-Type the Action is on alone - since it can be on a normal Keypad or an Encoder on the SD+.

After that I need to wrap my Head around how to implement the Action Handling. There was only really on Sim-Action / Event per SD-Action so far (the Long Press is only really the same Mechanics) - but now I can have multiple Sim-Actions (Tap, Dial Press, Dial Press Long?!, Dial Rotate) and I of course want to give them the same Degree of Freedom as with the normal Buttons when it comes to supported Action-Types and how they can be adjusted.

Since I also want to have some Benefit for me when investing that much Money & Time, I will be focusing on the Stuff to get FCUs & Co and Radios working on the SD+, since that has the most benefit. But I think we're all on the same Page with that 😅

Fragtality commented 1 year ago

I should have a Test-Build for you Guys ready in 1-3 Days 😉

For now I have enabled 3 Actions for the Dials (aka "Encoders"):

Pressing the Dial is mapped to the "normal" ButtonDown / ButtonUp Handling used from the Keypads (so yeah, there is a LongPress Option for the Dial). The Events for Dial Left / Dial Right / Touch Tap can be mapped to separate/different Actions. All Action Types allowed, but not with all Options (Reset Value for Lvar or Toggle Switch for Controls/XP-Commands for Example).

You may think that the COM Radio should have two Sets of Dial Commands (Outer/Inner Knob) - but that is not really needed thanks to the Encoder-Stack Feature of StreamDeck. Just put two (identical) COM Radio Actions in a Stack and when pressing the Dial the Action is swapped. One Action has the Commands for the Outer Knob, the other for the Inner Knob. Swapping can be done with the Touch Tap Event. That way you can have it all on one Dial (turn > push dial > turn > tap). For easier Identification which Knob/Action is currently selected you can use the Format Option to differentiate the two Actions - for Example I insert a ">" at the Beginning for the Outer Knob and for the Inner Knob a "<" at the End.

Using Lvar Actions will now be much easier, reducing the Need to write Lua-Code for them. I still promote using Lua, but for the simple Cases it is not necessary anymore:

This is especially important for MSFS, since the Lvar or Script Action work, but not are not as smooth when turning the Knob faster - in Contrast to XP-Commands or Controls (more popular under FSX/P3D than MSFS). But manipulating the Lvar via Calculator Code feels really great for the Dials!

Cookizza commented 1 year ago

This is amazing, I've been excited all week to hear some progress and it sounds like you've really put some huge effort in the last week or so to produce what you've described.

Really keen to help once there's test builds available - perhaps with profile updates we can all pitch in.

Thanks for the update! Tuned in closely :)

Fragtality commented 1 year ago

@Cookizza @Zofren @florisporro

Here the latest Test-Build, take it for a Spin 😃 https://github.com/Fragtality/PilotsDeck/raw/master/PilotsDeck-latest.zip

Cookizza commented 1 year ago

I've got this rolling and got the FCU all responding.

To confirm - should we now use the exposed LVAR instead of the event number? I'm finding success only with the below (with raw values enabled) on the rotary dials using the fenix

image

Also, sorry if it's covered somewhere - but is there a way to format the heading to include a leading zero if under 3 digits?

Thanks so much for this, it's really looking great!

Fragtality commented 1 year ago

To confirm - should we now use the exposed LVAR instead of the event number?

No should from the Plugin side, whatever the Plane needs 😉 For the Fenix FCU Knobs, you need the E-Variables for turning. (For Knobs with Stop-Position it is A and all other Switches are S) (And both are Lvars - don't confuse it with event number)

I'm finding success only with the below (with raw values enabled) on the rotary dials using the fenix

What "raw values enabled"? The Plugin does not have something like that.

Also, sorry if it's covered somewhere - but is there a way to format the heading to include a leading zero if under 3 digits?

The "Format" Option just allows a fixed Length after the decimal Point. I'll look into expanding the Format Option - seems really missing when handling numeric Values 🤔 (I personally don't need it, since some kind of external Code does that and I just display the finished String on the Deck)

Cookizza commented 1 year ago

Ah sorry - I'm meaning the configuration option from the memory scanner to get the fenix FCU values - https://github.com/Fragtality/PilotsDeck_FNX

With it disabled, the values get formatted nicely but they also get prefixed with HDG, ALT etc which I'm trying to keep off the LCD hence the formatting questions.

Fragtality commented 1 year ago

@Cookizza Redownload the latest, the Format Option now can apply leading Zeros!

In your Case it would be "3.0" => 3 Signs, no Decimal Part (zero Signs) The old Syntax of just one Number still works and produces the same Result.

Fragtality commented 1 year ago

Oh and also on the Knobs: You could also manipulate that Lvar via the Calculator Action Type! Just use "$E_FCU_HEADING:-1" (or +1) as the Action Address!

kens1108 commented 1 year ago

After Version 0.7.5 i can't choose an Action Type (XPCMD or any other)

Fragtality commented 1 year ago

Are you running Version 0.7.5 or upgraded from that Version to this Dev-Build? If the latter - seems you have missed the Basics (documented in the Readme): .NET is not on Version 7 or the Binary is blocked by Windows-Security or other AV-Software.

kens1108 commented 1 year ago

Thanks, thats it.... .NET ist not on Version 7...

Fragtality commented 1 year ago

Here the next Dev-Build for you all to test :smile: https://github.com/Fragtality/PilotsDeck/raw/master/PilotsDeck-latest.zip

❕ Please note: Delete everything in the PilotsDeck-Plugin-Folder (except the Sub-Directories) before unpacking the new Version to avoid DLL Conflicts. If you have changed the manifest for Profile Switching with custom Profiles - just use the new ImportProfiles Binary now to update the manifest 😉

Fragtality commented 1 year ago

@florisporro @Zofren @Cookizza @kens1108

Please also try the new Installer: https://github.com/Fragtality/PilotsDeck/raw/master/Install-PilotsDeck-v0.7.8.exe

Fragtality commented 1 year ago

Some Changes:

https://github.com/Fragtality/PilotsDeck/raw/master/Install-PilotsDeck-latest.exe https://github.com/Fragtality/PilotsDeck/raw/master/PilotsDeck-latest.zip

KR283 commented 1 year ago

Moving from 0.7.7 to 0.7.8, custom images (257x257) don't seem to resize on Display Button with Switch

Fragtality commented 1 year ago

You mean the Display Value with Switch? On which StreamDeck Type?

The Image Handling was changed since there are now 3 Sizes respectively not everything is square anymore. But it should work as before ... for the correct Size and Naming! The Images can't just have any Size. Sure the Readme is lacking there, but if you take a look at the included Images, they are 72px with a "hq" Version of 144px (with @2x at the End) used for the XL and Plus. If you add a hq-Version (@2x) then you need to also add a normal Version.

KR283 commented 1 year ago

Sorry - yes Display Value with Switch, and using both XL & Plus.

In the image below, both buttons are using the same image at 257px. Button on the left is Display Value with Switch, and button on the right is a Simple Button.

image

This image shows the same 2 buttons, but running on 0.7.7:

image

Fragtality commented 1 year ago

Hmm, interesting 🤔 And that Picture has no hq-ending right?

KR283 commented 1 year ago

correct - just tried with the Display Value, and behaviour is the same as Display Value with Switch - also tried appending @2x to the filename with no change

Fragtality commented 1 year ago

Again: it has the incorrect Size, regardless of Ending.

The Simple Button (and Dynamic Button) Action just sends the Image to the StreamDeck (which does the Resizing). But all other Actions are rendered - and they assume the default Sizes as defined by Elegato's Style Guide. The Image is rendered centered on the Canvas and the Size of the Canvas is determined by the Deck-Type and Control-Type - not by the Image Size!

Fragtality commented 1 year ago

I'm wondering - why that Action at all, when it is about showing an Image and not a Value. Why not the Simple or Dynamic Button?

richardkennedy commented 1 year ago

I'm wondering - why that Action at all, when it is about showing an Image and not a Value. Why not the Simple or Dynamic Button?

Correct me if I'm wrong but a simple button can't manage multiple states and in reality the Dynamic Button and Display Value with State ultimately achieve the same thing? It depends on the use case.

To add my two cents to the above issue - I'm seeing the same problem except, but in my case the images are 256x256. These images were correctly resized with previous plugin versions, are correctly resized by the Streamdeck and other plugins such as Cosmetic. The new behaviour with the Display Value with Switch seems to be the exception?

richardkennedy commented 1 year ago

You mean the Display Value with Switch? On which StreamDeck Type?

The Image Handling was changed since there are now 3 Sizes respectively not everything is square anymore. But it should work as before ... for the correct Size and Naming! The Images can't just have any Size. Sure the Readme is lacking there, but if you take a look at the included Images, they are 72px with a "hq" Version of 144px (with @2x at the End) used for the XL and Plus. If you add a hq-Version (@2x) then you need to also add a normal Version.

The style guide recommendations are to ensure compatibility across various devices but it's not definitely required. Providing the images are proportionate, it does work.

Fragtality commented 1 year ago

Correct me if I'm wrong but a simple button can't manage multiple states and in reality the Dynamic Button and Display Value with State ultimately achieve the same thing? It depends on the use case.

If the Image does not need to change, a Simple Button fits that. Sure, a Dynamic Buttons sounds more likely (differentiation between No Smoke being On or Off). That why I wrote "or". But we both don't know, since we both are not KR283 🤷 And I can't really grasp you Conclusion, that Dynamic Button and Display Value with Switch would achieve the same Thing?! 😮 The first is Image-based and the latter is Text-based (displaying the Value ...). And only really with the new Image Map Feature they are both comparable, since the Dynamic Button only could display 2-3 different States before. I'm with you (but only with new Feature) that both fit the Use-Case to manage Multi-State-Switches since both can represent the multiple States. But still it is not "achieve the same thing" because either a User wants to display different Images for that or different Text/Strings as the Representation of the States. Similar, but not same. And both Display Value Actions are not about displaying Images. And the current example is about displaying an Image. So that it is why I'm asking - why is an Text-Based Action used when it is about Images? 🤔

To add my two cents to the above issue - I'm seeing the same problem except, but in my case the images are 256x256. These images were correctly resized with previous plugin versions, are correctly resized by the Streamdeck and other plugins such as Cosmetic. The new behaviour with the Display Value with Switch seems to be the exception?

To put that right: the Images happened to be resized before. That does not mean it was the correct behavior when using unintended Image-Sizes. It is not an Exception, since all rendered Actions (both Display Value, COM Radio, both Gauges and Korry Button) where and still are tuned to produce either 72 or 144px Images (for Keypads) and assume their Background Image in that respective Size and will show these "no resize" behavior. That they were resized before with these Actions was not intended, so I did not think about unintended Usage when changing the Rendering- and Image-Handling-Code for the SD+ Support. Since Cosmetic is probably just sending the Image, it works there. But that is exactly what the Simple and Dynamic Button are still doing: they are just sending the Image. And here we are again at the very same Question: When it is about showing an Image as Representation for the State, why is a Text-Based Action used for that?! 🙄

The style guide recommendations are to ensure compatibility across various devices but it's not definitely required. Providing the images are proportionate, it does work.

Not only compatibility, also to achieve the best visual result. That is why the Images should be provided in distinct Sizes, although it possible when not followed. That is also why Icon Packs follow that (take a look at Guensli's Icons for Example - they are all 144px). Simply because something can or still works, does not mean it is always a good Idea to just wave-off should Recommendations when a consistent behavior is expected. From IETF RFC2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.



Unless I see a sound Reason/Use-Case, I do not consider this as something that needs fixing. Maybe try to Answer my Question with an Answer. Try to explain the Use-Case so I can understand it. Starting a general Discussion about why it should be correct to ignore Recommendations is not the recommended way to convince me. 😉

richardkennedy commented 1 year ago

Is this a difficult issue to correct? The level of detail (you're actually quoting internet standards) seems a bit excessive. I don't need to convince you to resolve the issue, I'm just making you aware (as is the other user) that the recent changes have introduced a regression and I would like to see it resolved. If a new user comes along and creates a dynamic button with a 256x256 image, it'll work as expected. If they create a Display Value /w Switch button, it won't. It's inconsistent and it impacts the user experience.

Dynamic buttons and Display Values with switch buttons both support images. Using a display value with switch makes it easier to build and debug a button. The text can then be hidden after the fact.

Fragtality commented 1 year ago

It is not really the Question if it is difficult - it is neither Rocket-Science nor is it a simple Code-Change. It is the Question why I should invest time in that? My own private time. For something that would just work if you would either use another (suitable and intended) Action or just Resize the Image. Maybe you should recall that I'm not gaining anything from sharing this Project/Plugin. No, I'm just loosing Time. And even Money - the SD+ was not really something I needed.

And it is not a Regression (which is a Bug) - the Changes did not break a Feature. They did break an unintended behavior which you have kind of "exploited". And well, if you like to see something resolved, especially when I don't consider it as Bug - then you'll either have to convince me or resolve it in your own Fork. It is just as simple as that.

The Argumentation/Example around a new User and an inconsistent Experience/Behavior is true. But the Solution for me is/was to correct the Readme on which Image-Sizes should be used. That is really lacking.

Yeah, the Dynamic Button and the Display Value both support Images. But they use them completely differently! The Dynamic Button is about showing/sending an Image based on the current State/Value. The Display Value Actions are about displaying that State/Value - the Image is just the Background there for the Text. Using a Display Value Action to never Display any Value so it somehow shows Images like the Dynamic Button is just something it was never designed to. It still makes no sense for me to use a Display Value Action when it is not about displaying the Value but an Image instead - there is an Action for that and it still has the same behavior as before.

All I can say is: Your Argumentation is currently having the opposing Effect.

Fragtality commented 1 year ago

It was as I feared: allowing non-standard sized Images to correctly resize broke other Stuff and finding out why was difficult due to all the different Handling in the Actions (due to added Features in the past, especially due to SD+ Support). So I rewrote / refactored some Portions of the Code so that there is more common handling in the Code again 😵 But it ended it easier and even lesser Code and hopefully ease-of-use for everyone 😃

So try the latest Version: https://github.com/Fragtality/PilotsDeck/blob/master/Install-PilotsDeck-latest.exe

@KR283 @richardkennedy et. al. The Plugin now makes it easier to just throw in an Image and it will fit - I'm with you that the Plugin should not make it that different to just use an Image (on all Actions!). IF the Quality is not important. It is still the recommended way to provide a 72px (none) and a 144px (2x) for optimum Quality (respectively 3x with 200x100 for the Touch-Display). Should other Problem arise due to non-intended Usage of the Display Value Actions: Please invest your time in describing your Use-Case (Why using that way? What are the Simple/Dynamic Button missing?) and not in Questions of Principle. If there is a sound Reason it is used that way, I'm open to look into possible Solutions/Enhancements.

@florisporro I'm a little bit "puzzled" that the Poster of Issue shows the least Interest in it? I mean I don't need a full experience report or something like that ... but at least something like a thumbs-up reaction (like Zofren e.g.) on a Post that I know everything is good with the Build respectively the Implementation of the requested Feature.

richardkennedy commented 1 year ago

That's great, appreciate your time and effort 👍🏻. I'm in the process of resizing images, and swapping the button types around etc based on the above feedback. Once that's done, I'll move on to testing with the SD+.

As a side note, are you accepting project donations?

Fragtality commented 1 year ago

You don't have to do all Images anymore 😃 But especially more "iconographic" Images benefit most when being designed/resized to the Standard-Sizes - they look more crisp! For example the Images I provide with the Plugin are not resizes of each other - they where each "drawn" in 72px or 144px. So a Resize is only really needed if you want two different Sizes for an Image (so that the Plugin selects the right Picture according to Deck-Type) or want to have more control over the Quality (iconographic Images). If that is not imported - just throw it in 😉

No, I'm not accepting donations. But thanks 👍 Just spread the Word, that there is an Alternative to the other and paid StreamDeck-Plugins for Simming. It surely is not for everyone, but for a considerable amount of People it seems to be the better Option 😉

florisporro commented 1 year ago

@florisporro I'm a little bit "puzzled" that the Poster of Issue shows the least Interest in it? I mean I don't need a full experience report or something like that ... but at least something like a thumbs-up reaction (like Zofren e.g.) on a Post that I know everything is good with the Build respectively the Implementation of the requested Feature.

@Fragtality Actually, I don't own a StreamDeck+ myself so I haven't been able to try it 🤐

I'm always looking for these type of integrations and when I came accross this project and saw the newly released hardware I thought it might be a good idea, but saw there was no thread for it yet. I just wanted to get the discussion started. Sorry, it was certainly not disinterest on my part, you've been extremely responsive and quick I might add with this update. I might still buy the plus in the future and will certainly try this out then!

Fragtality commented 1 year ago

🤣 🤣 🤣

richardkennedy commented 1 year ago

@KR283 Have you tested this on your SD+?

Fragtality commented 1 year ago

@Zofren @Cookizza @richardkennedy @KR283 @kens1108 New Test-Build is out! https://github.com/Fragtality/PilotsDeck/raw/master/Install-PilotsDeck-latest.exe

When testing I had again Problems with the L-Var Limit of FSUIPC (3066 max) and since it is unlikely that Asobo or John Dowson can/will fix it in the near Future ... I've introduced Support for MobiFlight's WASM Module! 😅

Fragtality commented 1 year ago

Just updated the Build - The Values would not update in some Situations

richardkennedy commented 1 year ago

Just checking in to say that I haven't had a chance to test this yet, but I'll provide feedback as soon as possible.

Fragtality commented 1 year ago

No Problem! It was already updated because there was a small Bug with the "Toggle Switch" Feature. And I'm already preparing the next Build which removes the Dependency to the WASM from FSUIPC 😉

Note: That is not a breaking Change - everything WASM based should directly run as-is like before!

Fragtality commented 1 year ago

@Zofren @Cookizza @richardkennedy @KR283 @kens1108 New Test-Build is out! https://github.com/Fragtality/PilotsDeck/raw/master/Install-PilotsDeck-latest.exe

Fragtality commented 1 year ago

https://github.com/Fragtality/PilotsDeck/raw/master/Install-PilotsDeck-latest.exe

Mainly renaming / reordering Stuff in the Property-Inspector so that there is more commonality and that the Labels are more in line with the new Readme (RM.md for the moment). Getting closer to Release 😉

Fragtality commented 1 year ago

Changes included in Release 0.7.8