John Dowson

Looks good to me!

But you haven't checked the profile-specific check-box in the calibration tab. Do that to make your calibration specific to the Turbine Duke profile. Once this is done, you will still have the duke calibration in your general profile - you probably want to remove this. But you have! The image you posted shows you have at least configured the throttle axis in FSUIPC, and the assigned is in your Turbine Duke profile.

For all auto-start issues, please see

Re-installing will not overwrite any of your settings, That would be a series issue/defect if it did! Of course - that is just one of the components that is installed. For most users, you just need to accept the defaults when you re-install. John

I still have no idea what you mean... You have a choice - use these if you find them easier, and if you prefer their support. There is also Axis-and-Ohs. The choice is yours. Really? I also support the freeware version. And I know the documentation could do with a good update. There is so much to do, I have limited time, a 5-year+ backlog of improvements and updates. But spending 6 hours a day on support leaves little time left for keeping up with MSFS/P3D updates, let alone adding more functionality, improving documentation, etc The documentation is what it is, but I try and improve it all the time on feedback from users. There are also other resources - these forums, including the history of questions asked (many hundreds of times for each issue...), the FAQ section, the User Contributions. The information is out there, you just need to look., And you need to understand Lua if using lua. Consult the Lua documentation. I provide ONLY the additional documentation on the lua functions I implement. This error: is from the Lua interpreter. It is basically telling you that 'getLvarID' doesn't exist (its a nil value). The first thing you need to do when you see such an error is consult the documentation as it indicates a misspelling or a case issue (Lua IS case-sensitive). That would save me a lot of time! Take care - and listen to yourself, you need to chill. John

Yes - just make it a profile-specific calibration. i.e. check the profile-specific checkbox and add it to your BS Duke profile. If you don't have one, it will prompt you to create one. Please see the User guide on how to use profiles. John

Please be aware that FSUIPC has 2 different auto-start methods: 1. via the EXE.xml 2, via the MSFS.bat file So it depends on which method you are using. If using the EXE.xml auto-start method, MSFS will start FSUIPC7 however it is started. If using the MSFS.bat method, FSUIPC7 will only be started when using the desktop icon installed by FSUIPC (or the MSFS.bat file which is what it links to). PLEASE see the installation and registration guide for details on these two different auto-start components. And there is a FAQ entry on MSFS auto-start if you are having any issues. I have really said all I can about FSUIPC7 and auto-start, and many times. Please see the documentation and FAQ entries on this - all the information is there. And there is a FAQ entry on the start-up parameters, as well as a asection in the Advanced User guide. And I don't l know why you added your comment to this topic, which is related to simconnect issues and not auto-start. Please do not hijack unrelated topics. Anyway, the OPs issue was solved by rebooting his PC, so I am closing this topic now. John

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.