Pete Dowson

Just write your program to emulate any buttons you choose from the 288 available (288 = 9 x 32)! Which ones you choose doesn't matter unless you have other software also using this facility, in which case of course you'd want to avoid choosing the same bits. Once your program is operating the bits in those "virtual button" locations, THEN you can easily program them in FSUIPC to do whatever you like. All you need to do is get your program to operate each "virtual button" and program it in turn. This is EXACTLY the same as connecting a real joystick or button pad and programming the buttons on that in FSUIPC. The "virtual button" facility emulates real buttons. Okay, fine. Please yourself. I won't argue. I just don't understand how you find buttons so mystifying. Regards Pete

I've no idea how yur are sending them, but WideClient merely reacts to the standard WM_KEYDOWN and KEYUP messages. There's nothing clever, no magic. If you are using a programming language which supplies microaoft's "spyxx" program you can check the messages it is receiving and compare them with the ones it gets from the keyboard. Yes, thought you don't need to write a whole DWORD just to change one bit, just the byte with that bit will do. Bits 0-7 are in the first byte, 8-15 in the second and so on. Neither. How can you get 32 x 9 bits into a 32 bit word? And 3341 is only one byte past 3340, with only 8 bytes. For 32 x 9 bits you need 4 x 9 = 36 bytes, as it says, from 3340 all the way to 33663 inclusive! You write to them through the FSUIPC interface. Please see the SDK. You use FSUIPC_Write and so on. Sorry, you are losing me completely. Of course you need to set the button first, else how can you program it? I assure you it is 1000% easier and mch more efficient and reliable than messing with keys. What exactly is so strange about a "virtual" joystick button being recognised by a bit changing in memory? This is exactly how all the joystick interfaces work. Regards Pete

It is just waiting for a connection. Seems like you''ve got a parameter in the WideClient.ini file which tells it to hide or start minimised -- just delete the INI and start again, or open it up and check the Windows and other parameters near the top. All the parameters are documented in the WideFS DOC so you shouldn't have any problem. Pete

I had a look, and it was pretty easy. I also found the menu bug -- looks like it's been that way for a *long* time. Evidently not many folks using it for individual menus. The saved flight filename system will be as follows: A 16-bit (2 byte) count will be updated at offset 3BD4 each time a flight is saved, no matter by whom or how. To get the name of the last saved flight, you will need to use the "path reading" mechanism operating on offsets 0FF0-10FF. This is described in the text section of the Programmer's Guide already. The last saved flight will be using a 3 in the Command Word. Note that flights are normally saved to the default Flights path, and this won't be included in the flight filename you read. The best thing to do is use the path reading facility once only, when you first get connected, with command word = 1, then prepend the path to the filename (check that there's a separating \ character) before using it. I've made the changes but its getting very late here now so I won't test till tomorrow sometime. If you want an interim version to check out, please email me on petedowson@btconnect.com. Otherwise it'll be in the next general release, probably 3.24 in two weeks. Regards, Pete

Great! That's good -- it saves me a lot of work adding new controls which aren't really needed after all! Phew! :D Good flying! Regards, Pete

Oh, I see. But doesn't that amount to the same thing? Simply swapping over which side is "standby" and which is "in use" instead of swapping the frequencies themselves? Don't the FS Controls I listed operate on whichever is the "standby" frequency whichever side it's displayed on? This should be exactly what the controls I listed for you do -- they don't change the "in-use" frequency, only the "standby". You can't be talking to a controller on the standby frequerncy because that isn't in use! Perhaps I need to re-install the PMDG panel so I can test the controls I mentioned, but it is bit of a palava when I don't need it. Can you re-check please and describe it a little more carefully? Internally they must be changing the frequency not being used. It sounds like all PMDG have done is made the display of the standby left or right according to the swap button. Can you please just try the commands I mentioned and tell me what happens on screen for each state of in-use/standby, standby-in-use? Thanks, Pete

Assuming you are talking about using FSUIPC controls to do this, then obviously it is more efficient in terms of Network use, and also to reduce the latency in the response, to connect to the Server. The only way it would be more efficient on the Client would be if the MCDU itself could accept your inputs, but I don't think it has button programming facilities. Some joystick drivers offer keypress capabilities from buttons, so that's another possibility. Correct. Regards, Pete

I don't think that the FS sim engine is designed that way, with simple values which can be changed on the fly. I am no expert on the aircraft side of things, but it seems to me that the parameters read from the Aircraft.CFG and the AIR files are used as a basis for generating a complex flight model, maybe with tables and all sorts. Certainly most of these things interact with each other. There are jet thrust values for each engine (204C etc) but I suspect that these are derived values and I doubt whether you can change them, though you are welcome to try. I really don't know of any "spoiler effectiveness" value internally, but simply manipulating the value in 0BD0 should be sufficient provided there's enough effect pre-defined for the aircraft. Even if the were specific values matching your needs which I could find and map offsets to, which is unlikely, I doubt whether writing to them would have the effect you might be seeking, simply because of the interaction in the modelling. I don't know what you are trying to do, but experimenting with writing to the assorted velocities and accelerations (3060-30B8 and 3178-31D0) may give you what you want. Alternatively try changing the loaded weight and distribution (1400). Regards, Pete

Oh yes, I see. I will add it to my list. It should be easy enough, but I really don't want to allocate space for another filename string. I may consider just changing a "save" count somewhere you can read and updating the Loaded FLT pathname at 3F04 but without changing the 'load' count. The only problem then is that the currently loaded FLT name may change to an AutoSaved one pretty soon after loading -- I wouldn't be able to easily distinguish auto-saved flights from user-saved ones. Okay, I'll check it out. Regards, Pete

No, not at present. FSUIPC doesn't currently detect flights being saved. I'm not sure without research whether it could do it reliably. Flight saving doesn't need menu access in any case. You can do it by pressing ; and giving a name. This doesn't use the menus. Furthermore, modules and gauges can save flights "surreptitiously". In fact my own AutoSave does just this -- it saves flights on a regular selected basis without any menu or user action. Well, I'm not sure I can do that. I could maybe add it to my list, but I would like to know the reasons please. The main thing to check first is the AIR file change counter at 32FC. This may of course change when the user reloads the same aircraft -- but you cannot tell if any of the files have been changed in the interim. Sorry, there's no way I could detect that. If all you need to know is that there is a possibility of change, then merely seeing the count change would be sufficient. I'm not setting anything to anything. It may be that FS is doing this, or simply that the memory being addressed isn't accessibly during such times. I have no idea. These facilities have not been revised at all specifically for FS2004, so possibly it is some change there which is affecting this. If it does what you say I would call it a bugbut I shall need to verify this and then correct it. Do you have a demo program which I can use to check it? I am tied up with other matters for a few days but I can look at this early next week. Regards, Pete

No, sorry. All the FS facilities follow standard Bendix-King radio design and only allow changes to the standby unless the standby display is in use for other things (like radials on the NAV). They normally only have the one dual concentric rotary for adjusting the values, not two. I don't know the PMDG panel, but if they have added the facility to adjust either separately, with separate rotary control, then surely they've also provided some way of controlling this apart from the mouse? Did you check the key assignments they provide? Quite honestly I don't know why you find it "frustrating" to be forced to use the radios in the way than most folks have to both in the sim and in real life. Maybe it is because I don't know the panel, but I don't really understand the need to change the in-use frequency directly. I've been using 'real' (hardware) radio stacks with FS for many years (right back to FS5) and have never found it a problem to dial in the next frequency on the standby whilst still talking to the current controller on the "in use" frequency. It seems quite natural. I am quite prepared to add to my long list of FSUIPC requests additional commands to allow in-use frequencies to be incremented, decremented and set, but I really would first of all like to understand the need, please? Regards, Pete

Well, I've never been -- but I can't spare a couple of years. Anyways, if you tear me from my cosy environment I am next to useless! :wink: . And if you are building real hardware I am even worse! :? Regards, Pete

Thanks for helping. It's a little difficult to be so specific without the panel in front of me! Regards, Pete

In my experiments FS2004 discards the bad values, so the current one gets left unchanged. Therefore you can't increment passed the bad one. I certainly don't think it will get you to 3000 from 2997! I'm not sure about FS2002, but certainly FS2000 and earlier would display rubbish if you sent it bad frequencies. Either way it isn't any good for a simple inc/dec control set. Do you think we are arguing? :? I thought it was a discussion about a misunderstanding. :wink: Regards, Pete

Why not just use the keystrokes provided by PMDG? I'm really not understanding what your problem is. You want to control something with keypresses, and PMDG offers you that facility. You just don't need to program them in FSUIPC. Regards, Pete

As I said, I think the PMDG panel does not implement the FS Autopilot. There is NO WAY that the standard FS controls will work on panels which don't have the facilities on which they operate. Please re-read my last reply to you, and also please go check the PMDG documentation. This is not an FSUIPC matter, it is between you and your PMDG aircraft. Regards, Pete

There is a big difference between hex and BCD. If you have a hex number like 2457 (for 124.57) and you add 3 to it, you do NOT get 2460 (for 124.60) but the hex number 245A, which is not a legal frequency in BCD. To get 2460 you'd need to add 9. It gets worse if there's a need to carry further. 2997 (for 129.97) would become 299A with 3 added or 29A0 with 9 added. To get the 3000 you want (for 130.00) you'd have to add hex 669 (decimal 1641). You see that there is no way to assign simple inc/dec controls for hex to any BCD numbers. It is not a matter of "how it is called" but how arithmetic works with it. In short, there is no way the offset increment/decrement facility I am offering in the next version of FSUIPC would work correctly with BCD, though it will in decimal and hexadecimal. Please believe this. Well, I expect the PMDG SDK will allow programs to be written for this -- PMDG have provided nothing but keystrokes for operation of all the important stuff like the MCP and this is much more frustrating I think for cockpit builders. I don't at present see a great need for new FSUIPC controls for changing in-use radio frequencies, but I will consider it if there is really a demand and I have some spare time. I'll put it on the list and see. Regards, Pete

As far as I know, PMDG's autopilot is not FS's autopilot and none of the standard FS controls work with it. I think PMDG provide key press combinations for most of the operations -- just use them directly. You can't use FSUIPC to program keystroke outputs from keystroke inputs, there's no point in doing that in any case. I am sure other PMDG panel users here will be able to advise if you still don't understand. I don't use the panels at all I'm afraid. Regards, Pete

The ones haveing the same name of the others, so they do not work. But Mike does not need any of those -- as I keep saying, he does not need any controls which say "standby" to operate the standby frequencies, because the regular ones (those that used to operate the "in-use" frequencies back in old versions of FS) now act upon the standby frequencies, not the in-use ones. The set of controls I listed earlier do work fine. There are no FS controls to control the in-use frequency directly. The radios emulated don't have such a facility. The NAV facility for increment selection is not related to the COM radios, which was the subject of the enquiry. The COM radios go in increments of 25khz, which is an additive of 2 and 3 alternately. It is not hex, but BCD. FSUIPC allows hex or decimal, but the only application of BCD would be for the radios, and there is really no need for that because the FS controls do actually work fine. If it is important to control the in-use frequencies directly then it would be better (and in fact easier!) to support these by adding new FSUIPC controls specifically for this. But I am currently still confused about the need. Surely standard practice is to set new frequencies in the standby side and then swap when needed? There must be many thousands of aircraft fitted with radios which only work this way, and it would become second natrure to do it. Why is a direct in-use change needed? Regards, Pete

Sounds like either some other program has changed the menu entry, or possibly you have some corruption in the FSUIPC.INI file. The menu to be added and the entry therein are specified by these two lines in the INI file: MainMenu=&Modules SubMenu=&FSUIPC ... where the "&" tells Windows which character to underline (and thus make the keyboard selector for the entry). Check those lines. The INI file is found in the FS Modules folder. If there is any corruption in your INI file it would be a good idea to delete it (when not running FS), and let FSUIPC build another, next time you load FS. Of course this will reset your options to defaults and delete any joystick settings or key and button assignments you've made, so you may want to save those sections. Regards, Pete

Just scan the release notes at the top of this forum when a new version is announced, or check the History document in the Zip when you update each time. It will keep you abreast of things. :wink: Which controls are messed up? The ones I listed above certainly work with all the aircraft I've tried. And by writing to the standby offsets in FSInterrogate, effectively you are mostly getting FSUIPC to use those same controls internally. As far as I remember without looking at the code the only ones which write direct are the "in use" offsets, for which there are no controls. Unfortunately the amount to increase or decrease will be difficult to arrange -- the inc/dec facilities for offsets which will be offered in the next release allow any increment/decrement, but not one in BCD and varying according to the current value. Remember that the frequencies are not in normal numerical format, so many values are invalid, and even then the fractional values change by 2 or 3 alternately, thus: .00, .02, .05, .07, .10This is because the 1/1000th's digit, a 0 or 5, is omitted. (Here the .10 value is actually represented by decimal 16 of course, being BCD. Regards Pete

Sorry. what do you mean? What "comes up VSUIPC"? I've never heard of that. What "FSUIPC Window" are you opening. There's only the options dialogue, accessed by ALT M F, or by mouse selection from the Modules menu. This looks like the pictures you will find in the User Guide. Sorry, FSUIPC doesn't do anything with any aircraft. It is passively acting as an interface for any program, gauge or module which wants to use it. You need to look elsewhere to find out why an aircraft doesn't do what you expect. Please check the FSUIPC User Guide. It tells you at length what FSUIPC is for and what options you have. none of those are there to keep an aircraft in the sky. That's to do with FS's simulation of flight. Regards, Pete

It seems then that there was some sort of corruption in your original installation. I don't use WidevieW, so I'm not sure what its needs are -- but I suspect that if it uses FSUIPC (which I think it does) it may install a copy itself. If so, then obviously you will want to install the latest version of FSUIPC afterwards, to ensure it is up to date. If it doesn't install FSUIPC, then instead it may complain that you don't have FSUIPC installed and ask you to install it, in which case obviously you'll need to do that first. If neither problem arises I really can't see that it makes any difference which way you install these things. Regards, Pete

In that case there is surely no problem at all -- the standard FSUIPC controls will do the trick. If this isn't the case then I am surely not understanding something. If you mean program a key or button to write specific vlaues to specific FSUIPC offsets, then yes, of course. The main such facilities were added in version 3.14, back in January, as documented. With those you can write 8, 16 and 32 bit values, or simply clear bits, set bits, or toggle bits. The facility has been augmented to do increments and decrements too, but this part isn't yet released -- it will be in the next version. But I don't really see how this is relevant to the thread. Care to explain? Regards, Pete

REVISED AFTER READING MORE CAREFULLY! :wink: Then it is acting the same as the normal FS radio stack, and the same as a standard Bendix-King type radio in real life. The extra controls to alter the in-use frequencies in the PMDG are not supported by FS so there aren't any controls supplied by FS for those -- there will only be whatever PMDG supplies in the way of key assignments. There aren't any facilities to do that in FS for any aircraft which has standby frequencies -- you always enter the next frequency in the standby, THEN use the Swap button or control. The only times that in-use frequencies are directly changeable in the type of radio supported are in the NAV radios (not COM) when the Radial is being displayed in the standby position (but I don't think FS emulates this feature). Why "temporarily"? That is really the normal correct way to use the simulated type of radio. It is the way they are designed to be used. Sorry, you've lost me. You always have up to 4 different frequencies for COM to choose from -- two on COM1 and two on COM2. There can only ever be two actual "in use" frequencies as there are only two actual COM radios. You simply enter new frequencies in the standby side. This is the way Bendix-King style radios work. I am not understanding why you think this is "frustrating" -- is it simply just the unreachable extra knobs added by PMDG which are annoying? Regards, Pete