Pete Dowson

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

Okay. Neither FSUIPC nor WideFS are involved in making other players aircraft visible in FS. With FS2004 and before I think SquawkBox and other such programs use the FS Multiplayer interface. With FSX it is done through SimConnect. Either way it sounds as if you have not got a proper connection for those interfaces between your SquawkBox PC and your FS PC. I'm sure the SB folks will be able to assist. Regards Pete

Answers to most things are in the documentation supplied, rather than on Forums. It is quite extensive. Didn't you "search" that first? After all, that's why it is provided. Forums aren't documentation, they are for problem resolution. Assign the button to a KeySend control (in the drop down). With any so far unused parameter 1-255. Then in the [user] section of the WideClient.INI, add a KeySend line to define your keypress and, if the program is being loaded by WideClient (best), the Run or RunReady details. Please do refer to the WideFS documentation supplied. It is all there, and it shouldn't have to be repeated verbatim here. If there's something you don't fully understand, by all means come back and ask a specific question, but please don't just ask how generally to do something which is documented. Regards Pete

I found a bit of time to make the small changes needed and test them, so please download FSUIPC 4.281 from this link: http://fsuipc.simflight.com/beta/FSUIPC4281.zip Offsets 07F4 and 07FA should now work fine, reading and writing. Regards Pete

Sorry, I think you are under some sort of misunderstanding. WideFS has nothing whatsoever to do with aircraft visibility, whether AI or multiplayer. I'm really not sure what you are doing -- whose other airplanes are you expecting to see, and where are others seeing you? All WideFs does it extend the FSUIPC interface to Networked PCs. There would be no copies of FS running on the client PCs. Regards Pete

I don't know what is meant by "temporal button press", not where to set half a second but I suspect this may be referring to the "Eliminate Transients" facility, for buttons programmed via FSUIPC. It is documented in the Buttons section of the FSUIPC User Guide, as follows: The parameter has to go into the [buttons] section of the FSUIPC.INI file. Later versions of the Saitek yoke fixed this problem I believe. Regards Pete

Okay, I've checked into this. I can make offsets 07F4 and 07FA work, for both reading and writing. The writing of 7f4 to turn the N1 hold on/off will have to use the FS control, internally, and that's only a toggle, but it will check the last read value first. The N1 hold value can only be set directly in whole numbers, 0 to 100% or more, even though you'd normally have values at least ot 1 decimal place, so I'll make the 07FA value readout more accurately, with 16384 = 100% as it already does in the Engine read-outs. Unfortunately, the only way to set the value directly is via the FS control, so writing to 07FA will actually write the nearest whole % number. All this is easy enough for me to do and it will be in the next incremental release, on my return from holiday in three weeks. Regards Pete