Pete Dowson

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

Well, neither SimConnect nor FSUIPC makes any distinction between ground and airborne traffic --it is only a flag saying "on ground" or not. Oh, and of course the range at which FSUIPC adds ground traffic into the list is 3 nm, whereas the range for airborne is 40 nm default, or unlimited if you set it that way. The flight number is not relevant before the clearance. Okay, so it is only TrafficLook not getting the data? Yes please. Oh, maybe for the FSUIPC4.LOG could you enable IPC read logging again, just so we can be sure the ground tables are still all zero? Don't leave it on after this though. It makes the logs far too big and hard to read. Apart from that I need to think what extra logging I need now. Nothing is making any sense. As I say, there's really no difference at all between ground and airborne except for a flag, unless all your ground traffic was more than 3nm away. I have tried it on a P4 3.2GHz with 1.5Gb, a Core 2 Duo 2GHz with 2Gb, and an Extreme Core 2 6800 with 2Gb (my fastest), and none of them exhibit ANY of the symptoms your does. Equally, none of them manage to get to loading any AI traffic for at least the first 120 seconds -- well over 80% of the progress bar. (Did you observe this at all in yours?) Maybe it's related to some setting in your CFG file. Could you Zip me your FSX.CFG file so I could try it please? I'll think about what additional information I need to find out what it happening to the ground traffic. Looks like another day ... Regards Pete

Okay. I've analysed the logs in detail, and I can only conclude that the problems are down to the change to multi-threading in FSX + SP1. I cannot reproduce anything like the problems you see, but I can theorise how they may occur assuming several things are going on in parallel in FSX. There are two things I could do, and I've decided to do both of them. 1. Make FSUIPC4 "start immediately" if it detects SP1 or later. This will put it in a better position to catch things hapening in parallel with the main thread sequencing. 2. Utilise a separate SimConnect facility for requesting a list of all traffic at a given moment in time. I hadn't used this before because it wasn't needed - FSUIPC had always requested notifications of AI additions before they started. Just to be on the safe side, I have made it ask for the list repeatedly, every 5 seconds, until it receives the first notification of an additional aircraft. This will prevent it missing any at all, I hope. Before I make any general release of a version containing these changes, could you please download 4.112 from this link: http://fsuipc.simflight.com/beta/FSUIPC4112.zip This is just the DLL -- copy it into the FSX Modules folder. Try it and let me know, please. BTW, I should have mentioned this earlier really. Instead of enabling all that IPC read/write logging, for AI data you can get good logging by adding these lines to the [General] section of FSUIPC4.INI: Debug=Please LogExtras=512 Actually, with "Debug=Please" there you can enter the LogExtras number in the Logging options. There are a number of different debug logs which I control that way, but they change from version to version and I prefer to have them used on a need and request basis. Regards Pete

Okay. So the problem is actually FSX SP1 rather than anything different in FSUIPC. The phrase "after the sim is running." seems to imply that somehow you are getting AI aircraft populating BEFORE SimConnect has loaded FSUIPC and told it the the Sim is running. The method FSUIPC has of getting data on AI aircraft is by telling SimConnect to notify it of every "Add Aircraft" and every "Remove Aircraft" event. Obviously any of those occurring before it is even running won't be seen. That's actually completely different to what I see here, where FSUIPC is most certainly ready and receiving data from SimConnect when the first loading progress bar is between 10 and 25%, certainly well before it reaches the "loading AI traffic" stage which is generally at 60-80% minimum. I am puzzled as to why your system is behaving so differently to mine -- I've tested this on three different systems, very different speeds, XP and Vista, and with different amounts of add-ons installed from none to a lot. And it seems pretty invariant. I'll take a look. I think only the early parts will be relevant to this, though your other, separate, problem of missing flight numbers is odd too. [LATER} After a first brief look at the SimConnect log, and comparing it with a typical one of mine, the difference i see is amazing. I get no notifications of any objects being added at all, but after 63 seconds of SimConnect starting there's a whole load of these: < 63.60396 [63] ObjectAddRemove: EventID=10 Type=2 ObjectID=2936 which are Object Removed notifications! The sequence FSUIPC is using should be foolproof. Here is the start. within 6 seconds of SimConnect starting up FSUIPC is asks to be notified when the Sim is ready ("SimStart"): > 6.81561 [63, 2]SubscribeToSystemEvent:EventID=2, SystemEventName="SimStart" and this actually occurs 34 seconds later: < 40.39737 [63] Event: 2 upon which FSUIPC asks for notifications of Object Add/Remove: > 40.50822 [63, 13]SubscribeToSystemEvent:EventID=9, SystemEventName="ObjectAdded" > 40.50832 [63, 14]SubscribeToSystemEvent:EventID=10, SystemEventName="ObjectRemoved" but it never then gets the ObjectAdded event for all those which get removed 23 seconds later! All this is happening in the first 60 seconds of FSX being started. Even on my fastest system it takes over 100 seconds before it gets its first notifications of objects being added, yet it seems on your system they must have all been added in the first 40 seconds, before Simconnect has even said it is ready! What sort of system are you using there? Maybe this is all to do with speed and multiple cores. Is it a Quad core or something? Maybe the SimConnect thread is running is one core whilst all these other things are racing ahead in another? If this is indeed where the problem lies, there's one more thing you can try before I work out a general solution. Try setting StartImmediately=Yes in the [General] section of the FSUIPC4.INI file. If it isn't there to change, just add it. Here's how it is described in the Advanced User's Guide: StartImmediately is not expected ever to be useful, but adding it and setting it to ‘Yes’ makes FSUIPC4 initialise the data interface with SimConnect immediately it is started, rather than wait for SimConnect to indicate “SimStart”. This is the way it operated throughout the Beta phases of FSX and in the first few public releases of FSUIPC4, but it was changed in order to avoid the SimConnect problems which seem to occur when more than one Client initialises at the same time, prior to FSX’s “start”. Please let me know. If that helps or works, I may change FSUIPC4 so that it assumes that setting -- for FSX+SP1 only (because the problem it fixed certainly still exists without SP1). Regards Pete

Please check the announcements and stickies at the top of this Forum. You will find one dealing with what to do if you lose your keys. Pete

Updated from what version to what version? You don't have to pay for updates from any Version 4 to another Version 4. Can you describe more carefully what you mean, please? When you say you are "unable" to enter the key, can you tell me what you mean, please. Is something preventing the entry, or what? Perhaps you should send me your registration details privately, to petedowson@btconnect.com, so I can check them. Regards Pete

There are reports of it being done with a 396. Is the 496 are newer model in the same line? If so it should be fine. See for example http://forums.simflight.com/viewtopic.php?t=42486 . USB is just another type of serial port. When connected, does the unit show as another COM port in the Windows Device Manager (Control Panel-System-Device Manager)? If so then it is using USB only in COM port emulation mode -- which seems likely if you can also get a serial cable for the same device. Otherwise, it may be connectable using the more complex USB port name as mentioned in the documentation, though I've no experience of any of that. If you have some sort of active sync program installed for map /route and other type info updates, you may have to kill that as it could be running in the background waiting to grab the device as soon as it is connected and switched on. Regards Pete