pilotjohn

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?

Thanks... this appears to fix the problem. I tested it twice through 4 separate sessions (2 each, old version problem, new version no problem).

A quick report back with the just released version, the first flight of the day issue remains: if FSUIPC is running before MSFS is started, the first flight load does not respect any control inputs until what I assume is a reconnect (forced by going to Axes... and clicking Ok).

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.

I have all my axes set to "Send direct to FSUIPC Calibration" and continue to experience disconnects. This usually happens when I'm turning on the ground tightly (e.g. with some differential breaking, although is probably irrelevant).

I filed a CTD and general SimConnect bug, listing: 1. Random crashes to desktop, especially during flight loading screen2. On first flight load SimConnect input is ignored and requires a reconnect/restart (of FSUIPC)3. Random periods where SimConnect inputs are completely ignored and reconnect/restart of the client does not solve the issue (but eventually recovers)

Nothing else is assigned in MSFS (I created FSUIPC or None profiles where applicable). I have two Thustmasters that have a "None" profile, and the VirtualFly axes have an FSUIPC profile which are unset in MSFS. I'll dig more to make sure (at least nothing that would so noisy), unless the "wind" buffeting the rudder would be sent to MSFS. 🙂

Ok, so in the 350 this is likely just an animation issue (e.g. at -15% the reverse lever does not go past the detent mark), but in a the Caravan it seems fully correct.

Similar issues happened to me today. Taxiing on the ground as I was turning around, all axes controls (don't have any buttons), went dead. FSUIPC still connected, Axes showing correct input etc. Exiting and restarting FSUIPC did not help. It randomly recovered after a few minutes for no apparent reason as I was about to quit the sim.

FWIW, I've been seeing CTDs that started after I started using FSUIPC (or I would imagine any other SimConnect client).

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

The logs are attached, and here's the series of events: Start FSUIPC and enable axes logging Exit FSUIPC, delete log Start FSUIPC Start Sim Launch into flight Axis does not move anything Show FSUIPC, go to Axes, check movement/calibration, click Ok (don't have to check, clicking Ok is enough) Axis starts working in sim <end of log> I then also tried to: Exit FSUIPC Start FSUIPC Axis works correctly End flight Launch into flight 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

The throttle axes don't start working until I open and close the Axes settings. For some reason the aileron/elevator work fine, but I have no throttle/prop/mixture when first launched into the sim.

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.

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?

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

It's not about the FSUIPC profiles, but the Stream Deck profiles (e.g. what button does what and show what image).

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

Are there any plans to support Stream Deck in FSUIPC? While it seems the device could be used to trigger FSUIPC through hotkeys (or vJoy with an existing plugin), there doesn't seem to be a clean way to have it switch profiles on plane changes (for example).

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: Low-level: basic interface for button handling (e.g. efficient callback infrastructure etc.) Mid-level: logic that is generic (that may require state coordination), but that can be reduced in complexity to simple state changes 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: Map OFF/ON or ON/OFF/ON to ON/ON or ON/ON/ON states (e.g. like https://gist.github.com/IslandJohn/06589d5dec3c278dcd75f207cf42d099) Map long and short presses to different buttons (e.g. https://gist.github.com/IslandJohn/30fb66b8a3d0161ff6fe15053c9f3d01) Simulate encoder acceleration by pulsing vJoy buttons (e.g. https://gist.github.com/IslandJohn/ee13718fce203af52f13bd3c8e0e0ae2) Map multiple toggles to decoded bit states (like two OFF/ON to toggles to 4 buttons, e.g. OFF/OFF = 1, OFF/ON.= 2, ON/OFF = 3, ON/ON = 4) 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.

Ack, thank you. That works and it's what I was looking for.

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

Where can I download the Advanced User Guide or other document that lists all the command/events for the sim? I gave up on FSX/P3Dv2 5 years ago, and don't have a PC with the sim or FSUPC installed, and can't seem to install without the sim being installed (in a VM for example). The document listed in following thread is a 404, not found:

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

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.