Pete Dowson

Hmm .. it does sound very much like something isn't performaing fast enough and a queue is building up. If it isn't to do with memory buffers than it just has to be something else en route to the Client PC. Do the Client or Server Logs show any problems at all? What versions of everything are you using? Is there a delay is things happening in the Sim and being reflected in the GC? If so something is queing. If not thenI don't know. Something's going strange in the FS PC. What are the OpenGL graphics frame rates shown by the PM GC on the client? Are you sure you are not trying to drive the client too fast? 40 fps as an average is quite high for a PM networked system, though it should cope okay. As an experiment try limiting the FS frame rate to, say, 25 fps, and see if that makes a difference to how long it goes or whether it starts stuttering at all. What protocol are you using -- TCP, UDP or IPX? It may be worth trying a different one. Regards Pete

In FS9 I think it is something like "HideInfoText=1". There's also "show_brake_message=0" in the [sim] section I think. In FSX there are about half a dozen different parameters for different message types. Regards Pete

Okay, I've experimented and soon found the problem. I don't think you need report it to MS, except maybe to get it clarified in documentation somewhere. I'm not sure where you got the above content for the XML file from, but as far as I can tell, by including that file you are overriding the default setting for how SimConnect uses TCP/IP protocols in the current (FSX) PC. SimConnect is still loading modules according to DLL.XML and programs according to EXE.DLL, but it cannot communicate with them because you have changed the port and IP address. If I change your file to read: Then everything works again. I'm not sure I need the Port number, and probably the Protocol should be Auto in any case to allow it to use IPv6 if installed, but the critical part is the 127.0.0.1 which universally means "this PC". I also set scope as "local" but, again, I'm not sure how necessary that is. Regards Pete

Ah .. so the problem you are saying is that if you set SimConnect to operate on multiple PCs on a Network, it either doesn't service any of the local Simconnect client programs, or perhaps just doesn't obey the DLL.XML and EXE.XML instructions to load them? If this is true it is extremely serious and certainly needs attention. I will try some experiments here. Thank you. Regards Pete

How do I know when it is in mission mode? I think this may first need to be a request to Microsoft, to provide information about FS modes? I can get a notification "Mission Completed" and also another "Custom Mission Action Executed". But I think the latter only refers to missions being controlled by that particular SimConnect client, and maybe the former does too. There's currently no "User has entered mission mode" notification. Oddly, I did get a positive note from one user (Doug Horton no less) who was actually very pleased that the AutoSave not only worked in mission mode, but actually allowed the saved states to appear in the saved missions list. Here is what he said: "Autosave .flt files are visible from the Missions UI if you check the "Show save missions" checkbox. Nice to have, particularly as I try to work through missions, in view of my two persistent crashing scenarios. Of course, they'll disappear from being listed under applicable mission after being overwritten by newer Autosave files that don't pertain to mission." He regards this as a very useful bonus and suggested I mention it in the documentation as such. Curious that you find AutoSaves an actual disadvantage in missions. Why is that? I have two opposite views. I can understand the positive one, but not yours. How do the autosaves detract from flying missions? Care to explain further, please? Regards Pete

You shouldn't do that! An XML file has filetype XML, not DLL. The SimConnect DLL is the compiled program part of FSX which loads and runs all SimConnect client programs! This XML file: should be called Simconnect.XML, and is only needed if you are running SimConnect client EXE programs on a Networked computer other than the FSX PC. Why create the file, then? And odder, why call it SimConnect.dll? If you think you have found a bug in FSX you really need to report it to MS rather than me -- send all the details to tell_fs@microsoft.com. Regards Pete

Sorry, no idea. FSUIPC wouldn't know how to stop those, but there are parameters in your FS CFG file to stop them. Otherwise it sounds likely that you are somehow preventing access to the fonts used. Pete

Thanks! Nice to have some positives here too! It does get depressing sometimes only seeing the problems, especially when nearly all of them are at present outside my control, being to do with SimConnect by the look of it. Regards Pete

Is there an FSUIPC4.LOG file? If so, let's see it please. Are you saying that the 4.026 install (available above) runs through and says "okay" but doesn't actually copy any new files into the Modules folder? I really cannot see how that is possible, as for success Windows must be reporting okay to each operation. Regards Pete

Good. Glad you got it all sorted! Regards Pete

Sorry, no other ideas. This is evidently another SimConnect bug. Please report it to Microsoft via tell_fs@microsoft.com with as much information as possible. Regards Pete

You didn't follow some advice to COPY over the existing DLL.XML file with another, surely? :-( The FSUIPC Install program carefully edits an existing DLL.XML file to insert the correct lines to get it loading by SimConnect. From what I've seen so far precious few other software publishers are bothering to be so considerate. Chaos is inevitable. :-( What is the exact message? In version 4.026 Installer I deliberately make the Modules folder read/write accessible and also unprotect any of the files FSUIPC4 needs to install. I simply cannot understand how any file can become "Access Denied" -- unless FSX is actually still running. Do CTRL_ALT_DEL and see if FSX.EXE is present in the Process list. Maybe one of the add-ins you are using is not terminating. Kill the process (button bottom right). There are never separate "documents". All of the DLLs to be loaded by SimConnect are detailed in DLL.XML and all of the EXEs are detailed in EXE.DLL. There are no other files relevant to this business. Regards Pete

I received your log, by email, and it shows that ASV6 is somehow trying to write to C800 illegally before it has supplied its credentials: 79797 Client Application: "ASv6" (Id=3640) 79797 G:\Flight Simulator 2004\Modules\ASv6\ASv6.exe 79797 Product="ActiveSky 6" 79797 Company="HiFi Simulation Software" 79797 Illegal write attempt: offset C800, size 1024 [P3640] 79797Program or module not accredited for use with this unregistered FSUIPC I assume that its attempts have been thwarted by everything else going on during initialisation. The ActiveRadar DLL muscles in immediately after, and a program called "FSHotSFX" is then so monopolising the interface to FSUIPC for so long that I suspect ASV6 is having problems: Client Application: "FSHotSfx" (Id=3612) 79984 G:\Program Files\FSHotSFX\FSHotSfx.exe 79984 Product="FSHotSFX" 79984 Company="FSHotSeat.com" 79984 READ0 [P3612] 3304, 4 bytes: 00 00 09 37 79984 READ0 [P3612] 3308, 4 bytes: 07 00 DE FA 79984 WRITE0 [P3612] (failed, read-only!) 330A, 2 bytes: 00 00 80094 WRITE0 [P3612] 8001, 12 bytes: 55 39 39 45 5A 59 52 34 50 30 47 50 80094 Program [3612] "FSHotSfx" access registration is okay 80094 ... This above sequence shows a correct startup and registration, unlike the ASV6 one. Somhow ASV6 never gets to send its registration key early enough. Most of the rest of the log is full of so much traffic between FS and FSHotSFX that I'm surprised you manage to fly at all. Every 200 mSecs it does over 200 individual read requests! The next seen of ASV6 is 87187 WRITE0 [P3640] 8001, 14 bytes: 39 47 39 4C 43 4E 54 32 4D 44 55 59 00 00 87187 Program [3640] "ASv6" access registration is okay showing that it finally writes its access Key 8 seconds after it attempts to first write any weather data. Something is wrong with ASV6 as there is no way it should attempt to do one before the other. Please send the Log and my comments to their support. I suspect they have several threads running and there's an interlock mechanism missing. Meanwhile, there are two courses you can take: 1. I don't know how you are starting these programs, but it seems to me you have too much happening immediately after FS is ready. You really need to start up FSHotFSX some time AFTER ASV6 has started, or vice versa. 2. I am looking at removing the access checking in FSUIPC3 in any case in version 3.71, to be released this month. Nothing definite yet, but if I do the this problem will just disappear in any case. Pete

What version are you trying to install? Pete

Did you purchase FSUIPC4 / WideFS7 keys? Check your receipt. 99.9% of all registration problems are caused by incorrect entry of the correct Name, Address and KEY. Use cut-and-paste to be sure. All three fields muct match EXACTLY what it says on your receipt. The newest is 4.026 available above and I am using it all the time with PFC devices. In any case the problem in 4.02 only applied to unregistered users! Please do read the details in the Announcements! Regards Pete

This sounds like it might be related to, or the same in effect, as the problems discussed in thread http://forums.simflight.com/viewtopic.php?t=57105. That has been reported to Microsoft. Which version of FSUIPC4 are you running? If it is down to the same Simconnect bug then I did find a work-around which I've implemented in FSUIPC4 recently. If you are not using 4.026 or later, get it from the FSX downloads announcement above and see if it helps. Let me know please. Possibly the problems you are seeing are completely different. This won't help clashes between other SimConnect clients -- they either all need to take the same steps as I've done, or we need a fix from MS. I'll be releasing 4.03 next week, replacing the 4.02 on the Schiratti page. Regards Pete

First off, the Log shows that you have some Gauge or other DLL trying to use FSUIPC the wrong way. This is shown by these lines: 6016 Client Application: "fs9" (Id=1548) 6016 C:\Program Files\Microsoft Games\Flight Simulator 9\fs9.exe 6016 Product="Microsoft Flight Simulator 2004 - A Century of Flight" I don't know what it is, but it could be interfering. I suspect it to be a gauge in the aircraft loaded by your default flight, "ord.flt". Do you think you could load FS2004, change the default flight to one using a default aircraft, then close FS again please? The log then shows that a program called "MotionDrive302.exe" connected. Unfortunately you did not close FS2004 before zipping the Log. The closing is important too. Also I notice you are using version 3.65 of FSUIPC. The earliest supported version is 3.70. Som please do these things: 1. Download the currently supported latest version of FSUIPC, 3.709, from the Announcements above, and put that into the FS Modules folder. 2. Run FS2004, go to the FSUIPC Options, Logging page, and enable IPC Read and Write logging. Turn ALL other Logging off please. I only want IPC reads and IPC writes. 3. Run your MotionDrive program. See it not working, but don't run it too long in case of a gigantic log file. 4. Close FS2004. Find the FSUIPC.LOG in the Modules folder, ZIP it and send it to petedowson@btconnect.com. Please do not attach it to a reply here. Thanks, Pete

Yes, in common with others. MS seem to be insisting this is a firewall problem. Please follow the link in the Firewalls announcement above. The error in hexadecimal is 0x80004005. I have no idea what it means but I am pressing MS for answers. Please report it to MS via tell_fs@microsoft.com in the meanwhile, with as much information about your system as possible. Regards Pete

Why's that, John? Guess I'll never understand VB! ;-) Pete

Are you comparing TRUE direction with MAGNETIC direction by any chance? Please take the Magnetic Variation into account. If you still think it is wrong, show more figures for comparison so I can see, but also state where you are in the world. In some places the MagVar is small, other places it is very large. Even in Seattle, for example, it is about 20 degrees. Even better, please try using FSInterrogate, part of the SDK and deliberately provided for exactly this sort of assistance. view the heading there AND the magnetic variation in offset 02A0. There's also a lot of logging and monitoring facilities in FSUIPC for you to use, to find out what you are doing wrong. Please take a look at those. Regards Pete

Well, to start you could use the autostart control. Exactly. So it could send the 4 controls even though you only say one thing? Anyway, try the _SET controls. Pete

FSUIPC always creates a Log file, even if you select no logging. If it doesn't then it isn't running or there's something rather seriously wrong with the file system somehow. In the seven years FSUIPC has been available I've never heard of a case where no log file was produced. The previous log file is always deleted and a new one created each time FSUIPC starts. Regards Pete

That wasn't the point. The controls appearing in the FS assignments are supposed to work. The ones in the FSUIPC list are all those actually present in FS's tables (in CONTROLS.DLL). A lot of those aren't assignable in FS's assignments, and there's no guarantee they will work therefore. They may be hangovers from previous versions or new ones not yet hooked up. Yes, of course. Because it represents a switch position, like the pilot holding the switch on start against the spring pressure. That same switch, when released and allowed to spring back will send abother value, meaning "Both", for example. The starter motor remains connected till the switch is released. Checking my code for FS9, I've never used those OFF/LEFT/RIGHT/BOTH/START values. I've a feeling they've never actually been hooked up inside FS, even back in FS98 days when they were added. An alternative to writing directly to the offsets which should work, though I don't know about FSX (where there's a bit of a mess in this area), would be to use the KEY_MAGNETOn_SET controls with the parameter giving the position 0-4. I just checked and FSUIPC3 uses these. I'm not sure how this relates to SpeechBuddy. Surely with that you are only seeking to replace keyboard use, so the INCR/DECR controls should be the most applicable, shouldn't they? That's what you use on the keyboard. Regards Pete

No, it means running FS, going to the FSUIPC options, pressing the "REgister FSUIPC" button, and entering your name, email and Key exactly as you did on the first computer. If you've copied the FSUIPC.KEY file into the new Modules folder you may need first to delete that before running FS. It does explain these things in the documentation. This is the relevant part: Pete

In that case there is really no way that Windows should tell my program that it cannot find the host called "MAIN". There's no way past that unless you give the client an explicit IP address (ServerIPAddr=n.n.n.n). Then it won't ask Windows to supply the address. To test the connection and the IP address you can get into a DOS box (Run, enter "Command" and press Enter), then Ping n.n.n.n See if it gets a response. If not the IP address is not accessible. It could still be a firewall problem too. Regards Pete