Pete Dowson

Yes. The whole purpose of the FSUIPC IPC interface is onward compatibility. It is the same from FS98 through to FSX including even CFS1 and CFS2. Obviously extra things are added as new FS facilities appear, but the interface is the same and the older data is supported as far as it is still applicable. Pete

This number pad generates key presses? Why not use them directly then? What does FSUIPC do for you? The ATC Menu 0-9 controls are actioned by keypresses 0-9 (on the main keyboard) in any case. Erwhat do they do when the ATC window is closed? If they are generating keystrokes which aren't valid when the ATC window is open, maybe their input is defeated before they get as far as FSUIPC's detection, which operates at the Windows "KEYDOWN", "KEYUP" message level. Certainly, programming Buttons for the ATC menu selection works fine in FSX -- I can assign buttons either to keypresses (1, 2, 3, ...) or to the controls (ATC Menu 1, 2, 3 ...) and they work equally well. I'm afraid I don't have a separate keypad sending keystrokes to test, but I think it would help to know what keystrokes yours generates -- after all, a normal keyboard could be used as a substitute. All mine are USB anyway, not that this would make any difference. [LATER] I've done some tests with FSX and the normal keyboard NumPad. You don't need to assign things in FSUIPC to see what is happening. When the ATC menu is showing the normal NUMLOCK off NUMPAD keypresses are ignored. For example, the trim wheel on the 737 throttle quadrant is operated by the Home/7 and End/1 keys with Num Lock off -- but not when the ATC Menu is shown. Interestingly the NUMLOCK On mode is unaffected. I wonder if this is a bug? It effectively means that keyboard flying with the normal keyboard assignments is inhibited when the ATC menu is showing -- you'd suddenly lose keyboard throttle, aileron and elevator control! Can you verify this? Please report it to MS via tell_fs@microsoft.com. I'll ask about it too via my contacts. Regards Pete

Make sure you installed FSUIPC 4.11, not 4.09 which I cannot support. Can I see the FSUIPC4.LOG file, please, and the Install LOG also? You will find both in the FSX Modules folder. I need to know what version of Windows your are running. If it is Windows Vista you need to run FSX using the right-click popup menu selection "Run As Administrator", as described in the FSUIPC4 User Guide. If you still have difficulties I need to check the KEY. Please ZIP up and send your FSUIPC4.KEY file (from the FSX Modules folder). Regards Pete

SimConnect seems okay. If that was wrong you'd not get anything working correctly. You haven't said whether you tried the simplified / different SimConnect.xml I suggested. I am not using a SimConnect.xml which looks like yours -- I'm not sure where you got yours from. Try deleting the local section and substituting the one I suggested. Pete

Well, nor do I, sorry. I have no idea what that strange message means. You really need to go back to the supplier of the program which produces it and ask them what they mean. By the way, why do you mention FSUIPC 4.090 in the title of your message? The current supported version is 4.11 (and there's a 4.115 update in the Announcements). Version 4.09 is not supported now. Regards Pete

Okay. You have three files concatenated there. The FSUIPC4.LOG file is the only relevant one, and that is actually incomplete (FSUIPC4 is still running according to that). There doesn't appear to be anything wrong with SimConnect. You are using an out of date version of FSUIPC, but that is unlikely to be the problem. However, best to get it up to date first. Pete

Ah .. terribly sorry. I replied as if this were the last thread I replied to (the "done everything" one close to this). Comes of trying to reply to everyone at once. Ignore entirely my last reply. In fact I shall delete it. I shall now compose a correct reply ... Pete

FSUIPC offers facilities for applications to add menu entries. You don't need to run inside the FS process just for that. Check the FSUIPC SDK. The section in the Programmer's guide is entitled "MODULES Menu access for applications". For FSX, SimConnect provides more comprehensive menu facilities which can be used instead. The language used isn't relevant. Regards Pete

Best to check the FSUIPC4.LOG file first, because if there's no Simconnect problem shown there you will be wasting your time. Change the names of what DLL files, exactly? Installing a later FSUIPC will overwrite any earlier or same FSUIPC4.DLL there already. What other DLLs are you using? Regards Pete

No. There is actually no way FSUIPC itself can cause a crash. It is a complete SimConnect client, using fully documented SimConnect facilities. FSUIPC never affects anything but itself. If it isn't named FSUIPC4.DLL in the FSX Modules folder, it won't run. It sounds likely that one of the programs or add-ons you are running uses FSUIPC and crashes when it is running because it then does more things. Without FSUIPC it simply doesn't do the same thing. You will need to do a process of elimination to find the rogue add-on. Regards Pete

But does it work on the FSX PC? FSUIPC runs on the FSX PC, inside FSX. It needs SimConnect working there. The fact that it is working on a separate Client PC is not really all that relevant. But I expect ASX would not work on the FSX PC, like FSUIPC. Yes, the installation is fineI can see that from later details. Well, it looks like something is blocking SimConnect locally, on the FSX PC. Once an install works okay there's really little benefit of running it again, unless something else you have run messes one of the XML files up. More about the latter below. The FSUIPC Log simply shows that SimConnect won't respond correctly: This is normally down to a block by a security program -- even if they are disabled, some security programs still place hooks into the TCP/IP protocol path. Since FSUIPC cannot operate in any case, it follows that whether you enter a registration or not is irrelevant. It won't do anything because it cannot. It isn't being allowed to. Yes, that should be okay. But just to test, try renaming the SimConnect.XML so it doesn't get used. Maybe there's another SimConnect bug we need to report. If it still doesn't work, please obtain a SimConnect log, as described in the FSX Help announcement above, and I will try to get help from Microsoft. Note that I am running ASX on a separate PC along with FSUIPC4 on FSX with no trouble, but I am using XP Pro on both, with no firewall enable and no security programs even installed, and also I have a simpler "Local" section of the SimConnect.xml file, thus: False Auto local Maybe, if it works without the SimConnect.xml at all, you could try changing yours to have this as the Local section. (It is what the FSUIPC4 installer would add if it found no "local" section). Regards Pete

I've been trying to analyse what the actual value is. I now think the explanation in my offsets list isn't quite correct. Or at least it isn't as accurate as it might be. The values appears to be an AofA INDICATOR angle value, in FS degree units - that is with 360 degrees represented by 65536. The value 32767 would then represent 180 degrees, which must represent the indicator being "flat", or reading 0.0 (taking the Boeing AofA gauge as an example). This would also accord with your estimate of the FSX value being a factor of about 100 out. See here: In FSX at present 11BE is giving (Angle in radians x 100). Call this "N". To convert this to FS angle units: First (N/100 x 180/PI) gets it into degrees then x 65536 / 360 gets it into FS units. Simplifying: (N x 180 x 65536) / (PI x 100 x 360) gives N x 104.3. SoI'll proceed on this basis. Download 4.115 from the FSX Downloads announcement above when I get it there (probably later today) and try that. Regards Pete

The attitude as shown on the AI would have been useful, as I don't know what sort of way your aircraft sits on the runway or cruises 'level'. And the wing itself will usually be set for a small AoA even with the fuselage "level". According to the docs for 11BE, 32767 means 0 AoA, and 24000 means 27% of maximum AoA. So, it seems to me that the FSX figures should be going UP as the FS9 figures go DOWN. If the AoA being provided by SimConnect for FSX really is in Radians, like it says, and I am multiplying by 100, as I am, the results you show are: 3.14 radians and 2.33 radians, respectively These are rather large for AoAs. I think they must be measuring not the actual AoA but the incidence of the airflow on the wing, 180% opposite. This would explain the 3.14 (probably 3.142otherwise known as PI). PI radians = 180 degrees. I'll do some checking on various aircraft types. Meanwhile, what is the maximum AoA you can get without stalling? Regards Pete

And what are you seeing in 11BE for the same aircraft asttitudes that give you these figures? I need to see how to make FSX give similar resluts ot fS9 but I can't see how at present. I'll do some experiments with default aircraft attitudes, comparing FS9 and FSX. I should be able to derive some sort of useful conversion. Regards Pete

Great! I'll see about making an official release in the FSX downloads then. Just a problem with Angle of Attack indication to resolve first ... Regards Pete

You always need to cater for zero values. Zero mostly simply means "not yet set". Test for zero and reset the instruments to "off" defaults. In fact you should be testing the battery switch, vacuum, etc and just staying "off" till the aircraft "comes alive". Send what? I don't think I need anything, thank you. Regards Pete

Really? As far as I can see it is completely different, or should be. I have it down in my Offset Status list as "?" and shaded yellow, meaning needs checking. I'm afraid for these things I am completely dependent upon feedback from someone who knows these things. You are the first to come back, so please advise me. In FS2004 and before the value I got was: In other words it appears that it was an inverse value -- getting smaller as the angle got bigger, with 0 = 100% of maximum, whatever maximum is, and 32767 being 0% The only value I can get from SimConnect is an actual Angle in radians. Currently all I am doing with that is multiplying it by 100.0. So this value is going to go from 0 for 0% (instead of 32767 for 0%) to some value probably around 100 or so for 100%. I need to know how to convert it to something reasonably compatible to what we had before, but how do I know the max angle of attack? That will vary from aircraft to aircraft. How can I compute it from what I have? For the time being I could do something like this, perhaps: assume 1 radian for the max angle of attack, just for convenience, then convert the value thus: (1.0 - actual angle) * 32767 What do you think? Should this be allowed to go negative? Can you advise please? Regards Pete

Hi again Ian, Okay, I think I've nailed it. The original problem was that because of the way your system was behaving (and I still don't know why the timing was different), there were AI traffic additions being made inside FSX before FSUIPC4 had asked for these events to be notified. This resulted in some AI being missing -- and since ground traffic tended to be added before airborne traffic, it affected the ground more than the air traffic. Probably the quickest fix for that, had we realised what was happening earlier, was to do that "StartImmediately=yes" change (or just set that parameter). This may not have been foolproof, but it may well have been. To try to make things foolproof I added new code to ask SimConnect to supply complete lists of all current AI traffic, before I start receiving Addition events. This should have worked fineand it would have, except that with your StartUp setting for FSX it supplies that list BEFORE it actually tells me anything about the user aircraft. At the time I'm checking whether the aircraft are in range the User aircraft position is Lat=0, Long=0, so unless you are parked in the sea off the West African coast none of the ground traffic are in range initially. The [startUp] difference in FSX.CFG is that you have your default flight loaded THEN you go into the FSX initial selection menu and presumably "Fly Now" to get into flying mode. I use "SHOW_OPENING_SCREEN=0" to go straight in with the default flight. This seems to have everything right when FSUIPC4 is getting the AI lists. Now even not having the correct User aircraft position shouldn't have been a problem, since when it is actually positioned the range check will work and the appropriate AI aircraft will be put in the tableexcept that after the user aircraft is ready I get a pile of aircraft added events for the same aircraft. This second appearance of the same batch of aircraft caught me out. The code for dealing with them put them in the same, correct, slot, but because they were apparently "added" (new) aircraft it reset the flags saying that it had the information needed and then wouldn't deal with them until that information arrived -- which it never would because SimConnect had already provided it (it only sends changes). So, all in all, a complex sequence of events occurred. In effect, I fixed the problem of the missing aircraft but in so doing I created another problem which caused even more to disappear! :-( This latter problem is the one I saw, and which I have now fixed in 4.114. I've never actually seen the original problem, but from the logs I do believe that was fixed in the last two test releases. Please get 4.114 here http://fsuipc.simflight.com/beta/FSUIPC4114.zip and give it a test. If it is okay I'll put it on the FSX Downloads announcement. Regards Pete

The logs make no sense to me at all. Everything in my code is the same whether the traffic is on the ground or in the air. The only difference is the range, as I explained. The FSUIPC is log is simultaneously showing that there are some ground aircraft at EGBB (where you say you are, and presumably within 3 nm), yet also showing that the ground TCAS table is empty as shown in TrafficLook. I will try to adapt your FSX.CFG to one of my test systems to see if that enables me to reproduce it, but it is pretty much unlikely. There are actually three possible reasons why an aircraft might be excluded from the tables: 1. Tables are full (there's only room for 96 of each, air borne and ground). This obviously doesn't apply as the ground table has 96 free slots! 2. The aircraft is actually BELOW ground. This check was put in because some programs or flight schedules managed to fly AI aircraft underground causing all sorts of problems. 3. The aircraft is out of range. I need to see which of these is actually doing it, presumably because of some odd miscomputation, so could you please download 4.113 from: http://fsuipc.simflight.com/beta/FSUIPC4113.zip I've added some extra logging for this. Please disable the IPC read logging, and change the "LogExtras" number, in the INI file, from 512 to 1536. You don't need to do SimConnect logging any more as that shows all is as I'd expect. I just need the FSUIPC4.LOG please. Regards Pete

Please remember to include your FSX.CFG file as I mentioned. It seems now this problem is unique to your system, so I need to find out what the differences are. AHit has just arrived, and I see you have! Thanks. Regards Pete

Actually the interface is independent of FSUIPC version or FS version. In fact it is the same as in FS6IPC days, before FSUIPC. FSUIPC doesn't open a connection, your program does, via FSUIPC_Open. All that does really is create the memory-mapped file which will be used to exchange data, and get the FS and FSUIPC version numbers for you. The full source of all the application-side interface is supplied in the SDK, so you can review it yourself. That's not my language, but I assume you only ever want that one Read and nothing else from FSUIPC in the session? Normally you'd Open at the start and Close when your program has finished. And you'd accumulate all the Reads and Writes you needed, per cycle, for one Process, at intervals appropriate to your application. Forgetting the Open, because you only ever do that once, the only part of that which leaves your program is the Process call. That Sends a Message via Windows and waits for a response. How long that takes is completely up to Windows, the loading on the system, the state of FS at the time, and, of course, whether you are running on a WideFS client or on the FS PC. The only thing you could think of as a "connection" is the memory-mapped file the Open creates (and the Close destroys). That is unique to that Open (and that process). FSUIPC itself doesn't keep track of any of them. All requests are treated equally. Ten "connections" from ten programs, you mean? Since the "connections" are merely memory-mapped files created by and owned by the programs, if they are never closed they stay open, using virtual memory. If the program closes I presume Windows might tidy that up, but if not you have a memory leak and if you continue like that forever you will fill the swap file space. All that is irrelevant to whether FS continues to run or is closed, as it (and FSUIPC) knows nothing about the memory-mapped file -- as far as it is concerned it is just used during the Process call, to get data from or put data in, and then forgotten. From many programs? No. there is no need. As far as FSUIPC is concerned, 100 programs "connecting" and asking for data once a second each is the same as one program "connecting" and asking for data 100 times a second. All you should have to worry about is how to get those 100 programs all running smoothly under windows without severely reducing FS's own performance. That wouldn't be a concern on a WideFS client of course. If you are really talking about one program with multiple "connections", don't try it. To do so in any case you'd have to write your own interface code, or each "connection" could have problems with the generated memory-mapped filename. In one program you only need to Open at the start and Close at the end. One memory-mapped file per process. Regards Pete

Well, I'd hope so as you started it! ;-) 4.112. I may release it as 4.12 in due course. But I have a 4.113 here under test, so we'll get that checked first. Well of course I believe it, as it should. I don't understand how Ian still has a problem. He shows that FSUIPC4 is receiving the ground traffic data, and from what he's shown me so far the only possible reason they don't get into the TCAS tables is that they are out of range. Anyway, until I know for sure I am not able to do more. This is why I am awaiting new logs from him before getting 4.113 up for testing. Thanks for confirming it is okay on your system. Regards Pete

Where are you getting "nonsense values" from? All that should happen is that you get frozen values whilst FS is not updating, or zero before the sim is ready in the first place. I have three separate hardware panel setups and never see any "nonsense values". Pete

If FS isn't running (or on a WideFS client WideClient isn't running), then the Window classes "FS98MAIN" and "UIPCMAIN" won't be found by the IPC code in your program, so you will get an error returned from the FSUIPC_Process call. If FS closes after you are connected, the SendMessageTimeOut call will time out instead, giving a different error. However, such timeouts can also occur when FS isn't responding too -- it needs the message processed withing the specified time. There are two flags -- "ready to fly" is 3364 but "in a dialog" is 3365. They are next to each other for good reason -- you can treat them together as one 16-bit flag which is only zero when FS is ready. I'm afraid I don't know of any way to distinguish the specific menu or dialogue the program is in at the time. Regards Pete

I've been looking at my FSUIPC4 code for this [Red part is a later correction]: When this is logged the data for that aircraft has ALREADY been added to the TCAS tables being read by TrafficLook, UNLESS it needs to be eliminated for some reason -- the main one for Ground traffic being range. Of course I don't know where you were so I can't check that. In the next update I'll add a comment for "out of range" where appropriate. Oh, one other thing: the ground range of 3nm only applies when the user aircraft is on the ground. When you are airborne the range in 6 nm. See if, when you get in the air the ground traffic get listed. If so then it seems the range is the problem. (You can slew to get in the air but you will have to unslew temporarily to get the "on ground" flag cleared. Enter slew mode again before you crash then check TrafficLook). BTW the Flight Number "1123" above isn't used because until clearance it isn't valid. That one almost certainly comes from the default Flight number in the aircraft's CFG file. That's part of the new code -- the response from SimConnect to my request for a list of all current aircraft. There should have been some BEFORE the first AIRCRAFT entries, otherwise those must have arisen from the normal notifications of objects being added. No, they'll more likely be the results of the preceding Object ID supplied occurrences -- in fact you should be able to match up the IDs (I call the ID "Ref=..." in the AIRCRAFT lines -- this is historical, from FS2002 days). Pete