ark1320

Reinhard, Thanks for the detailed info -- very nice. Al

An interesting thread -- thanks! Al

Thanks to both of you for the great support once again!! Al

I do need to make more use of macros. Can a Name.mcro file have more than one Lvar listed in it, for example: [Macros] 1=L:PITOT_L=Toggle 2=L:PITOT_R=Toggle For some reason I only see the first Lvar listed in the P3Dv4.5+ FSUIPC6 keys drop down list. Thanks, Al

I try to avoid having to use the mouse and have lots of scripts for controlling switches and buttons in different airplanes and of course they all use different Lvars, and scripts for calling up different checklists which are aircraft specific, and also more general scripts (like moving an aircraft to a new location in the air) that apply to multiple aircraft. And yes, there are ways to consolidate. Typically what I do now if necessary is to convert the separate scripts into functions which are then then combined into a single script and selected based on an assigned parameter ( ipcPARAM, flag, etc) value. So, for example , I now have a controls script for the Lear35 that has 47 different functions in it. Given the difficulties of making a change in the Lua scripts limit as outlined above, I agree it does not seem like a reasonable course of action at this point, especially since apparently no one else has raised the issue. The idea of tying scripts to an aircraft profile seemed like a nice organizational feature so I decided to ask to see what might be involved. As I said, it was just a thought. Thanks very much for the responses and explanations. Al

Yes, I have run into the 128 Lua limit a number of times. When you have scripts for multiple planes the total can add up quickly. If something like I described was to be implemented, you could add a prefix or postfix to the Lua scipt name to identify the profile. For example, Lear35_checklist.lua might become [L35]Lear35_checklist.lua where the profile name is L35, etc. Or perhaps profiles could be numbered or lettered with a single character, and you would prefix the script name with the associated number or letter. Just a thought. Thanks, Al

I understand that currently the number of Lua files is limited to 128 (0 to 127). I was wondering if in a future version of FSUIPC this limit could be extended by designating certain Lua files to be aircraft (profile) specific Lua files. Such files would then be listed under something like [LuaFiles.profile_name] in the FSUIPC ini file. Thanks, Al

Good idea, thanks! Al

Does the ipcPARAM parameter value supplied with a key or button assignment have to be an integer, or can it also be a decimal value? Can it be a string? Thanks, Al EDIT: From what I can tell, ipcPARAM has to be an integer.

OK, thanks for the info! Al

Hi John, I have not been able to get AILERON TRIM LEFT and AILERON TRIM RIGHT (controls 66276 and 66277) working, but after seeing AILERON_TRIM_SET in the above list I'm wondering if that suggests I should also be able to get AILERON TRIM LEFT and AILERON TRIM RIGHT to work? Thanks, Al

I wondered about the c:\Windows\System32 part of the path in the FSUIPC7 bat file because I had been using a short cut (posted in the AVSIM MSFS Forum) to start MSFS that uses the path C:\Windows\System32\cmd.exe /C start shell:AppsFolder\Microsoft.FlightSimulator_8wekyb3d8bbwe!App -FastLaunch However, as shown below, the path in the FSUIPC7 bat file starts with "just" cmd.exe. Perhaps that is OK, I just don't know. Al :: remove CMD window if not DEFINED IS_MINIMIZED set IS_MINIMIZED=1 && start "" /min "%~dpnx0" %* && exit :: MS Store Installation: start MSFS with FastLaunch cmd.exe /C start shell:AppsFolder\Microsoft.FlightSimulator_8wekyb3d8bbwe!App -FastLaunch

John, When I try to run the batch file to start MSFS and FSUIPC7 I get the below. I am using the latest Win10 OS. MSFS was a standard MS store purchase. Any ideas? Thx, Al EDIT: Got the shortcut to work -- had to set it to Run as Administrator. Might be good to add that in the ReadMe file as something to try if necessary.

I have been aware of this info for the MaxSteerSpeed from the Advanced users guide since you pointed me to it at the top of this thread. I assumed a tiller axis would only be available on the ground since a tiller is used for taxiing! The fact you can already set different values for the MaxSteerSpeed under different profiles is a valid point. So the question is is there utility in being able to set different MaxSteerSpeeds within a profile. Not all profiles are specific to a particular aircraft, but rather to an aircraft category, eg, Jet Aircraft, and the aircraft in that category may have different stall speeds and you may want to set the MaxSteerSpeed based on stall speed or maybe aircraft type name. And I think there usually is a wide range of aircraft in the non-profile category, so again being able to set the MaxSteerSpeed based on some characteristic such as stall speed would be good. I would not want to have to create a new aircraft profile just to be able to tailor the MaxSteerSpeed to what I want. I don't like to have more profiles than I really need. I think when it comes down to it being able to set the MaxSteerSpeed based on some fraction of aircraft stall speed would provide ample flexibility, and there is already an Offset for stall speed. So an additional Offset for the MaxSteerSpeedStallFraction would be all that is needed. That Offset could default to some value like 0.7. I guess, John, it comes down to how hard it would be, or how much time it would take, to implement something like this. I would put having this capability in the "useful to have " but not critical category. Al

Lua scripts under [Auto] and/or [Auto.profile_name] would be all you would need. Al

I like that idea. Making MaxSteerSpeed default to a fraction of the stall speed (say 70%) would prevent having to reset the value for different aircraft, e.g., a Piper Cub vs an A320. Al

Ah! 😮 Didn't realize what I was being told by FSUIPC! ☹️ Al Update: Got the Steering Tiller axis calibrated and assigned to the rudder peddles, set a slope of +8 to the axis to desensitize the steering and all seems to be working well. Thanks very much for the great support, John!

John, When I assign the rudder and steering tiller to the same axis as shown in the pic below, I don't get a range entry (-16380 to 16380) for the steering tiller under [JoystickCalibration] but just a range entry for the rudder, and if I go to the FSUIPC7 Joystick Calibration tab it says the Steering Axis is not processed. I do see the entry 1=RR,256,D,3,36,0,0 -{ DIRECT: Rudder, SteeringTiller } under [AXES]. however. I also see there is a parameter SteeringTillerControl=0 under [JoystickCalibration], do I need to change that? Thanks, Al

Hi John, Thanks for the info, I was not aware of the MaxSteerSpeed and RudderBlendLowest parameters. My main interest is in reducing the sensitivity of ground steering in aircraft that don't have a steering tiller, like the Beech Baron or TMB 930, etc. because I find them hard to control during takeoff and landing roll. In these aircraft ground steering is strictly through use of the rudder peddles. For such aircraft, what do you think of the idea of editing the FSUIPC7.ini file so rudder peddles are assigned to both the rudder and steering tiller axes like the below. Does this cause some undesirable conflicts? Under [AXES] 2=RR,128,D,36,0,0,0 -{ DIRECT: SteeringTiller }- 3=RR,128,D,3,0,0,0 -{ DIRECT: Rudder }- and under [JoystickCalibration] Rudder=-16380,-256,256,16380 SteeringTiller=-20380,-256,256, 20380 (range expanded to desensitize the ground steering) I have not changed the MaxSteerSpeed and RudderBlendLowest parameters from their default values. What would you suggest given the above setting? Thanks, Al

Can the sensitivity of an axis be made conditional? In particular, to enhance ground steering without impacting the effectiveness of the rudder in flight, if possible I'd like to make the sensitivity of the rudder axis conditional on whether or not the a/c is on the ground (Offset 0x0366). Perhaps by adjusting the slope of the rudder curve somehow with a Lua script..... Thanks for any ideas. Al

Ah, I see, sorry I misunderstood. Couple of ideas. I wonder if you tried to read the fuel quantity of a tank that did not exist if you would get a null response -- if so that would be a way to tell if a tank exists or not. However, you might get a 0 value back which I assume could be a valid value. Or you could try to "fill" each tank with a particular quantity of fuel and then read back the tank value. Getting back a 0 or null value would tell you the tank doesn't exists, I think. Or better perhaps, read a tank value, if non-zero that tank probably exists, if null it probably doesn't exist, if zero fill it to some level and read back the tank value to check if it exists but was just empty. Something like this is probably worth a try. I also see for reciprocating and turbine engines there are offsets like 0x3884 which is "Reciprocating engine 1 tanks used, a bit mask" and offset 0x2058 "Turbine Engine 1 Tanks Used, a bit mask" that might be worth looking into. I don't know if these offsets define the tanks available to each engine or not. Of course, how well the current MSFS SDK supports all this might be an issue. Al

Sorry, but I don't understand where this quote comes from or what it means, or which aircraft you are talking about. Regardless, after loading the aircraft onto the runway you can select the Fuel icon from the menu that pops up when you move your mouse to the top of the screen. This is one way to fuel the aircraft and shows you what tanks are available. You could also look in the aircraft's flight_model.cfg file under ]Fuel] and see what fuel tanks the aircraft has. Al

Hi Thomas, EDIT: Think I figured it out. Had a key conflict between my Lua script activation and an existing default MSFS key input. I keep forgetting you might have to remove the MSFS key inputs if you are using them elsewhere. BTW, I think you have a typo above, the Offset parameters for COM1 and COM2 should be reversed. Thanks for the help, Al

Control 66372 (Com1 freq swap) and control 66444 (Com2 freq swap) do not seem to be working correctly. The Com1 freq swap sometimes works the first time, but often does a double swap so you end up with unswapped active and standby frequencies. The Com2 freq swap control works except it swaps BOTH the Com1 and Com2 frequencies between active and standby. Interestingly, the Nav1 and Nav2 swap controls seem to work fine. Al EDIT: Using Offset 0x3123 seemed to work at first, but then started to behave similar to when using the control codes directly which I guess is not surprising.

Thanks for the pointer to the SDK SimConnect_Status_of_Input_Events table. Very interesting. In that table they have the digits 0, 1, ...9 and NUM_0, NUM_1, ...NUM_9 in the Base group and listed as a 'Success' under Event Callback. VK_NUMPAD0, VK_NUMPAD1, ...VK_NUMPAD9 in the Virtual group are listed as 'Skipped' under Event Callback. Based on your comments I assume by 'Skipped' they probably mean not sent via Simconnect. I'm not sure what the distinction is between the digits 0, 1.....9 and NUM_0, NUM_1....NUM_9, however. In any case, hopefully Asobo will get this fixed in the not to distant future. I would think this would be an issue for many developers. Thx, Al