ark1320

Well John, that is very interesting. What I had found was the increment script worked fine if I repeatedly pushed and released the key that called the script. But if I held the key down, or repeatedly pushed and released it very fast, it only incremented once or twice and then "quit". I thought I had read that a repeated call to a running Lua script would kill it, and then restart the script, so I thought that was the problem. I just searched through both the FSUIPC7 User and Advanced User Guides and could not find anything to that effect -- so another age problem I guess! I will look further and try to figure out what is going on. Thanks very much for the help! Al

Guess I was not clear. I was not asking for anything to be modified for ALL users, but rather if there was technique I might use for my particular situation. I will look into the event.key function idea -- thanks! Thanks. Al

My understanding is if you recall a Lua script while it is running, the first instance of the script is immediately killed, and the script is restarted. Is there a way to modify this behavior, such that the running script will ignore any repeated calls until it has completed? What I'm trying to do is use a script to repeatedly increment a sim value while a key is held down until the current target value (which is displayed) is reached. The script is very simple, it just reads the existing Lvar value, adds 100 to it, and writes the new value back. Thanks, Al

John, A wnd.ask() function would sure be helpful, but I can appreciate your time constraints. Thanks, Al

Hi John, Do you happen to know if there has been any "advances" in the MSFS SDK that supports getting user input values via the keyboard? I'm thinking of something similar to the ipc.ask() function that we have available in FSX and P3D. Thanks, Al

Thanks John -- I apologize for not seeing this info in the manual. Al

My understanding is the max button number you can use for programming a button is 31. I'm asking because another user I'm trying to help pushed a button he was trying to program and what showed up in the FSUIPC7 button window was Joy# A with Btn# 146. I know you can have many joysticks, and I thought, a max button # of 31 with each joystick (ignoring the hat switch button #s). I was surprised to see FSUIPC7 report a button # of 146. So there is something I don't understand. Thanks, Al

Is that something you do in FSUIPC7, or in the sim? If in FSUIPC7 I don't understand how to do that. In contrast to the above, I find the Tiller axis too sensitive, even with a slope of 15 -- it is hard to keep a/c on the center line. If on the calibration tab for the Tiller axis I set the axis extremes at - 8192 and +8192, would that further desensitize the Tiller axis? Thx, Al

For anyone who might be interested, I went back an tried a flight test. In MSFS I set both aileron axis Sensitivities to -95, and set the Dead Zone to 95. I then took off and the plane flew normally -- the aileron response seemed unaffected by the MSFS Sensitivity and Dead Zone settings. So I conclude the FSUIPC7 axis control inputs bypass the MSFS controller axes settings which, in my opinion, is unfortunate. It would be useful I think to be able to use both FSUIPC7 and the MSFS controller settings to fine tune the response of axes. Al

It is the delta value - inly value changes greater or equal to this are sent to the FS. When I look at the Delta box value in the axes assignments tab, I see values like 256, not 16. And not all my axes in the FSUIPC7.ini file have a /n after them, but they all have a Delta value on the axes assignments tab when I do a rescan and move the axis. Do default delta values of 256 not show up in the ini file? After a rescan and the axis is moved, does the Delta box value reflect the currently assigned Delta value? Thanks, Al PS: Hope you had a good holiday!

Well, if seems that way if just looking at how the rudder moves while the a/c is on the ground is a valid test for the rudder axis. If you ever have time and a reason to look into it I'll be interested in what you find out. Thanks, Al

I calibrate all my controller axes through FSUIPC7, make use of the slope curves where it seems useful, etc. In some cases it also seems there might be some benefit from also using the controller sensitivity curves in MSFS. I originally thought the axes output from FSUIPC7 calibration would become the axes input to the MSFS sensitivity curve settings. So, for example, if you used a FSUIPC rudder axis slope of 4, and had a rudder sensitivity setting of -50 in MSFS, both of these "calibrations" would be applied to the final input to the sim aircraft -- or so I thought. But after some additional testing it does not seem to work that way. As an extreme experiment I set the rudder axis sensitivity curves in MSFS to -98, and a dead zone of 95%, and then looked at rudder movement while the a/c was sitting on the runway. Small rudder inputs still seemed to move the rudder despite the extreme sensitivity curve settings. 🤔 So it seems FSUIPC7 calibrated controller inputs bypass the MSFS sensitivity curves. If anyone has tried something similar I'd be very interested to learn what you found. Thanks, Al The above was edited after additional testing.

The calibration entries for my brakes in my FSUIPC7.ini file look like the below. What does the /16 indicate? I don't see anything like that on any other of my axes. Is that a setting I have control over? LeftBrake=-16384,16383/16 RightBrake=-16384,16383/16 EDIT: Also, my Steering Tiller axis is: SteeringTiller=-16380,-1024,1024,16380/8 My understanding is that the input range from -1024 to +1024 defines a dead zone centered on 0. Is my understanding correct? And again, similar to the above, I don't know where the /8 came from. Thanks very much, Al

John, Based on the above, my understanding now is that if a Profile specific a/c has a Calibration section, that rules in total and no General section calibrations settings apply to the profile a/c. And the same idea holds for Axes sections, which I don't think I realize before this either. So in summary, between the general and profile specific areas, axes and calibration section specifications work on a sectional existence basis, and key and button specifications work on an individual key or button basis. Thinking about all this a little further, I assume default values are used where necessary if the profile calibration section fails to mention a necessary setting. So for example, if the profile calibration section had no entry "UseAxisControlsForNRZ", a default value (e.g., UseAxisControlsForNRZ=No) would apply. Thanks very much for this info -- extremely important and helpful to say the least!! Al

I'd like to confirm that axes calibrations settings specified in the general (non-profile specific) area will apply to aircraft specific profiles if those settings are not explicitly specified in the aircraft specific profile areas. In other words, the axes calibration settings work like the keys and button assignments as far as the non-profile/profile specific relationship is concerned. So, for example, an axis slope value set in the general, aircraft non-specific area will apply to profile specific aircraft if there is no corresponding slope value set for a profile specific aircraft. Do I understand this correctly? Thanks, Al

BTW, similar to the above, the Saitek TQ has a switch (T7) at the bottom of the Prop axis, and the button assignment below works to move the Kodiak 100 Prop lever into the Feather range when the Saitek prop lever is pulled all the way back to activate the switch. Al

I have a Saitek TQ and at the bottom of the throttle axis there is a switch (T6 in this case) which is activated when the throttle lever is pulled all the way back. The button assignment below works with the Kodiak 100 to move the Kodiak's throttle lever into the Beta/Reverse range. I am not familiar with the Saitek X52, but perhaps the below will provide some useful clues that might work with the X52. Al

What is the difference between using Throttle Set vs Axis Throttle Set under the FSUIPC7 Axis Assignment Tab? Thanks, Al

I've also found this works, at least based on how the Prop lever moves in MSFS, but I don't understand why because a feather prop is in high pitch, not low pitch? What am I not understanding here? Is the definition of high pitch "backwards" in MSFS? Thanks, Al

Thanks! Al

What is the proper way to add comments to an .Hav file in the FSUIPC7 WASM module Hvar file Persistent area; that is, what symbol(s) designate a comment? Thanks, Al

According to the documentation, the default install location for FSUIPC7 is C:\FSUIPC7. I would expect the FSUIPC7.ini file to be in that location. If necessary, a file search for FSUIPC7.ini should work. Al

Will aircraft Hvar files that were added to the WASM modules folder by the user be deleted when FSUIPC7 updates? Thx, Al

Yes,I am using the WT G1000NXi which is very good ( the latest few SU7 related bugs aside, they will get fixed). Thx, Al

John, After the recent SU7 MSFS update I have found that a Lua script that used to work to set a target altitude in the G1000NXi via offset 0x07D4 no longer works. But this script still does work for the G3000, so it seems to me something has changed with the G1000NXi. In trying to figure out what is going on, as an experiment I assigned a key for the event AP Alt Var Set English along with a parameter value which is the target altitude. Again I find that this works for the G3000 but not the G1000NXi. So I'd just like to understand how FSUIPC7 invokes the event AP Alt Var Set English in case this might provide a clue to help explain what might have changed with the G1000NXi. Thanks, Al Edit: The WT guys just found that there was a change made to the G1000NXi altitude code, hopefully that will be fixed so offset 0x07D4 will again work. In the meantime they suggested using the simvar AUTOPILOT ALTITUDE LOCK VAR:1. Is there a way to invoke a simvar within a Lua script?