Pete Dowson

Sorry, I think you misunderstood me rather completely. The point of removing those modules, and not running ActiveSky or any other FSUIPC user (e.g. not PMDG aircraft either), was purely to make sure that the only FSUIPC program being logged was the one we are interested in! Otherwise it becomes almost impossible to work out which program is doing what and we'd get nowhere. I was not suggesting removing those things to see if it then worked (though I did mention in passing that Actigate had caused some problem according to other reports). That was not the point at all! In fact, if the problem did NOT persist after removing those things we'd be in a bit of a fix as then there'd be less ways to find out what is actually going on! Thanks, though I'm not sure why you consider merely enabling tow options in the Menu, to get more logging, a "full test" as such. It was the only test I asked for. It would really have been easy to do that as soon as you loaded FS after removing those modules. Regards Pete

In my multi-PC cockpit network I have WideClient in the StartUp folder, and it loads and simply waits for FS to start on the Server and then connects. Or, vice versa, if the Server and FS is up and running when the client is switched on. As far as I know there is no difference at all when you start it You aren't getting WideClient to run application programs too at that time, are you? If you are there may well be some start-up problem with resources they need so early. Best to use "RunReady" in the INI file instead of "Run" so that the applications don't start till FS is ready and the connection is made. Ah, so you areWell, although it shouldn't affect WideClient directly, it could be getting resource problems at that time. Try changing all the Run parameters to RunReady. And if you are loading multiple applications in the same PC, use the DelayReady to separate their loading by a few seconds each to avoid resource conflicts again. Regards Pete

Can you show me the Installer log from 4.06 or, better, 4.067 please? Things have changed since last November. I don't know if I have specifically dealt with the problem you are getting -- if not I'd like to fix it immediately as I am planning a release this weekend. From the installer log, this should actually point to where FSX is (and I do mean FSX.EXE etc): Whereas you kmow it is here: Okay. After you identified the correct path, then, according to the log, my installer still continued using the Registry path. That is wrong, but I think it might have been corrected in 4.06, or maybe later (hence, please try 4.067). If you could, please, as a matter of urgency, try 4.067 and let me knowif there is still the latter problem I would like to fix it now. I am also wondering whether, when you get the warning about the wrong folder, it would be a good idea for my installer to offer the option to fix the registry entry. It should be easy enough to do. Regards Pete

The entire title of the plane, the one that identifies it uniquely in the whole list of installed aircraft, is available at offset 256. There are also assorted ATC identifiers from the AIRCRAFT.CFG file in offsets 3130 to 3160. These are the only identifying strings available. If you need others from the AIRCRAFT.CFG file (are there others, always?) you could read that file yourself. You can derive the path to it from the path to the AIR file, in offset 3C00, as both AIR and CFG files are normally in the same folder. Regards Pete

Following on from my previous message, Markus, that log file seems to show IPC Reads (no Writes? not enabled?) from several different applications. Since it is a continuation log ("Continuation log requested by user") there's no way I can identify any of the others, only yours (P2264) as it was loaded later. I count 4 FSUIPC client applications operating there: 599469 READ0 [P3820] -- another external process, or an internal module or gauge using the external interface. 599797 READ0 [P2264] -- your ACARS program 600344 READ0 [M2] -- a module or DLL 600750 READ0 [M3] -- another module or DLL To do these comparison tests, to find out what exactly is going on, we need 1) both of you using the same version of FSUIPC 2) both of you using ONLY this ACARS application, absolutely no other FSUIPC client whatsoever, be it DLL, GAU or EXE. 3) both of you logging IPC Reads and Writes. Note that in 3.71 there is no identification of each module, gauge or program going on. It was in all this area which I wanted to simplify things -- it was time consuming (at run time), and rather error prone code needing certain versions of system DLLs available. I removed all that code to end the constant hassle it was causing me. Thanks, Pete

Great! Thanks Markus. Okay. That is, of course, with FSUIPC 3.70 or before. Version 3.71 doesn't check the key in any case. We simply need to compare the IPC exchanges going on between your program and FSUIPC on his PC with the exchanges you show in your log, when it works. This is why I asked for the IPC logging to be enabled, with only your program running. How else is there any way to proceed? If, with the correct logging requested in FSUIPC, there is no log of any IPC exchanges from your program, then your program is not even contacting FSUIPC, so I have nothing to look at. You would need to add diagnostics to your program in this case, to find out why. One of the first steps you, as the developer, could do, is at least update your FSUIPC to the currently supported version, just as your user has done. Then maybe we''d be comparing apples with apples rather than pears! ;-) Best Regards Pete

No, sceneries and FSUIPC are absolutely and totally independent. And FSUIPC4 is totally dependent upon SimConnect. Did you get a SimConnect Log? Please see the FSX Help announcement above. What programs or other add-ons are you using which use FSUIPC4? Could it be one of those? The other possibility is the weather data. Do you use FSX's weather downloads? There exists a possibility that sometimes weather data for areas of the world are bad, and this might possibly upset FSX via SimConnect, when FSUIPC4, for instance, is reading the weather data. If you have any Flights saved with the weather, with which you get these problems, maybe I could try them here to see. Regards Pete

I actually said "... the IPC Read and Write logging". The abbreviation "IPC" is the IPC from the name FSUIPC and is what FSUIPC is all about -- Inter-Process Communication -- and, oddly, there's a whole Options Tab in the FSUIPC Menu called "Logging". I'm surprised you've never noticed it. For developing or testing or finding any sort of problem it is almost essential -- which is why it is even provided for non-registered users. If you look at that options page you will see the checkboxes for the two logging facilities I suggested that you enable. Really the programmer of the program you are having problems with should be doing all this. How come it isn't he who is writing to me? It doesn't seem terribly sensible me helping one of his users to find problems in his programming. It doesn't matter what those DLLs are from. All I said was that you would be wise to temporarily remove them from the Modules folder, otherwise their access to FSUIPC will be all muddled up in the logging with the program you are trying to debug and no one will be able to unravel it. Ah. I misunderstood you then. Sorry. Yes, now I look it up, it is ActiveSky writing that key repeatedly. I remember that coming up before. It looks odd but apparently it is harmless. So this ACARS program doesn't write a key to FSUIPC itself, or at least it doesn't appear to. That's a bit strange as a Key was supplied back in August last year (6PVSXSWUGJAF). So we don't know whether it makes any attempt to talk to FSUIPC or notat least, without that logging I asked for for we don't. To be sure we know it IS this ACARS program, you certainly do need to rremove those DLLs, and not run the PMDG aircraft or ASV6 or FS FliteTracker. The ONLY add-on program you want to run is the program with which you have a problem. Are you sure you cannot get the programmer to help with all this? Regards Pete

Oh dear. Why provide huge pictures, when all I asked for was the Log? See the picture with the Window entitled "Installer for FSUIPC4"? And see, when the installation fails, the little Menu entry in that Window saying "Save As ..."? Didn't you read my reply to you, just above, at all? :-( Anyway, at least your pictures show that you are using an unsupported out of date copy of FSUIPC4 -- 4.05. The released version is 4.06 (since November 25th last year!), and there's a version 4.067 available above. Version 4.07 will be released within a week. Also, it does actually show that the Setup Path stated in your Registry is wrong. The registry says that FSX is in "Microsoft Games", whereas you found it in "Microsoft Games\Flight Simulator X". So the warning it gives you is correct. And you will have problems in future. Didn't you press "Aceptar" to allow the installation to continue? Check back. In your first message you said but you don't show anything of the sort here!? Please do NOT post large unnecessary and unwanted pictures of your screen. Please just provide the information I ask for. First please get a current copy of FSUIPC4 (4.06, or better 4.067 from the FSX downloads announcement above), run the Installer as far as it will go, and if it still fails Save the Installer log (e.g. as "FSUIPC4 Install.log") and show it here. Either way you are likely to get problems in future, even if FSUIPC4 installs. It certainly looks as if you moved FSX after installing it, as the Registry evidently thinks it isn't where it is. Regards Pete

No point in sending me that, it isn't at all relevant, thanks. The "AppKey" entries, although not checked any more, are made every time the program or gauge or whatever writes its Key to offset 8001. It looks like your program is looping, writing its Key. Nothing else in the log is at all of interest. To find out what programs are doing it is always best to enable the IPC Read and Write logging, so that what is actually being exchanged, byte for byte, can be examined. The programmer should know this, it is the main tool for development in the first place and most certainly the first thing to look at when trying to debug a problem. However, the log does indicate that you have a lot of other FSUIPC client applications, and if you Log all the IPC reads and writes it is going to be a job sorting out which relate to the problem program. Here's what you appear to have connecting to FSUIPC: It might be a good idea, for testing and debugging purposes, to temporarily remove all six of those DLLs from the FS Modules folder. Then re-check, with the IPC read and write logging enabled. Then you should be able to see what is going on -- show me that log if you or the programmer still cannot fathom it. Incidentally, I've seen problems reported with Actigate.DLL before. I couldn't reproduce them here, but possibly it may be interacting badly with your program? Regards Pete

You really need the PM offset reference documentation, from the PM site, to use these facilities, as they tend to change rather faster than I can keep up. There is a list in the FSUIPC Advanced User's Guide, but it isn't the definitive one. Always use PM's own for accuracy and to be up-to-date. The PM GC controls take a numeric parameter definiting the action you need. These are listed. The value of the numeric parameter is the value you place in the FSUIPC Button assigments "Parameter" field. That is why it is called that, because it is where the parameter goes. Apart from that I don't really understand your question. There is no "formatting" to do with the numeric parameter -- you just enter it. It is a number, use numbers, as listed for the functions you want to use. Okay? Pete

No bother. But if you still can do some testing I will send something when I have something to test. Okay? So far it looks certain to be a timing problem exacerbating bugs still in FS itself. When I add diagnostics to try to locate the problem on my test sites, it slows things like flight and aircraft loading down, and then there are no CTDs at all. It is thus proving almost impossible to get any information about what is happening. One thing is for certain now, though. It isn't actually anything in the FSUIPC code -- every part of it is now covered by traps, and they aren't being triggered. The problems are deep in FS's threading somewhere. If they never occurred with 3.70 or before it was just plain luck. Regards Pete

I'm in the process of trying all sorts of things out with other testers (I thought you said you were too busy?). As I cannot reproduce it here even with many hours of trials, I have had to make lots of different versions with different changes to ascertain what affects what. I'll post progress when there is any. Until then it remains a mystery. Sorry. The no CD crack is essential for debugging as otherwise that process you mention prevents the debugger being run and the stops anyone getting any information. It could be a reason for getting useless uninformative CTDs rather than proper crashes with details reported and a dump sent to Microsoft. But otherwise, no, I don't think it can be interfering in a causal sense, only hindering progress. Regards Pete

I've had a brief look at the FSUIPC4 logs, and I'm rather puzzled. The reconnections are retrying far too quickly after the first error -- within 120-330 mSecs. That should be more like 5-10 seconds. I'll have to double check. I know I dealt with one type of time-out correctly, I'll need to "simulate" this one, especially if you've set the Stall Time to 5. That's certainly a bit of a puzzle. Looks like I've not covered all the possibilities. It won't stop the errors occurring in the first place, of course. I''m only trying to tidy up and smooth over the aftermath. Thanks, Pete

Already done -- from your first message. I treat these things with urgency. I am thinking that Microsoft will be wanting to rush out some sort of "performance" update as soon as they can, and I'd like some of the more important SimConnect problems resolved at the same time if at all possible, not have to wait another few months. Regards Pete

The FSUIPC4 installer produces a log on screen explicitly to allow these things to be resolved. When you get such errors, there is a file menu for you to save that log. Please do so, and show me the log. I cannot possibly help without information. Pete

EXACTLY -- The Host cannot change the time of his own session, once it starts, even if he uses FSUIPC or SIMCONNECT to alter his Local or Zulu time while the sim is running in HOST mode. Those Changes just get overwritten by, what I am calling this 3rd SIM_CLOCK, which was initialized when the session started. Okayso the Zulu and Local times are maintained, so you know what they are, but you can't adjust them -- even via the Menu I assume? If you've got some idea about this "SIM_TIME" write to me by email and we'll go into it more. I do have good tools for delving, but I need as many details to start with as I can get, especially to an area completely new to me. In order to find it and work out how to access it I might also need some brief instruction on making myself a host -- treat me completely as an MP newbie, please. Regards Pete

Well except for your assertion about a "third clock" with SIM TIME, this is EXACTLY how I assumed it would work. It is how I would do it if I were in charge! But I wouldn't need a third clock because there would be nothing at all wrong with using the one I already have -- the one called ZULU time and offset in my own Host PC to my local time. Well, I think an local Zulu offset option would be nice. I would keep it to a nice round value like 6 or 12 hours, so that the controllers and pilots could still talk about ETA's etc meaningfully. Yes, but surely only the Host PC can change that time. You surely cannot allow each user of each client PC to choose the time he wants everyone else to be on? Well, no, not really, because now, apart from this third clock notion, you seem to be agreeing with my view of how it would work. The point now is, if you agree that the clients shouldn't be able to change the host time, is how the host, i.e. the guy in charge of it all, can change it. So, let me ask the questions which seem to be unanswered so far: Are you saying that the Host time cannot be changed by the guy sitting at the Host PC? Are you saying that the Zulu and Local times at the Host PC are NOT at all related to the times that host is sending to all of its clients? Where does this "third time" come in? Regards Pete

That doesn't seem terribly likely -- each PC connected to the host would gradually drift and be operating on different times. That would give a controller some nightmares. How do you know the time isn't regularly refreshed? (I know nothing whatsoever about the MP side of FS I'm afraid). I'm not sure what the "hint hint" is for here, but doesn't this just confirm what I think, that the time is synchronised regularly from the host? Ahso you are NOT saying it free runs in the local PC!? If you are a host, surely the host time is the host's time. Are you saying the host PC has no way of setting its own time? I think I'm confused here, or you are. Not sure which! ;-) So you ARE the host, you have control over the host PC, yet, you are saying, you cannot set the time? Sorry, I evidently don'ty understand this at all. I find it rather incredible that the host cannot set the time. How are you so sure there's a third clock, which no one can control? I think you must know more about the insides of FS and particularly MP than I do -- how is this host clock set, at random, or from some Internet time, or only by the host PC's system time? When the host says is it, say, 12 noon Zulu, then I would assume those local PC's connected would see their Zulu time as 12 noon, too, and their local time appropriate to their location in the FS world. Is this not so? Are you saying the read-out of local and Zulu time, from e.g. FSUIPC's offsets or the relevant SimVars, show whatever they have set locally, but the sim nevertheless continues using this "third clock" of yours, set to some unknowable (unreadable) time at that PC? If this is so it seems to be one of the most glaring bugs in the history of FS. How can the local pilot not know what the time is?? Maybe I am completely misunderstanding you? If so, can you perhaps explain in some clearer details please? For instance, why do you think there are three clocks -- Zulu, Local and Host -- being maintained in each PC? I just cannot get my head around that. Regards Pete

I'd be delighted, if you could tell me how? The only access I have is to Local and Zulu time. Surely, the Host's zulu time is imposed on the MP clients as their Zulu time, and this sets their Local time according to their offset, based on time zone. Trying to change the time on the clients would be futile as it would be reset on the next packet from the host. If you mean to change the Host's Zulu time, surely that would not be allowed, not be possible, as that would affect all clients! Are you saying that the time you can see in the client PC is not the same as or derived (by time zone) from that imposed by the host? I don't understand that. I'm afraid that is not correct, or at least that is not the intention -- at present FSUIPC uses Simconnect for 99% of the things it does in FSX, and the remaining 1% are promised, along with further things in the future we hope. Additionally, Simconnect will expand beyond what FSUIPC will offer, as time goes on (in some areas it does already, of course). FSUIPC's interface is essentially only there for backward compatibility. I think you need to put forward your needs in this area to Microsoft themselves (tell_fs@microsoft.com). I really do doubt that it is possible to do what you suggest with the current FSX code. If the FS team won't do it, then someone who is familiar with the MP protocols will need to write a program to act as a filter between FSX and the Internet packets and change the times being set. I'm afraid this is not my area of expertise at all. You may want to talk to someone like Jose Oliveira, who wrote AIBridge, or the Ivap or Squawkbox folks who can perhaps do something their end. Regards Pete

Interesting indeed! Before going into detail, could you please put everything you have, logs etc, and this report together in an email+attachments together, to tell_fs@microsoft.com. Do this as soon as possible, because I know the Simconnect folks in the FS team are struggling with all this at present. I will forward the details from here directly too and ask them to look out specifically for your email. Make sure you have 2SimConnect" in the subject heading f your email. Thanks. Now: The things I need to know here are: 1. The version number of FSUIPC4. 2. If you are using the recent update, 4.067 (from above), then have you tried increasing the FSUIPC4 timeout on receiving data from SimConnect at all? (SimConnectStallTime). It would be useful to know the number of seconds this has to be increased to to avoid the problem. 3. Please show me the FSUIPC4.LOG extract for the bunch of reconnections, so I can see the time involved there. I think if you had been using 4.067 you would only have one or two instead of a spate. If you Zip these up they should be quite small, relatively. Please do that before sending them to FS. If the FSUIPC4.LOG is also too big for you to extract parts (which is less likely I think), then Zip that up and send it to me at petedowson@btconnect.com. Thank you! Pete

Nothing so far. No, not being used by other testers. Regards Pete

Well, I think the "another program" possibility has pretty much been eliminated. I am having a lot of help from one user who can generate the CTDs and with no other FS-related programs running. and of those the only ones I don't use are ActiveCamera and Autower (whatever that is). I don't see anything useful in the hardware stuff either. I assume you are using WinXP SP2, fully updated? Regards Pete

I'm not sure I understand. What has you "main computer not working" got to do with FSUIPC and FS2004 or FSX? Have you just purchased FS2004? FSUIPC3 is one product, with one set of paid registration keys, and FSUIPC4 is another product with an entirely different set of registration keys. sorry, they are not interchangeable. FSUIPC3 can be used on FS98, CFS1, CFS2, FS2000, FS2002 and FS2004. FSUIPC4 can be used on FSX and is destined to be the version for future versions of FS. Regards Pete

I wish I could make it do that here. I've spent about 6 hours today so far on nothing else! Loading flights, changing aircraft, changing views, doing my utmost to make it crash -- zilch. Solid as a rock! Pete