Pete Dowson

Yes. There is one. Haven't you looked? Pete

Read data on a Windows WM_TIMER message, or in a TIMERPROC routine established by the Widows API "SetTimer". As for matching it to FS's frame rate, that isn't really possible to do exactly, buty you can get close by doing something like limiting FS's frame rate to, e.g. 20 (in the Options-Settings-Display menu) and having your reads timed to happen every 50 mSecs (probably every 55 mSecs actually, as I think that's the default granularity of the Timers, or at least it used to be in Win98. Maybe it is better now). An "internal user" is one which is running insdide the FS process, so doesn't need the complexity of the inter process communication (IPC) nor the process switching. Internal users are panel Gauges and other DLLs running inside FS. Nothing has to put FS in pause mode -- there's an option in FS to stop it going into pause mode on task switch. Regards Pete

Just one clarification, in case you misunderstand. The same WideFS key will not enable both WideServer 6 and WideServer 7. You'd need to register both. Regards, Pete

Well, all the symptoms reported so far point to some sort of TCP/IP blocking going on, so it will depend on what settings folks have, what third party protection programs they've added, and so on. I've put in a request for clarification to the Microsoft FSX Team. It has to be sorted because, as time goes on, there will be more and more Simconnect client programs and DLLs and there's going to be a lot of unhappy people if there's not a way to plough through the blockages. I'll post here, and probably in an announcement, as soon as I have a decent solution back from MS. Meanwhile, all I can suggest is checking through all the possible things that may block access. Regards Pete

Somewhere way back in this thread I gave a very long folder name, so that's one way to start looking, but if I were you I'd simply use Explorer's Search facility. Search the Windows folder for "simconnect.dll". Pete

Shucks! But then I did give up smoking about 20 years ago, in any case. ;-) I have a sense of Deja Vu here, but for all my other readers, here goes ... Ah, sorry. It just looked SO unlikely. The "My Documents" bin gets so full of junk all the time anyway. Ugh. I always install in its own top-level folder: C:\FSX, or more usually D:\FSX etc -- more efficient if possible to get Windows and FS on separate hard drives, but even separate partitions on the one drive makes regular defragging much more expeditious! And then you can always share it on the Network, no probs. Must be something to do with its location (and a change in the SimConnect loader checker) then, as it all works fine in the sort of install folders I use. Certainly worth reporting, and if it is a restriction it should really be detected by the FSX installer so that you get a "can't install there" message before it does so. Regards Pete

Yes of course. That's the whole point of keeping WideFS 100% compatible! No. Why should there be? Just don't run both FS9 and FSX at the same time! Not that you'd want to (and I doubt that you can). Regards Pete

So what is the problem? Of course. Else it will just sit there looking pretty! ;-) That's what it is for. Sorry, please use RC support for that. You'll need to tell JD a little more than "it simply doesn't work" too. Not sure why you are posting that here anyway -- if you offered to test it for JD, shouldn't you be talking to him? I've run my old RC4.0 or something on FSX, but I really haven't had time to keep it up to date for weeks, if not months. When I am over this "FSX Release Rush" I wll try to get someone to put all the latest stuff on a DVD so I can get up to date. ;-) Regards, Pete

Eryou mean the FSUIPC4 option for AutoSave? Not sure what that's got to do with anything? It's dormant most of the time. Was the first one in the DLL.XML file the FSCopilot.dll? If so I'd like to find out what it is actually doing that can remove the FSUIPC menu entry. SimConnect is supposed to treat each client separately and equally, and it is SimConnect which manages the Menus. I hope FSCopilot.dll is obeying the rules and not trying to fiddle the menus directly as we had to in FS2004 and before. Is FSCopilot freely available? If so where? Maybe I could try it here. If not, could you do me a favour? Somewhere further back in this long intertwining thread I explain to someone how to get a SimConnect LOG. Could you do that, put the DLL.XML back as it was, then try and reproduce the phenomenon of the FSUIPC entry disappearing? ZIP up the SimConnect log you get and send it to petedowson@btconnect.com. Thanks! Pete

Well, it seems very strange that you have exactly the same symptoms as someone with a firewall blocking access, who fixed it by removing that block, yet yours is caused by something else. Anyway, it is certainly now a matter for Microsoft, being a problem between one part of FSX and another. There is no way I can actually debug it. I have written to the appropriate authority in the FSX team requesting assistance on this, and I hope he is returning from holiday this week. I'll get back to you as soon as I know more. Meanwhile please help by reporting your problems by email to tell_fs@microsoft.com. Provide all the details you have provided me. It all helps to get things fixed. On the other question i asked, which is probably not relevant really: Your DLL.XML contains loading instructions for the Object Placement and TrafficToolBox parts of the FSX SDK. You must have installed these. They add menu items in FSX. Are you programming for FSX, that's why you installed the SDK? It is getting very confusing here. there are about three intertwined threads! Regards, Pete

Ah, and I'm afraid I only speak English and C (well ASM too, but less and less). ;-) The settings are the same in both FS9 and FSX cases, yet you say FS9 works fine. The logs show absolutely no communication from the Client to the Server, so all I can think it can be is a firewall preventing access by the Client to FSX. It seems likely that you have given permission for access to FS9 but not FSX. So, can you check that, please? Regards Pete

What about WinXPs? Are the mission_placement and TrafficToolBox facilities working? Mind you, I don't think they actually USE SimConnect, they are simply loaded by it, so it probably isn't a good check. Yes, the log shows FSUIPC4 is running, but there simply is no communication between SimConnect and FSX. There's not even anything I can do in the program to check and report these conditions. All that happens is that it never does what i ask and I see no responses -- even errors are returned using TCP/IP, so if they're blocked, nothing at all happens. Ugh. Me too. I've written to the MS chap in charge of SimConnect to see what the best thing to do is -- if I can program a way around it I will, but it seems unlikely. Meanwhile, I think it simply MUST be some sort of firewall protection which you've not actually managed to disable yet. Please look further, see what you can find. Regards Pete

Hmm. Odd. I've no trouble with the relative path to my FSUIPC4 installed in \Modules. I don't think the path used for this is the SDK install path, it will be FSX's install path. But in Beta2 and Beta3 the SDK was automatically installed into the FSX folder, so the relative path will be correct. In the RTM version, you can install the SDK anywhere. If you didn't install it into the usual place, the FSX folder, then obviously the relative path won't work. Ahthere's your answer. Surely you haven't installed all 8 Gb of FSX into C:\Documents and Settings\Bill\My Documents\Flight Simulator X? Relative paths for FSX are relative to where the FSX.EXE is placed, which is the folder listed in the registry as "InstalledTo" for Flight Simulator\10.0. Regards Pete

I don't really know. Certainly FSX needs to talk to SimConnect and vice versa. Bt what puzzles me is that these are, of ocurse, actually part of the same process. simconnect uses TCP/IP to talk to FSX, even though it is in the same process (for a DLL in any case). I think Microsoft did it this way because it then works with external EXE programs, and across Networks, without any extra interfaces. However, it is confusing when one part of FSX cannot talk to another. I really know nothing at all about firewalls. I use a router for the Internet and leave it all to that. Every time i've tried using any type of firewall I get into all sorts of difficulties on my Network, and it really isn't worth the hassle to me. Please see the message above from Splodge, who had the exact same symptoms and fixed it. Regards Pete

Is there an FSUIPC4.LOG? Does it look a bit like the one shown earlier here? If so, can you disable your firewall? For most of this stuff I am most likely going to have to pass the problems over to Microsoft. It is all to do with their SimConnect interface and its use of TCP/IP. Pete

Ahmaybe the "trusted" block was the only one needing allowing. SimConnect doesn't need the Internet, but it does talk to "trusted" programs like FSUIPC4.DLL via TCP/IP. The thing you'll block on the Internet connection will be the weather. Regards Pete

Correct, which is why I asked for the WideServer section of the FSUIPC4.INI file. Take a look, -- I said The main files I needed to see, which you forgot, are the WideClient LOG (after all, it is the WideClient which isn't connecting, is it not?), and of course the FS9 WideSever INI so I can compare like with like. After all, the same code should behave the same given the same parameters. Please show me the files as I asked, then I'll look and try to work out what the problem is. Regards Pete

Ahit is NOT the same as that old case I mentioned. It looks like FSUIPC4 is happily running but it totally unable to get any response from SimConnect. SimConnect, oddly, uses TCP/IP to talk between itself and FSX. I am wondering if there's a Firewall problem, there, or something up with the TCP/IP installation on your PC. Do you think you could try switching firewalls and similar off (as an experiment), and also check your TCP/IP settings? I may need Microsoft help here. Ity's all getting into areas of FSX beyong my competence. Regards Pete

The WideServer log shows nothing wrong, but that's only half the story. Where's the WideClient log? Also I need to see your FS9 WideServer INI file and the WideServer part of the FSUIPC4.INI file. Maybe you are running with different settings on FS9. The Network code for WideServer 7 is identical to that in version 6.70, which is what I assume you mean? Regards Pete

Change even within the same FSX session? I can't imagine how that can happen, as FSUIPC4 (at least, can't speak for FSInn) only ever adds its Mnu entry the once. Maybe FSInn is adding and deleting its entry, and there's a bug in SimConnect which occasionally makes this affect FSUIPC4's entry too. I wouldn't be surprised -- I don't think there's been a lot of testing with multiple SimConnect DLLs running together. I have only ever had one in any case. If the FSUIPC menu stays put with the other DLL removed (just move it out of wherever it is, temporarily, or rename it), then it certainly sounds like a bug -- you will need to report the details to tell_fs@microsoft.com. Tell me too and I'll tell the guy directly. Another thing to try is adding the two extra FSUIPC menu entries -- Load Flight and Load Plan. The options for these are in FSUIPC's Miscellaneous page. See if those stay put, with and without FSInn. That's for the Aircraft Specific axis assignments problem, which you say you can't reproduce? Could it possibly have been finger trouble at all? Regards Pete

Well, that's short and sweet! It definitely shows SimConnect loading the DLL, but it doesn't then actually call the entry point to start FSUIPC4 off. It is supposed to call a routine called "DLLstart" in FSUIPC4 -- everything kicks off from there. Is there an FSUIPC4.LOG or INI file in the Modules folder at all? It doesn't look likely, but if there is can you show it to me please? I recall one (and only one) instance like this in the FSX Beta test group, several weeks ago. The SimConnect author in Microsoft was looking into it. I'm not sure whether it was ever resolved, I've a feeling it wasn't. I'm going to try searching for it now. Regards, Pete

Thanks for letting me know. Sounds like the switch was faulty. I have a couple of DLink switches and they work fine. And it won't be a speed problem -- if anything the simple hub will be slower, though with only two PCs a switch is overkill. Regards, Pete

Erthat all works fine here, and there's no relationship between anything in the INI file and the "Add-Ons" menu, which is created by FSX when FSUIPC4 starts. I need more information please. Your INI file, and a LOG for the sequence with the specific assignment not working. If you've deleted and lost the INI file for the problem and cannot reproduce it then I cannot even start looking at it. :-( Pete

Is there a Modules folder in your FSX installation, with FSUIPC4.DLL included? If so, please right-click on it, select Properties, and check that it is Version 4.01 and has my Signature attached. What Windows version are you using? Hmmmnot sure. Maybe you accidentally told it NEVER to run programs by me instead? I'm not sure how to find out or how to reverse it if so --- those checks are imposed by Windows following calls to check the modules by FSX's SimConnect. However, I think it should be possible via Internet Explorer (for some reason IE is what Windows uses to manage these things). Do this: 1. Load IE, select Tools - Internet Options - Content. 2. Click the "Publishers" button. 3. You should now see tabs for "Trusted" and "untrusted" publishers. See which one I'm in. 4. If I'm not in either then your choice wasn't logged, so you SHOULD get the warning next time you run FSX. If I'm in the Untrusted list, Remove me from there. If I'm in the Trusted list, then, wellwe need to look further. If everything so far checks out I'll probably have to ask my SimConnect contact in the FSX team -- he's been on holiday, but I think he's back this week. There are two other things you can check, but a little more difficult that those you've already done: 1. In the same folder as your FSX.CFG file (Documents and Settings\\Application Data\Microsoft\FSX) you should find a file "DLL.XML". If it isn't there, that's the problem. Maybe you installed FSX and FSUIPC4 under different user names? If it is there, Open it with Notepad and look to see if it mentions FSUIPC4 at all. If you aren't sure about all this, ZIP it and send it to me at petedowson@btconnect.com. 2. You can get SimConnect itself to do some logging which may show why it isn't loading FSUIPC4. To do this you'll need to create a small Text file (eg in Notepad) containing: [simConnect] level=Verbose file=\Modules\Simconnect%01u.Log file_max_index=1 Fill in the folder stuff, then save this as "Simconnect.ini" in your "My Documents\Flight simulator X Files" folder. Now, when you run FSX, SimConnect will log all sorts of things to a file "Simconnect0.Log" in the Modules folder. ZIP it and send it to me. Then delete or rename that Simconnect.INI file. Otherwise, when we do manage to solve your problem, the files will become HUGE (and I mean HHHUUUGGGEEE) with all the FSUIPC4/Simconnect interaction. Yes. Always best to install, check, then pay, really. We'll sort it out though. Sorry it's so complicated. This is all imposed by Microsoft, it isn't my design. And I am informed it gets worse with Vista. More red tape than the tax man! Regards, Pete

Do you really mean PFC.DLL -- on FS2004? Or are you still talking FSX and therefore PFCFSX.DLL? If the latter, please re-test with FSUIPC4 version 4.01. You know you can copy over your FS2004 version of PFC.INI into the FSX Modules folder and re-name it PFCFSX.INI, don't you? Then everything should be the same. But please use FSUIPC 4.01, and keep an eye out for further updates. They are bound to be quite frequent in the early days of FSX -- after all I've only had the Release build of FSX for a little over a week myself! Regards, Pete