Pete Dowson

That's from your FSX.CFG file. I didn't want to see that at all. Only the DLL.XML file which is in the same folder. However, I do notice that FSX seems to think it is loading both FSUIPC4 and FSCopilot: X\Modules\FSUIPC4.dll.zqlwhweqrliokbczhiotiuuriaebcklrnlcerioo=1 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\Modules\FSCopilot.dll.uuallbheqrrraequbanlklraletqtkaqqowakhnk=1 But isn't that only an installer? The "FScopilot" I am aware of is an FS DL, it can't be "run" by you, only by FS. Okayso FSUIPC and FSCopilot are both running. That is entirely a different matter. In that case, none of this is really anything I can help you with. There's obviously no problem in SimConnect, and FSUIPC has nothing at all to do with Internet or chat or any of that. I'm afraid you do really need to get support form the FSInn folks. Regards Pete

sounds like it should be! ;-) Thanks & Best Regards Pete

Yes, goodbut of course it is impossible to derive anything from that which points to whatever it might be causing the problem. I really hate that sort of thing! Best Regards Pete

That is something impossible to imagine if the files were identical. If they are not, what could possibly be changing them? Okay. That sounds more reasonable. I'll keep it open. Regards Pete

How do I tell? Not sure. If you haven't assigned fixed IP addresses to each PC (recommended), so don't know what you are using, then I assume you should be able to find out by looking in the Network configuration of your Server PC? Pete

I'm afraid, then, it becomes a matter for Microsoft support. Regards Pete

Odd. Sorry, there have been no other such reports, yet. I can only suggest reducing the 5.0 turbulent wind speed rate in the INI. Or suppressing turbulence altogether. Even those flying the originally sensitive PMDG 747X are now finding it okay. Regards Pete

But if "rebuilding" the INI fixes things, albeit temporarily, surely something, something unknown,must be changing the INIwhat and how? Obviouisly 2rebuilding" a simple text file to be identical to what it was before cannot possible make any change whatsoever. That being the case, we need to track down wehat is changing it. And to do that I need to see your "working pristine rebuilt INI" and your "old corrupted original INI" to see what has been changed. Do you think you can show me such a pair? Regards Pete

There's a slider in FSX's weather settings to control the rate of change in the weather -- the "dynamics". Changes cannot be turned completely off, only slowed. Since you may be clearing the weather because you want it to stay clear, or because you want to set up some specific weather and not have it change on you, the option is offered to move that slider to its minimum. Unfortunately it isn't possible to stop all changes. You didn't need to add those yourself, those are the default values it sets in any case. Good. Thanks! Pete

As I said, I was most surprised at the odd initial arrangement you stated before. Having a normal start of no traffic except Ships seems extraordinary, and it is probably wrecking the calculations. I'll look at that. But I would say that you are likely to be the only person in the world which such a strange configuration! Correct. No, not at all. The GA is on the same status as Ships -- it is not treated any differently at all. The only thing I suspect it needs is for all of them to be non-zero or all zero, to start with. The problem is probably in the odd arrangement of their being no Airline traffic for it to maintain in proportion with the others, in your unusual starting arrangement (effectively you have infinitely more ships than anything else). It looks like a special case, that's all. I'll look at it when I get time. But i'd be interested in why you have only ships and nothing else to start with? No, I don't get that happening here. It only uses the original value if your parameter is zero. I don't understand why it is different for you. :-( I can't handle anything which isn't "AI" (i.e. operated to a plan and a shedule. The others don't, the are just moving graphics effects, not AI traffic at all. I have no idea how to hack into the grahics stuff. I only did it for AI traffic. Sorry. Well, as the whole point is for performance adjustment, and Ships, in places where there are ships, are each almost as costly in performance terms as AI aircraft, I think it right to include them. I would like to include the two graphics effects, but i don't know how. I'll recheck your "100 means 75" assertion, but I'm pretty sure it worked fine here when I checked before. But certainly I need to look at the 0 airline, nonzero ships (or GA). That's probably messing the calcs up. Regards Pete

This is because it really cannot be an INI file problem, but must, I think, be a device problem. The INI file parameters for your calibrations are really just very simple limit values, and they aren't going to suddenly change, or correct themselves simply because you nudge an axis. The fact that nudging the axis does fix the value really indicate that some spurious value has arrived for it beforehand. FSUIPC will only ever act on a joystick input value when it sees a change occur, so FS initial values will be left as they are until you move the axis. This does mean, of course, that the values in FS may not initially accord with the placement of the levers, not until you move them -- this is why it is important to save flights with predictable axis settings (like idle for a parked aircraft). I could, I suppose, make FSUIPC always send a "zero" to FS for all the axes it is responsible for, on first loading, but I feel this is not really a good idea as your startup flight might really need it someplace else. It shouldn't really do anything until asked to act on an input change. Anyway, I've made a note to double-check all this, to see if there's any odd initial condition which can arise -- this can of course only happen once, on FS first loading, in any case -- certainly not on an aircraft loading subsequently -- unless, possibly, you are assigning different axes for different aircraft, so previously unseen axes can suddenly "join the party"? Maybe FSUIPC should deliberately discard the first so many seconds worth of joystick values it sees, afterafter what, first loading? First seeing this axis? Maybe some extra clarity as to exactly WHEN this problem occurs is needed first. The title of the thread suggests startup of FSis that right? Only at FS startup? If not, when, exactly? Another thought. Possibly they are USB devices and you have Windows cutting power to them when there's no action on them for some time -- go to the device manager and make sure you have power management switched off for all USB hubs, every USB place where there is such an option. Regards Pete

I assume this is not with the fixed version 4.253 I posted this morning? It has the relationship between the Airline and other sliders working I think. That's an odd starting set! I must admit I've not tested with that sort of arrangement! Yes, I think that would be correct with the bug I mentioned earlier, now fixed. Yes, correct. Good. So that confirms it - the toggle is working perfectly on the Airline slider (which is what I found, and what I didn't understand about your earlier report where it didn't), and the other sliders getting stuck on zero is the bug I described to you earlier which I think I've fixed in 4.253. Thanks! Better download 4.253 now. If you find it still wrong, let me know, but it seems good here. Best Regards Pete

Yes, the FSX downloaded weather is usually pretty good. I use ASX which I think pays a lot more attention to correct temperature gradients and upper winds, and combined with its graphics counterpart it produces some gorgeous skies. Good, I'm glad it's coming together! Pete

1.0,5.0. Yes, because you set it to 5.0, remember? If there's only one number it replaces the default in that position. Unless I change the names of the parameters each time I change defaults, I'm afraid any previous user values stick. Regards Pete

Those two statements sound totally contradictory. How is it "more stable" if you get such sudden banking all the time? I don't understand how you could report both at the same time. Maybe the wind speed factor is too high at 5.0 -- that is 5 times what it was in 4.251, so I would expect it to be worse, not better. Can you clarify -- is it turbulance tipping the aircraft, or something else? If it was with turbulence, try reducing the 5.0 value, the second in the TurbulenceRate= parameter. Pete

Really? I don't remember that! Maybe you are confusing the job of "WeatherSet" which is a test program for the FSUIPC Advanced Weather Inteface (AWI) for FS2000 -- that one deals only with global weather setting. Then there's WeatherSet2, for the New Weather Interface (NWI) which can deal with local weather stations on FS2002 and FS2004. They both sort of work with FSX, with qualification -- FSX tends to take over and do its own thing no matter what you do through these little programs. The main weather interface into FSX now is via SimConnect. WeatherSet and WeatherSet2 are both available in the FSX Downloads Announcement, above. Regards Pete

Well, if you've run FSX there must certainly be an FSX.CFG. Didn't you look in the right place? (Documents and Settings\your user log-on name\Application Data\Microsoft\FSX, on XP, somewhere similar on Vista. Okay, so at that time the DLL.XML was okay. How did you run that? I thought it was a DLL running inside FSX? Right. I am obviously misunderstanding something then. What is "text chat for ATC"? Is that something in FSX, or in FSCopilot, or something outside of FSX? Are the Add-Ons menus you expect to be present in FSX there or not? It is sounding like this is nothing to do with FSX or FSUIPC, but to do with FSInn. Have you asked their support? I really know nothing at all about these on-line programs. When you first asked here, I thought you were saying FSCopilot wasn't running, and the most obvious reason for that is that the DLL isn't being loaded into FSX -- and that is the job of the DLL.XML file, as it is that file which tells Simconnect what to load. That is how FSUIPC4 gets loaded. Regards Pete

I've never actually seen a connection timeout reported by Windows. Something is blocking it for sure. Don't forget firewalls and things may be operating on both ends, stopping either direction. Here the Client can't get through to the Server -- but it could be either the Server stopping access in or the client stopping access out -- or something in-between. All WideFS can tell is that Windows wouldn't connect after trying for whatever time it tries for. WideClient will continue to quietly retry at several second intervals, just as it would do if waiting for WideServer to start. Sorry, I have no other ideas than a firewall block of some sort. I assume you've left the INI files to default? Is that IP address it has been given (192.168.1.84) correct? Regards Pete

Aha! That explains it all. Thanks! Pete

If you are talking about the INPUT value, that isn't FSUIPC calibration, that's the value being received from the levers. If they don't change in your 'red' area, that because that are isn't part of the hardware axis range. If you mean the OUT values don't change, but the IN values do, then you can most certainly calibrate in FSUIPC to make use of that red zone for reverse thrust adjustments. You have to calibrate the "idle" at the top of the zone, so that there's a gap in the values between minimum (max reverse) and the lower of the two central "idle" values. Regards Pete

Sorry, there should certainly be no difference to any other program between using FSUIPC 4.20 or 4.25. You didn't delete anything before installing FSUIPC4.25, did you? Check your DLL.XML file -- it is in the same folder as your FSX.CFG file. It is a text file so you can paste is in a message here if you like. Maybe it wasn't quite right before and when you ran the FSUIPC 4.25 install is stopped the FSCopilot section, though there's no difference in that part of the FSUIPC4 install process. Maybe you installed FSCopilot after 4.20? If so, have you tried just re-installing it? Regards Pete

That's very strange. All it is doing when you have made changes to the options and closed the dialogue is to re-write those parts of the INI file which have changed. Then, to keep its internal tables exactly in line, it reads some of the sections back. For any changes in Joysticks, Axes, Buttons and Keys, the whole section is normally re-written, to keep everything internally totally efficient. To do this disk access it calls Windows own "profile update" APIs. The only thing I could think of slowing it down is Windows disk access during that exercise. Five minutes seems totally extraordinary. A few seconds is the maximum I've ever seen. Could it be that your disk is getting full, or is highly fragmented? Could there be something else in your system getting in the way at all? Is this on a WinXP or Vista system? I've noticed on Vista even simple file copying or moving using Explorer can sometimes take minutes, making it look as if Explorer is hung (sometimes it IS explorer hung!) -- I think this is supposed to be a known issue fixed in Vista SP1. Whatever it is, it is certainly related only to your FSUIPC4.INI file and its placement, because there's nothing else going on between you closing the options and normal simulation being resumed. Since it is related to your INI file, maybe you could Zip it up and send it to me at petedowson@btconnect.com, so I can try it here? Yes, they are fine. But as another test, please enable "Extras" logging. Then it will also show the time spent "stopped". Regards Pete

Arrggghhhhhumble apologies. I've just found a "little" bug. :-( The TurbulenceRate was only affecting the direction of the winds, not their speed. So it isn't so surprising that it didn't make much difference. Terribly sorry for wasting some testing time. I'm working on it now, but I also need to make the wind speed changes proportional to the wind speed -- you can't have 40 knot changes with a 5 knot wind! ;-) I'll see if I can get a new version uploaded tonight. Otherwise it might not be till late Monday now. I have guests this weekend. Best Regards Pete

Actually, I just did this and I see one error. I had Ships at 20, which it correctly set to 0 on the first toggle, but the second set it to 100 -- it sohlud have maintained it in porportion, so, since I started with 100 : 20 it should have restored the 20. I'll find out what's gone wrong there. But: Looks like the Ships one was correct, and the others weren't. But, sadly, I cannot reproduce this problem here. The toggling between 0 and 100 works every single time I use the toggle. So, it looks like I need to ask you to dig further. First of all, to guard against double-activations, could you do two things: first, enable both button and "Extras" logging (in the Logging tab), then repeat the test. Show me the log. Then try testing it as I have been doing, by assigning a keypress (in Keys) instead. Well, the latter is the only bug I've found so farI'll fix that anyway, but I need to understand why your system isn't "toggling off" after 2 togglings. Regards Pete

Okay, first off 4.20 is out of date and unsupported. You should be using 4.25 at least. Second, this error: Checking compatibility with installed SimConnect: ... Probe Manifest fails to match a valid base SimConnect needed to load FSUIPC4! is very serious. It means your installation of FSX is corrupted. Have you been uninstalling and reinstalling it or moving it about? The main part of SimConnect, installed with the original DVD copy of FSX, is missing or wrongly installed. If you have the DeLuxe version of FSX you can try re-installing just the SimConnect from the SDK on the first DVD. You will have to install the SDK first, then find the "SimConnect.msi" file in the "core Utilities" part. Execute the SimConnect.msi and it should re-install the broken part. (Note that if you are already using the SDK, and have installed the SP1A SDK to match your SP1, then you want the RTM version of SimConnect.msi form the appropriate SDK folder). If that doesn't work, the only other way I know to fix this is to first uninstall SP1, then delete the bad WinSxS folders, and then run the original FSX installer to repair it. Test it. If it is then okay you can reinstall SP1 and re-test. Please refer to the "FSX Help" Announcement above. It tells you where the folders to be deleted are. Note that if you are using Vista you will need to run Explorer "as Administrator" to get privileges enough to do this. Regards Pete