Pete Dowson

Yes, I found it. The reason I didn't recognise it is that it isn't defined in SimConnect, but in a standard WinError header file! So, yes, you are rightit simply means "an error has occurred"! How naff! :-( The SimConnect author merely agrees that the SimConnect error reporting needs improving. He cannot say what the error is yet. Of course. There's no way anything I can change in FSUIPC can get around the fact that SimConnect is simply refusing to connect. "ASL"? I don't use the expression so I don't mean anything. What does it stand for? Looking back on your previous report, I see you've created a SimConnect.XML file for remote use of SimConnect, but in that you have not allowed the default local use. I think that is the problem. If you don't have that file (rename it for now) I think FSUIPC will work. Seems that SimConnect assumes the local connection by default if you omit the file, but if you are explicitly listing connections you need to list the local one (on 127.0.0.1 I think) as well, else you won't get one. Daft I know, and I only discovered that through another user recently -- there's a thread here about it somewhere. Regards Pete

I've never heard of that before. Is FSUIPC the only file you've added to the Modules folder? Is there an INI file? Is there any FSUIPC Log file being produced in the Modules folder? There's no reason why it should help at all. Nor has any one else to my knowledge. Regards, Pete

I think it probably needs registering with Windows somehow as well as simply "being there". Good. Thanks for letting me know. Regards Pete

Yes. That is what it is for. Set everything up the way you want it, save the flight, then apply the lock. Good, shows it works! Wish I could get it working on FSX. :-( Regards Pete

Why did you uninstall and re-install FSX? Sounds like something went wrong. That message happens if either SimConnect is not installed, or the wrong version is installed. If this is the case then FSUIPC4 could not operate (nor could any other Simconnect client) even if the Installer did continue. There's been one reported incidence before of the FSX install not installing simConnect correctly. The user got that sorted eventually by contacting MS tech support and getting detailed instrcutions for a manual install. It can be done that was but it is messy. First, do a search in your Windows folder for "Simconnect.dll" -- make sure you tell Explorer's search to look in hidden and system files/folders too. It should be found in a folder lke this: C:\Windows\WinSxS\x86_Microsoft.FlightSimulator.SimConnect_67c7c14424d61b5b_10.0.60905.0_x-ww_429211e9 If it isn't, then the FSX install went wrong. You'll need to find the SimConnect.msi file on your FSX DVDs and execute it to install SimConnect properly. Regards Pete

No, it is completely different. Have you by any chance enabled the Miscellaneous option in FSUIPC4 to allow FS's own weather to be modified? That can do it. There are bugs in the SimConnect facilities to control weather in FSX and this is one of the nastiest. I reported it duing the Beta. It produces some very weird effects on screen. If you know how to reproduce it, just before doing so enable the Weather logging in FSUIPC4. Check the METARs being logged afterwards. The ones that are returned are influencing the ones that are sent back, esepcially if you use that Miscellaneous option. And not only are the reported ones wrong, the ones sent back aren't actually obeyed correctly. This is why I recommend not using it for the time being. Regards Pete

Two things to note there. 1. 50 fps for Widefs is very very high for an average. What sort of super-processor is ther Server? What is your FS frame rate limiter set to? 2. Have you tried using UDP protocol at all, to see if it is something in the TCP/IP part of the Windows drivers? You say there's no apparent latency in the actions on the Clients, so it isn't queuing problems. I can only think that somehow the Network parts of Windows, on the Server, are getting far too much of the processor time. Can I see the INI files too please? There are parameters which can slow down WideServer, but there's not been a case needing their use in many years. I must admit never to having seen a case quite like this before, not in the seven years or more of WideFS! It's rather puzzling. Regards Pete

Well, that's really weird then, because that's al it needs for the installer to find FSX automatically. I use exactly the same standard Windows calls as all other installers will, so I think you will have problems with any other add-ons you try to install in future. If that didn't change the registry entry it shouldn't matter. You ARE installing FSUIPC as an administrator, aren't you, or a user with Admin privileges? I wonder if IE7 might change some of those types of settings? Who's we? It's only you at present I think. I can email you 4.031 not 4.03, but I still think you need to try to solve the problem. Regards Pete

Hi Thomas, Why? None of these symptoms indicate that. Have you found out something else? Regards Pete

Erthat only happens if BEFORE that it comes up with ann Explorer type window saying: "FSX not found! Please locate and 'open' FSX.EXE:" Did you do that? Did you find the correct FSX.EXE? (Of course there should only be one). If you had to do that then the registry entry for the path is wrong. What may have changed on your PC between the two installs? Have you by any chance rolled back Windows registry? The correct Registry entry is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 with "SetupPath" containing the path to the FSX folder. It sounds like it was looking in the wrong place altogether then. Please check that Registry entry, and tell me exactly what you did, step by step. Something is missing here, including a very important step of FSX.EXE location. Regards Pete

It calls FSUIPC to supply it with data, such as aircraft position, etc etc. That's the whole point of SimConnect. If it isn't supplying data as requested it isn't doing anything useful! The difference between SimConnect's way of doing things compared to the way FSUIPC used to operate is that it operates in a Server/Client manner. FSUIPC initially tells it what it needs, then whenever that information is available and changed, SimConnect supplies it without being asked again. This is done at most once per frame for things that need closer monitoring, once per second for other stuff, at most (they still have to change). FSUIPC3 and earlier didn't have SimConnect to do this for it, and just obtained information on every single frame, whether it had changed or not. The rather disappointing thing about SimConnect from my point of view that it uses TCP/IP to talk to FSX even if the client is actually inside the same process as FSX, as FSUIPC4 is, of course. To me, that's a big unnecessary overhead, and I am still remonstrating with MS about it. If you want a more informative way of seeing what is going on between SimConnect and its clients, try using the SimConnect logging. You may find it very interesting. See my replies in the thread below about GPSout problems to see how to make it produce a detailed log. Regards Pete

Thank you for the confirmation. It seems it is likely related to the SimConnect start-up problems already reported. Whether there's a separate solution which can be implemented in the GoFlight driver, I don't know. Hopefully, if the appropriate information is sent to GoFlight, they can also work out a way to avoid the problem. Since in this case it is the EXE crashing rather than FSX itself, it seems that a programmed recovery should be possible. Regards Pete

Me too. I tried to implement it automatically in FSUIPC4. But I can find no reliable way of getting a notification of closure early enough to actually successfully ask SimConnect to save a flight. I even looked to hack into the same routines in FSX as I did in previous versions to call the Save Flight actions directly, but things have changed that much I didn't find them. I've put in a request for a more advanced notification from SimConnect. Yes, and this is why it wasn't a problem for Doug when he was testingthe normal timed saves of AutoSave aren't the problem, it is the default flight loading in mission mode. I can't see a logical solution to that unless either FSX comes up with a prompt on such a load ("do you really want mission mode?"), or there's a way of detecting mission mode from SimConnect. Thanks for the clarification. I'll tell Doug too as i think he'll be writing this up in one of his articles. Regards Pete

May be making it the default flight triggers this behaviour. Ahactually I didn't read that as part of Joshua's problem with AutoSave. I assumed that was referring to a parallel but distinct problem. Naturally if the "Also saved" flight option in AutoSave is used to create a new default flight every so many seconds then, you are right, it is the same problem. Loading a flight with mission mode status obviiously enters mission mode (as would be required), so having one saved as default would logically generate the problem Joshua sees. Doug replied to me when I asked him about this, saying it hadn't been a problem for him -- so I guess that is the difference. Joshua, is that so -- are you using the "also saved" flight for your default flight? If this is the problem then, yes, it would be nice to be able to detect mission mode (I don't know how at present) and suppress just the Also Save action, but still retaining the normal timed saves. Thanks & Regards Pete

That sounds as if, with FSUIPC4 now delaying its initialisation to avoid the serious crashing of FSX when two or more SimConnect clients are being loaded together, it is clashing with Goflight's initialisation. Does the Goflight program generate a Security Warning dialogue at all? These sorts of SimConnect problems have been notified to Microsoft and we are awaiting a solution. In the meantime it would be best to avoid running your GDDevFSX.exe program until AFTER FS is loaded and ready, or at least until the loading progress bar is well past its half-way mark. Regards Pete

The Microsoft guys have reproduced the problem and are trying to work out a solution. It seems that it only affects a SimConnect client which is open at the time you switch to MP mode. If a client is started AFTER you switch it works okay. That suggested a work-around, whilst we wait, possibly a long time, for an official FSX patch. I can detect a period of non-receipt of data from SimConnect, and then close the SimConnect connection and restart it. I've tried that here and it works. It does cause a few seconds extra delay at the start of the MP session but I think it would be okay as a temporary measure. If you like I can send you an interim test version of FSUIPC4 to try. Let me know. It would be tomorrow (Wednesday) or Thursday. Regards Pete

If it only happens when you run your program, how could it be anything else? If you are writing stuff to FSUIPC and want me to check any of it, enable IPC write logging and show me the log. Then maybe try a binary-chop search on your program -- i.e. eliminate half the things it does and narrow it down that way. Regards Pete

What red background? The text appears in red over whatever's there. I'm sorry, I really have no idea how your program is doing this. What does it do? Is is related to FS or not? Why are you running it with FS? If it is using FSUIPC and writing to unknown parts of FS it could do any sorts of damage. Perhaps you should say more about your program which is causing this? All you've told me so far is "I built a program and while its running all the red text bars (like: Pause text, Parking brakes, SHIFT + Z bar, Sounds off etc) just doesn't show. ". Don't you think you ought to start dissecting your program to see what it is your are doing to cause this to happen? Maybe it is doing something you didn't intend? Pete

That's very strange. Can you try and get a Log of each for comparison -- actually two logs, an FSUIPC4.LOG and a SimConnect log. For the latter you need to create a text file containing just these lines: [simConnect] level=Verbose console=No file=\Modules\SimConnect%01u.Log file_max_index=9 where you of course replace with the full path to your FSX installation. Save this as SimConnect.ini in your "My Documents\flight simulator X files" folder. Then, keeping things a short as possible, run FSX, see if you have the Menu entry or not, then close FSX. If you could do this once for when there IS a menu, and onvce when there is NOT, possibly the differences may be indicative of something. For each of the two cases, Zip up both the relevant (latest) SimConnect log and the FSUIPC4.LOG, identifying which pair is which, and send them to me at petedowson@btconnect.com. Are your pedals calibrated via FSUIPC4? If so that would explain it. If the Add-Ons menu isn't appearing FSUIPC can't do these things as it means Simconnect contact with FSX is broken. No, but it just has to be related to firewalls or privacy settings somewhere. Regards Pete

On the first point, did you see the important note in the documentation? NOTE: This option does not work if you have your Windows’ Display Properties set to “show window contents while dragging”, in the list of options in the Effects tab. FSUIPC then has no chance to prevent the re-draw On the latter point, the only time sync FSUIPC offers is to keep the seconds number in line with FS's. Any minutes or hours difference is not corrected. So, unless you go into menus, or pause, or use different Sim Rates, it should stay in time, but not otherwise. But once it's a minute out, it stays a minute out and so on. It only stops the annoying gradual drift whilst flying normally. This, also, is documented: It just synchronises the seconds values with that of your PC’s system clock. If you want a more comprehensive time synchronisation you need something like Joshua Robertson's "FSRealTime" program. That's what I use. Regards Pete

The last paragraph Pete was exactly of what I am trying to do. This is where I am lost And where, exactly, in the User Guide are you finding that paragraph? It in't IN the User Guide!! Why don't you refer to the User Guide -- it is part of the package supplied with FSUIPC and it is your main reference! If you look up Joystick Calbration in the User Guide, which is what you should have done in the first place, then following the numbered steps for proper calibration (steps 1 to 11, including pictures of the slopes options) there are a series of bulleted OPTIONS you can apply. The two you are interested in are in two of those bulleted options. How come you didn't find them? The idea of bulleting things is so you can skim the first few words to find applicable entries. Surely the very words "If you have twin throttle levers ..." at the beginning of one would have caught your eye, if you'd actually looked? Every option in FSUIPC's option dialogues has a section or paragraph explaining it, and, on the whole, I think the layout follows a logical order. You should calibrate then apply the options. This is why the calibration steps are there, followed by individual instructions on each option you may want to apply. PLEASE do refer to the User Guide. I don't understand why you are quoting out of some different document altogether. Your quote above sounds like something from a list of features, not the guide!!! :-( Pete

Strange. So the same would happen to anyone, not an AutoSave user, who just happened to save a flight during a mission? I would have thought that a common thing to want to do, especially in longer ones (or are they all short?). I'm surprised that Doug didn't mention this -- he's writing a review I think and mentioning the autosave as a useful feature for missions to. I'll ask him how he worked around the problem. Anyway, I'd be glad to provide an option to automatically turn off the feature during missions if we can find a way to detect when missions are started and ended. Do you know of any way to do that? Regards Pete

Why? That is a list made by WideServer so it can number joystick nuttons sent by Clients consistently, that's all. You never need nor want to edit it manually. It doesn't make WideServer actually do anything. There's no file used by WideFS actually called "wideFS.ini", and you had ServerName set before in the Wideclient.ini, didn't you? Haven't you yet tried setting the ServerIPAddr parameter? But is the client still saying that Windows says "Host not found"? There is no way WideFS can make such a report up. The error number 11001 comes direct from Windows. It means Windows is not able to return an IP address for the computer name "MAIN". But you can bypass that by giving it the IP address yourself. I think you need to show me both your WideServer.INI and Wideclient.INI files. I've no idea what you've actually changed now. Better show the latest Logs too please. Pete

Okay, but no need to send me anything. I reproduced it here straight away. I've never used multiplayer before, but I simply started a session as Host for a shared cockpit, here on my one PC, and I could see immediately that SimConnect stopped sending me any data -- EXCEPT oddly enough it still sends me the regular Frame events (i.e. it tells me another frame has happened so I can do other stuff -- like still send GPS data which, of course, isn't changing now! :-( I can also read the weather, but for all intents and purposes the main functions of FSUIPC, to supply data to client programs, has been killed. I am sending the data on this directly to my contacts in FS. Please, you report it too. Send the description, with the SimConnect Log, to tell_fs@microsoft.com. The FSUIPC4 log isn't needed, the SimConnect log shows it all. I hope they fix this soon -- it effectively means that no SimConnect add-ons can be used with what is one of FSX's main attractions -- shared cockpits, shared skies, etc. :-( Regards Pete

I managed, eventually, to get this to happen with 4.026 here, but it isn't consistent. I don't know what is (or rather was) causing it, but please go get 4.03 now available above (and tomorrow from the Schiratti page I hope). The code in the installer has changed quite a bit since 4.026 and i cannot make this problem occur any more. Please try it and let me know. Regards Pete