pilotjohn
-
Posts
377 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by pilotjohn
-
-
45 minutes ago, John Dowson said:
@pilotjohn Could you please try the attached version and let me know if that helps/solves your issue, thanks.
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).
-
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.
-
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 screen
2. 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).
-
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.
-
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.
-
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?
-
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.
-
4 hours ago, Thomas Richter said:
Hi,
when you create profiles in FSUIPC then they are related to Aircraft/planes only and change automatic when you change the Aircraft/plane. Check the FSUIPC manuals for Profiles and how to create them.
Thomas
It's not about the FSUIPC profiles, but the Stream Deck profiles (e.g. what button does what and show what image).
-
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).
-
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).
-
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:
- 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.
-
1 hour ago, Pete Dowson said:
I've updated the text and the link for the list of controls now.
Pete
Ack, thank you. That works and it's what I was looking for.
-
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.
-
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:
-
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. 🙂
-
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.
FSUIPC7 intermittent disconnects: TransmitClientEvent failures
in FSUIPC7 MSFS
Posted
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?