Pete Dowson

This is a question for aircraft designers. In FS control terms throttle idle is 0. Above 0 is positive thrust, below 0 is reverse thrust. Only 0 is idle. You want to change thrust in the aircraft CFG or AIR file, or maybe increase friction somehow. I'm not the perseon and this is not the Forum for this I'm afraid.. Note that many aircraft do in reality move with idle thrust, unless braked or chocked. The 737 is actually taxied most of the time with idle thrust, and certainly always needs brakes or chocks to remain stationary whilst engines are running. Regards Pete

No, no access, and probably not. In fact certainly not unless it supports SimConnect. Regards Pete

FSUIPC logs them, as you see, and so does SimConnect if you enable its logging. ASE for FSX doesn't use FSUIPC, which is why I suggested it for comparison, but looking at SimConnect logging. I'll try and find time to do some comparisons in global mode. It won't be today though. You could also experiment with your own METAR strings. You can write them via offset B000 -- FSUIPC doesn't interfere with those, it just sends them on to SimConnect. Regards Pete

I notice you are setting GLOB weather, not station weather. Are you definitely in Global weather mode, and did you clear weather first? I'm wondering if your weather might still be in transition (forming, so to speak). Do the clouds get drawn correctly? I've really not done much testing in Global mode myself, but it is used by several Flight Instructor programs, and of course by ASE in its DWC mode. It might be instructive to see what METAR strings it sends and what results it gets. this would have to be done with Simconnect logging, of course. Regards Pete

I am pretty sure it is correct for "A". If it is the top it would be a "D". Really? I just did this at EGCC with the EGCC METAR string in front of me and, with the smoothing interpolation taken into account, it seems correct. You don't get a precise boundary between layers of course, but a gentle change. Regards Pete

Well there must not be another FSUIPC DLL in the main FS folder either. There will never be two in any one folder with exactly the same name, but FS9 will try to load ANY DLL in the modules folder, so if you ever renamed FSUIPC.DLL (eg to keep an older copy) but allowed it to keep its DLL ending, it would be the cause. Otherwise, with Task Manager, you need to look at the Processes tab, NOT the applications one. The FSX process must still have been running in memory. You won't see it listed as a running application because by then all of its Windows have closed. It has become a hidden background task because of some misbehaving or deadlocked thread. Regards Pete

Why, when I said the complete opposite, that it doesn't matter at all? Pete

Okay. Good. In that case the most likely cause of your problem was that the SimConnect connection was being lost through timeout checks applied whilst FS was engaged in those long disk operations. The later versions of FSUIPC used a more generous timeout, and also then automatically reconnected. Logs from your earlier problems would have shown this problem, no doubt. Regards Pete

I am going by this definition in the SDK: "Format 1: This repeats the surface wind data but instead of specifying a surface layer depth it specifies a base altitude. The extension format is &ANNNNTS. Note the A for altitude instead of D for depth, and that wind altitudes are above mean sea-level (MSL). The format is otherwise the same as for surface winds, including the extension giving the depth, turbulence and wind shear" Notice that the entries contain 'A' not 'D' like the surface layer. I agree this caused confusion in the first place -- that statement completely conflicts with the 'A' definition of the format. The correct method, as used in FSUIPC, was derived by experimentation and testing, and of course by reading back the weather so written. I suggest you test this yourself. Set the weather at a station with several contrasting wind layers, then, instead of looking at the misleading graphics in the FSX dialogue (which are wrong, in fact -- they've never worked correctly), use slew to slew up into each layer in turn (use Shift+Z to check your altitude), pause and exit slew mode so the Shift+Z display shows the wind details (Mag, not True, but okay otherwise). You'll find that what is written not only accords with what is read back but also with what can be really observed in the sim, rather than in the dialogues. Remember whilst you are doing this that the wind speed and direction are both gradually changed towards the 'boundary point' to avoid a sudden transition (windshear). Again, derived from testing -- and observing the order on readback. It is correct, and obviously more sensible, to have the variance block immediately after the surface wind block. It doesn't work the way you suggest, it is ignored. Try all this yourself. Use Weatherset2 to change wind values and add/delete layers at a WX station whilst reading back the resulting METAR in offset B800 and checking the actual simulated result. I'm afraid the SimConnect WX documentation leaves a lot to be desired. By the time they came to write it up, Niniane Wang, who wrote the code, had left.the team. The reason the obvious bugs (the interpolation errors causing the exctreme wind shifts) were never fixed, even in ESP, was apparently because no one understood her code. They planned to re-write it all completely in FSXI. Regards, Pete

I don't know from what you say whether any of this has anything to do with FSUIPC or not, but it would be real easy to eliminate it -- just remove (delete or rename) your FSUIPC INI file. It won't touch any axes or buttons then. There is no such message, only one about another copy of FSUIPC being detected, nothing about duplicate folders. And that normally occurs when there's still a running copy in memory when you try to reload FS. In turn that means the previous FS session didn't terminate. It is still there, running with no Windows showing. You need to use Task Manager to terminate it forcibly. Something in your setup caused FS to hang on termination (there are quite a few add-ons which can do that). Pete

Sorry, is recognising button presses a problem now? Why? Do you want them ignored? What is "MCP747"? Maybe it isn't connecting to FSUIPC? No. I'm sure you must be misinterpreting something. There's no difference whatsoever between a line manually inserted into the correct section of the INI and one generated by FSUIPC from the options, if indeed they are identical and in the correct section. There cannot possibly be any difference, because that's what FSUIPC reads for its definitions and there is nothing else it can get that information from. See? It's a logical impossibility. I don't think the documentation will describe an impossible situation like the one you are describing. I think you should show me the non-working section and the working section. There's something you are not spotting. Pete

Well, two things wrong there: I'm sorry, that is really such an old version (over FOUR YEARS old!) that I cannot possibly support it. Please don't come back until you are using a supported version. The oldest supported version is 4.70 and the current main version is 4.745, with a 4.748 also available in the Download Links subforum. The other thing wrong is that a log showing things working fine is obviously not going to show anything wrong -- other than the ancient version of FSUIPC, that is. And I wouldn't be at all surprised if that wasn't the source of your problem unless your FSC9 is over four years old too! I really should remember to ask folks their FSUIPC version number before answering any details in the first place. It would probably save a lot of time for all of us in the long run! Regards Pete

The quickest way to find these things out is to enable Event logging in FSUIPC, then operate the switch with keypress or mouse. The control will be Logged with both number and name. Anyway, I've not checked like this (I don't think I have an aircraft in FSX with a carb heater), but I'm pretty sure it's operated by the Anti-Ice controls. If you look at the list there's a heap of these to choose from, including ON, OFF, SET and TOGGLE for all engines or for specific ones. Well that one's surely easy enough to find, even in alphabetic order -- COWLFLAPn_SET when n is the engine number, 1 - 4. Regards Pete

No. You just can't run WideClient and FS at the same time -- unless you change the ClassInstance parameter in the Wideclient.INI file. That way you can run FS and any number of WideClients together, though I can't imagine why you'd want to. Though, come to think of it, I have one client PC running three copies of WideClient -- one normal one to support applicatiions and the other two using ClassInstances 1 and 2 and supporting two separate buttons touch screens, one on pilot's side the other on the copilot's side! ;-) Regards Pete

You can use any FS or FSUIPC control, including the FSUIPC-added controls for sending a keypress. Please check the drop-down list for these: Key Press Key Press/Release Key Release The parameter gives the keycode and the shift code -- see the Advanced User guide list of FSUIPC added controls for details. Regards Pete

Sorry, I don't see one mentioned above? I wasn't referring to an FSUIPC message. If a program can't talk to FSUIPC, FSUIPC doesn't know about it so cannot report it. In that case it should always connect irrespective of the time to reload. I'm afraid that without knowing what FSC9 is doing I can't really help. FSUIPC won't be withdrawing its services unless something nasty has happened in FS -- for instance, with FSX, a SimConnect problem. But the FSUIPC log would show if there's a problem. If that shows all is well I'm afraid we'd need the FSX9 author to tell us why it cannot talk to it. So, did you check the Log after such a problem? Regards Pete

Try logging the button/key presses. If FSUIPC is actually seeing them they really must be activated. it does sound like they are being intercepted before FSUIPC gets them. Pete

Sorry, I still don't understand that. Makes no sense to me. It certainly didn't happen and wasn't even mentioned when I got my copy of the NGX, nor the SP1 update. Regards Pete

No. The email address you used looks correct as far as I recall. Pete

Ah, it's just reading the aircraft position through FSUIPC. FSUIPC does support GPS data outputs too, for moving maps, hence the confusion. So you simply mean that FSC is not connecting to FSUIPC? Does it say so? Most programs which connect to FSUIPC produce an error message if the connection fails. Strange. FSUIPC doesn't do anything particular when you load a flight. I cannot imagine why FSC should lose its connection. Maybe your system is taking so long reading the files on the flight load that FSUIPC is not able to respond in time to FSC, and it times out. But then it should either come up with an error message, or simply re-try. When FSUIPC cannot continue because of FS disk activity and so on it signals "not ready", and programs connecting to it should then allow much more time for a response. I don't know if FSC does this. I've not heard of any other users with any similar problems, so it does sound like something up with your specific installation. Check the FSUIPC log after such an occurrence to see if it is reporting any problems. Pete

A gmail address is handy, and free, but in general it is NOT a good one to have as your main address. Regards Pete

Most likely the keypress is being taken by the NGX. It seems to do that with a few. Try something other than Y. (I think it pinches G too). Pete

Sorry, I am confused. What has "GPS connection" got to do with FSC? And what are "new flights" compared with whatever else you use? I'm not sure how any of this relates to FSUIPC at the moment. Why did FSC support point you here? Regards Pete

I'm sorry but "latest version" isn't really very meaningful. All my FS software has version numbers. It is those I always need. The actual latest version of FSUIPC4 is 4.747. The latest version of PFCFSX.DLL is 4.381. See the Download Links subforum. So, what versions are you using, and where are the Logs, please? The FSUIPC4.LOG and PFCFSX.LOG will tell all. Paste them here. As I said, PFCFSX works fine here. There's absolutely no difference in its code for FSX, ESP or Prepar3D as it uses FSUIPC4 for everything. FSUIPC4 loads it automatically if it finds it in the Modules folder. Regards Pete

Assuming CH number theirs from 1, correct. FSUIPC follows the Windows API convention, numbering from 0. I know FS numbers from 1 as well. In any case you can tell which button is which by pressing them as seeing what is registered in the FSUIPC buttons & switches tab. Regards Pete