Jump to content
The simFlight Network Forums

Fragtality

Members
 View Profile  See their activity

  • Posts

    147

  • Joined

  • Last visited

  • Days Won

    11

 Content Type 

Posts posted by Fragtality

  4. Introducing Pilot's Deck, a StreamDeck Plugin

    in User Contributions

    Posted

    *Version Bump*

    The Release with a big Plus 😄

    Version 0.7.8:

    • Added Support for the SD Plus!
      • The Actions "Display Value with Switch", "COM Radio" and "Display Gauge" are also available on the Encoders
      • You can set separate Commands for Left, Right and TouchTap (no Hold or Long-Touch)
      • The Normal/Long Press (called Main and Second Command now) are mapped to pressing the Dial
      • Besides having more Commands to set, they behave the same as their KeyPad Variant
    • Simple "Value Manipulations" possible on all Variables used as Command
      • Increasing/Decreasing by a defined Step with an optional Limit
      • Sending a Sequence of Values
      • The Calculator Command now understands two Templates for increasing/decreasing L-Vars and triggering K-Vars (SimEvents) without the Need to write full RPN Code. Especially the Template for inc/decreasing is very useful on the Encoders for Left & Right (on L-Var based Aircrafts. Else prefer Controls/K-Vars).
    • "Toggle Switch" now available on all Actions and all non-Variable based Commands (except vJoys)
      • A separate Variable to Monitor can now be configured
      • But still only available for the Main Command
    • Reset Value renamed to "Reset Switch." Available on all Variable-based Commands (except vJoys) and all Actions 
    • A new Option called "Hold Switch" available on all Commands except vJoys. Because it will act like a vJoy! With that Option but you can directly configure the Commands (or Values) for down/pressed and up/unpressed in the StreamDeck UI!
    • The Dynamic Button now allows to define an "Image Map". It works roughly like the Value-to-Text Mappings: You can map Values to Images, as many as you like (so more than 3 States are possible now!)
    • The Format options now also allows to add leading Zeros
    • The Plugin now has an Installer as the recommended Way to install it. It will check the basic Requirements and informs which are missing.
    • The Plugin now uses the WASM Module from Mobi-Flight (Requirement now)
      • Situations where new L-Vars could not be read because FSUIPC ran into its Limit are gone now!
      • That also enables the Plugin to read any A-Var (SimVar) -they can be accessed without the Need for the myOffsets File. And generally accessing them by Name instead of an arbitrary Hex-Number - but you have to get the Units right, though.
      • FSUIPC is still the main Connection Method (and thus Requirement) for anything but X-Plane.
      • The Plugin is just using something else in the Background for LVars, HVars and Calculator. Nothing to reconfigure in your Profiles.
    • The Plugin now includes ImportProfiles Tool to make it a little bit easier to use your own/downloaded Profiles for Switching
      • It asks for the DeckType and imports every Profile from the \Profiles Subfolder to the Plugin manifest
      • The selections are saved on each run. It will only ask for new Profiles (handy on Plugin Updates)
      • The old empty and preconfigured Profiles Whiskey, X-Ray and so on are not needed anymore. They can be deleted if never used.
    • Some Improvements in the Property Inspector
      • Added a small Image Preview in the Property Inspector for every Image Selection
      • Renamed and Reordered some Options so that there is a bit more commonality, e.g. using the Terms Command and Variable throughout 
      • Tried to improve the Appearance a little bit, but my CSS-Skills are just INOP ^^
    • The Default Image drawn when not connected is now closer to the current Configuration so that changes can be better previewed. A Value of 0 is assumed.
    • The Readme was completely overhauled ... which is hopefully an Improvement!
    • Much Rewrites/Refactors in the Background and Bugs I found on the Way ;D
    • Airbus Profiles/Integrations with the new Features: FSLabs, Fenix, ToLiss. The FBW too, within the possibilities given ...
    • Thanks 1

  7. Missing LVAR after 3066 Lvars loaded (since SU11)

    in FSUIPC7 MSFS

    Posted

    25 minutes ago, John Dowson said:

    No, there are no plans to implement another method or to increase the number of lvars available.
    What you suggest may be ok for you, but not for the vast majority of FSUIPC users. How would you even know what lvars are available if FSUIPC couldn't list them? I would receive a lot of support requests if this was the case...

    I was thinking of two different Modes - the current "Full Scan" Mode if there is Need to see (explore) all Lvars. And a second "Subscription" Mode which only transfers the Lvars requested by any Client (whether it is the UI, a Lua Script or the C# Client). For the Fenix and the FBW for Example I don't need FSUIPC to know the Lvars. They can be looked up in a File / the Homepage. So it can be known in Advance without the need of doing a "Full Scan".
    I'm also getting support requests because my Plugin is not working (although FSUIPC has the Issue) and I don't see any money for my Software.

    Please give me one Example of that vast majority.

     

    25 minutes ago, John Dowson said:

    As I keep saying, the problem here lies with Microsoft / Asobo. I suggest you raise a ticket/bug report with them, saying that all lvars from a previous aircraft should be cleared before loading the lvars for a new aircraft, and the ids re-used. This would solve the issue.

    I highly doubt MS / Asobo will ever improve this because some Application wants to transfer all Lvars via CDAs ... It is not really a Bug or Issue that needs fixing on their Side.

     

    25 minutes ago, John Dowson said:

    FSUIPC doesn't get confused, and you don't need to restart FSUIPC. It is the WASM module that asks/scans for lvars by id using the Gauges API, and it is this scan that is returning the lvars from the previous aircraft.

    I did not say restart FSUIPC. That would be somewhat bearable. It is restarting the whole Sim.
    Yeah right, FSUIPC is not confused ... it is Users wondering and troubleshooting why XY does not work anymore.

     

    25 minutes ago, John Dowson said:

    Note also that lvars don't have to be known by FSUIPC to use/write to them - you can use calculator code for that. However, they do have to know by FSUIPC if you want to read them (including adding them to offsets),

    I know. But just writing an Lvar without the need to ever read it is very very seldom.

     

     

    So in the End my Plugin-Users and I are between a Rock and a Hard Place. I guess I have to evaluate if writing a dedicated SimConnect-Client/WASM-Plugin for my Plugin is an doable Option ...

  8. Missing LVAR after 3066 Lvars loaded (since SU11)

    in FSUIPC7 MSFS

    Posted

    Hello John,

    the Limit is becoming more and more an Issue. Users have to specifically control that MSFS is started with the Plane they want to fly, just to access a small portion of the Lvars via FSUIPC. 

    Are there Plans to implement another Method of accessing Lvars? For Use-Cases like my StreamDeck-Plugin, I don't need to know and access every Lvar that exists. It would suffice enough to just "subscribe" (dynamically!) to the Lvars it currently needs and only these would then be transmitted via WASM, especially though the CDA-Bottleneck.

    Sure it is very handy to scan/see all available Lvars for Debugging/Development ... but which "normal" Use Case does need access to 3066 Lvars in parallel?! A Subscription-based Model would be much more efficient and the Limit of 3066 would only be experienced in very specific and rare Cases.

    It is really annoying to restart MSFS just because you want to load another Plane and that for the sole Reason so "FSUIPC does not get confused".

  11. Introducing Pilot's Deck, a StreamDeck Plugin

    in User Contributions

    Posted

    *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

     

    • Thanks 1

  13. Fenix A320 vs PFC Avionics Help Needed

    in FSUIPC7 MSFS

    Posted

    6 hours ago, John Dowson said:

    Also, the offset I would like to see logged (initially) is the following:
       3102 as U8 - ELECTRICAL MASTER BATTERY

    Maybe @Fragtality can check this? The avionics won't turn on unless this is set. I presume 0x3364 is set (otherwise FSUIPC wouldn't be working), and Daniel has already told us that offset 0x3103 (AVIONICS MASTER SWITCH) is always 1. If the ELECTRICAL MASTER BATTERY simvar isn't being used, is there an lvar that can be used instead?  

    Thanks,

    John

    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).

  14. Fenix A320 vs PFC Avionics Help Needed

    in FSUIPC7 MSFS

    Posted

    54 minutes ago, John Dowson said:

    Yes, but the ready-to-fly offset at 0x3364 is the one that activates the PFC driver as far as I remember. It has been a while (3 months) since I last looked at this, so I really need to review the whole thread and the PFC driver code again if you want to resurrect this....

    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:

    FBW.jpg?width=1094&height=821

    Using that Switch (1) bound to (2) turns on the PFC Box respectively the Displays of it (3).
    And the Switch is bound to:
    fbw1.PNG

     

    1 hour ago, John Dowson said:

    But if its always 1, then it is always on, so I don't think this is an issue. However, I could check the PGC driver code to see if it is waiting for this to change from 0 to 1 (but I don't think so).

    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 😉

     

    1 hour ago, John Dowson said:

    Yes, I do - and I have asked for a log with these offsets being monitored with the Fenix. I see no point in looking at this again until this is provided. Please see my last comment from 3 months ago, If you can provide those logs with the suggested logging/monitoring, then I will look at this again. Otherwise, I do not think it worth me spending the time to go through this again...

    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?

     

    1 hour ago, John Dowson said:

    And the Fenix will be updating simvars and lvars, not offsets. It is FSUIPC that picks up these changes and maintains the offset data. If the Fenix is not using the standard simvars for this. then we need to determine what it is using instead, add this to an offset and then spoof the original offsets for these values to the new offsets, so anything reading the original offsets will automatically get the spoofed value from the new offsets.

    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.

     

    1 hour ago, John Dowson said:

    The ready-to-fly offset is at 0x3364, but this is not related to the Ready-To-Fly button being pressed. There is no event generated for this. You could try offset 0x026D - CAMERA STATE. This offset was added in 7.3.11 and will be < 11 (and non-zero) when ready, but not necessarily after the Fly Now button has been pressed. FSUIPC now also uses this to determine when to start threads for aircraft control.

    Kewl, thanks! 🙂
    I'll look into this, maybe that's a workaround for the Design-Problem Asobo created there.^^

  16. Fenix A320 vs PFC Avionics Help Needed

    in FSUIPC7 MSFS

    Posted

    7 hours ago, John Dowson said:

    As I previously indicated, the PFC driver is waiting for the ready-to-fly offset flag to change before the avionics are activated. The driver does not react to sim events, only offset changes.

    And my theory is about a specific Offset Change?

     

    7 hours ago, John Dowson said:

    I don't think the polling frequency is an issue, it is the offset values themselves. This is why I need to see those offsets logged. If those offsets (or simvars associated to those offsets) are not being used by the Fenix, it is just a matter of determining what is being used (simvar or lvar) and then adding that to a spare/free FSUPC offset and then spoofing the value of the original offset (which is monitored by the PFC driver) to the value of the new offset.

    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.

     

    8 hours ago, John Dowson said:

    But I really don't think it is worth looking at this further if the OP is not prepared to supply the information required to resolve this for him.

    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.

  17. Fenix A320 vs PFC Avionics Help Needed

    in FSUIPC7 MSFS

    Posted

    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:

    Quote

    Previously Pete Dowson made a .DLL for our serial device and also made the PFChid.dll for our USB Devices. He or John Dawson are therefore more suited to be able to answer your questions. With this in mind we do not know what event, simvar or FSUIPC offsets will trigger the avionics to come on because we did not write the DLL.

     

    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

  19. Introducing Pilot's Deck, a StreamDeck Plugin

    in User Contributions

    Posted

    3 hours ago, eagle11 said:

    I have already done everything as described in the readme. Also made an exception in the Windows Defender on the whole Streamdeck folder. No Log is created by the plugin, so I can't attach it. What else can I try?

    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?

  20. Introducing Pilot's Deck, a StreamDeck Plugin

    in User Contributions

    Posted

    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)

     

    • Like 1

  21. Introducing Pilot's Deck, a StreamDeck Plugin

    in User Contributions

    Posted

    2 hours ago, filldasbill said:

    And I dont understand the LVAR logic: I created a dynamic button for the nav lights for the cessna 172. As action address: LIGHTING_NAV_0 (as read by FSUIPC). Also as Control Status Value: LIGHTING_NAV_0. When I press the light switch in the cockpit, the value is read back correctly. The image is changing. When I press the button on the stream deck, the value also seems to change but the switch in the cockpit does not change. What do i wrong?

    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) 😉 

     

    2 hours ago, filldasbill said:

    f.e. the EGT (engine exhaust gas temperature) for my cessna profile. I find a value for that in the manuel of FSUIPC: 0x3B70 - General engine 1 EGT in degrees Rankine, as a double (FLOAT64). Convert to Fahrenheit by Rankine – 459.67. FS default gauges show Centigrade.

    I have no option to correct the read value. I would like to subtract 459.67 from that. I can only manipulate the value by the scalar:

    image.png.414e8e9f331d776cacc84b95093fa207.png 

    I would like an option like this to convert the value in the right way.

    I have a similar problem with the N1 value on the Fenix. I cannot correct the values.

    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.

  24. SU10 and FSUIPC7 MSFS

    in FSUIPC7 MSFS

    Posted

    9 minutes ago, John Dowson said:

    Note that 7.3.9i has now been released, hopefully fixing the axis calibration issues. No change in the WAPI/WAPID though, so PilotsDeck 0.7.3 should still be fine, but I recommend updating to this latest release. I will publish this as the official 7.3.9 tomorrow (probably....!).

    John

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

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.