John Dowson

I don't have the Black Square Turbine Duke, but looking at the Kodiak, which also has a reverse range on the throttle, when I assign using 'Send direct to FSUIPC calibration' and calibrate with No Reverse Zone checked, the throttle moves between idle and full throttle. If I calibrate without this checked, I can use the reverse zone. I would expect the same behavior in the BS Duke, so I don't fully understand why it is still going into reverse when you calibrate with NRZ checked, especially as it looks like the minimum value the axis is sending out is 0. But you should still set the minimum (in the calibration) to your axis minimum, i.e. around -16384 - 16300. Can you also try activating logging for Axes Controls (Log -> Axes Controls), open the logging console window (Log -> Open Console) and see what parameter values are being sent with the Throttle axis controls - what are the values when the throttle in the VC is at idle, and what is it using for the reverse range? Also please show me / attach your FSUIPC7.ini and FSUIPC7.log files so I can take a look.

License sent.

Looks like its sending only positive axis values from the calibration page, so I don't understand how it can be going into reverse. I would need to see your FSUIPC7.ini files and FSUIPC7.log files to see why, the latter with logging for Axes Controls activated. Just move the throttle through its full range and back, then exit FSUIPC7 before attaching files. You can also try assigning using 'Send to FS as normal axis' and use the Throttle1 Set control, and check the NRZ box. You may also need to uncheck the Exclude Throttlen Set checkbox - try with and without. Check also that you have UseAxisControlsForNRZ=No in the [JoystickCalibration] section of the INI file.

Try checking the No Reverse Zone checkbox (top right) and then calibrate. what throttle axis are you assigning to?

You don't need to convert from 64bit to 32bit. The units part of the altitude is available at offset 0x0574 as a 32-bit value, and you would need to multiply by 65536 to spoof this value to offset 0x31E4. But I am not sure this will help, and doesn't offset 0x31E4 hold the correct value (RADIO HEIGHT) anyway? I think its more likely that you need to spoof the reading of offset 0xC000, but that is going to be very difficult I think. If I called this function, I could maybe use the results to populate offset 0xB000, but not sure that would help. I could not populate the 0xC000 offset area from this data. I will check further on how the 0xC000 is populated in FSX/P3D, but I think this was done via the simconnect weather interface which is just not available in MSFS.

I'm not sure how you would do this, but first you would need to add the COM VOLUME simvar to a free FSUIPC offset. Once its in an offset, you could have a lua script that monitors the offset (using event.offset), and in the handling function you could then set the IVAO Pilots client volume. How you do this I don't know - maybe better to ask about this on the support channel for this client. Also check the IVAO client SDK to see what offsets it supports and if there is one for the COM volume. If not, I am not sure how you would do this, but you should ask on the IVAO client forums (presuming there is one!). John

Ok, then leave it as it is. Only reduce if you find that FSUIPC7 is not connected once you arrive at the main menu.

Can you also show me / attach your FSUIPC4.log file. Do you know what changed to cause this issue? There has been no change on FSX for many years (apart from installer updates). Can you take a look at the following FAQ entries:

👍Thanks.

Sorry for the delay - I have been rather busy with other things. I will look into this in more detail within the next few days.

FSUIPC7 should start-up automatically however you start MSFS, if using the EXE.xml auto-start method. Yes, your SimConnect seemed to be blocked, which is why I recommended a reboot. Usually restarting MSFS should fix this, but if problems persist always better to reboot. John

Ok. That log shows FSUIPC7 was auto-started and it connected and everything looks ok. Was not everything working? One thing to note is that you DetectToConnectDelayAuto parameter is quite high (375). This may be ok, if MSFS takes > 5mins to boot to the main menu, but if MSFS isa ready sooner this will imply that FSUIPC7 will not connect and be available for some time after MSFS has started. You can change this parameter to 60, and then also set StartUpTuningActive=Yes to re-run auto-tuning, and that should then set a good value for this parameter. John

Then show me a log file! Both of the log files you attached show FSUIPC7 manually started: 141 Manually started with DetectToConnectDelay=1, InitialStallTime=5 John

That is the recommended way. Show me the log file from this then - you keep showing me log files when FSUIPC7 is manually started.

That log again shows FSUIPC7 was manually started, and with InitialStallTime=5. Are you not using auto-start? If manually starting, when are you starting FSUIPC7? As I said, if manually starting, make sure MSFS is already running and has passed loading to the main menu. But once you have so many re-connection attempts, best to exit MSFS and start again. And, as I said, I would reboot your system to start afresh.

Please change the InitialStallTime first... I think you have your FSUIPC7 start-up parameters badly tuned, so it is re-connecting too many times and using up all the simconnect connections, and so preventing other clients to connect, You need to tune your FSUIPC7 start-up parameters (or use auto-tuning). Anyway, your logs will confirm this. Taking the dogs for a walk now, I will look at your logs when I get back... John

The log file shows that you started FSUIPC7 manually when MSFS was already running, and it failed to establish a stable SimConnect connection. Can you please exit MSFS (and all your MSFS clients) - and also maybe reboot your system. Then restart MSFS, and let FSUIPC7 and let get auto started (presuming you are using auto-start). Once MSFS gets to the main menu, wait a short while to see if FSUIPC7 gets a connection. Once it does, or if it doesn't after a short period, exit FSUIPC7 and then show me the FSUIPC7.log file. If you are not using auto-start, please start FSUIPC7 AFTER MSFS has started and arrived at the main menu. John P.S. Before re-starting MSFS, please change the InitialStallTime parameter in your FSUIPC7.ini to 15, i.e. InitialStallTime=15

I am not interested in images, especially from vPilot. I only support FSUIPC. Please show me the log file. John

Please show me / attach your FSUIPC7.log file. Also, try exiting and restarting - does it then work? John

If things are working, keep it that way. Just be aware that many things won't work when MSFS is in the main menu, and especially when booted to the main menu as many FSUIPC threads will not be running and are not started until an aircraft is loaded and ready-to-fly. That certainly shouldn't happen, but I think there were some situations where this could happen in the past but these should have been corrected. So, if you do get this again, please show me your logs. Regards, John

I have moved your post to the FSUIPC7 support sub-forum, where it belongs. Please take care to post in the correct forum for support. You posted in the User Contributions sub-forum, which is, as the name suggests, for User Contributions only, and it does say NOT for support requests. John

First, you posted in a FAQ entry completely unrelated to your question. I have moved your post to a new topic. All your settings are saved in your FSUIPC7.ini file, so just save and re-use that. Note that if you re-install windows (and for other reasins), your device GUIDs and IDs may change. This can cause issues but is easily fixed. I can help with this if/when needed. Other files that you can save (if using) are the following: - FSUIPC7.key file : this holds your registration details - *.lua files: any lua scripts that you are using - *.mcro : any macro files that you are using - *.dll : any additional drivers you are using - myEvents.txt file : if you have defined any of your own presets - myOffsets.txt : if you have added any simvars to spare/free FSUIPC offsets John

This is happening as you have added some simvars to be requested from the Modular Fuel System in your myOffsets.txt file: You need to remove these entries when using aircraft that do not use the new modular Fuel system. This is really an issue with MSFS - it should log (and return) an error once when such a simvar is requested, but it continues to log an error at the request rate, and no erro is returned to the client. John

Sorry, but I cannot really help you with python as I am not familiar with this language or the SDK. However, you can also use FSUIPC to log those offsets to check the values, although they certainly don't look correct, although I do not know why. Yes, but you have to request this. This information is held in the indexed simvar COM ACTIVE FREQ TYPE. To read this simvar, you need to add it to a free/spare FSUIPC offset first, using the facilities provided. See the section Adding Simulator variables (simvars) to FSUIPC offsets in the Advanced User guide. John

This sounds very strange... However, all FSUIPC does with autosave is to call the P3D function to save the flight, and a P3D function is then later used to load the saved flight. So if there are issues with saving or loading a flight, it will be an issue with P3D. Does this only happen with the PMFG MD11? Does the same occur if you save / load the flight from within P3D? If it only occurs with the MD11, then you should probably raise this with PMDG. Otherwise, you could try re-installing the P3D client to see if that fixes this issue. John