Pete Dowson

Wasn't "Flight" scrapped many years ago, a failed MS venture after FSX Accel? It wasn't compatible with any third party programs. FSUIPC4 is made for FSX. If you do mean the recently released MS Flight Simulator then, as John says, you'd need FSUIPC7, currently on open Beta. Pete

That's the standard older spacing and is supported ok I think (will check the offsets later today as I need them for my Upper cockpit). . The newer spacing is 8.33 isn't it? None of my hardware radios support that, but there are separate offsets for those which I will check too. Pete

John, the problem is not in FSUIPC's facility to load flights or plans, thought that is certainly still true as far as I know. it is the fact that the plans saved by AutoSave aren't usable. MSFS won't load them, irrespective of how you try. It doesn't complain, it just does nothing. The Autosaved flights are of no use at present. I did say I tried comparing one with a regular saved one but whilst there are lots of differences I couldn't pin-point anything easily. I guess whatever is missing could be determined by lots of trial and error, but as we can't fix it ourselves I saw no point. If anything in FSUIPC needs disabling, it's the AutoSave facility as it disappoints folks thinking they have a way of recovering after a crash only to find it doesn't work. Love Dad

In versions 1 and 2 of ProSim, tThe Prosim panel display is part of ProSimPanels.exer. In version 3 it's now within ProSimDisplay.exe. Either way the link between ProSim and its parts is direct (via TCP or UDP protocol to/from an IP Address), it is NOT via FSUIPC. FSUIPC lierally is out of it. No, all of ProSim's parts talk to each other directly, not via FSUIPC. Pete

Oh, right. Some minor directory corruption by the sound of it. Files intact but pointers wrong. Chkdsk is good at correcting those. Good! Pete

How are you seeing this? I don't understand. Where are you looking to see the action of the switches? What is ProSim actually sending to change a switch? On my cockpit FSUIPC interfaces TO Prosim for all my switches. ProSim doesn't send any switch settings BACK to my cockpit. The traffic is cockpit -> FSUIPC -> ProSim. Then Prosim acts on whatever the switches request, via the offsets I've programmed in its settings. How is it yours is in reverse? Pete

No, I'd never say that. You choose whichever is applicable. My throttle quadrant and Thomas's are both serial port devices, and that needs PFCcom64.dll with FSUIPC5,6 or 7. It may possibly be a HID device (USB rather than serial port) which needs PFCHid64.dll instead. The quadrants in the Cirrus consoles are like that. But PFC also made (make?) yokes and pedals which are normal Joystick USB devices and don't need any special drivers at all. Whether they also made normal UDB throttle quadrants I really don't know. Sorry. You should get adequate documentation or other information from PFC, with the hardware. You only install the drivers you need. You'll just confuse things otherwise. Pete

If you assign in FSUIPC you must NOT also have any assignments in MSFS. There's bound to be such conflicts if you do. Choose FSUIPC or MSFS for axis assignments, not both. This has always been the case with FSX and P3D before this -- but at least those had one place where you could disable controllers. I think in MSFS you have to create a blank profile. Pete

Hmm. Strange that it would install different files on that basis. Pete

"return" means "exist from the function". But you haven't declared a function. The script will end naturally when the last line is passed. your "return" does no harm there, it was just misleading, making it look like the script was partial. The FSUIPC log you provide shows multiple key presses repeating very fast, alternating A 1 A 1 A 1 ...before FSUIPC is actually fully initialised ("Starting everything now", line 15093. I suggest you touch nothing until everything is loaded and 'ready to fly'. Then the sequence is many repeats of B 2, then C 3 and so on. I really don't know how you are making the keyboard inputs look like this. The problem with keys repeating when you are assigning them to read a Lua file, compile it, run it and terminate it is that it just can't be done at the keyboard repeat rate of typical 15-20 per sec. You MUST check no repeats. I suspect that quite often the Lua pli=u-in is being killed before it even does anything! Also, you checked the Log option for separate logging of the Lua results. That spoils the whole point of having the log output -- to show the relationship between you pressing keys and what the plug-in does. Please UNCHECK that separate log option! Then the Lua log lines will go into the main log showing the relationship with the key presses. AND uncheck Lua log/trace options. you don't need that either -- the whole point of adding the ipc.log line was to get a single line each time an ipcPARAM was seen. Pete

Yes, this confirms that only the Rudder and Yoke are registering as Joystick type devices. You could run HidScanner to get more details of other types of device. In the past we've found that true Joystick HID devices work fine without special drivers installed. The Saitek driver may be masking the device's true Joystick nature, assuming you want to deal with it via its own settings. So you could try uninstalling the Saitek driver. FSUIPC doesn't have any special non-Joystick drivers built in (except some heritage code for VRi devices). Even GoFlight devices need a GoFlight DLL. John is probably correct in saying you need SPAD or SPAD.Next, but those too might need the Saitek driver uninstalled. Pete

The "Manifest" files are not the .DLLs. Here the DLLs are installed in folders like C:\Windows\WinSxS\x86_microsoft.flightsimulator.simconnect_67c7c14424d61b5b_10.0.60905.0_none_dd92b94d8a196297 C:\Windows\WinSxS\x86_microsoft.flightsimulator.simconnect_67c7c14424d61b5b_10.0.61242.0_none_e079b46b85043c20 C:\Windows\WinSxS\x86_microsoft.flightsimulator.simconnect_67c7c14424d61b5b_10.0.61259.0_none_55f5ecdc14f60568 This is on a Win10 installation, running Win10 version 2004. I have seen installs where they go into C:\Windows\WinSxS\Fusion\.... folders instead (i.e. one subdirectory, "Fusion", deeper, but we never figured out what made the difference. But really, if you have successfully run the SimConnect.msi installers, the DLLs should be in the correct place and the FSUIPC4 installer should have found at least one of them. I think the latest FSUIPC installer may be having difficulty with versions of FSX before FSX-SE, but I am unable to test and change it now. Are you using the 4.975 installer or the latest one, Install_FSUIPC4975a ? If not the latter please try that first. If that doesn't work, there are two choices: either upgrade your FSX to FSX-SE (well worthwhile as lots of things were corrected and it performs better, being recompiled with more up to date tools), or retreat FSUIPC to 4.974:Install_FSUIPC4974.zip Pete

Crashes in MSFS do need reporting to MS/Asobo (eg on ZenDesk) along with the Event Viewer crash details from Windows. FSUIPC is an entirely separate process and can't crash another process without it having a problem with the facilities being used. The FSUIPC log, as expected, merely shows that MSFS stopped running. the same occurs if you just close it too, though sometimes (not always though, it seems) FSUIPC will receive a QUIT notice. We could try to narrow down the actions leading to such, but if they can occur just when MSFS is loading a flight without any overt action by FSUIPC, that could be fruitless. Better things to work out at present with hopefully more hope of success! Briefly, on this part: Is nothing at all assigned in MSFS too? The log is reflecting what is detected from MSFS, not what is sent to it. Pete

Well, there isn't one in the MS-Store install either. Could yours be left over from a previous install, i.e. not the release version? Were you testing the Alpha/Beta versions at all? Pete

Surely ProSim is supposed to be using SimConnect directly, not FSUIPC? As Thomas says, if it is in FSUIPC, without MSFS, you are somehow detecting changes (you don't describe how you see the change in FSUIPC...?) then it has something to do with it's interface to FSUIPC. Where are you viewing this OH panel if you aren't running MSFS? Pete

Please replace the ipc.writeSTR(0x3380, " ipcPARAM = "..ipcPARAM); ipc.writeSW(0x32FA, 2); lines with ipc.log(" ipcPARAM = "..ipcPARAM) and test again. We can't really deal with anything attempting to use the really non-working text display facilities. What is the "return" for at the end? What are you returning from? Is this a partial script? Why the 2 second delay? Pete

to my knowledge there's never been any built-in facilities for transponders in any version of FS for any aircraft apart from setting the transponder code. Any on/off and mode settings have always been local to the specific gauges in the models, and possibly controllable via Local Panel Variables ("L:Vars") if anything. Currently there's no chance of accessing anything specific and local to gauges like L:Vars from an external program like FSUIPC. We have requested such facilities from MS/Asobo, but, even then, whether they are applied to such switches is unpredictable. Pete

Okay. The value for max reverse IS working. here's the results for the airliners Boeing 787 285516 Monitor IPC:0B00 (S16) = -4095 285516 SimRead: 0B00="THROTTLE LOWER LIMIT" FLT32: -25 285531 Aircraft="Boeing 787-10 Asobo" The offset value didn't change for the 747, meaning it is the same for both Boeings. Airbus A320: 911609 Monitor IPC:0B00 (S16) = -3276 911609 SimRead: 0B00="THROTTLE LOWER LIMIT" FLT32: -20 911625 Aircraft="Airbus A320 Neo Asobo" So I think the 15% you are getting for the A350 is intentional. If you think it is wrong perhaps you could lodge it as a problem with Asobo (on Zendesk). Ah! Thanks! So there we have it -- 20% for the A320 as reported by SimConnect. @pilotjohn If the -15% for the 350 isn't right maybe you can adjust it in the engines.cfg file. Pete

First, there's no "WideServer.INI" (and no "WideServer.DLL"). WideServer is included in FSUIPC7. the only part of WideFS you need is WideClient. Delete WideServer.INI and WideServer.DLL from the FSUIPC folder. Second, if you actually read the documentation I assume you must have read the part on page 3 headed: Configure your Network IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! This tells you about possible connection problems due not only to Windows Firewalls, but also to its WorkGroup system. It also suggests making things more straightforward for WideClient to connect by providing the ServerIPAddr and Protocol parameters. Try that. Coding language? Entering single line parameters is "coding" in your book? In a foreign language? Flying, whether on a simulator or for real, is a complex task and surely requires some application -- configuring things is all part of the task. You must have had to configure things before, surely? BTW the WideClient.log you uploaded appears to be empty. How did that happen? If you have any more problems, the FSUIPC7.LOG from the FSUIPC7 folder is more important, plus the WideClient.LOG on the client PC. Pete

First, please note that you posted into a reference sub-forum ("FAQ") which is clearly marked, in red, not for support requests! I've moved it for you otherwise i would never be answered! I don't know the "saitek switch panel", so please tell me -- is it seen by Windows as a joystick type device? Does the Windows properties see all the switches? If it isn't a joystick type device then neither FSUIPC nor FSX would recognise it. Does the "latest driver" for it handle it? If so, why would you need FSUIPC or FSX to see it? It may work better for them if you uninstalled the saitek driver. Why would that be? Is that a problem with the saitek drivers -- Saitek not keeping up with Windows developments? But you said "i have purchased a new Saitek Flight switch panel". Is this, then, replacing an old Saitek Switch Panel? If you look in the FSX Modules folder you will see a file called FSUIP4.Joyscan.csv. This will tell me more about your devices. Let me see that. Pete

Yes, SimConnect is telling us that the max reverse thrust is 2457/16384 of full thrust. If this isn't defined in the Aircraft.CFG file for the aircraft then it must be default. Maybe it isn't defined for any of the aircraft. It might be a good idea to see if it reads the same for a jet, especially an airliner like the 787 or Airbus. I'll check this myself later. For information, the parameter defining this value in FSX was in the [GeneralEngineData] section of the Aircraft.cfg file. The section for the old King Air 350 was: [GeneralEngineData] engine_type = 5 //0=Piston, 1=Jet, 2=None, 3=Helo-Turbine, 4=Rocket, 5=Turboprop Engine.0 = -8.3, -4.8, 0.5 //(feet) longitudinal, lateral, vertical distance from reference datum Engine.1 = -8.3, 4.8, 0.5 //(feet) longitudinal, lateral, vertical distance from reference datum fuel_flow_scalar = 1.0 //Scalar for fuel flow efficiency min_throttle_limit = -0.25; //Minimum percent throttle. Generally negative for turbine reverser Maybe this doesn't feature in the "new model", but in that case SimConnect should supply the correct value from wherever it is now defined. It will probably need raising with Asobo. Pete

-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

So it used to, but then it suddenly stopped? When, exactly? hat changed? FSUIPC doesn't support anything called "usbkeys card opencockpit", at least not directly. So how does it interface to FSUIPC? What is it, exactly? Pete

I'm pretty sure it always used to. but then it needs to use camera views and so far we've not had much success with the usual SimConnect controls for those. So it makes one think ... Pete

No, it isn't true. You can just start the Lua plug-in again. The previous incarnation will be automatically killed and the revised one started. This has always been the case. If you are starting the plug-in automatically (via an [Auto] entry in the INI, or from another Lua like ipcReady.lua) then you'll need to just assign a keypress or button to loading it whilst you are developing it. Pete They too should work, being unchanged since FSUIPC6. None of the facilities needing in-FS screen displays work correctly yet as the text display facilities aren't working in SimConnect. You could probably emulate the facility using the WND Lua library. Pete