Pete Dowson

Okay. I found some spare time and tried it. I can confirm that it works fine with the as-yet unreleased P3D version 2.3 -- this is with the early Beta1. I'm not able to test it with 2.2 10438 because I am not in a position to re-install it. Maybe it was a bug and is now fixed, but my guess is that it's to do with your bad 10438 install. I actually went to LFPV as in your first example, tuned to 286.0 and within 5 seconds the autotune set 286.5. The signal is strong even on the runway at LFPV. My normal test is Whitegate near EGCC, on 368.5, because it is local to me, but for that I need to get nearer and off the ground. If you still have problems you'll need to try to do the tests I told you about. Pete

The airport traffic is filtered out in FSUIPC, and is only read (to see if it needs to delete duplicates for AES/GSX) if the parameter "DeleteVehiclesForAES" is set to "No", the ground vehicles shouldn't matter. Perhaps you could check? FSX only generates traffic within its "reality bubble", which I think is 80nm around the user aircraft. FSUIPC ignores all but the nearest 96 on ground and 96 in the air -- that's a limitation of the offset tables it maintains. However, in order to determine which of the aircraft are the nearest it has to read all of them, and compute their distance according to yours and their latitude/longitude. I could limit the range for the data being supplied by SimConnect to less than the "reality bubble" size, but one of the main uses of the tables is for TCAS, and that can be up to 80 nm I think. I'll check further on that. (My range is 200 km, based on the bubble size). It would be nice if I could restrict the range for ground aircraft separately, but it isn't an identifiable group -- of course they change status in any case. As it is I am checking aircraft parked at airports up to 80 nm away just to see if they are withing the nearest 96. I have them all, and what makes them heavy on performance is mostly AI traffic. The latest verston of EGLL Extreme, with the Terminal 2 open, was a HUGE performance killer on my PC and I had to turn the traffic down quite a bit. It's just the sheer number of gates -- more gates, more aircraft. Pete

I think the about display is generated from another module -- the DLL for different languages I think. It sounds like you may have not got all the correct components of the 10438 copied over from their ZIP. To check the EXE, right click on it and select Properties - Version. Probably then best to re-copy all of the parts from the ZIP over again, and re-check. It works fine for FSX. It's pretty simple. I would suspect a P3D bug, but I'll check and report it next week -- if it is still the same in 2.3, that is. Pete

Not according to the version number of the P3D exe, as saved in the INI file you showed: FSVersionUsed="Lockheed Martin® Prepar3D® v2",2.2.10437.0 Maybe you didn't install the update correctly? You don't need to understand it. If you just bothered to go to the Logging Tab in FSUIPC options, you will see on the right-hand side words matching those I said, like "Offset" and "Type". I knew I didn't need to actually explain what they meant because you can simply match the words -- they are there, on the screen. ;-) I can understand that you then might not know where to look to see the results. I'll help. just check the "normal log" option below (that's the checkbox with those words next to it), do the test, then show me the log. Well, it's so unimportant to you, and you really can't match my words to words on screen, yes, I can look. Maybe next week. I rarely run P3D at all. But first try again with the 10438 update for P3D properly installed. If I've not come back by a week tomorrow, remind me, because after that I'm on holiday in Poland. ;-) Pete

Or just change the 123's to 122's in the WideClient.INI file. Well, I did say, many messages back, that until you actually press the button it obviously cannot show anything. Folks have many many buttons each with different assignments. What do you think it should show? I did ask you if the joystick number and button was blank, and you said yes, so I told you to press a button, and you said you did but it was still blank. that's why, for most of this thread, I've been concerned that you were losing the joystick connection!! It isn't really a mess. with only two buttons assigned and one keypress, it couldn't possibly be a mes! You ought to see some folks INI files! Yes, you can delete anything you like. Pete

There is no FSUIPC version which works properly with your installed version of P3D 2.2. you MUST apply the 10438 update as made clear in the sticky at the top of the forum and also in the Changes notice included in the ZIP file for 4.931. And, yes, please now update to 4.934 also. You can check this yourself -- I won't have time for a couple of days. All the AutoTuneADF option does is try the frequency with .0 and .5 alternately. You can Monitor this in FSUIPC logging, right-hand page. Offset is 0356, Type U8. That should be changing between 0 and 5 at five second intervals whilst no ADF signal is detected. If it is doing this, then the option is working but maybe the signal strength indication from P3D is broken. That is in offset 0C1C, type U32 and needs to be 50 or more for a recognised signal. Note that this option can also be disabled by a non-zero value in offset 3108, type U8. Check there too -- this option is used by some applications (I don't recall what they wanted it for!). Pete

They actually give instructions for using WideFS for PTT? Okay. Then in that case they must have tested it, so it should certainly work. I see several assignments for KeySend recorded in your FSUIPC INI file. No other button or key assignments at all, which is rather unusual. [buttons] ButtonRepeat=20,10 3=P0,10,C1006,1 4=U0,10,C1006,2 5=R0,11,C1006,1 6=U0,11,C1006,2 You have both buttons 10 and 11 assigned, with 11 repeating whilst held. [Keys] 2=122,8,1006,1,1006,2 You also have F11 assigned to do the same thing. Looking back to an earlier message: KeySend1=123,16 ; Press F11 KeySend2=123,24 ; Release F11 UseSendInput=Yes I now notice there's something wrong there. 123 is F12 yet you labelled it F11. For F11 you'd need 122. Looking at the WideClient log it is most certainly sending F12 as shown: 13687 Post/Send input for KeyHook action 1 13687 SendInput used for KeyHook action 1 13687 WM_KEYDOWN sent to Window 00090f76 ok, VK code 123 13687 Action request sent 1 events 13875 Post/Send input for KeyHook action 2 13890 SendInput used for KeyHook action 2 13890 WM_KEYUP sent to Window 00090f76 ok, VK code 123 13890 Action request sent 1 events Maybe all your problems are simply using F12 instead of F11? Does the vPilot manual say 123 is F11? sorry I hadn't spotted this earlier -- I don't know all the keycodes off by heart, I have to look them up just like you should have. And the main problem appeared to be that you kept saying you'd lost the assignments, which I really don't think is possible unless you are constantly deleting your INI file. Can you please clarify again why you think you are losing them? Regards Pete

Right. But I'd still like to understand why so much traffic makes things stall. I don't know what SimConnect's limit on numbers of pending data requests is, but evidently it was being exceeded, and one of the results was that it never accepted requests for certain vital items of data which FSUIPC waits for before starting everything properly. One way I might tackle it, if i can and once I know more, would be to ration the requests for data on AI traffic. However, if I never ask for data on more than, say, 250 aircraft, I may not get to those which are in range, so not then populating my traffic tables correctly for the nearest ones on ground and in the air. Another possibility is to avoid any AI traffic scanning until AFTER the initialisation stage is well completed. It does order things in that way, but it looks like there's insufficient gap. I might incorporate a multi-second delay after starting everything up before asking for anything to do with AI. Odd that FSX has been going now for 9 years or more and this hasn't cropped up as a problem before. What AI traffc are you using? Looks like you are in or near London, so do you have lots of traffic for all the London area airports? Just so I can be sure of exactly what is happening, before deciding what to do, could you please do one more test. Remove all of the monitoring offsets (easiest way is to delete the [Monitor] section in the FSUIPC4.INI before running FS). Re-enable all your traffic, as before, in order to induce the problem, then show me the log, at least as far as when is appears to fail to provide your Lat/Lon. The "TestOption" logging you added will tell me what data FSUIPC is waiting for. I don't see the "## Starting everything now ..." line -- maybe it's in the part of the log you omitted? If so, then it's all okay. Yes. In my opinion you made it unflyable too -- but maybe you just want to sit and watch AI instead? ;-). Look at your average frame rate without all that traffic: 100355 Sim stopped: average frame rate for last 61 secs = 34.6 fps However, I don't like anything stopping FSUIPC working correctly like that, so I'll need to consider what to do about it also. When I do decide, I'd be grateful if you could then again overload FSX so you can test the changes for me! Regards Pete

The "too many requests" error is a SimConnect problem I've rarely seen. What's changed since the previous log? Just enabling Extras logging doesn't change that. Have you actually got over 500 AI aircraft loading and running at the start of the program? It looks like simply requesting data on them all is overflowing SimConnect's buffers. I have seen it happen occasionally, but generally it's a symptom of something else going wrong. It might be worth testing with the AI traffic turned off (sliders to zero) to see if it's something there that's stopping things proceeding normally. It will also certainly help a lot with those dreadful frame rates! ;-) No it doesn't. It identifies the FLT file and the AIR file. the aircraft name is the one from inside the CFG file, and is logged as in the line in the log I pasted: 189135 Aircraft="Boeing 737-800 Paint2" Assuming things aren't (always) getting snarled up in a SimConnect buffer filling loop, it remains a mystery. Here's some other logging I need you to enable now: Before running FS, edit the FSUIPC4.INI file, adding these two lines to the [General] section: Debug=Please TestOptions=x800 This will log more information about what FSUIPC is waiting for before it thinks you are "ready to fly". Oh, the other thing, please now use the exact same build I'm using here, 4,934f download using this link: FSUIPC4934f.zip It isn't that I think this will behave any differently (it has some interim changes for a P3D beta, that's all). It's just that I want the code to match exactly in case I need to dig further. Pete

That's not a good idea really. Why would you want to keep telling WideClient to press the key? Once it is pressed it is pressed -- Windows takes care of any repeats. Uncheck the repeat option! I'm afraid I don't know vPilot. Perhaps the way it reads the keypress is simply not compatible with any of the ways WideClient (and I) know how to get the keypress to it. However, this, which is not quite what you said before: definitely indicates that you are not actually assigning or at least completing the assignment, because there is no way, if the assignment is completed and saved in the INI file that it will be forgotten. Note that previously you stated that the joystick and button were not being seen again ... seems that has changed now? Perhaps you should paste here, in a message, the contents of your FSUIPC4.INI file. You can use the <> button above the edit area to enclose it. That should be sufficient. You can use WideClient logging to see if it is being received and actioned. Just edit the WideClient.INI file and set "Log=KeySend" in the [user] section. Show me the resulting WideClient.log after you test the PTT. Pete

Please see my subsequent message, above. Back later ... dinner time, flake out a bit. I'll catch up before bed-time. Pete

Ah, I've just notice an anomaly from your log, after examining it more closely. I don't think FSUIPC is actually starting. Here's the critical part in the log I showed: 184861 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N 185438 System time = 02/07/2014 17:51:34, Simulator time = 17:48:39 (16:48Z) 189135 Aircraft="Boeing 737-800 Paint2" 190259 Starting everything now ... This occurs after the flight has fully loaded, some 90 seconds (in my case) after the Flight/AIR file was identified here: 9797 FSUIPC Menu entry added 9906 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y 9921 \\LEFT\FSPLANS\738 EGCC Cold and Dark.FLT 9921 \\LEFT\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.AIR In your log the whole sequence ends before getting to the state where everything is ready: 4321 FSUIPC Menu entry added 4352 c:\users\b\documents\flight simulator x files\Start-up setting.FLT 4352 F:\FSX\SimObjects\Rotorcraft\Bell206B\Bell_206B_JetRanger.AIR 147561 Sim stopped: average frame rate for last 70 secs = 13.7 fps 601898 Sim stopped: average frame rate for last 377 secs = 12.5 fps 630447 System time = 02/07/2014 17:35:20 630447 *** FSUIPC log file being closed The only time I've seen this was in a version of P3Dv1 where the flight being loaded was already in Paused mode. Unpausing it got past the problem. I think this was fixed in a later version of P3Dv1. So, first, can you tell me if the flight you are loaded is paused? Second, can you enable "Extras" logging (one of the Logging options), close FS down, then just run it and close it when it is ready to fly, producing a short log like before? The Extras logging produces those Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y lines, giving me the "ready to fly" status. The other thing FSUIPC needs to receive from SimConnect before it starts properly is the Aircraft name. it needs this in case of assignments to profiles and so on. After this, there are some other logging options we can apply to see why it isn't starting. One other thing you can try is changing aircraft, in case for some reason SimConnect can't supply its name. Regards Pete

I see you figured out how to get a short log after all! ;-) And, yes, everything looks fine. There's nothing there which can cause FSUIPC not to supply the correct data to any program which is asking for it correctly. If it is supplying only zeroes, as I think you said, then I can only think there's a fault in SimConnect, which is the part of FS which supplies the data. All FSUIPC does is map the data into an offset memory area for programs to read. Just to check this aspect (i.e. SimConnect reception), I'm going to ask you to actually add logging now. Load up just FS -- NOT any client program, in case it is that which is somehow clobbering things. Please go into the Logging tab and on the right-hand side enter these offsets and types in the relevant columns: 0560 as type UIF64 0568 as type UIF64 6010 as type FLT64 6018 as type FLT64 Then check the 'normal log' option below. This will first log the current position values. Slew or move the aircraft a ways, so it receives more changes. This will log several for each change of position -- the 0560/0568 values are very precise, the 6010 and 6018 less so. Keep it short but by all means just post an extract if it gets long. The log should show what is being actually returned by SimConnect for the latitude and longitude. Here's an example (the 0560 and 0568 values are in FS internal units, so don't worry about them being so different). 663207 Monitor IPC:0560 (UIF64) = 5940739.3454 663207 SimRead: 0560="PLANE LATITUDE" FLT64: 53.4572990817 663207 Monitor IPC:0568 (UIF64) = 4267551246.7788 663207 SimRead: 0568="PLANE LONGITUDE" FLT64: -2.29798669918 663238 Monitor IPC:6010 (FLT64) = 53.4573 663238 SimRead: 6010="GPS POSITION LAT" FLT64: 53.4572912577 663238 Monitor IPC:6018 (FLT64) = -2.2980 663238 SimRead: 6018="GPS POSITION LON" FLT64: -2.29797546725 663238 Monitor IPC:0560 (UIF64) = 5940740.3509 663238 SimRead: 0560="PLANE LATITUDE" FLT64: 53.4573081288 663238 Monitor IPC:0568 (UIF64) = 4267551091.8271 663238 SimRead: 0568="PLANE LONGITUDE" FLT64: -2.29799968708 663269 Monitor IPC:0560 (UIF64) = 5940741.1814 663269 SimRead: 0560="PLANE LATITUDE" FLT64: 53.4573156023 663269 Monitor IPC:0568 (UIF64) = 4267550963.8280 663269 SimRead: 0568="PLANE LONGITUDE" FLT64: -2.29801041584 663300 Monitor IPC:0560 (UIF64) = 5940742.0104 663300 SimRead: 0560="PLANE LATITUDE" FLT64: 53.4573230622 663300 Monitor IPC:0568 (UIF64) = 4267550836.0607 663300 SimRead: 0568="PLANE LONGITUDE" FLT64: -2.29802112517 The Monitor line is what FS is putting into the offset for applications to read, and these two following show the actual Simconnect name for the value and what it returned, in normal degrees, in floating point. Regards Pete

A run of FSX with FSUIPC installed, just starting FS, running it for a short time, then closing it, produces a very small log. Only selecting logging options will extend it. Since I've never yet seen you first log (you always click the "New Log" button for some unknown region) I can't tell what you have set -- it is logged in the early parts. For the log to get to 108Kb it would need to contain a minimum of 1300 lines even if all were full to 80 characters each. There is no way a log with no options selected will get that long. Here's a typical log file just loading FSX, running a couple of other programs (which have no effect on the log anyway) and closing FS after five minutes or so. the file itself is just 3kb. 108kb is HUGE. Please tell me what sort of lines you see in it which are not on this one: ********* FSUIPC4, Version 4.934 by Pete Dowson ********* Reading options from "E:\FSX\Modules\FSUIPC4.ini" Running inside FSX on Windows 7 Module base=0DA30000 User Name="Pete Dowson" User Addr="petedowson@btconnect.com" FSUIPC4 Key is provided WideFS7 Key is provided 78 System time = 02/07/2014 17:48:29 78 FLT UNC path = "\\LEFT\FSPLANS\" 125 Trying to connect to SimConnect Acc/SP2 Oct07 ... 156 FS UNC path = "\\LEFT\FSX\" 4165 LogOptions=00000000 00000011 4165 SIM1 Frictions access gained and basic values patched 4165 Wind smoothing fix is fully installed 4165 G3D.DLL fix attempt installed ok 4165 SimConnect intercept for texts and menus installed ok 4165 SimConnect_Open succeeded: waiting to check version okay 4165 Trying to use SimConnect Acc/SP2 Oct07 9797 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 9797 Initialising SimConnect data requests now 9797 FSUIPC Menu entry added 9906 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y 9921 \\LEFT\FSPLANS\738 EGCC Cold and Dark.FLT 9921 \\LEFT\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.AIR 10062 Memory in use: 517Mb, Avail=3579Mb 70325 Memory in use: 748Mb, Avail=3348Mb 130588 Memory in use: 830Mb, Avail=3266Mb 184861 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N 185438 System time = 02/07/2014 17:51:34, Simulator time = 17:48:39 (16:48Z) 189135 Aircraft="Boeing 737-800 Paint2" 190259 Starting everything now ... 190321 Using "E:\FSX\Modules\DLL\GFDEV.DLL", version 2.2.2.0 190321 GoFlight GFP8 detected: 2 devices 190321 GoFlight GFT8 detected: 2 devices 190321 GoFlight GFRP48 detected: 2 devices 190337 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N 191553 Advanced Weather Interface Enabled 193363 Memory in use: 1107Mb, Avail=2989Mb 253595 Memory in use: 1156Mb, Avail=2940Mb 313843 Memory in use: 1169Mb, Avail=2927Mb 314888 Ready Flags: Ready-To-Fly=Y, In Menu=Y, In Dlg=Y 314888 Sim stopped: average frame rate for last 130 secs = 29.3 fps 324123 System time = 02/07/2014 17:53:53, Simulator time = 17:50:45 (16:50Z) 324123 *** FSUIPC log file being closed Average frame rate for running time of 130 secs = 29.3 fps G3D fix: Passes 13117, Null pointers 0, Bad pointers 0, Separate instances 0 Memory managed: 112 Allocs, 112 Freed ********* FSUIPC Log file closed *********** But by "starting again" you mean pressing the New Log button which closes and renames the current log (adding a .1) and starts a new one, without of course all the essential startup information. But this is something only the author of the program which is trying to interface to it correctly can deal with. I cannot support all FSUIPC client applications. If you simply want proof that FSUIPC can ad is able to supply data correctly please download the SDK and run FSInterrogate to view the assorted offsets at will. Or run one of my own example utilities such as TrafficLook or WeatherSet2. I would class frame rates as low as 11 as unflyable. My worst airport is UK2000 Heathrow Extreme, latest version (with the new Terminal 2), with realistic traffic levels, and than can drop to as low as 18. i wouldn't like it lower than that! ;-) Regards Pete

Yes. Everything it does is listed in the log file, "runways.txt". The log is produced in the order of processing, layer by layer in the SCENERY.CFG file in the same priority system as FS -- all deletions in a layer before all additions. the specific BGL file name is listed. You shouldn't have the traffic layer ones enabled for add-on airports which come with their own AFD data. The reason traffic packages provide them is for parking specific airlines at the correct gates. but UK20000 AFDs do that better, and of course their position for the gates will not be exactly the same -- the traffic ones will be based on default scenery. You should either go through all the BGLs in the traffic folder and remove or rename those for which you have add-on scenery, or make sure that the traffic layer is processed before the add-on scenery -- i.e. move it. I always rename the ones which shouldn't be active, just changing the .BGL to .BGX will suffice. Don't forget to rebuild the files afterwards. Yes, of course. That one also contains the graphics. The Traffic layer won't provide new graphics! It will just refer to default gate and runway positions to be used by AI traffic . JustFlight don't know what add-on scenery you use and wouldn't be able to provide all the correct files for all the possible add-ons in any case. Always the last one to provide the actual graphics -- buildings, tarmac etc. But the positions of everything would be in the last one to change those. Different layers contain different things. Often terrain mesh and autogen layers are separate too. The layers are always processed in SCENERY.CFG layer order, as shown in Runways.txt too, though MakeRunways does not care about buildings, mesh or autogen, of course. But it is! Each type of scenery element is independent. For example the last one to set buildings will have its buildings seen. If it doesn't delete previous layer buildings (flattening i think it is called), then you'll get both lots with the later ones superimposed. . In your case the GRAPHICS will be from the ad-on scenery layer, the second one, but the gate positions and so on will have been messed up for traffic by the later traffic layer. Pete

Don't ever bother to try to post text files in any case. It is always best to simply paste their contents into a message. If you ever do need to attach files, ZIP them first. Even a huge text file ZIPs pretty small! If the file is large it must be because you have logging options still checked. Just make sure all options are unchecked on the logging tab BEFORE closing FS down, then when you start it up again the log will be normal. And yet you STILL went to the logging tab and pressed "New Log" just like I asked you not to! :sad: Anyway, the little it does contain (as a result of aborting the start-up log and starting a new one, again), does show that FSUIPC is working fine, no problems at all -- unless they are occurring during the first 3 minutes which would have been detailed in the normal, original, log. Your frame rate of a mere 11.6 fps seems terribly low. Pete

Sorry, I don't know about default ATC. I've not used it since becoming a Radar Contact users many years ago -- about FS2000 time I think! You'd be best asking such questions in the P3D forum on AVSIM. Regards Pete

Please clarify. At some time you see the joystick and buttons in FSUIPC, and at other times you don't? Can you identify what the difference is between when the joystick is recognised and when it isn't? FSUIPC actually uses the same Windows facilities as FS to read joysticks. Generally folks find FSUIPC much more reliable reading joysticks than FSX, and in fact many switch to FSUIPC because FSX sometimes loses their joysticks. So I wonder why you have the opposite results. It is rather odd and completely different to all others' experiences! Pete

You are logging things not needed. No wonder the log is large. Switch off ALL logging options please, I asked for none. The log will be very short then! And do NOT press "New Log" as that closes the original log and starts a new one. And i need to see the whole log, with the closing parts after FS is closed. And it needs to be for a currently supported version -- 4.929 is old. Current is 4.934. Just start FS, run the program you have problems with, close FS, show the log. That's all. do not set any options whatsoever. Regards Pete

So the joystick is disconnected? This will be why it doesn't work. Pete

We (SimFlight and I) used to codesign FSUIPC, but we had problems with the codesign authority when it came up for renewal (it isn't cheap) and simflight decided not to continue with it. there were always odd coming up too, needing support attention, with services needed in Windows being closed by users for performance and so on. Pete

In that case just press the button!! The dialogue doesn't show anything until it knows what button you want to program!! Sorry, no picture found. But if vPilot say it works and they tested it, what is different on your system? Pete

There's no way FSUIPC is "not picking up the coordinates". Please close FS down and show me the FSUIPC log file. Past its contents into a message here. You can enclose it using the <> button, above the edit area here. Pete

It isn't to do with WideClient. FSUIPC has never had any mouse assignments except for the special functions offered -- mouse wheel trim, and the mouse look and mouse move options. If you want to make a mouse assignable to any FS or FSUIPC controls like KeySend you'd need to have a Lua plug-in, which does have a mouse library with events for buttons, movement and so on. Okay. Okay, too. Cleared out, including the joystick and button number? Or do you mean after you press the button again? If you only assigned them, as shown in your picture, for the profile "Single Prop", then, yes, if you are looking at the general assignments not the correct profile ones, it wouldn't show the specific ones, and vice versa. Obviously. Check the Profile checkbox to toggle between the general (unticked0 and specific (ticked) assignments. Pete

Ah, so it isn't the three way switch you want to program! I thought that you had a simulator 3 position switch and simply wanted to match the positions on your real 3-way switch to it. Okay, so that is why you want to use key presses. Right ... Yes, of course. You need all actions programmed. Er ... but your three way switch merely switches the modes on the joystick, right? You aren't programming the 3-way switch itself in FSUIPC? I think I am still not fully understanding the question here. Sorry. Pete