Jump to content
The simFlight Network Forums

Fragtality

Members
  • Posts

    147
  • Joined

  • Last visited

  • Days Won

    11

Posts posted by Fragtality

  1. *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

    • Thanks 1
  2. 52 minutes ago, filldasbill said:

    Hello,

    I have the same problem like kingm56 and since SU10. I use FSUIPC 7.3.9f and PilotsDeck 0.7.2.

    I read the LVAR values without any problems, but I cant switch the status with the streamdeck. Can someone help me?

    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*

  3. @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

  4. 3 minutes ago, kingm56 said:
    14 minutes ago, Fragtality said:

    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 😉 

    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 🙂 

  5. 21 hours ago, John Dowson said:

    I  have released a new beta for SU10, including an updated WASM. Full installer available from Install FSUIPC7-7.3.9f

    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?

     

    4 minutes ago, kingm56 said:

    Good morning, John. 

    I can confirm the current version of FSUIPC seems to work well with every aircraft, except the FENIX;.  I can read the LVARs via 'legacy offset' fine but can't seem to set them via WASM.   Interesting enough, the new FSUIPC seems to work just fine with the PMDG and every other aircraft.  So, I'm at a complete loss.  If there's something I can do to assist, please don't hesitate to ask. 

    Matt

    You mean generally or in the Context of my Plugin? In case of PilotsDeck: John can't help you with that, but I can 😉 

  6. 13 hours ago, John Dowson said:
    Quote

        14703 *** LUA Error: C:\FSUIPC7\PilotsDeck.lua:1: unexpected symbol near 'ï'

    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

     

    13 hours ago, John Dowson said:
    Quote

       205953 *** LUA Error: C:\FSUIPC7\FNX320_SYNC.lua:24: attempt to perform arithmetic on a nil value

    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! 🙂 

  7. 43 minutes ago, PSantos said:

    I´ve mentioned this a few times, but don´t know what I´m saying that is confusing.
    I need a BUTTON/SWTICH that can turn that PFC AVIONICS RADIO STACK "ON"...... not "in" the aircraft. 

    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)

     

    3 minutes ago, John Dowson said:

    So, the PFC device must be monitoring an offset to determine when to light up the displays, and maybe this offset is not being populated by the Fenix? Have you tried monitoring the avionics master switch offset (0x2E80 or 0x3103) to see if those change value when the avionics are on in the aircraft? Or maybe the master battery offset (0x281C)?

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

  8. 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 ^^

     

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

    • Like 1
  10. Oh man, very frustrating indeed 😞 

    But to be completely honest with you: You're really taking a hard way - I would not get started with such a raw and complex Hardware Box, if I don't want or can't do the tinkering to get it work.

    I'm too frustrated with Fenix that they can't provide the "Quartz Display Data", but they have very extensive API (you can even pull Circuit Breakers. And much "cleaner" compared to FBW and like "500% more" then FSLabs). FSUIPC is just the "middleware" here, it can only exchange the Data and Information both Parties allow.
    In my opinion, PFC are the ones which really let you down! For a 4-digit-priced Hardware Product - being it used or new, someone payed that Money. I would expect a better Support (both in User-Support and pre-done Integrations with Planes) and more technical functionality to just some nice GUI-dropdown in FSUIPC and listening for the Standard "Master Avionics Switch" SimVar (my Guess). That approach reaches exactly then the Limit when you have an complex external simulated Aircraft (like in this Case with the Fenix).

    Could you get the other Buttons to work? Is it just the turn-on Feature that is missing now? If so: ask PFC again what SimVar / Offset it is they are monitoring for that. I'll do the Script for you! 🙂 

     

    And who is following this Forum? Fenix? PFC? If so:
    @Fenix: give me more Data, that's a joke!
    @PFC: you can do much better for that Price.

  11. *Version-bump* 🙂

    The Plugin was ported to .NET 6 and x64 only. Be sure to read the Requirements and the Upgrade Procedure in the Readme! (It is NOT just dropping it in)

    The Plugin now uses the WASM/WAPI Module from FSUIPC7 on MSFS2020. With that:
    - The Lvar Access is now faster and more reliable (not reporting the last Lvar's Value for unknown/inaccessible Lvars)
    - Hvars are also available as an additional Action-/Command-Type
    - CalculatorCode can be now directly be run from the StreamDeck as Action-/Command-Type (can't really imagine a Use-Case for that, but it was possible so why not^^)
    This only affects / is only available with MSFS2020 / FSUIPC7. 

  12. What if you use a Lua-Script which polls the Battery Lvars every 250-500ms (see event.timer) if they are turned on and then send a Command to your Shack? (However that is done with PFC - that has to be answered by their Support). 

    But yeah, I just hit a similiar Wall to have my FCU back on the StreamDeck ... "licensing issues blabla".  😐
    Which is probably true (but which they probably did not understand in my Case):
    They did indeed license the ProSim-AR 320 Software on which they build up on (the Reason they can offer such a System-Complexity on a new Product). And this Software has indeed built-in Support to communicate with a range of Hardware-Manufacturers directly. So that is what they probably don't have licensed respectively have license issues with.
    But I never asked them to Support the StreamDeck (or my Plugin directly), I just wanted to read the "raw" Data from the FCU (Values, Dashed, Dot ... doesn't even need to be via FSUIPC). So things they already present visually in the Cockpit and in case of the Dot more or less already as Lvar. It's very frustrating ... I got a working FCU (or MCP) on every on my other Planes, there was always a way.

    As in this Case too ... I've "hacked" my way through and have my FCU at least basically working 😈
    (Not as accurate, but working)

  13. 3 hours ago, PSantos said:

    Don´t know any other way. Need help on that department also.

    Uhoh okay ^^ But I can't teach you FSUIPC Basics and you have to know your Radio Shack is interfaced 😉

     

    3 hours ago, PSantos said:

    That would be great. (Discord? WhattsApp? Other?)

    Discord - you got a PM 😉

  14. Hey Paul,

    so your Radio Shack uses FSUIPC to communicate with the Sim (in both directions)?


    I've found it rather easy with the Fenix, compared to the messy FBW to make a StreamDeck/PilotsDeck Profile for that. Which is more or less your Use-Case: an external Hardware which interfaces with FSUIPC to read from/write to the Sim (and therefor the Plane). The only thing I'm missing now is to read out the Quartz-Displays - But for COM and XPDR you can use the default FSUIPC Offsets (SimConnect Vars).
    Are you aware of these two KB-Articles?
    https://kb.fenixsim.com/example-of-how-to-use-lvars
    https://kb.fenixsim.com/useful-default-keybinds
    Some Functions are available directly via Standard-Controls (directly selectable in FSUIPC GUI) and for nearly everything else there are Lvars which can be read from or written to.

    For manipulating there are either FSUIPC Marcos (never used myself) or Lua-Scripts (called via LuaToggle / event.flag - the way I prefer). Here the Lua-Script I use for the Fenix: FNX320_AUTO.lua (the Functions could also be mapped via FSUIPC GUI as LuaToggle <scriptname> and as Parameter the event/flag number from the Script-File).
    It doesn't have all Controls in it since my "Hardware" can directly manipulate Lua-Values (via FSUIPC) and so the Script-File only is needed for some which require more Logic/Automation. But that's basically how you manipulate Buttons in the Cockpit and can read their State/Position.

    If you want we can look through an Example together?

    Regards,
    Daniel

    • Like 2
  15. YEP! That works 😃

    I can restart either FSUIPC or my Plugin and neither Crashes anymore!
    Although I only replaced the FSUIPC7 Executable - don't know where I would need the static Libraries. Since my Plugin is C#, I use Paul's C# Client which in Turn uses the dynamic WAPI Library (FSUIPC_WAPID.dll from the Utils-Directory).

    In addition my Plugin now sets the UpdateFrequency to 0 (but I've tested that before the Special-Build, that was not the Issue).

    Many thanks!!! 🙂

  16. 1 hour ago, Fragtality said:
    2 hours ago, John Dowson said:

    Note also that the WAPI is open source (see https://github.com/jldowson/FSUIPC_WAPI) and a debug version of the library is available. It may be easier if you can try and track this down in your plug-un/client (unless I can reproduce). Try with the debug enabled lib to se if you get any more information...

      I can give it a try, sure! But I'm very unused to C/C++ and especially how I debug a library which is not part of the project 😕

    Nope, I'm to spoiled from C#/.Net -.-

    After getting it finally somehow compiled, the Plugin is crashing now because "Unable to find an entry point named 'fsuipcw_isRunning' in DLL 'FSUIPC_WAPID.dll'. " 😕 
    Which is true - none of the source-File would contain such a function. I'm missing some kind of Info/Step here which I can't figure out myself.
    I wanted to give it a try with a quick & dirty try/catch Block and (and write the Exception to the log) around that specific area if that would yield any info.

  17. 1 hour ago, John Dowson said:

    Not sure what you mean by 'second [WAPI] Section' - there should only be one....!

    As simple and dumb as I said - I added another [WAPI] Section at the Bottom of the Ini to enable Logging completely unaware there was already one^^ So only the first was used and the second one was ignored. Typical Problem where the Root-Cause was in front of the Monitor 😄

     

    1 hour ago, John Dowson said:

    .it is crashing somewhere between the LOG_DEBUG and the LOG_TRACE statements in this section of the code:

    1 hour ago, John Dowson said:

    Its also strange that this only occurs when you have a 2nd WAPI client running. I will test with multiple WAPI clients tomorrow and see if I can reproduce...although that section of code should be independent on clients used....

    Strange thing, for sure! 🤔
    I can only do wild and uneducated guesses: Either dwdata, lvar_cdas or lvar_cdas at cdaId causes a Null-Pointer-Exception or the Critical/Mutex Section should also include those lines (because multiple Clients alter the Counter/Index which in turn generates a Null-Pointer/Out-of-Range Exception). *g*

    1 hour ago, John Dowson said:

    Note also that the WAPI is open source (see https://github.com/jldowson/FSUIPC_WAPI) and a debug version of the library is available. It may be easier if you can try and track this down in your plug-un/client (unless I can reproduce). Try with the debug enabled lib to se if you get any more information...

      I can give it a try, sure! But I'm very unused to C/C++ and especially how I debug a library which is not part of the project 😕

     

    1 hour ago, John Dowson said:

    Update frequency of lvars CAN be set by the client, using the LvarUpdateFrequency ini parameter, I'm not sure how thus is used/set using Paul's dll, but it should certainly be possible to set this to 0 (i.e. no update - let the  WASM control this), which should be the default. As your plugin is requesting updates, this has been changed to a non-zero value. Find out where that is, and change or remove it. Ask on Paul's dll forum if not sure.

    Sure, I'll ask Paul! I do not set the Frequency to leave it at the default, since per his description in the Thread it defaults to 6Hz (the same in the WASM-Config). So I thought the Default is fine for me! Did not want to mess around with the settings 😅
    But I can set it explicitively to zero 😉 

     

     

    59 minutes ago, John Dowson said:

    I have enough information to look into this now, and will report back when I find the cause.

    Thanks for those logs!

    Great! If you need anything more or any testing with special Builds, just drop me a line 🙂 

     

    Thanks &
    Cheers
    Daniel

  18. Some Updates:

    - It seems to be dependent on which plane is loaded. I accidentally choose the FBW32N and FSUIPC7 did not crash (twice).
    - With the Default 747 I tested all the time it crashed again.
    - Found the Reason for the missing Messages in the FSUIPC7.log: I've added a second [WAPI] Section -.- Sorry!
    - Although I now forgot to re-enable Event-Logging. Will redo later ^^
    - But: FSUIPC7 crashes at the same Point like my Plugin: after the "EVENT_LVARS_RECEIVED" Log-Message is received.
    - Compressed with 7-Zip, else it would be to big

    logexport-crashed.7z logexport-working.7z

  19. 11 minutes ago, John Dowson said:

    The FSUIPC7.log doesn't show anything...can you change the log-level to Trace and repeat please. Maybe also activate Event logging in FSUIPC7.

    Of course it does not show anything ... FSUIPC crashed, that is the Test-Case you requested ^^
    It is a very hard crash - even the catch-Block in my Plugin is not able to catch any exception that would help 😕 Got the information about the "Access Violation" from the Debug Output from VS (debugging my Plugin). The Debugger itself also just stops and is not able to show the location.

    Please provide me with the exact Settings you want me to set in the FSUIPC7.ini - I did like I described in my Post earlier and that was described as per Advanced User Guide. But either that is not want you wanted or I configured it wrong.

     

    22 minutes ago, John Dowson said:

    This won't be the cause of the crash, but you should disable this and leave the lvar update period to the WASM (you can change this period if you like).

    Uhm ... I don't know what you mean, I'm not aware that I enabled something like that in the first place 😮
    I'm just starting it (IPCManager.cs#L73) and checking the IsRunning State (IPCManager.cs#L29).
    Only after WASM is ready (that is after VariableListChanged Event received) the Lvars are read (IPCManager.cs#L267  --> IPCValueWASM.cs#L18 - for every unique Lvar the User has configured and currently visible on the Deck)

     

    46 minutes ago, John Dowson said:

    Show me the updated logs. Finishing now - I may take a look tomorrow morning if I get time, but most probably be Monday.

    Here the Logs 🙂
    Whenever you have time - it's no showstopper for normal usage and for developing the loading of new flight thankfully does not take that long in msfs (compared to p3d^^)

    logexport.zip

×
×
  • 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.