Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple L:Vars in one button #62

Open
mtchul opened this issue Jun 5, 2024 · 2 comments
Open

Multiple L:Vars in one button #62

mtchul opened this issue Jun 5, 2024 · 2 comments

Comments

@mtchul
Copy link

mtchul commented Jun 5, 2024

Hey legend,

Love the product. I've encountered an issue since updating to your latest software. I was a fair few versions behind so it's probably been an issue for a while.

Previously, I could run multiple L:Vars under the one button (For example, Landing Light L and Landing Light R).

Since the addition of being able to have an L:Var with a colon in it, the feature of having multiple L:Vars under the one button doesn't work. Is there a solution to this?

If you've got one written somewhere and I'm being blind, please point me in the right direction!

@Fragtality
Copy link
Owner

Hey,
thanks for the kind Words! 😃

That is (and will be) a Thing from the Past. Such Concatenations are not allowed generally on any Value-Types.
It isn't just MSFS allowing strange Names (so L-Vars having "fake Indexes" like ENG_MASTER:1) which conflict with the common Syntax in the Plugin, it is also how the Plugin handles Value-Type Commands then.
When using a Variable-Type (so more than just L-Vars) as a Command, that Variable is also read so that it's current Value is evaluated against the On/Off State provided to know which Value to write when a Button is pressed (or Dial is turned). So now when that would be multiple Variables, Questions/Problems arise: to what State is their Value evaluated? Sure for something like Landing Lights on a Button it would be fine, since they share the same Value-States. But what if it is an Encoder Action? What if the Variables don't share the same Value-States? Would any such Implementation work on all other Value-Types? (Offsets, A-Vars, DataRefs ...).
In the End it would just be a Compromise only allowing certain Cases, but not all - I would need to restrain it somewhere.

So it is just easier on both Sides to have 1 Command = 1 Variable. For the less common Cases where it is needed, there are other Ways to solve what - which also provide more flexibility than I could implement:

  • On MSFS there is Calculator/RPN Code that you can run which can set multiple Variables at once or even more advanced Stuff. And it is only restricted by the MF Module' Message Size of "only" about 1000 Characters. Since it is run through the MF Module it is also "free" (don't requiring a paid Version of FSUIPC)
  • On all Sims there is the possibility to use Lua-Scripts for Actions which require more advanced Logic than the Plugin would provide. (So either paid FSUIPC on all MS or free FlyWithLua on XP)

Sure, RPN Code is something nobody understands and not everyone is willing to pay for FSUIPC just to get a Lua Engine (meanwhile XP Users be like 🤷‍♂️ ). But with the new Stuff I'm cooking these Problems (respectively Reasons to implement anything in the multiple Value Direction) just are not a Thing anymore. Because:
The Plugin now has it's very own Lua Engine - anyone can now "just script it" on any Sim without the Need to do that in another Addon.
(Note: FSUIPC will still be a Requirement to connect to MSFS, but if even Companies like vAmSys still require it, it's fine for the Moment ^^)

For Example, let's look at that Script:

SimVar("L:Some_Landing_Light_1")
SimVar("L:Some_Landing_Light_2")
SimVar("L:Some_Landing_Light_3")

function MyLandingLightSetter(myParam)
	SimWrite("L:Some_Landing_Light_1", myParam)
	SimWrite("L:Some_Landing_Light_2", myParam)
	SimWrite("L:Some_Landing_Light_3", myParam)
end

function MyLandingLightToggler()
	if (SimRead("L:Some_Landing_Light_1") == 1) then
		MyLandingLightSetter(0)
	else
		MyLandingLightSetter(1)
	then
end

It isn't that complex, is it? And at least we can agree: much easier than RPN 😅
Especially when considering that you can call either of these Functions directly in the Plugin, e.g. with lua:MyScriptFileName:MyLandingLightSetter(1) or lua:MyScriptFileName:MyLandingLightToggler

@Fragtality
Copy link
Owner

FYI, I have finished the Rewrite of the Plugin and pushed it to the Repository: https:/Fragtality/PilotsDeck/blob/master/Install-PilotsDeck-latest.exe
I would appreciate some help with Testing to get some Feedback if everything is working properly. Making a Export/Backup of your Profiles is highly recommended! The Intention is that everything just continues to work and I had not seen any Showstoppers with my Setup - but it is better to be safe than sorry 😉

On your initial Issue:
There is a all new Composite Action which is freely configurable, especially on Commands: you can absolutely define two Commands now each updating a separate L-Var. I used it myself for some Landing Light Controls 😅
The Readme was also updated to cover this new Action. So it would also good to know if the Readme does it Job of giving useful Information 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants