John Dowson

I am sorry but I need to see your FSUIPC6.ini file to see your settings, not your FSUIPC6.log file. Please attach this. Maybe in the real aircraft, but how does this work in the sim? I presume you are using the flap controls for the flaps (flaps set, flaps incr/decr), but what controls/events are used to control the wing sweep? Ok. So you want one hardware axis to control one section of the sim's flaps axis (to control flaps), and another hardware axis to control another section of the flaps axis. So, the full range of your hardware flaps axis (-16384 - + 16383) will control the flaps section of the sims flaps axis (-16328 to x), and the full range of your wing sweep axis (again -16384 to +16383) will control the wing sweep range of the sim's flaps axis (x to 16383)? And that will also cycle through the wing sweep positions, no? Ok. But the flaps could be in any position when you use the wing sweep lever, no? If so, would this not cause a strange jump if using the wing sweep lever, say, when the flaps were stowed? Rather than using axis ranges, try assigning to the Flaps Set control, and then scale the axis assignment to the range to the wing sweep range, using FSUIPC's axis scaling functionality - see section Additional parameters to scale input axis values on page 43 of the Advanced User guide. If you want the wing sweep lever to control the range 12000 to 16383, try adding a scaling factor of *0.134,+14195. If the wing sweep range is before or after the 12000 mark, adjust as needed. It should also be possible using axis ranges, but I think you would need to use the Flaps Set control to set the flap positions to the correct wing sweep setting for each range, and not use the in/dec or other controls. Sorry, can't see that as I am not on Facebook. John

Not sure what you mean. Once FSUIPC7 is started, it is iconized to your system tray, not the task bar. This has always been the case. It will only appear in the task bar once you open FSUIPC7 from the system tray, or if it is iconized to the system tray once opened. The only change to the auto-start is the way FSUIPC7 is started, now how it is available from the system tray or task bar. John

That looks fine, and shows that FSUIPC7 should be started here: start "" "C:\FSUIPC7\FSUIPC7.exe" "-auto2" after a 95 second delay after MSFS is started. As long as you don't kill the script (by closing/exiting the console window) I cannot see how FSUIPC7 cannot be auto-started if using that bat file (usually via the MSFS desktop icon). As I said, if you are having issues with this (and I have no idea why), then re-install and switch back to the old method of starting FSUIPC7, via the EXE.xml file. John

Please see Could you please attach your MSFS.bat file so I can take a look at it. John

Are you aware of the changes to auto-start in the latest version, 7.3.12? In 7,4,12, the default way to auto-start FSUIPC7 has been changed from using the MSFS EXE.xml file to using the FSUIPC7-installed MSFS.bat file, vie the MSFS Desktop icon installed by FSUIPC7. Therefore, if you are using the default auto-start method, you must use the MSFS desktop icon installed by the FSUIPC7 installer. If you start MSFS any other way, FSUIPC7 will not be auto-started. A console window is also created but this should be iconized, although sometimes this window is shown (a black/empty console window). If this window is killed/closed, then FSUIPC7 will not be auto-started. If you are having issues with starting FSUIPC7 via the MSFS.bat file/Desktop icon, you can go back to the previous method of auto-starting FSUIPC7, using the MSFS EXE.xml file. To do this, re-run the FSUIPC7 installer. In the Components selection page, open the auto-start component, de-select the MSFS.bat method of auto-start and check the EXE.xml method. This will then revert to the previous method. Note that I changed this as it looks like lua fscripts are running approx 10-13x slower when FSUIPC7 is auto-started via the EXE.xml method. If you do not use many lua scripts then this may not be an issue, and the performance is still probably acceptable even if you are. John

Btw, where is that cockpit VC image from? That doesn't look like the virtual cockpit that I see in the C510. What are those lighting switches that you say do not work? There are various Input Events for the lights, so try those. For the generator switch, you can use the Input Event ELECTRICAL_Alternator_2 with values/parameters 0, 1 & 2 for the 3 positions. In the down position (2), it will only stay there momentarily and then spring back to the central position (1), as it does in the VC. John

Not really. This doesn't really make sense. All your assignments are kept in the ini file (or files). The myevents.txt file just holds your preset definitions. I could have kept these in a [myOffsets] section of the ini file I suppose, but as the MobiFlight presets are provided via the events.txt file, I thought I would use the same mechanism for user-defined presets. Why not? What do you mean? You should use Input Events when available, I see no reason not to. No need to attached this as I know what is available as I have this aircraft. I don't see why they shouldn't. There can be a short delay when using Input Events for incrementing/decrementing the Input Event value, as a round trip to the FS is needed to get the updated value before a next increment/decrement, but this is the same as when using lvars. John

First, you posted in the Announcements sub-forum, where it explicitly states NOT for support requests. Please post in the correct forum for support. I have moved your post. It it is not working, it can be due to one of three things: 1. There is an issue with the assignment and FSUIPC is not sending the key press when you press the button. You can easily check this by activating logging for Buttons and key operations, open the logging console (check Send to console window) and see if the keysend command is logged. 2. The keyboard shortcut Ctrl+[ is not assigned to control the TOGA switch. Check this in your P3D key assignments. Note the default assignment for TOGA is Shift+Ctrl+G. You can also set logging for Events (non-axis controls) and you should see the AUTO_THROTTLE_TO_GA event logged. 3. The default AUTO_THROTTLE_TO_GA command does not work for the PMDG NGX aircraft. PMDG aircraft use their own custom controls for many buttons/switches. Looking at the header field for the NG3 (for the MSFS version, I do not have this aircraft for P3D) I can see the following custom controls: #define EVT_CONTROL_STAND_TOGA1_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 684) #define EVT_CONTROL_STAND_TOGA2_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 687) To use the PMDG custom controls, see this FAQ entry: John

Can you please attach your FSUIPC6.log file so that I can see your assignments. Are you calibrating with detents, or sending those Flaps Decr and Flaps 1 (not sure what the first extension would be in this aircraft) commands on entering/leaving an axis range? If so, I don't understand why you would want to do this if you have also assigned the axis itself to the Flaps Set control. And the Flaps Incr/Decr events/controls do not take a parameter. If not calibrating with detents, maybe try this - see page 45 of the User Guide. Best to do this with the axis assigned using Send direct to FSUIPC calibration, but can use Send to FS as normal axis if this gives issues.

Please also note that I have already advised on how to assign for the battery, avionics, starter - all of these are easily controlled using Input Events. For any further questions on the C510, can you please use the other thread you created for this: I would like to keep information on how to use FSUIPC7 to control this aircraft in one place, so it is easy to find for other users. So, please post in that thread for anything that you are having difficulties with - and please re-read what I have already said in that thread. John

Any errors setting client data calculator code are NOT due to the calculator code itself, it means that the calculator code could not be sent to the sim/WASM for some reason. Any errors in the calculator code itself will be logged in the FSUIPC_WASM.log file (or possibly the MSFS console) and not in the FSUIPC7.log file. Looking at your log file. the errors are reported as the WAPI hasn't yet connected to the FSUIC7 WASM module and so the calculator code could not be sent to the sim, i.e. they are logged before this message is logged" Basically you are trying to do things too early - just be more patient. Once you have loaded an aircraft and are ready-to-fly, wait for a short while before trying to do anything. Usually it is best to wait until the lvars have been loaded, i.e. when this is logged: The reception of lvars is also logged in the FSUIPC7 main window. And if using InputEvents, you need to wait until all these are loaded and initial values received, which in your log is here: i.e. approximately 2 minutes after FSUIPC7 is started. The number of Input Events is also logged in the FSUIPC7 main window. I will look into your other questions, as well as taking another look at the C510, at the weekend. I believe SU15 should be released tomorrow, and I will release FSUIPC 7.4.12 shortly afterwards, which has improved handling for Input Events - this may be useful for the C510 so please update once released. John Later: could you just give me a list of the buttons/switches that you are having issues with, and I will take a look at each and let you know how to assign to them in FSUIPC7. This will be quicker and easier for me than going through your files or lua code.

👍😎

First, run MSFS and FSUIPC7 and load the PMDG aircraft to the ready-to-fly state. Then, open the FSUIPC7 axis assignments panel and create your profile lets say you call the profile PMDG-737. You will be asked if you want to import your axes - agree to this. Then click Ok, and then exit FSUIPC7. Next, open your FSUIPC7 in an editor. Find the profile section and edit the aircraft name to use a substring, e.g. Next, rename all the following sections to make them profile specific: [JoystickCalibration] -> [JoystickCalibration.PMDG-737] [Buttons] -> [Buttons.PMDG-737] [Keys] -> [Keys.PMDG-737] and also the following, but only if using them: [Auto] -> [Auto.PMDG-737] [LvarOffsets] -> [LvarOffsets.PMDG-737] [InputEventOffsets] -> [InputEventOffsets.PMDG-737] Then re-start FSUIPC7 and you should be good-to-go. Cheers, John

The latter, i.e. you have created that and forgotten about it. FSUIPC does create a file called FSUIPC5.JoyNames.csv, but you do not need to copy that - it is created on-the-fly. John

Seems like you are using some different controllers now as well: 1. There is no longer a HOTAS Warthog Joystick, but a Right VPC Stick WarBRD 2. The rudder pedals have changed from Mad Catz Pro Flight Combat Rudder Pedals to Saitek Pro Flight Combat Rudder Pedals I have also switched the assignments for these, i.e. what was assigned to the HOTAS Warthog Joystick are now assigned to the Right VPC Stick WarBRD, and what was assigned to the Mad Catz Pro Flight Combat Rudder Pedals are now assigned to the Saitek Pro Flight Combat Rudder Pedals. The pedal assignments should be ok, but you should revise your assignments to the Right VPC Stick WarBRD. So, please try the attached ini file. Any issues, let me know and please re-attach your updated .log and .ini files. I have also update your profile aircraft names to use substrings. However, you seem to have two profiles for the 777 so I have left these: This is the same aircraft so you should use just one profile. I am not sure which one you want to use, but choose one profile, delete the other profile (all profile sections), and then set the aircraft name to be a useful substring, e.g. John FSUIPC5.ini

You can edit the MSFS.bat file to remove the display of if you like, but why not just not install the desktop icon installed by the FSUIPC installer. To do this, you need to select the auto-start via the EXE.xml method (and de-select the MSFS.bat method) during installation (if you want FSUIPC7 auto-started) and also uncheck the installation of the desktop icon on the last installer page. If you want to use the MSFS.bat but just not show the splash screen, change this line: start mshta "%splash%" to this ::start mshta "%splash%" i.e. comment it out John

You also need to copy across the FSUIPC5.key file or re-register, as well as any lua files (*.lua), macro files (*.mcro) and additional drivers (*.dll) that you are using, if any. Just copying across your ini file is also not enough, as the GUIDs of your devices will also have changed, and so some manual editing of the ini is needed. This is far easier if you are using the JoyLetters facility on your old PC, but please attach both your FSUIPC5.ini and FSUIPC5.lg files from your new PC and I will take a look. John

That seems to be the same as the documentatin link I always give when people ask about this: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm Looks like this has recently been updated - until recently this was very sparse and only gave the basics! Looks a lot better now... Not sure now - I usually only use the stacks/registers if the value is needed in multiple places... Looking at the calc code now, it doesn't look correct...it is not possible to set a B:var via calc code...that is why an lvar is introduced, to control the b:var via using that xml update.

After the latest AS update, the API documentation is now available in the AS documentation folder (Active_Sky_API.pdf) - could you take a look at this? I am not sure what information I should request. I would have thought to use the GetCurrentConditions call. However I am not sure how useful this is - it seems to return the first string only from the Conditions tab of the AS UI - i.e. the Metar data. This is what this returns when on the runway at LEVX (Vigo, Spain): @POS 201348Z 28012KT 250V320 9999 FEW019 SCT024 FEW028 16/10 Q1015 RMK ADVANCED INTERPOLATION For comparison, this is what the AS UI shows under the Conditions tab: The GetMetarInfoAt call using the ICAO LEVX gives the following string: LEVX 201400Z 28012KT 250V320 9999 FEW019 SCT024 FEW028TCU 16/10 Q1015 NOSIG I guess I could extract the wind direction/speed, temperature, etc from the Metar string.... Or would the basic weather data (WindDirection, WindSpeed, Temperature, Pressure) at the aircraft position, using the GetAtmoshere call, be sufficient?

That is why I needed to see the log file! I don't think you should change this even if possible - if it is running with elevated privileges then I', pretty sure its doing this for a reason... Sorry but if AS is being ran with elevated privileges and FSUIPC not, then I don't think it will be possible to have AS auto-started by FSUIPC7. I do have AS for MSFS so will take a look when I get time (after the SU15 release). You could maybe try adding an entry to the MSFS EXE.xml file instead to see if that can start AS.

Can you please show me/attach your FSUIPC7.log and FSUIPC7.ini files. John

Your ini file shows that you have assigned to the Lua control and not the LuaValue control: This is also confirmed by your log file, which shows the lua script continually being restarted (which is what using the Lua control will do): Not sure why as the image you attached shows LuaValue - can you please check again. Your assignment should look like this: It is only running as it is being started/re-started each time the axis valuer changes. As well as changing the assignment from using Lua to LuaValue, you also need to have the lua auto-started. To do this, you need to add an [Auto] section, i.e. John

So FSUIPC7 on the client PC cannot connect to MSFS? Did you configure your SimConnect.xml file correctly? Can you please attach your FSUIPC7.log and FSUIPC7.ini files as well as your SimConnect.xml file please and I will take a look. What log file? What cfg file?

Are you using MSFS2020 / FSUIPC7? If so, please use the specific sub-forum for FSUIPC7. I will move your post. I don't have the LVFR so cannot look into how the elevator trim works for this aircraft. You can try using FSUIPC's logging facilities to see what is being used - activate logging for Events and Input Events and open the logging console (Log -> Open Console), increment and decrement the elevator trim in the VC and see if anything is logged. If so, try using those evens (or input events). If nothing is logged, try listing the available lvars to see if any of those look applicable. As a final resort, you can inspect the model behavior of the VC trim controls using the development facilities provided by MSFS to see how they work, and then try and duplicate that (usually using calculator code via a preset) - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ on how to do this. John

You are using a very old and unsupported version - please update to the latest and only supported version, 7.4.11. John