John Dowson

Before I look at your files, please see my last post and try that...

That is because the function is ipc.getLvarId, and not ipc.getLvarID - i.e. lower-case D at the end. Lua functions are case sensitive, although I do sometimes allow for other cases. Again, PLEASE check these things on the documentation before posting and you would find your mistake. You can already do this. What does this ('functions are executed') mean? I see no need to provide any further documentation, and you don't seem to be looking at the documentation already provided. Start with that before asking for further documentation. Why is the current documentation not sufficient? Cockpit builders have been using FSUIPC for > 15 years with the current documentation... This depends. Luas are generally loaded when you start them. Auto luas are loaded once the initial lvar list have been received (when using the WASM) or when the aircraft is loaded when not using the WASM. For other luas (ipcinit.lua, ipcready.lua), see the lua plug-in document. Profiles are loaded once an aircraft is loaded. That is determine by MSFS, not FSUIPC. There are many sophisticated lua programmers who get along quite well as it is. I see no point in continuing this thread, sorry. John

If the throttle is going into reverse when low positive values are being sent, you can maybe prevent this by extending the throttle range by editing the calibration in your FSUIPC7.ini file. Find the throttle calibration line (Throttle1=....) and change the lower limit (which should be around -16384) and change that to say -22000. Try that and then adjust as needed, i.e. decrease further if you still get reverse thrust, and increase a bit if you cannot get to idle. As an example, this is my throttle calibration line for the Kodiak: Throttle1=-16320,-512,512,16380/32 I would change this to the following to restrict the lower value range sent: Throttle1=-22500,-512,512,16380/32 Do the editing with the axes assignments/calibration window open, and when you have saved your changes, click the Reload all assignments button (in assignments tab) to load the changes.

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