Pete Dowson

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

Except for one thing I omitted to mention -- the solution with sending two different controls alternately only works if you have the acceleration fix option selected in FSUIPC's Technical page. Regards, Pete

I'm here now, but I confess I am not sure what you find awful about the views you posted. If you could capture a picture with at least the horzon in it and maybe some scenery, and explain what you think is wrong, then it might make more sense to me, but those just look like views straight up of an early morning or evening sky. In any case, I'm afraid I am no expert in any of the graphics of FS. You may have better luck in the main FS2004 forum. Sorry, Regards, Pete

Two points: 1. In offset 3367 at present only bit 0 is used for doors (in FS2004). In case other indications are added in future you should check for bit 0 only ( and logically AND with 1). 2. The bit is set to 1 if the doors are Open, so you are interpreting it in reverse. What is a "Variant"? The value is a simple byte or character. You could read it into an integer, but set that to zero first to avoid confusion in the parts not read into. Regards, Pete

Apologies for the delay in my reply -- as announced in this Forum I've been away with no Internet access from 24th September until 12th October. Provided all your PCs are running WinXP, then since WideFS 6.50 there is virtually nothing to do except install the programs. You don't even have to provide Server Names and stuff now. None at all if you aren't unloading some external programs from the FS PC. And even then it depends on what processor you are using on that PC. For instance a hyperthreading P4 will run FS and several external programs with virtually no degradation in any of them. The prime purpose of WideFS isn't really to gain performance, though it can help, but to support more applications on more screens. Regards, Pete

Apologies for the delay in my reply -- as announced in this Forum I've been away with no Internet access from 24th September until 12th October. Possibly, but how do I find such details? Maybe RealityXP know how to do these things, but I'm afraid I don't. I will be asking MS to provide some interface for this in future versions of FS, but i won't be holding my breath! Regards Pete

Please contact PMDG support about this. If there is a bug there it needs to be fixed. I cannot support any old versions of FSUIPC, and in fact some later PMDG products will be dependent upon later versions of FSUIPC. This is not at all related to FSUIPC. I am using the 737-800 with no problems at all. And merely replacing the FSUIPC.DLL corrupts nothing whatsoever. Regards, Pete

Apologies for the delay in my reply -- as announced in this Forum I've been away with no Internet access from 24th September until 12th October. Not if you don't want them, no. Yes, this is a built-in action of FS. It is automatic is two identical controls arrive within something like 400 mSecs of each other. You can only avoid it by pressing more slowly, or making sure there's an intervening control which is different. I see you have "repeat whilst held" checked. If you want to press it repeatedly yourself you need to uncheck that. Alternatively, reduce your "32" increment value to compensate for the acceleration. The only ways are as I just described. Sorry. If reducing the increment to compensate isn't suitable, you could add another line in the FSUIPC.INI file to program a different action on the same button -- another non-axis FS control with no effect, or an innocuous one. Then when you are holding down the button both controls will be sent alternately and this will defeat FS's acceleration. Regards, Pete

Apologies for the delay in my reply -- as announced in this Forum I've been away with no Internet access from 24th September until 12th October. Try using the Logging provided in FSUIPC. If you enable IPC read logging you will probably see that your VB code actually tries to read offset &FFFFE004 (masked to 1FE004 probably). The stupid VB compiler sign-extends everything with a top bit set. Even stating &0000E004 doesn't appear to work. I think you have to postpend another & to stop this, i.e. &E004&. Please always use the latest version -- 3.47 is well out of date. Regards, Pete