Pete Dowson

I'm afraid the case here sounds like too many programs confusing things. I don't know why, but CH users get into all sorts of trouble with interaction between CH Manager, FS itself, and FSUIPC. Why not just use one? Try deleting the FSUIPC INI file (from the FS Modules folder), so that FSUIPC is doing nothing. THEN re-enable everything in FS Assignments, making sure all Sensitivities are max (right-most) and all null zones are at minimum (left-most). That's FS sorted. Now you only need to calibrate in either Windows Game controllers or CH manager (or both -- sorry, I don't know CH stuff). Get it working as close to what you want that way. If you then want to make use of extra trickery in FSUIPC, come back and we'll deal with that for specific needs. If you don't do things step by step, with three programs interacting on the same axes, you will confuse yourself and the programs.. Pete

Sorry for the delay -- as announced here, I have been on holiday. Sorry, I have no hints specific to either -- it is not possible as I have no such equipment. Whatever specific hints you found are from other (real) users. However, in general a joystick is a joystick is a joystickThe main discussions regarding CH stuff was whether or not to use their "CH Manager" software instead of or as well as FSUIPC. I suspect you don't have that complication with Saitek. Regards Pete

Sorry for the delay -- as announced here, I have been on holiday. Have you tried enabling IPC read/write logging in FSUIPC's logging page, to see what is happening? This is why such debugging facilities are provided. Always state version numbers when asking for support please. Also, are you using the supplied library or using your own code? I am not sure what programming differences there are for Services. Regards Pete

Actually, FSUIPC has long provided the full path to "where FS will save flights", which is the default PLANs folder too -- see offset 1000. The path is provided in UNC format when appropriate, so that it can be used from WideFS client PCs too. Regards Pete

Sorry for the delay -- as announced here, I have been on holiday. Of those I know FS commander can work on a Wide client PC, but I expect it still needs direct access to your scenery folders etc on the Server, for its data base etc. Maybe there's a user group providing help with that? ASX certainly doesn't use WideFS at all. I don't know about the others I'm afraid. No, both your Server and Client logs show all is well. There are just no programs asking them for information, that's all. In later messages you say: I suspect the FS9 version uses WideFS, but possibly the FSX version is using SimConnect, like ASX? and ... If you mean WorkGroup name, it isn't strictly necessary, but it makes life a lot easier as two computers in the same workgroup share things better and receive broadcasts from each other -- making WideFs parameter free to install and run. I see you got around the failure to broadcast by specifying the Server name in the Client, which would otherwise be unnecessary. There was nothing wrong in your first logs, only the lack of any program trying to use it. I suspect that only FSC uses FSUIPC and that you need to do some other configuring in FSC first -- as I said, it probably needs pointing to certain folders on your Server. Regards Pete

Sorry for the delay -- as announced here, I have been on holiday. "Autopilot disconnect" is the same, in FS, as switching the A/P off (0 to offset 07BC). There's no separate switch. Pete

Sorry for the delay -- as announced here, I have been on holiday. It works fine here. Have you checked it with FSInterrogate? I think you must be doing something wrong. Please use the IPC read/write logging (Options Logging page) and check the log. Show me if you don't understand it. If means that when you change that offset, FSUIPC4 has to see that and send a normal FS control (PAUSE ON/OFF or TOGGLE, whatever) to FS to make it work. SimConnect provides only a reeadble value,m not a writeable one, so this is forced on FSUIPC. If you enable Event logging to you will see the event/control being sent. Note that only current versions are supported, so if you are not on at least 4.28 please update first. Regards Pete

Sorry for the delay -- as announced here, I have been on holiday. FSUIPC doesn't change things by itself. As far as FSUIPC is concerned, there are the on-line options showing these things, page by page, 4 axes to a page, or, if you want to try decoding the numerical parameters, there are the sections in the INI file. Well, without specifics I cannot really help. Things are logical, and as documented. Maybe you are confusing settings which you have made for specific aircraft? Just delete the FSUIPC INI file, or just the JoystickCalibration and Buttons sections you don't want. Regards Pete

Sorry for the delay -- as announced here, I have been on holiday. If you are disabling the input via offset 310A, then, as documented in the write-up for that offset, the value which would otherwise have been used is readable in the offset range 3328-3339. The whole process is supported for fly-by-wire intervention. Regards Pete

Sorry for the delay -- as announced here, I have been on holiday. Not that I know of, but then I have no idea how Windows or Vista number the joysticks, I just retrieve the number assigned. I suspect that you may need to either uninstall them all, then reconnect in the desired order -- or, of course, edit the numbers in the FSUIPC4.INI file. Maybe, if this is likely to be a recurring thing, I can look at having a mapping facility to do the INI editing for you. Regards Pete

Sorry for the delay -- as announced here, I have been on holiday. Yes, it almost certainly would cancel it. Try using the wind smoothing recently added to ASX instead. No, with FSX SP2 (or Acceleration) and the latest FSUIPC4 versions there should be no noticeable oscillation unless you are experiencing some turbulence or other wind effects (all suppressible). Regards Pete

Sorry for the delay -- as announced here I have been on holiday. If you still have not resolved your problem, I would need to see the FSUIPC4 log and the Install Log too, please. The start of the SimConnect log shows all is okay, that far. FSX SP2 is better for SimConnect, especially with so many clients as you have there. Regards Pete

That's odd. All the other reports, preceding this one, pointed only to toe brakes assigned in FSUIPC in "direct mode". This is the first ever report of it happening without that setup. Perhaps you could please confirm exactly what axes you are assigning where, and in what mode. There are several combinations, as pointed out earlier in the thread: Assigned in FSX, Not calibrated in FSUIPC Assigned in FSX, Calibrated in FSUIPC Assigned in FSUIPC, routed via FS controls, not Calibrated in FSUIPC Assigned in FSUIPC, routed via FS controls, calibrated in FSUIPC Assigned in FSUIPC, routed direct to FSUIPC calibration All previous reports of the problem pointed to toe brakes (only) using the last option above. Please try to narrow it down before i return. Thanks, Pete

I know that there is absolutely no way anything in FSUIPC itself can change the data BETWEEN SimConnect and FSX, which is what appears to be happening. Could you report this to Microsoft (for SimConnect), via tell_fs@microsoft.com, and then use the work-around you already know about. I will also send details direct to my contacts in Microsoft. I'm on holiday soon until May 19th, But I am making notes now to add some diagnostics to FSUIPC -- I'll see if I can trap the occurrence of the first logged SimConnect error (the Exception 2), and then make FSUIPC log profusely everything it does regarding SimConnect. Even if it isn't a bug in FSUIPC (and it isn't looking like one), at least it may provide a clue as to how to work around it more tidily and automatically. Incidentally, this is still only when brakes are assigned "direct to FSUIPC calibration", right? If you don't hear from me soon after May 19th, please remind me about this. Regards Pete

I do on my PFC CDU. But I don't know if it can work on any others -- it can only work on those CDUs using a normal Windows screen and Keyboard, like the PFC one. Thomas released the details on his website with the first version of WideClient which supported this. I use keys on the CDU, as documented. But they simply use the offset Thomas provided to show or hide the checklist. I am on holiday soon, till May 19th, so I might not be able to reply again. Regards Pete

Both 162 and 49 are KeyCodes, from the KeyCode list. The two numbers after the = are NOT a "LIST" of keycodes!!! Only the first is a KeyCode. The second is a value which adds the shifts, like Control, Alt and Shift. It says that very clearly here in a part of the document you clearly never looked at: I've never had anyone in such confusion as you! You are obviously picking bits out of the documentation without even bothering to read it! I should not have to quote parts here!!! :-( Please go and read it a little more slowly. AND look at the examples! Surely they are clear? You can have only one number from the KeyCode list, then one number giving the shift states. I am on holiday now for over two weeks so you have plenty of time to read it and sort yourself out. if you still have any questions then you can ask me again -- I'm back on the 19th may. Pete

But that would mean it would have to be repeated without being detected, so it would have to start when FSUIPC was loaded and continue tillwhen? You pressed it? I cannot see any way to implement that which wouldn't be absurd. Currently all button actions operate on "changes" - off to on, on to off. Or are you saying to IGNORE the button until "on to off" is seen? If it is a reversal you need, i.e. "on" to be seen as "off" and vice versa, so that I effectively invert the data I'm reading for one or more buttons, at source, then that would be easier to implement. It would be an INI-file parameter only, though, much like the "Ignore" and "Initial" button facilities already provided. I am on holiday starting in a couple of hours or so until May 19th. Remind me then. Regards Pete

Yes, pretty much all user-oriented parameters go there. The Config section is about how WideFS operates, not what options it performs. How do you work that out? The list in the document clearly says 162 is "left control". There are two "1"s, of course -- the main keyboard one which is 49 and the NumPad one which is 97 (but the numpad one would need NumLock on, as it says). Please explain how you could possibly misinterpret the list in the document. I don't understand! :-( And where are you getting ",49" from? The list of shift codes wouldn't get past 31 even if you had "Release key" and Shift and Control and Alt! Maybe you have 49 for the "1", which should of course come first as it clearly shows in both text and all the examples, but then where do you get 162 for the shifts? Control is listed as 10, so the whole thing would be "49,10". Please please please explain how my documentation is so bad that you get this screwed up so much? This is documentation which has been developed and used by many over 11 years or so. I am completely gobsmacked. :-( Well, there are two ways of trying that. First there are certainly codes for Left and Right control keys listed (there's no single control key code), but as noted these may or may not work. The other way to try is Ctrl + NULL (NULL just means zero), so "0,10". Don't forget you need to identify the Run program as a another parameter on the line, so for control+1 with the Run1 program it would be: KeySend1=49,10,Run1 assuming you assigned the button to KeySend with parameter 1 in FSUIPC. Regards Pete

Sorry, it just means "applications that WideFS knows about" -- i.e. the ones it loads. What they do when loaded is immaterial. I am away on holiday after tomorrow morning, so if you have any specific technical question please do be quick. Otherwise, maybe others here can help. But it isn't hard, really. Pete

No it is no joke. I am sorry for your suffering, but your appeals for charity are not best worded as a complaint against folks who may not be so unfortunate but who work damned hard for a living. You came across as one who thinks software doesn't cost anything to make and should therefore be free. I apologise for that misunderstanding. Regards Pete

Yes. Whilst I managed to make FSUIPC3 compatible all the way from FS98 to FS2004, I'm afraid FSX needed a complete re-write. That's why there are two current ersions, sold separately. No, WidevieW is by Luciano Napolitano, and is a completely separate program. You may be thinking of WideFS, and the Server for FSX is in no way an update for FS2004. Only the WideClient program, running on your client PCs, is the same -- it wouldn't be very helpful otherwise! How do you afford all the "games" then? Anyway, in the case of FSUIPC/WideFS and FS, there is only the two versions for all 10 years of FS development since FS98, so it isn't "each game" at all. Pete

Why on Earth do you want the class name? Why not have the program be loaded by WideClient, via one of the Run parameters. Then you can direct the keystroke quite precisely. I already suggested this. The class name method is hardly ever used these days, it was the first method implemented about 11 years ago! Whether a program is associated with FS at all is totally irrelevant. If it can be run under Windows it can be started by WideClient. And WideClient has the handle on any program it is able to start. Regards Pete

Two points there. First, registration for FSUIPC4 has no effect whatsoever on the registration already in place for FSUIPC3. Your registrations are contained in "KEY" files, in the Modules folder, right next to FSUIPC. Secondly, there has never been a 7-character key for FSUIPC. The current version of FSUIPC4 for FSX has no registration screen within FSX. The registration for FSX is done by the Installer. Since there is no installer for FSUIPC3, what you say makes no sense. And deleting the very files which would have resolved it for you is not a good idea. No, you cannot conclude anything of the kind. There is no relationship between the two registrations and one cannot affect the other. I have no idea what you are seeing (as what you say makes no sense at all, especially the business about the 7 character key!) but it is not in any way related to the standard FSUIPC registration procedures. Sorry, that's not possible. FS2004 was not out in 2001, and no registrations existed until FSUIPC3 in 2003. It sounds like you are mixing FSUIPC up with some completely unrelated program. Please ALWAYS state version numbers in any further requests for Support. Regards Pete

Ah, not tried that one ... ... Hmmm. There are two problems, one of which is that the alpha and numeric keypad buttons all seem to call the same routine. They may each be one big 'button' (mouse rectangle) with the resolution of which one is clicked being done in code. There's no way I can deal with that by pre-programmed buttons or keys because of the screen position dependency. The other problem, which I may or may not be able to overcome, is that all the function buttons and selection keys, whilst being neatly different rectangles, all use some user-defined structure pointer which I don't provide. I might be able to conjure up a simple substitute that satisfies the gauge, but it isn't al that likely, and I won't have time even to look for a few weeks (holidays). Since the CDU really does need to be on screen to use, maybe this is one area which should retain "Key2Mouse" use? Alternatively, undocked it could be placed on one of those neat little touch-sensitive screens (Lilliput do nice 7" and 8" ones). Regards Pete

Thanks Ian. So nice to have more positive feedback, especially just before going on holiday (off later tomorrow for just over two weeks). Incidentally, it seems it doesn't work on the PMDG CDU (see other thread), though since the CDU really needs to be seen to be used I would think Key2Mouse or a touch-sensitive screen would be appropriate in any case. Best regards Pete