Pete Dowson

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

You shouldn't need any experiments or luck. I think the main controls work just fine: Com Radio Whole Dec Com Radio Whole Inc Com Radio Fract Dec Com Radio Fract Inc for COM1, and Com2 Radio Whole Dec Com2 Radio Whole Inc Com2 Radio Fract Dec Com2 Radio Fract Inc for COM2. As I said, these actually change the standby radio -- there are no controls supplied for the "Use" frequency. You always set the standby then Swap them over (there is a Swap control which works). Regards, Pete

I don't know of any such thing in FS. Any gauge which provides stopwatch facilities simply does the counting, stopping and starting itself. I did the same for the FlightLink KR-1 ADF unit (in an ISA EPIC program) and the one on the PFC Avionics (in the PFC.DLL). Both these units feature Bendix-King style ADFs which incorporate Flight and Elapsed times including stopwatch and count-down alarm systems, utilising the standby ADF frequency display and just two buttons "FLT" and "SET". If you want to keep your timer in line with the PC you can access the "tick timer" at offset 0310, but this won't slow or speed with a changing sim rate, and it probably won't stop when paused or maybe even not in menus. Provided you only want 1 second accuracy (and this is normal in such timers -- you don't display fractions of a second), then you can't go wrong using the normal seconds counter at offset 023A to regulate your own. Regards, Pete

So they are! Hmmm. I never noticed that before. Thanks. However, there's not a lot I can do about it. It arises because the assignments were derived directly from the CONTROLS.DLL file in FS itself. Unfortunately, presumably due to an oversight by MS, the actual usage and names of some of the controls has been changed, but CONTROLS.DLL still contains the old names not the new. The CONTROLS.DLL actually dictates what the names are to be when assigned in FS, i.e. in FS9.CFG and FS's other joystick configuration files. It is CONTROLS.DLL which parses those and decodes them -- FSUIPC accesses exactly the same tables, so that it automatically gets the controls specific to each version of FS. However, there are a number of new controls which never made it into CONTROLS.DLL, so unless I did something special about those they'd never be listed (in my Controls List, or FSUIPC's drop-downs). So, in order to provide access to these newer ones, which aren't actually available (at least under those names) in FS Controls, I added a heap of them artificially, both in FSUIPC's drop down and to the Controls list. Of course, in doing this, I never noticed that some of the new ones actually replaced some of those already listed in CONTROLS.DLL with different names, even different functions! Apart from noting the fact some place there's not a lot I can do about it really -- as I say, the CONTROLS.DLL list is obtained at run time, automatically, even if it is wrong. It isn't as bad as it sounds. There are actually no controls for changing the "in use" frequencies, you have to change the standby frequencies then tell FS to swap them over. So the term "Standby" in all the frequency inc, dec and set controls is misleading and not needed. Just use the plain controls for changing the frequencies and you'll be okay. BTW, by way of clarification, I have not tried all the controls to see if they work or what they do, so I cannot guarantee any of them. In particular, where a control has two names which apparently mean different things, I really wouldn't necessarily know which was correct -- I'd have to try them and see. I'm afraid this is the way with all of the FS controls. All I offer is the ability to program keys and buttons to send them to FS. What happens then is another matter. Of course I always hope they work and do something related to their name, but I do think several of them are not even connected inside FS and are just leftovers from a bygone age, or hopeful entries which never made it to the released version of FS. Regards, Pete

Not through FSUIPC , no. I do locate the place where user flights and plans are stored in AUTOSAVE.DLL, but that isn't the same, though presumably both use the current username. If you are trying to do this programmatically look at the SHFOLDER API, and SHGetFolderPath specifically. Regards, Pete

Sorry, but I've absolutely no idea. Does it emulate a keyboard and send keystrokes to the PC, or does it look like a joystick with loads of buttons? You should be able to find out easily enough. FSUIPC can recognise any buttons which can be seen in the Windows joystick API. This is an interface which supports up to 16 "joysticks" each with up to 32 "buttons" (and also a hat switch or "POV" - point-of-view switch, and up to 6 analogue axes). This is the interface FS used to use up until FS2002 -- nowadays it actually uses DirectInput, part of DirectX, which supports a superset of this. To see if FSUIPC sees your buttons, load up FS, go into FSUIPC's options (ALT M F), select the Buttons tab, and press a button. You can of course do the same in FS's own Options-Controls-Assignments, but just with a smaller set of controls and options. If it looks like a keyboard and provides keystrokes then program them in FSUIPC's Keys page instead. Again, you can use FS's Options-Controls-Assignments but with a shorter list of controls. Sorry, this is an engineering question which I am not at all qualified to answer. You'll obviously need some sort of interface to the PC and drivers to deal with it. There are a few companies making interfaces I think, but the only one I'm still vaguely familiar with is the EPIC. You need to check in some hardware and/or cockpit builders forums. The manuals for the FS100? I shouldn't think they will tell you how to re-wire the device. Or do you mean FSUIPC? There is nothing in any of my stuff which will get you from a few wires connected to a switch to anything recognised by Windows sufficiently for FSUIPC to see it. FSUIPC is not a hardware driver, it is a module which sits in Flight Sim and reads standard Windows-provided indications, like joystick buttons and key presses. I'm sure there are lots of solutions, though you are starting with the relatively cheap components like switches and knobs and looking for the more expensive ones such as an interface card and driver software which will connect your bits to your PC. You may well find lots of choices as to how to proceed, but you need to go to the right forums. Good luck! Pete

I really cannot understand anything preventing keyboard use, whether on exit from a dialogue or not. Such things are usually just indicative of something being busy, probably with disk access, yet you seem to imply that FS is running okay but just not reponding to your keyboard. Are you sure this is not simply a delay caused by FSUIPC writing back the FSUIPC.INI file, which it will certainly do on exit from the options? This should take no time at all, but if your disk is getting full or, especially, if it is getting fragmented, it may become noticeable. If this is the case you would probably notice some delays in quite a few operations, not just those involving FSUIPC options. I assume these are all merely keypresses forwarded to the PMDG panel? FSUIPC has no idea what the keys mean, it will simply be sending them on, so for differences like this you really need to ask the PMDG folks. You could also, of course, compare results using the same keypresses on the actual keyboard. Again, if these are programmed as keypresses, there are no possible differences to FSUIPC. All these inconsistencies must be something to do with the way PMDG does things. To eliminate possible problems with the GF side of things you could swap over, say, the CMD and APP with the SPD and CRS, or whatever. If it is the GF buttons then the same actual buttons should still give problems. If the problem goes with the function then it is either the PMDG panel giving the unreliability, or maybe the key-press combination selected is also invoking something else. In the latter case try assigning different combinations. To be honest I have never found any panel driven by keycodes to ever work reliably and predictably. Wilco's 767PIC was the same -- I tried programming the original version of that for my PFC gear, and had to do it all with keypresses. It was dreadful. Version 1.3 came out with a programmable interface for many of the controls, and this was a 1000% improvement. I had hoped that PMDG would provide a programmable interface I could use, but as far as I know they intend instead to sell an SDK for equipment developers, so I wouldn't be able to provide support in FSUIPC. Possibly GoFlight will buy this and provide some drivers for your kit which will work -- it would be worth writing to both of them about this so they recognise that there is a need, a demand. Erif they were defined correctly then re-defining them exactly the same cannot make any difference. Identical data replaces identical data. It's all the same. FSUIPC doesn't implement forgetfulness :wink: . The data is either correct and works or it isn't. I respectfully suggest that the only explanation has to be that some of the settings were incorrect. Maybe you didn't notice these errors, but really there is no other possible explanation. All rotaries are implemented to look like on/off switches. Each click either turns the switch on or off. To get an action on every click you have to program the same function both on "press" and on "release". (I'll add a note to the FSUIPC document about this). If it is working okay it is better to leave that parameter out, please. This should give the best results. If it doesn't, I'll need to know, please. I have to get the defaults set to the best and most reliable settings. What concerns me now is that we don't know what was wrong with your installation as it was. Could it just possibly have been something related to the PMDG panel? It is a very very complex piece of work, and I'm thinking that somehow it got into a strange state, which has been fixed by your fresh installation. Did you do any elimination to check this earlier at all, such as by trying things with default aircraft rather than such a complex one? Have you loast the original installation onw? Anyway, thank you for the detailed report. Without determining whether your problems are/were due to the complex PMDG panel or not, it is really not possible for me to determine to do anything. At least you seem to have proven that, in themselves, the changes I have made up to 3.299 are not harmful, as I was frightened of by your earlier reports. Regards, Pete

Please calm down, or we cannot discuss anything. i have not changed anything relating to that option. Please check it first with a default aircraft. If t works with a default then I'm afraid you need to ask the aircraft authors for assistance. It is quite easy for any aircraft maker to override almost any of the FSUIPC options. Regards, Pete

Amazing! So, do you have to reset it each time you change some configuration item like this? Oh, rightvery clever! Sounds like a good device -- but expensive no doubt? Does it come with NavData just for one location, or can you get world-wide coverage? Regards, Pete