Fragtality

Hello @Paul Henty ! The ExecuteCalculatorCode() Function from the MSFSVariableServices seems to be limited to 256 Chars although the WASM-Interface allows for 1024 Chars (https://github.com/jldowson/WASMClient/blob/master/WASMClient/FSUIPC_WAPI/include/WASM.h). Is that a Bug or is there a technical Reason?

*Version Bump* Version 0.7.7 Released: - Toggle Switch Option for Control and XP-Commands added (toggle a Switch with two different Controls/Commands) - XP-Commands can now be chained - HVars can now be chained - Updated Libraries (full SU11 Compatibility) - Now compiled for .NET 7 (Update your Runtime!) - Improved Sim-Connection/-State Handling - Fixed Bug with XP-DataRefs where they would not update when a DataRef is used multiple times on one Profile/Folder - Fixed Bug with Profile Switching with XP12 - Fixed Bug with Comparisons/Value Matching - Fixed Bug where Actions would stay in Error State

You should check you got the Name right before using it 😉 Seems you're trying to start the Plugin on it own directly. That will not work. If it is installed correctly, it will be started automatically by the StreamDeck Software.

Made a quick Test for the FBW and Fenix, both starting Cold&Dark: Both start with 1 on that SimVar/Offset. Turning the Batteries on and off has no Influence - it just stays 1. The best Option for the Fenix A320 for the Batteries are the Lvars for the Battery Switches: S_OH_ELEC_BAT1 and S_OH_ELEC_BAT2 (1 => ON) Regarding ready-to-fly / Offset 0x3364: yes, it is 0 on both Planes (sitting on the Ramp/Gate).

Somehow it leaves Paul no rest 😉 But maybe sometimes a "fresh start" is better? For my Part I go with his latest Description of the Problem over at the Fenix Discord. On the FBW (and other Planes) this achieves what he wants: Using that Switch (1) bound to (2) turns on the PFC Box respectively the Displays of it (3). And the Switch is bound to: Was only a theory of mine based on a Difference between these Planes given the latest Problem Description - but you're the only one who could say that is false/not related to the issue or if is true or at least a clue 😉 Yes, I understand - but he is on it! The Description is a bit unclear for him what is meant with "UW", because he can't find it in the Dropdown. I guess you meant U16, right? Sure the Offsets are a "copy" of the SimVars monitored by FSUIPC - but I'm not sure what you want to express with that? If the SimVar is changed (either by a SimEvent or the Plane itself) the Offset changes also? So anything writing to a SimVar is indirectly writing/changing to the Offset also. So to correct myself - Fenix is constantly updating the SimVars I've mentioned. Which can be seen by monitoring the Offsets which FSUIPC maintains. Sure, if you find it more promising/effective to follow the Approach to look what SimVars (or Lvars) the Fenix is using. But then still, in the End, we need to know what exactly has to be spoofed for the PFC Driver? And that is my core Question - What does the Driver expect to turn on the PFC Box/Displays? My approach was/is to find that out first. Then it can be analyzed what the Fenix A320 is not doing (or doing) differently there. And based on that either create a Workaround or at least have clear Base for a Feature Request to Fenix. Kewl, thanks! 🙂 I'll look into this, maybe that's a workaround for the Design-Problem Asobo created there.^^

What would be of personal Interest to me, for StreamDeck Plugin and the Fenix Integration: what would that Offset be? And is that a reliable working way to test that the Ready-to-Fly Button was pressed by the User?

And my theory is about a specific Offset Change? So you confirm that the PFC Driver is indeed looking for Offset changes? One of the Offsets you have asked for, 0x3103, is constantly overwritten with 1 by the Fenix. So there is no Change (or the Change is too short). The Other Planes don't do that, which is completely normal: an Airbus just does not have the Concept of Master Avionics Switches. Given that the mentioned SimEvent changes these Offsets 0x2E80 and 0x3103 on other Planes but not on the Fenix could have been a lead. To explain my Theory another way: It is not the SimEvent and not the Plane reacting to a SimEvent. The mentioned SimEvent just changes the SimVars which is picked up by the PFC Driver. The Reason the other Planes are working is that they just don't care about these two Offsets and the Change can happen. Fenix on the other Hand (for Reasons unknown) is overwriting that Offset and a Change is not happening. Sure, it could also be that the Fenix is just not updating a complete different Offset(s). But somebody must be able to tell what exactly is monitored to send the turn-on Signal to the PFC Box? The PFC Support is always pointing to you and Pete and that you should know. I want to find out what is missing on the Fenix so that either a Workaround can be found or at least with the Knowledge of the Root-Cause a Feature Request to Fenix can be formulated. I have offered him to pick up the Discussion for him after he started another Discussion about the Issue on the Fenix Discord. Paul is not really able to conduct a technical Discussion about that - as much as he likes that Hardware, as much he does not understand how and why it is working. So please help me for the Moment with the PFC Driver and what the Driver is expecting. Also, I have very clearly told him, that he stopped the Discussion here and also that he should give you the requested Information. He needs to help you helping him. I would give him some days for that.

Hello @John Dowson I digged a little bit further in this Issue for @PSantos: From what I understood from him: He is used to, that Binding a Joystick Button to the SimEvent “AVIONICS_MASTER_1_ON” via FSUIPC turns on his PFC Box. Works for him on other Planes (e.g. FBW A32NX, Default Neo) but not on the Fenix A320. I’ve analyzed that a bit, tried to compare these three Planes in terms of that SimEvent: - I did monitor the FSUIPC Offsets (SimVars) for Master Avionics Switch (0x2E80) and Avionics (0x3103): The FBW and Default NEO start with 0/OFF. The Fenix directly starts with 1/ON. - When sending the mentioned SimEvent, these Offsets will change to 1/ON for the FBW and Default NEO. - Trying to write a 0/OFF to these Offsets on the Fenix reveals that it is instantly changed back to 1/ON. So my current theory on why it does not work with the Fenix: The PFC Box respectively the DLL/Plugin is polling these Offsets/SimVars and is waiting for a Change from 0 to 1 as the Signal to turn on. Although, with a Script which sets both Offsets to 0/OFF so that there is Change with the Fenix did not really work - but that could maybe related to which interval is used for Polling?! I tried again to get any Information out of PFC, but they are still on the Standpoint only you and Pete can know: I hope Paul picks up the Discussion again and generates the Logs - but maybe you can make some Use of my Information and can verify if that Theory is correct? Greetings, Daniel

Check the Plugin-Requirements You need to have .NET 6 Runtime and Desktop Runtime installed (both x64). https://dotnet.microsoft.com/en-us/download/dotnet/6.0

Did you also try that Unblock Command described in the Readme? Both .NET 6 Runtimes are installed? Please open a Command/Powershell Window and go to the Plugin Directory (where the PilotsDeck.exe is located). Start the Executable on the Command Line. What does it say / show there?

The Problem: what if an absolute value would be needed? Or a logarithmic calculation? What if some logic would be needed to determine the Value? What if some calculations on two or more Offset/Lvars are needed? The List can grow endlessly and still for all that there is a Solution. It really only 3 Lines of Code that would need to be added to the "template" Script provided with the Plugin (PilotsDeck.lua): local eng1egt = ipc.readDBL(0x3B70) eng1egt = eng1egt - 459.67 ipc.writeDBL(0x66CB, eng1egt)

You're assuming that manipulating Cockpit Controls means always "writing to LVars" - but that assumption is wrong. For some Planes LVars (or Offsets for that matter) are only there to read the State of a Control, but not manipulating it (if existing at all ...). Instead these Planes use standard (or custom) Control Codes. Sounds like you have found the right LVar to read from, but not the way to manipulate the Control. What about the standard Control for that: 66379 (TOGGLE_NAV_LIGHTS)? Maybe you also read my Answer on avsim again (Nav Lights should have not been an Issue if you understood the Beacon Light Example) 😉 Nope, something like that wont be added. For Use-Cases like this I described the "Lua Values" Mechanic. You need to have a Script which (continuously) reads the Offset, does whatever Calculation/Conversion/Logic is needed and writes the Result back to another Offset. Then you can let the Plugin read from that Offset.

*Version Bump* Version 0.7.4 Released: - Updated C# Client to current Version (should fix some connections Issues) - Bugfix for DataRefs not updating on the Deck when used more than once

No I don't have a Discord Server and probably will never have one - you can post your Questions here, on avsim, flightsim/xplane.to or send me PM 😉

Thanks John! If it works I'll wait with the Update for the official 7.3.9 Release ^^

@bangaroo PilotsDeck 0.7.3 released and the Fenix Integration is also updated! Should work now (with FSUIPC7 7.3.9h installed!) 🙂

*Version-bump* Version 0.7.3 Released! MSFS SU10 Compatibility: - Compiled against FSUIPC 7.3.9h Beta (available here in the Forum) X-Plane Support: - The Plugin now connects directly to X-Plane via WebSocket - DataRefs can directly be entered (Commands, Value Access for read/write) - Profile Switching is supported based on the Livery Path Comparisons: - Value Mappings now support multiple Comparisons (greater/lesser) and can be mixed with discrete Mappings (equality) - Values used for Image display can also be expressed as a comparison, e.g. ">=0.3" Fenix PilotsDeck Integration: - Added more Switches & Buttons - Updated to new Icons (Black/Round) - GSX Integration - Updated for SU10

Since it is my Plugin you could ask me directly ;D Try to copy the FSUIPC_WAPID.dll from your FSUIPC7\Utils Folder to the Plugin Folder (%appdata%\Elgato\StreamDeck\Plugins\com.extension.pilotsdeck.sdPlugin) (Stop the Streamdeck Software, copy the file, Start Streamdeck Software) If that does not work, you'll have to wait until I could push the new Version. If you really really can not wait, I could push the current Build?! *g*

@John Dowson Encountered the Error where the call to ipc.readLvar() Fails (returning nil). When I start a Flight, end it and start a new (same) Flight the Lua Scripts don't work anymore. The Plugin is working though in that Situation! Restarting FSUIPC in that Situation fixes the Problem: the Scripts work again. But then the Connection (C# Client) from my Plugin is not fully working, I can write Lvars but can't read them - still have to investigate if that is on my End or not. Don't know if it is only Fenix related (did not test something else), but the Steps are generally applyable to other ACs: - Lua Script with event.timer trying to read any Lvar of that AC (loaded via [Auto.ACPROFILE] ) - Start a Session with AC - Exit to Main Menu - Start a new Session with AC

With my own app (FSFO) using Paul's .dll. Were you able to resolve the issue with the Fenix? I would appreciate you advice you have. You mean FSFO as in https://flightsimfirstofficer.com/ ? ^^ Then my offer to have a look on the Code is not possible *g* But you can have a look at mine, did not have to change anything for SU10: https://github.com/Fragtality/PilotsDeck/tree/master/PilotsDeck/FSUIPC I'll just dropped in the new FSUIPC_WAPID.dll from 7.3.9f recompiled the Plugin and was good to go 🙂

No Problems with 7.3.9f and recompiled Binaries (with the new FSUIPC_WAPID.dll)! 🙂 If I remember / assume correctly: I won't have to recompile again with a GA Version of 7.3.9? Or should I wait? You mean generally or in the Context of my Plugin? In case of PilotsDeck: John can't help you with that, but I can 😉

That should be self explanatory - take a look at line 1 of that lua. @bangaroo You don't have to install that Lua File - it is just a kind of "Template" for a continuously running Script to run some Logic and generating Values (writing Offsets/LVars) that PilotsDeck could read and display that. I'll guess you never really did anything with the File except installing it? In that case you can safely remove it 😉 (For the Fenix Integration: That is exactly what the SYNC Script is doing) @John Dowson Line 1 starts with a Multline Comment ("--[["). See https://github.com/Fragtality/PilotsDeck/blob/master/PilotsDeck/lua/PilotsDeck.lua That one is probably due to an lvar not being available, but look at line 24 and that should tell you. @John Dowson Yep, your Guess is 100% correct 😉 There are two ipc.readLvar() Calls in that Line: https://github.com/Fragtality/PilotsDeck/blob/master/Integrations/Fenix A320/FNX320_SYNC.lua#L24 So either it is the ipc Function not working correctly, the ScanDelay is too short or Fenix renamed the Variable. All I can say at the Moment: Everything worked with SU9 (and Fenix 1.0.2.104). During SU10-Beta I got reports from Users that Lvars are not working/behaving strangely. On the Plugin-Side I made a workaround which seemed to help: it uses the "legacy way" (via Offset 0x0D70) to read LVars instead of using WASM (through Pauls C# Client). So the Sim and/or FSUIPC are behaving differently. @bangaroo Try Plugin Version 0.7.2 and set "Fsuipc7LegacyLvars" to true - maybe that helps still on the Plugin-Side (Consult the Readme how/where to set it and how to upgrade from a 0.6.x Version if you're not already on a 0.7.x Version) For SU10 GA: I hope to install it soon and hopefully get a better Understanding of what the Issue/Solution is and to Update the Plugin and Integrations accordingly! 🙂

Exactly this type of explanation it is 😅 😉 You answered "yes" that the Stack should turn on automatically. Here you write you want to bind a button/switch to turn the Stack on (to which you said no to). Whatever on top means "not in the Aircraft" - the Solution can only come from inside the Plane when the PFC should react to the Plane oO To be honest, I give up at this Point. I've just stumbled across the Topic trying to help/volunteer because I just did something roughly similiar. But I just can help when I don't understand yet alone the basic Problem, sorry 😞 The last Thing I could share is: if both Lvars for HDG/VS and TRK/FPA Modes are 0/Off, the FCU is off. As soon as it turns on, one of them is 1/On. So this could be another reliable Check (besides Checking the Battery Switches/Korrys) that could be used to test if the Fenix is alive/on. But we still don't know what we can do with that - you / PFC are the only ones which could tell us what we need to send/set in this Situation 😕 (IF we understand the Situation at all correctly) That was my Guess too, I've tested it. The Avionics Master Offsets are directly 1/ON when the Fenix is loaded. So either PFC never checks the actual Value and is just waiting for Value-Changed-Event (which will just never happen) or they are listening/checking on something else. My Guess in the Lua I shared is, that it is maybe the Master Avionics Control/Event. And just did a test with the Master Battery Offset: same Story, it is directly 1/ON. For the FBW that is behaving differently: the Avionics Master Offsets are 0/OFF when being loaded and Master Battery is 1/ON. But the Values do not change there too when Power is applied. So it should not work with the FBW too when PFC is monitoring these Offsets ... but I still don't even know if the FBW counts to Fenix (not working) or every other Plane (working) 😕

The thing is, you somehow contradict yourself 😅 So your initial Problem is with the Fenix - because on every other Plane it works. Then you give an Example (and requote and emphasize it) that is understood in such a way that it does not work with the FBW too. So is it every other Plane except Fenix and FBW? Or what is it you try to explain with the FBW when the Problem is "only" the Fenix? Because what you are describing with the FBW also does not match up with the Things you said no/yes to ^^ You know better Explanations don't have to be long, sometimes shorter is better 😉 Can you describe your goal in 2-3 short and general Steps (similiar to my try)? So we have a chance to get the basic Idea? Details and specifics don't matter if nobody understands the basic Idea ^^

These where not meant as either / or options, they belonged together as one flow^^ But okay ... we will go with ""When Plane turns on, PFC Displays become alive => YES. And ignore everything else you said (else I can't follow what your Goal is) Did you find out what exactly PFC is monitoring / expecting to get it's turn-on-signal? It can't be "AVIONICS_MASTER" - these Offsets / SimVars are already set to ON/1 by the Fenix (even without having Bat/Pwr turned on). From what I understand, something like this lua Script should do the Trick: local turnedOn = false function FNX_SYNC_AVIONICS() if not turnedOn and ipc.readLvar("S_OH_ELEC_BAT1") == 1 and ipc.readLvar("S_OH_ELEC_BAT2") == 1 then ipc.control(66701) -- Or whatever else is needed for PFC to recognize the Avionics being on ... turnedOn = true end end event.timer(500, "FNX_SYNC_AVIONICS") (Bind it to some Key / Button to test if this helps. Can be run as [Auto] Script to start it automatically - consult the FSUIPC Documentation.)