
ark1320
Members-
Posts
670 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by ark1320
-
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
-
OK, John, thanks. I will get you the files. In addition to the above general Auto load file problem, I have now found a much smaller aircraft profile specific Lua file that does not work at first with Auto load, but does work if I restart FSUIPC7 manually. So the problem is not Lua file specific. Have a great Holiday, Al BTW, I tried looking at the Console info, but it scrolls way to fast and the small font makes it just about impossible for me to see anything that way. Age problem!
-
Hi John, I have been auto loading a fairly large Lua file (over 1000 lines of code, uses LuaToggle for keyboard entries) successfully for years, but am now having what I think might be some kind of loading timing problem with it. If I load a plane directly onto the runway the Lua file does not work, even if I wait about a minute or so before trying to use it. But if I then exit FSUIPC7, and then restart FSUIPC7 manually, the Lua file works. This file makes use of the Wnd library to display short messages in response to keyboard entries, but when FSUIPC7 first starts (auto load), there is no message response to those keyboard entries. The auto loading of small Lua files that also use the Wnd library, but don't display messages in response to keyboard entries, seem to be working. I have not made any changes to the [Auto] section of the FSUIPC7.ini file. I am using FSUIPC7 ver 7.4.8. Let me know what type of log files might be helpful. Thanks for any thoughts, Al
-
Hi John, Couple of questions on axis calibration. 1. For single engine aircraft I usually set up the throttle, Prop, and Mixture/Condition lever using the first and second FSUIPC7 Joystick Calibration windows. There are also joystick axes calibration windows 3,4 and 5 where you can set up 4 throttles, 4 mixtures and 4 props. My question is, for a single engine aircraft, what is the difference between setting up the throttle, prop and mixture on calibration windows 1 and 2 as compared to using Throttle 1, Mixture 1 and Prop1 on calibration windows 3, 4 and 5? 2. Calibration windows 3, 4 and 5 have a check box ExcludeThrottlen Set (or Mixturen Set or Prop Pitchn Set). I did find a little about this in the FSUIPC manual, but still don't understand what this check box is for, and why there is no similar checkbox for the throttle, prop and mixture setup on Calibration windows 1 and 2. 3. In my FSUIPC7.ini file I see I have entries such as : [JoystickCalibration.TBM850] ExcludeThrottleSet=No ExcludeMixtureSet=Yes ExcludePropPitchSet=Yes Do these entries have any effect for a single engine aircraft? Should they all be set to = Yes, or what? Thanks, Al
-
John -- interesting ideas, thanks very much! Al
-
I understand John, and in fact have a number of scripts that do just that. This was a particular situation where as an experiment I did not want to use an event driven script. Thanks, Al
-
A flash happens when a window is opened, and since the "other" script is called numerous times, the window is opened and flashes each time. I don't think there is a good solution for this kind of situation. Thanks, Al
-
What is a good way to keep a Lua script from terminating? One way I found is to put a "dummy" (empty) do while true at the end of the script like this: WIndow Script code here do while true end In the particular case I have, the script above simply opens a window for display that I want another script to be able to use. So I don't want the window to close. I pass the window's handle to the other script, and this seems to work OK. The other script is called frequently as data is entered, and if I put the window definition code in that script, then each time the script runs the window flashes. If the window stays open there is no flashing. I just wonder if there is a better way to keep the window script from terminating then using the empty do while true? Thanks, Al
-
That's interesting because I've never run into this before. Is the preference not to open on startup saved somewhere and so passed on to new FSUIPC7 installs? I looked at the top of the FSUIPC7.ini file but didn't see anything I recognized related to this. Thanks, Al
-
Found the "problem"... apparently me. Somehow the option to Open on Start was selected under the FSUJIPC7 Options drop-down menu. I don't know how that happened, it has been so long since I've looked at that menu I didn't recall there was an option to open the window on startup. 🙁 Al