ark1320

Generally, Avars and Lvars require the > only if you are trying to write (store) a value into them. K events do usually have a > before the K. In this case I think of the > as meaning "activate" the event. Sometimes, but NOT in presets or calculator code, the > symbol will be replaced with > meaning "greater than". I'm not sure what the 60 represents in the above, but note that one radian is about 57.29 degrees, so 10 degrees is about 0.17 radians. Also, often you can change the units a variable uses, so you may be able to write the Avar (A:ELEVATOR TRIM POSITION, radians) as (A:ELEVATOR TRIM POSITION, degrees) which may be more convenient in your particular application. Al

Some observations: 1. Min and Max should be min and max. 2. According to the SDK, the value of (A:Elevator Position, number) goes only from -16K to 0. 3. Given the range of (A:Elevator Position, number) above, unless the Elevator_Angle_Trim value is less than - 16255, (L:Elevator_Angle_Trim, number) 128 - -16383 min will be -16383 and then you are putting that into (A:Elevator Position, number). It will then get more negative from there when the preset repeats and it seems you will almost immediately exceed the negative range of (A:Elevator Position, number). Don't know if that is OK. 4. Given the range of (A:Elevator Position, number) above, (L:Elevator_Angle_Trim, number) 128 + 16383 max will be 16383, and then you are putting that into (A:Elevator Position, number) which supposedly has a max value of 0. And the value you are putting into (A:Elevator Position, number) will get more positive when the preset repeats. Don't know if that is OK. 5. It would seem the Lvar (L:Elevator_Angle_Trim, number) located after the Min and Max operators is missing a > before the L: (unless I misunderstand what you are trying to do). 6. I have some timing concerns about trying to update an Lvar and them immediately using the new Lvar value in the next operation in the same preset. I would have to test that to see if it would work reliably. 7. While the presets are updating the value of the Avar (A:Elevator Position, number), I assume the sim might be doing that also, so how the dual updating will work is not clear to me. Any needed corrections to the above are welcome. Al

Johm, Above worked for me, tried it 3 or 4 times. Question: If at some point auto-tuning doesn't work and values are set manually for the startup parameters, the next time FSUJIPC7 starts will those manually set parameter values be over written by the auto-tuning, or does the auto-tuning code check the FSUIPC7.ini file for those parameters? Thanks, Al

Yes, that's what I meant by the current com freq spacing (channel spacing) -- 8.33 or 25 KHz. Thanks, Al

John, When and how are offsets 0x0B47 and 0x0B48 updated in order to indicate the current com frequency spacing? Is there a way to force those offsets to update? For example, GPS units often "contain" the Com radios, and you can select the number of frequency digits to be used. If after loading the plane you switch the number of frequency digits, do you have to manually update offsets 0x0B47 and 0x0B48? Thanks, Al

My understanding is Presets have to be one line, but can be a long line. If you want to use a toggle K event like TOGGLE_TAILWHEEL_LOCK, you typicality do not write a value into such K events since executing the K event actions the toggle function. It may be that simply using an Lvar in a preset in effect defines the Lvar. I seem to recall that being the case with calculator code, so maybe similar for Presets. I"m still not sure what you are saying here. But if you want to toggle the value of an Lvar between 0 and 1 each time a key is pressed, then one way to do this is to assign that key to a Preset similar to: MyPresetToggleName#(L:myLvar, bool) ! (>L:myLvar, bool) Then each time the preset is executed ( the key is pressed) the value of the Lvar will toggle between 0 and 1. I think the initial value of the Lvar will be 0 (and not undefined), but I would have to experiment a bit to confirm that. If it turns out the Lvar is undefined, then you would need to create and initialize it elsewhere before using the preset. Al

I'm sorry, but I don't understand what you are trying to do with the mini-keypad, but perhaps I can help a little until John is available. 1. Yes, the MSFS SDK defines Bvars as input events. 2. looked at your myevents.txt file a bit and would like to mention a few things I don't understand. Just for example, consider the entry: C510_ATC_2#(>(A:TAILWHEEL LOCK ON, Bool) 1 == if { (>K:ATC_MENU_2) 0 (K:TAILWHEELOCK) } i. Why is there a > in front of the Avar (A:TAILWHEEL LOCK ON, Bool)? You would put a > in front of the A: itself if trying to write a value to an Avar, but the SDK would have to say it was a writeable Avar (although some Avars are writeable, most are not). In this case it does not seem you are even trying to write to the Avar at all. ii. It looks like you are trying to put a value of 0 into a K event called (K:TAILWHEELOCK). If so, you would need a >in front of the K: (in fact K events routinely have a > in front of the K:). But in this case I cannot find a K event called TAILWHEELOCK in the SDK. Where did you find that K event? I did find a K event called TOGGLE_TAILWHEEL_LOCK. If I'm off base here, sorry and please ignore! Al

Easy enough to try I would think. Based on your log post above, it took 100 sec for FSUIPC7 to connect to SimConnect after you manually started FSUIPC7. For that particular test did you wait until MSFS had fully loaded (whatever fully loaded means) before manually starting FSUIPC7? Seems like you could run some experiments to see at what point starting FSUIPC7 manually works reliably for your setup. If FSUIPC7 doesn't connect to SimConnect, manually exit FSUIPC7 and then after 5 or 10 seconds simply manually restart it again. That has worked for me in the past. However, I still think using the FSUIPC7.ini parameters as John has outlined above is the best long term solution. That approach has been working reliably for me. Al

Very sorry John, edited my post so it is correct now. Al

I don't think a FSUIPC7.ini file is provided -- that is specific to each user. But yes, do add the new [General] section parameters as discussed in the above posts if needed. Al

Based on your log file, looks like the sim was detected at about the 30 sec point, and you connected to SimConnect at about the 130 sec point (rounding the values) so if I understand John's guidance correctly, you would need a DetectToConnectDelay setting of 130 - 30 = 100 sec (maybe add an additional 1 or 2 sec to be safe). Note that the log time stamp values are in milliseconds. Al Edited: In the above, changed DetectToConnectDelayAuto to just DetectToConnectDelay since FSUIPC7 was started manually, not automatically.

Hi John, Many thanks for all your quick attention to the various FSUIPC7 to Simconnect connect problems over the past couple or weeks. Wonderful support! I see you have now introduced a third new General section parameter called InitialStallTime. Do you see this as a replacement for the previous parameter DetectToConnectDelay, which was for manual FSUIPC7 loads, or do you expect this new parameter will be in addition to the previous ones? I'm just wondering which parameters will be available to experiment with should a future Simconnect connect problem come up, such as when SU15 is released. Thanks, Al

John, What do you anticipate will be the min, default, and max values for the DetectToConnectDelay and DetectToConnectDelayAuto parameters in the next official release of FSUIPC7? Thanks, Al

Yes, I looked at the wrong EXE.xml entry. Unlike the other entries, the FSUIPC7 entry is one long non-wrapping line and I just missed it. Hopefully your latest fix also works for the other user who reported a problem. Take care and thanks again, Al

Good news, latest FSUIPC7 version works -- tried loading the sim twice, both successful. I noticed a new entry in the EXE.xml file: <CommandLine>-FSIntegration</CommandLine>, but was not able to pick out the new FSUIPC7.ini timing parameter you mentioned. What is it called? Thanks very much for the work on this, Al

I understand those kinds of orders! 🙂 I added back the '-auto' command line flag. Unfortunately, the test FSUIPC7.exe file did NOT work. Log file attached. Al FSUIPC7.log

Yes, looks like it took a number of tries to connect to Simconnect. I also tried a few keys (N, T, X) just to confirm all was still working -- it was. Al FSUIPC7.log

or maybe change to this: i.e. remove the '-auto' flag. This will change some timings, That worked! Key presses responded on initial FSUIPC7 load with FSUIPC7 ver 7.4.8. 🙂 Did this EXE.xml change delay the loading of FSUIPC7, or load it earlier than previously? Al

Since FSUIPC7 version 7.4.4 works on initial auto load, but version 7.4.8 does not, is there some startup timing difference between the two versions? Al

Yes, that also occurred to me. Yes, key presses work right away if I start FSUIPC7 before starting the sim. This is what I see. There is no response in the Console window to key presses with the new FSUIPC7.ini file that I can see. The Console window doesn't change from what you see below. Al

Yes, the default MSFS key assignments work after initial FSUIPC7 load. Some more data that may be helpful: I found some older versions of FSUIPC7 in my Deleted folder: -- Installed ver 7.4.4: All worked on initial load. -- Installed ver 7.4.6: Did NOT work on initial load. Did work after subsequent manual load. --Installed ver 7.4.8 again. Did not work on initial load. Did work after subsequent manual load. I repeated the above experiment a few times, ver 7.4.4. always worked on initial load, versions 7.4.6 and 7.4.8 did not. They did always work on subsequent manual load. I thought maybe the FSUIPC7.ini file General Section entry OpenOnStart=Never might be a factor, but deleting it did not make any difference. Really appreciate the help -- thank you! Al

MSFS starts FSUIPC7, and the FSUIPC7 flash screen appears about 90-100 seconds after I click to start the sim loading. And yes, none of my key assignments work when FSUIPC7 is initially loaded. Neither General or Profile Specific lua scripts respond. I did click on the screen in the cockpit to hide the yoke, flip a switch, etc., to make sure the sim had focus before trying to input to one of the Lua scripts. Just doesn't work on initial load. Very strange. Al

Ran another experiment using one of my auto-loaded lua scripts. I assigned both a button (on my throttle quadrant) and a keyboard key to the same function within the Lua script (the function executes some code to toggle a switch on the panel of the Flysimware Learjet 35A). On first auto-load the button worked, the key did not. After exiting FSUIPC7 and restarting it manually, both the key and the button worked. I repeated the experiment a few times with the same results. This particular script does not make use of the Wnd library. Al

John, Attached are the two log files and one Lua script and the FSUIPC7.ini that I used. Only the one Lua script was auto-loaded, and it did not work meaning it did not respond to the three input keys I tried (N, T, and C). I then killed (Exited) FSUIPC7 and restarted it manually. I then tried the same three input keys and everything worked as expected. From what I can tell, the auto-loaded Lua scripts that do not initially work are those the use a key input. For example, in response to the N key, a message that looks like the below should appear for a few seconds in a small window. But that does not happen with the initial auto-load. I wonder if there could be some kind of initial loading or timing issue associated with getting user inputs? I'm starting to see that Auto-loaded scripts that don't make use of user inputs work the first time, those that do don't work the first time. I think the prev log file below was the results from the auto-load, the log file was from the subsequent manual load. Works fine with the manual load. Al FSUIPC7.log FSUIPC7_prev.log NpC4MSFS2020.lua FSUIPC7.ini

John, Here are the files. I think the Previous log file is what I get when FSUIPC7 first (auto) loads, the Log file is after I exit FSUIPC7 and then manually restart it. Al FSUIPC7.log FSUIPC7_prev.log FSUIPC7.ini