Pete Dowson

There's no wounds that I know of (???)and there's really there cannot be any "conflict" with anything in FSUIPC if you aren't trying to use any conflicting options therein. And to answer your question, no, no one has mentioned any such thing. Sorry. FSUIPC does not touch the spoiler unless you tell it to, so quite honestly it cannot be anything to do with FSUIPC as such. If removing FSUIPC "fixes" it it can only be because either something else you've set FSUIPC to do is doing it, or another add-in or add-on is operating this through FSUIPC's facilities. FSUIPC is not an "active" component, it only does what it is asked to do. Delete your FSUIPC.INI file so only default options are applied (none of which are related to throttles, axes or spoilers), and check the FSUIPC Log to see what other programs or modules are using it. Eliminate those one by one to find the culprit. You seem to imply that you only get this with registration of FSUIPC -- and since all user-registration really does is allow you to use more options, it is I would have thought pretty obvious that it is most likely to be related to something you have set. FSUIPC does NOT allow you to make any axis assignments. FSUIPC's joystick facilities operate on FS controls, there are no (repeat NO) axis assignments within FSUIPC and never have been. You must be making your spoiler axis assignment in FS, and that is where you have to delete it -- there's no way to make nor delete any such thing in FSUIPC. Regards, Pete

Yes, I noticed the highlighting had disappeared -- but the shortcut keys certainly still work the same, in all programs. Regards, Pete

Why Window mode? You should be able to access any of the FS menu entries, including those in Modules, by pressing ALT then either using the mouse or typing the shortcut key. e.g. ALT M F gets you to the FSUIPC dialogue. All these things work in full screen as well as Windowed mode. Doesn't this add-on provide a shortcut or hotkey specifically to show/hide its window? If not you should write to the author/suppliers and request it. It is surely a fundamental requirement for such windows? Regards, Pete

Did you simply try defining (typedef'ing) DWORD and an unsigned long? Seems odd that MS provide facilities so self-inconsistent. I'm afraid I don't know "Windows Forms" at all (in fact I've never heard of them), and I've avoided MFC altogether. I like my code to be completely under my control and as compact and efficient as possible, and I can only ensure that by using plain C, which ASM in places where I need even greater control. Maybe some one else here uses and understands "Windows Forms" and can help. Sorry I cannot. Regards, Pete

The current aircraft name is only shown on page 6 of the Joysticks tab, in the bottom right section where it also tells you the number of flap detentes and the increment used between them. There's no need (and no room) to show the aircraft name elsewhere. Pete

Two things here: 1. I use VC .NET 2003 and have been doing now since it became available. Everything compiles fine. I suspect your trouble may be to do with the fact that everything I provide is C, not C++ -- maybe you need to use C or put some parentheses around the H file to tell the C++ compiler that it is C not C++? 2. There are no classes defined in FSUIPC.H because C does not support Classes. ;-) DWORD is still a standard Windows data type -- it sounds like your Windows headers are corrupted? Very very many of the Windows API calls are defined with DWORD parameters or results -- even basic things like GetLastError, for example. DWORD is simply defined as an unsigned long or unsigned int. Of course, when we eventually get to 64-bit compilation all this will beed a good overhaul. Regards Pete

Only in FS98 or possibly FS2000, as since FS2002 nothing is available in the "global" offsets areas which you can find. 90% of the offsets provided in FSUIPC are now explicitly mapped after I've located the data by hacking the code. It takes me roughly a week or so of long hours to delve deep enough to even start finding things, and that's for areas I know. I wouldn't know where to start for doors -- if you have the tools and know C/C++ and ASM well you could try tracing things through and examining disassemblies, but I couldn't even point to the correct FS module for you to start with I'm afraid. Regards, Pete

Actually, for BUTTONs (only) you are correct, though you omitted to mention those. If button actions are defined in both FS and FSUIPC then both have effect -- FSUIPC has no way to stop FS seeing them. For Axes you are not correct because FSUIPC does not handle axes at all -- all the "joystick" facilities in FSUIPC act on FS axis controls, which are the results of axis inputs via FS assignments -- therefore it is imperative that any axes you want are assigned in FS else they cannot result in the controls which FSUIPC processes. For keypresses you are incorrect also, because FSUIPC actually intercepts all the keyboard messages before FS sees them, and if they are programmed in FSUIPC then FS never gets them. I hope this is clear now. Windows also provides a "Hot Key" facility (not used by FSUIPC), and this takes precedence over any programs awaiting keyboard input -- so other programs, like PowerStrip for example, can steal their allocated keypress combos before FSUIPC or FS sees them. Regards, Pete

FS's own assignments are entirely irrelevant to FSUIPC because it intercepts the key messages before they get to FS's processing. The only possible explanation is that you have some other program using Ctl + Shft + W as a hotkey -- the Windows hotleys facilities take priority and will steal them first. I expect there's a Ctl+Shft+W in there somewhere, then. Regards, Pete

I use the same combination and it works fine for me. There's certainly been no changes in FSUIPC for that. It sounds like you have some other program grabbing that combo. Regards Pete

Not with the latest versions, provided in FSUIPC you use the PTT controls, not the old KeySend method which you are evidently still using. The local PTT controls in the FSUIPC dropdowns work for a local SB3/RW/AVC or a remote one. Regards, Pete

Yes of course -- not for the panel, but for the gauge which is using FSUIPC. Details are in the Access Registration document inside the SDK. I am not familitar enough with the recent panel SDKs for MS to say, sorry. I don't think it was possible with the original C/C++ interface, but maybe the XML interface is more extensive. Regards, Pete

It recognises the aircraft each time you load one. That's the whole point of the facility. Didn't you just try it to see? Regards, Pete

The ADF2 frequency locations in FSUIPC's offsets are clearly documented in the document provided in the SDK. Did you look there? What offsets have you been trying. Please find the program called FSInterrogate in the SDK and use this to check things. It is provided for exactly such a purpose and can save you a lot of time! The offsets listed in the document are correct and are as follows (they are only relevant to FS2004 because ADF2 wasn't supported before then): Note that writing to these offsets will probably have no effect whatsoever unless you are using an aircraft which has the two ADF radios defined. For this, check your AIRCRAFT.CFG file. Regards, Pete

To open and close doors you will need to send the appropriate FS control via offset 3110. Controls are listed in a separate document in the FSUIPC Zip package. Unfortunately there appears to be no way to select secondary doors and so on without using the number keys (on the main keyboard) or sending the equivalent values or controls, and, like the pushback direction (Shift+P then 1 or 2) and Engine selection (E then 1,2,3,4), these can be upset by intervening controls. FSUIPC does try to help out by it cannot guarantee success -- it would be ideal if the main FS controls had the numeric value as a parameter, but they don't. As for detecting the state of the doors (open or closed), I'm afraid I only ever managed to find the indication for the main doors, and that for FS2004 only -- sorry, I just haven't had time to delve backwards into FS2002. The FS2004 indication is at offset 3367. Regards, Pete

But why control it by program? Isn't the user option enough? Pete

Either run it from a WideClient.EXE and INI in the same folder as SA_WXR, or download the interim update for WideFS in the "Get interim versions here" thread at the top of this Forum. Regards, Pete

Aarrgghh! You are right. My doc doesn't say exactly that it is read-only, but it does say it reflects user parameters -- the other bit in there most certainly can't be set by program and must never be allowed to be. Is the user option insufficient? I would have thought the choice of colours would be a user-decided thing in any case. After all, FS itself defaults to the same defaults as FSUIPC for these displays. Regards, Pete

I don't support older versions though. FSUIPC 3.50 is current, though there is a later one available in the top thread here. Also I'm pretty sure that the version 1.989 of PFC.DLL, in the same thread above, is better than the one currently being supplied by PFC. If you have a standard COM port on your PC it should work okay -- I know MS are trying to eliminate them, but I've not yet come across a desktop-type motherboard without at least one, even if it isn't brought to a socket on the rear. There are notebooks without, of course. Note that PFC.DLL will only list those which are available, so maybe your is already taken by something. Certainly the USB-Serial link works better in any case, and you can get adapters that work well for as little as $15-20. Just be sure it comes with a driver for your version of Windows -- for a while there wasn't a decent driver for XP. You can get latest drivers on the web. Regards, Pete

I don't know any of these parameters you are showing me, but it sounds like whatever program it is does not use bit numbers or button numbers, but bit masks. FSUIPC offers 9 virtual joysticks (numbered 64-72) each with 32 buttons, numbered 0-31. The virtual joysticks are represented as 9 32-bit words, at offsets 3340, 3344, etc (these are in hexadecimal -- FSUIPC represents all offsets in hexadecimal, following the original FS6IPC tradition). 3340 in decimal is 13120, so it seems that the program you are using insists on using decimal instead. Additionally it may well want to refer to individual bytes, i.e. groups of 8 bits, instead of the conventional 32-bit words. So you will have 8 bits in each of 4x9 or 36 bytes, addresses 13120-13155 in decimal. In a byte you have 8 bits, numbered 0-7. But, again, you seem to need the VALUE of the bit, not its number or position. The value of bit 0 is 1, bit 1 is 2 and so on, up to 128 for bit 7. (2 to the power of the bit number). I would have thought that whatever program it is you were using would come with instructions which explained all this, and at least some examples. Did you check? Regards, Pete

The reason for this is that the gear switch position in the PFC hardware is one of the items transmitted by its controller at regular intervals, approx once per second. The PFC DLL has no option but to obey since it cannot distinguish between a genuine switch operation and a regular scan. The only way to deal with it is to re-program that switch to do something else, either useful or innocuous, in FSUIPC's Buttons page. PFC support would have told you this f you had asked and would have saved you are rewiring job -- as it is you will need to reconnect the wiring. Regards, Pete

It simply calls the same procedure in FS that FS itself does when you use the ';' keypress and enter a name. It is simply entering the name automatically. AutoSave knows nothing at all about what is saved, that is completely up to FS. I know that some aircraft (e.g. the PSS ones) do hook the saves and then also save their own data, nrmally in separate files though I suppose it would also be possible to append data to the .flt files themselves. I have no idea what the LDS aircraft try to do I'm afraid. AutoSave "hooks" nothing -- it has no need to. As I said, it merely calls the correct "save" procudure in FS. If the LDS code hooked it correctly, as for instance the PSS aircraft do, then it should work. Possibly they only look for menu access? Do they save okay using the ';' key? You'll need to ask LDS this -- AutoSave can do no better than calling the correct procedures in FS. Regards, Pete

I think you will have to write your own code as I don't know of a program ready-made to do such things, though you should look at FS Flight Keeper by Thomas Molitor (not a free program) which does record a lot of data and may just include much of what you want. Alternatively, a recording facility in FSInterrogate may well be useful, so try writing to Pelle Liljendal (see his FSI2 announcement above) and see what he says. Regards, Pete

There's been no changes in FSUIPC which would have had such an effect. The Sim rate decr control should certainly do exactly what you say, i.e. simply reverse the last Sim rate incr used, not take you back to x1 -- that is done by the Sim rate set control with a parameter of 256 (units are in 1/256ths). However, easier still -- there is already a facility to do exactly what you want, programmable in the HotKeys page of the FSUIPC options. Regards, Pete

3.50 is current, any earlier is unsupported. For PFC digital controllers you need the PFC.DLL, latest on the http://www.schiratti.com/dowson page. It needs PFC.DLL installing in FS modules folder. There are no relevant settings in FSUIPC whatsoever, though PFC.DLL does use FSUIPC for its FS access. Please see the documentation inside the PFCDLL Zip. Regards, Pete