Closed mtchul closed 3 weeks ago
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:
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
FYI, I have finished the Rewrite of the Plugin and pushed it to the Repository: https://github.com/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 😉
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!