Jump to content
The simFlight Network Forums

pilotjohn

Members
  • Posts

    377
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by pilotjohn

  1. 2 hours ago, John Dowson said:

    @pilotjohn ok. But you have reported your issue in a different thread. Your issue is distinct from this issue, which has been identified as a SimConnect error that is causing the disconnect, known by having TransmitClientEvent failures noted in the log. There are currently lots of issues with SimConnect (and many in FSUIPC7, i'm sure), but it does not help me in the investigation when cross-posting your issues to different topics/posts. Could you please refrain from doing this, and post in the topic relevant to your problem. So, if you do not see any 'TransmitClientEvent' failures in your log, please do not add or follow the advice in this thread. It just causes confusion. Thanks.

    I will update the title of this thread to make this thread more specific to this issue.

    John

     

    Ack, should I start a separate thread on the in-game disconnects or is "FSUIPC7 control problem" the right thread for disconnects without the error?

  2. 2 hours ago, John Dowson said:

    Please note that there are known issues with flight loading at the moment, so use this feature at your own risk.

    I'll take a look at  your logs later and get back to you, but could you check your MSFS settings in relation to this, as reported in similar post (FSUIPC7 Control problem):
     

    John

    So to be clear, I'm not loading the flight from FSUIPC. The flight is being selected and loaded through MSFS world view, it's just that the controls don't work on "initial flight of the day" (e.g. first flight after sim launch with FSUIPC open).

    I have never pressed that key combination in my life 🙂, but will also unset it.

  3. I've recently had a similar experience, but it happened during a flight (or ground). Everything was set up, I was taxiing back to turn around, and all of sudden all axis controls (don't have any button bindings yet) stopped working. FSUIPC was showing the controls in axes, but the sim was not responded. Even exiting and restarting FSUIPC did not solve it, but it eventually resolved itself randomly (took maybe 2 minutes).

  4. The logs are attached, and here's the series of events: 

    1. Start FSUIPC and enable axes logging
    2. Exit FSUIPC, delete log
    3. Start FSUIPC
    4. Start Sim
    5. Launch into flight
    6. Axis does not move anything
    7. Show FSUIPC, go to Axes, check movement/calibration, click Ok (don't have to check, clicking Ok is enough)
    8. Axis starts working in sim
    9. <end of log>

    I then also tried to:

    1. Exit FSUIPC
    2. Start FSUIPC
    3. Axis works correctly
    4. End flight
    5. Launch into flight
    6. Axis works correctly

    It seems this happens when FSUIPC is launched before the simulator. I reproduced it a second time (quit sim, exit FSUIPC, repeat first set of steps).

    Also, I'm not sure what the AXIS_RUDDER_SET entries are all about, since nothing is assigned to that in FSUIPC (ini attached).

    Lastly, since playing with FSUIPC, I've been having a few CTDs, primarily (as I remember), during the loading into a flight progress bar (including the first attempt of this test - log also attached).

     

     

    FSUIPC7.ini FSUIPC7-1.log FSUIPC7-2.log FSUIPC7-CTD.log

  5. 1 hour ago, Pete Dowson said:

    -4096 is a nominal amount for calibration only. The actual max reverse sent is specified by the Aircraft-specific configuration -- specifically by the "min_throttle_limit" parameter in the Aircraft.CFG file. I'm not sure, but does that aircraft even have such a parameter.

    Typically that value might be -0.25 which means - (for reverse) 25%: hence the general value initially assumed of -4096 (25% of -16384).

    The value is actually supposed to be supplied in a SimConnect variable, "THROTTLE LOWER LIMIT", which is read into offset 0B00. Please use the Offset logging facility in FSUIPC to log 0B00 as type S16, to the Normal log, and tell us what it says.

    Pete

     

     

    Here's the log... which seems to align with the 15 marking (2457/16384) for whatever logic is used there.

     

          672 LogOptions=00000000 00000001
          875 Monitor IPC:0B00 (S16) = 0
         3313 Simulator detected
         8469 SimConnect_Open succeeded
         8469 Running in "KittyHawk", Version: 11.0.282174.999 (SimConnect: 11.0.62651.3)
         8469 MSFS version = 11.0.282174.999
         8469 Initialising SimConnect data requests now
         8500 C:\Users\[user]\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\MISSIONS\Custom\CustomFlight\CustomFlight.FLT
         8500 SimObjects\Airplanes\Asobo_KingAir350\aircraft.CFG
         8516 User Aircraft ID 1 supplied, now being used
         8563 Aircraft loaded: running normally now ...
         9344 Monitor IPC:0B00 (S16) = -2457
         9344 SimRead: 0B00="THROTTLE LOWER LIMIT"
                FLT32: -15.0000009537
         9344 Aircraft="Beechcraft King Air 350i Asobo"

    Switching planes didn't seem to update the read for this offset (e.g. from the King Air 350 to Caravan), but the Caravan is showing 15% as well at the bottom of the controller/input range.

    The animation in the Caravan goes to the stops (but still reads 15%), while on the King Air it goes to the "lift" marking.

  6. Reverse in aircraft (350) only goes to 15%.

    I'm running latest MSFS using latest FSUIPC7 beta with a VirtualFly TQ6+.

    1. Throttle axis is sent direct to FSUIPC for calibration of Throttle1

    2. Throttle1 is calibrated to the range 16383 .. -9801 (detent) and -10100 .. -16384

    3. Out correctly show 16384 .. 0 and 0 .. -4096 for range, but in aircraft reverser only goes to 15%

    Am I missing something?

  7. 6 hours ago, Andydigital said:

    Spad.Next is adding support for the Stream Deck, its already available in the beta version. Unfortunately the trial version doesn't allow for testing of beta builds, but I took the plunge anyway and it is working great and Spad.Next is a very powerful tool anyway. They are even adding support for VRInsight gear in the not too distant future. 

    Good to know, thanks. For now I'll probably use the vJoy actions without changing the button display state.

  8. 1 hour ago, John Dowson said:

    No, I've never even heard of this before now! Seems to be something used for 'live streaming'. I'm not sure what support FSUIPC could provide for such a device.

    I think the idea started for streaming, but it's essentially a button interface box (that happens to have a screen to allow you to "label" the buttons). It has an intuitive UI for configuring behaviors and an API for interfacing with it. I've seen several people use it for simming but it's a total kludge in most cases. There's a vJoy plugin for their app which would allow me to use it with FSUIPC, but the device itself can have profiles and the buttons themselves can actually show state (since it's just a screen). These are things that are missing. It would be nice to be able to use aircraft changes to load different button configurations (e.g. instead of having a generic panel with all the buttons for any airplane, load a config for specific planes), and to actually show the state of things (e.g. gear up/down, lights on/off).

  9. On 3/4/2019 at 1:23 PM, stevem737 said:

    Hi Reinhard,

    Thanks very much for your reply.  I guess you're saying that, performance-wise, many smaller scripts are better than one big one.

    It's not just the 50+ scripts I'll have to write, though... it's the 6 additional entries that FSUIPC creates in the pull-down menu when one, single Lua script is put in the Modules folder (i.e., FSUIPC creates the additional LuaDebug___, LuaKill___, LuaSet___, Lua Clear___, LuaToggle___, and LuaValue___ for every Lua script).  So, there'd be 300 (50 x 6) additional entries in the FSUIPC pull-down menu.  It's not easy to scroll that massive pull-down menu, if one needs to make a change.

    Here is a follow-up question:

    For a double-pole, single-throw physical switch, I cannot use this "toggle" code, because the code can get out of sync with the switch position, depending on where the switch is when you start the software:

    
    -- I cannot use this "toggle" code
    function switch_On ()
         ipc.writeLvar("FUEL_PUMP_sw7", 1)
    end
     
    function switch_Off ()
         ipc.writeLvar("FUEL_PUMP_sw7", 0)
    end
     
    function switch_Toggle ()
      if ipc.readLvar("FUEL_PUMP_sw7") == 0 then
           switch_On ()
      else
           switch_Off ()
      end
    end
    
    switch_Toggle ()

    Instead, is there a way to write a single Lua script like this, where it references the joystick controller and the button:

    
    -- Hard-code the switch position, instead of a toggle function
    -- I realize I could have two separate Lua scripts, one for each
    -- switch position, but combining them would make for fewer scripts
    if [JOYSTICK1_BUTTON7] == 1 then
    	ipc.writeLvar("FUEL_PUMP_sw7", 1)
    end
    
    if [JOYSTICK1_BUTTON7] == 0 then
    	ipc.writeLvar("FUEL_PUMP_sw7", 0)
    end

    2) 

    What solution did you go with?

    I will be in a similar state as I'm building a custom panel with many toggles, push buttons, encoders, with different behaviors (for example convert a OFF/ON toggle to ON/ON, or accelerate encoder, or long and short press etc.). I would very much prefer having everything in one codebase, but FSUIPC's Lua interface is sub-optimal for this, as you have to either launch on button press (as stated this incurs startup cost), or run one script polling (also inefficient, and may miss buttons?). Is there some wait/block function in the event loop (I don't remember from 5+ years when I was into this)? Also, there's no GUI interface/API to Lua scripts.

    I view this as a layered problem:

    1. Low-level: basic interface for button handling (e.g. efficient callback infrastructure etc.)
    2. Mid-level: logic that is generic (that may require state coordination), but that can be reduced in complexity to simple state changes
    3. High-level: simulator specific code that needs an interface like FSUIPC

    So my current plan is to perform most of the "mid-level" button logic conversion in Joystick Gremlin's Python interface, which is event driven and can be GUI-customized (e.g. if you have a generic script like convert OFF/ON to ON/ON, you can set the button used by the script in the GUI, making configuration easy and simple). JG handles this well by instantiating your Python code once (for each config) and then using callbacks on state changes. JG is also needed to convert from 64 buttons (e.g. Leo Bodnar's BBI64) to 32, since FSUIPC can only deal with 32 buttons on a given device. I will use JG for managing generic non-sim button behavior and mapping them from the physical interface to many vJoy devices. Then, I'll use FSUIPC for all the sim-specific stuff. For now, the identified generic behaviors are:

    I will use FSUIPC to map the vJoy buttons to whatever I need in the simulator. I do wish FSUIPC would have a GUI interface for sending multiple events or constructing some rudimentary logic (this is a rather simple GUI construct, but changes from major versions are mostly cosmetic on the UI side). Maybe there's an opportunity to write an FSUIPC GUI manager that generates these entries. 

     

     

  10. 1 hour ago, Pete Dowson said:

    Ah, the "Revised list of FSX controls" was superseded a long time ago. I'll look into updating that reference.

    If you mean for up-to-date reference, then you do have to install a current version.  The Advanced User guide doesn't list sim events inany case.

    What is it you wish to do with this without any sim installation?

    Pete

     

     

    I'm just looking for the list of events/command to send to the sim, as I'm planning my custom panel.

  11. 1 hour ago, Pete Dowson said:

    Who is  "are there any plans ..." addressed to?

    You must realise that there's a huge variety of hardware folks use, with an equally huge variety of interfaces and driving software. How is any "functionality" to be engineered for all that when it isn't known how to detect all such switch states?

    No, this sort of thing has to be planned and implemented according to the specific build of your cockpit.

    In my case I always load up "cold & dark", and when ending the previous session i always turn all the hardware switches and selectors to match. It isn't too hard -- make a checklist if you wish, but I always know how they should look so it has fast become semi-automatic for me.

    I did think once of programming it, but it simply isn't worth the hassle, especially if like me you have a real hodge podge of hardware from different sources connecting in different ways to different networked computers using different drivers. And much of it handled directly by ProSim rather than FSUIPC in any case.

    Pete

     

    I figured this was likely not on your roadmap, but maybe someone already hacked together something. I think with event based triggering it's less of (or not) an issue. With generic buttons and switches this seems semi-feasible, but you would need a well defined mapping from event sent to sim, to state of switches/system, and that will get unwieldy. This is a nice feature in large sims though. 🙂

  12. 45 minutes ago, Thomas Richter said:

    Hi,

    FSUIPC doesn't know your hardware and so it doesn't know any state of your used hardware. If you use i.e. Joystick controller based hardware like Bodnar cards then those would have to raise events as FSUIPC doesn't poll constant controllers. So it depends on the software/driver that the hardware uses to communicate with FSUIPC/WidFS.

    Thomas

    So are you saying that if a button is in an "ON" state, FSUIPC won't trigger an "ON" event unless there's a state change (e.g. that button goes from OFF to ON)? If so, that's mostly good, meaning that the aircraft's state won't change unless that button is touched first. I suppose this would be fine and  there's not need to get the panels into the "correct" state.

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