Pete Dowson

So, there's nothing to tell us why it doesn't work when it doesn't! The log shows it is okay. One of the programs you have removed is obviously conflicting with it. Have you found out which one? I really think this is not getting anywhere like this. Comparing a log with a working program on one PC with a log from the same working program on another PC is not very fruitful. It works, great! If you still have a problem to solve I think it is really now a matter for Markus to help you with, and possibly the author of whichever program it is which afflicts the ACARS program when it is running. Regards Pete

I tested the re-direction problem you had when using the older version (4.05) but with version 4.06 and I could prove that it was actually fixed, so you would have been okay with that. I'm not sure where you got 4.05 from -- it was only available for a week or so in November, being withdrawn when 4.06 was released in November, too. In version 4.07, now available above, there is an option offered at the end of the eventually successful Install process to correct the Registry entry for you, in the case where you had to find the right place during the install. You might want to take advantage of this when installing 4.07, as it will certainly save you getting problems with future add-ons. Regards Pete

What language or program is that from? Have you asked the author of whatever it is you are using? I don't recognise it at all. Sorry. I would assume that the parameters inside the () are the offset (0x0D0C for lights), the size (2 for 2 bytes, or 2 x 8 = 16 bits), and then the value to be written. Unfortunately all the lights are represented by separate bits in the same 2 byte section, so you need a facility to AND bits out and OR bits in, otherwise you'd be switch all of the lights all of the time. I've no idea if whatever it is you are using supports such facilities. Is there no support place for the program or hardware you are using for this, or a manual or something telling you more about it? Regards Pete

Seems the FSX installation is very prone to going wrong. Please see the FSX Help announcement at the top of this Forum for re-installing SimConnect. Regards Pete

No. I don't understand. are you saying that the program now works without the other add-ons? Which one is conflicting then? Unfortunately the log is a continued log. Why? The earlier reads being logged here don't correspond with those Markus shows as being used by the ACARS program. You appear to have some other program reading a batch of stuff every 5 seconds, thus: 105953 READ0 3364, 1 bytes: 00 105953 READ0 3365, 1 bytes: 00 105953 READ0 0264, 2 bytes: 00 00 105953 READ0 0560, 8 bytes: 00 00 52 BD 31 6E 50 00 105953 READ0 0568, 8 bytes: 00 00 DE 51 28 82 06 A9 105953 READ0 0570, 8 bytes: 00 00 73 EC 83 00 00 00 105953 READ0 0D50, 8 bytes: C0 19 B7 D8 B1 75 50 00 105953 READ0 0D60, 8 bytes: D2 4D 62 10 D3 00 00 00 105953 READ0 0D58, 8 bytes: 00 54 55 55 F5 44 06 A9 105953 READ0 3122, 1 bytes: 80 105953 READ0 8330, 2 bytes: 80 01 105953 READ0 034E, 2 bytes: 95 22 None of that relates to anything Markus's program is doing, according to his logs. What other program or DLL or Gauge are you still running? Later in your log: 167922 READ0 3304, 4 bytes: 00 00 10 37 167922 READ0 3308, 4 bytes: 07 00 DE FA 167922 WRITE0 (failed, read-only!) 330A, 2 bytes: EC 03 This is the part corresponding to the Open, occurring a good minute after you stopped and restarted logging (I'm still none the wiser why you are doing that). Then, these batches: 169062 READ0 0238, 1 bytes: 10 169062 READ0 0239, 1 bytes: 00 169062 READ0 0366, 2 bytes: 01 00 169062 READ0 11C6, 2 bytes: 00 00 169062 READ0 31F0, 4 bytes: 03 00 00 00 169062 READ0 0580, 4 bytes: 58 21 39 00 169062 READ0 0574, 8 bytes: 83 00 00 00 91 EF B8 FE 169062 READ0 0BC8, 2 bytes: FF 7F 169062 READ0 02B4, 4 bytes: A9 01 00 00 169062 READ0 023B, 1 bytes: 00 169062 READ0 023C, 1 bytes: 00 169062 READ0 0264, 2 bytes: 00 00 169062 READ0 0C1A, 2 bytes: 00 01 169062 READ0 0894, 2 bytes: 01 00 169062 READ0 092C, 2 bytes: 00 00 169062 READ0 09C4, 2 bytes: 00 00 169062 READ0 0A5C, 2 bytes: 00 00 169062 READ0 0AF4, 2 bytes: 00 06 169062 READ0 02B4, 8 bytes: A9 01 00 00 01 00 00 00 169062 READ0 030C, 4 bytes: 00 00 00 00 169062 READ0 31E4, 4 bytes: 0F 23 01 00 169062 READ0 0B74, 4 bytes: 00 00 00 00 169062 READ0 0B78, 4 bytes: 00 00 00 00 169062 READ0 0B7C, 4 bytes: B2 9D 7D 00 169062 READ0 0B80, 4 bytes: 1B 00 00 00 169062 READ0 0B84, 4 bytes: 00 00 00 00 169062 READ0 0B88, 4 bytes: 00 00 00 00 169062 READ0 0B8C, 4 bytes: 00 00 00 00 169062 READ0 0B90, 4 bytes: 00 00 00 00 169062 READ0 0B94, 4 bytes: B2 9D 7D 00 169062 READ0 0B98, 4 bytes: 1B 00 00 00 169062 READ0 0B9C, 4 bytes: 00 00 00 00 169062 READ0 0BA0, 4 bytes: 00 00 00 00 169062 READ0 0BA4, 4 bytes: 00 00 00 00 169062 READ0 0BA8, 4 bytes: 00 00 00 00 correspond okay with those that Markus's log shows. Even the Write to 0262 to release Pause is there. So, what was the problem? Regards Pete

No, there's no need at all. If there's a problem it is not going to be anything to do with any of that. We need to comparewhat you get normally (when it works) to what you get when it doesn't. That is why we need to compare side-by-side your results and your problem user's results. Your part is here. We wait on your user. This part: 114094 READ0 3304, 4 bytes: 00 00 10 37 114094 READ0 3308, 4 bytes: 07 00 DE FA 114094 WRITE0 (failed, read-only!) 330A, 2 bytes: EC 03 is the standard FSUIPC_Open() sequence. After which you appear to do a batch of reads every second: 115203 READ0 0238, 1 bytes: 0E 115203 READ0 0239, 1 bytes: 22 115203 READ0 0366, 2 bytes: 01 00 115203 READ0 11C6, 2 bytes: 00 00 115203 READ0 31F0, 4 bytes: 03 00 00 00 115203 READ0 0580, 4 bytes: 6E E6 38 00 115203 READ0 0574, 8 bytes: 83 00 00 00 3A 4B 1E FE 115203 READ0 0BC8, 2 bytes: FF 7F 115203 READ0 02B4, 4 bytes: 00 00 00 00 115203 READ0 023B, 1 bytes: 16 115203 READ0 023C, 1 bytes: 22 115203 READ0 0264, 2 bytes: 00 00 115203 READ0 0C1A, 2 bytes: 00 01 115203 READ0 0894, 2 bytes: 01 00 115203 READ0 092C, 2 bytes: 00 00 115203 READ0 09C4, 2 bytes: 00 00 115203 READ0 0A5C, 2 bytes: 00 00 115203 READ0 0AF4, 2 bytes: 00 06 115203 READ0 02B4, 8 bytes: 00 00 00 00 00 00 00 00 115203 READ0 030C, 4 bytes: 00 00 00 00 115203 READ0 31E4, 4 bytes: DA 22 01 00 115203 READ0 0B74, 4 bytes: 00 00 00 00 115203 READ0 0B78, 4 bytes: 00 00 00 00 115203 READ0 0B7C, 4 bytes: FD 9F 7D 00 115203 READ0 0B80, 4 bytes: 1B 00 00 00 115203 READ0 0B84, 4 bytes: 00 00 00 00 115203 READ0 0B88, 4 bytes: 00 00 00 00 115203 READ0 0B8C, 4 bytes: 00 00 00 00 115203 READ0 0B90, 4 bytes: 00 00 00 00 115203 READ0 0B94, 4 bytes: FD 9F 7D 00 115203 READ0 0B98, 4 bytes: 1B 00 00 00 115203 READ0 0B9C, 4 bytes: 00 00 00 00 115203 READ0 0BA0, 4 bytes: 00 00 00 00 115203 READ0 0BA4, 4 bytes: 00 00 00 00 115203 READ0 0BA8, 4 bytes: 00 00 00 00 The Write entry for 0262 (ensuring the Sim isn't Paused) is a one off I assume. If we see what your User gets, the problem should become obvious. If he gets nothing, then I'm afraid there's something happening in your program before the FSUIPC_Open() is even reached. I won't be able to help with that, you'll need to consider adding some diagnostics to tell you. Regards Pete

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