Pete Dowson

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

There's no big rush, though obviously I'm a bit worried. What I normally do, and would recommend if you have enough disk space, is rename your current FS folder then install a completely virgin copy again, using the same original install folder name. Check it all out, make sure it does the things you think it should, then rename its folder "FS9orig" or something and then change your older, full, molested copy back to its original name. This gives you a reference copy with which to compare things and also copy things back when in doubt. you can also use the otherwise "virgin" copy as a test bed for individual add-ons to make sure you've not got some interaction between them. First check is that PollInterval parameter. If that makes the GF buttons work okay again I have some logging which may tell me what is going on, but one step at a time. If there's no difference with the PollInterval addition I'll need to think further. Regards, Pete

Just as an extra test, I went into FS's Options-Controls-Assignments and deleted the assignment to the Hat there, then went into FSUIPC's Keys page and assigned the hat switch values to the 4 main Pan directions. I only used the main 4 directions, though this hat returns 8 codes, 4 for the quarter views each side too. The 4 main directions turned out to provide "button numbers" 32, 34, 36 and 38. The Pan controls were Pan Left, Pan Right, Pan Up and Pan Down (but not necessarily in the same order) The [buttons] entries for this are: 10=R1,34,C65672,0 11=R1,38,C65671,0 12=R1,32,C65734,0 13=R1,36,C65735,0 (for example). As you see, I engaged Repeat as well. These worked exactly the same as the FS control on the "Hat Switch". So, to see if I could get them interfering I left the FSUIPC ones programmed and went back and reassigned them in FS as well. result -- still okay. maybe a bit faster (understandably), but not noticeably so. Finally, I left both sets allocated -- i.e. FS assignments and FSUIPC assignments, but went into FSUIPC and reversed left/right and up/down. Now I still get it working, but slow and jerky -- the FS assignment is obviously "winning". But the one certainly doesn't cancel out the other and give that little "twitch" effect you are getting. Mind you, differences in computer speed and therefore repeat rates could change that I suppose. My conclusion from all this is that, assuming you've not got "view reset" or similar programmed somehow to the same buttons, then either something in FS itself has become corrupted, or you have some other add-in module or gauge which is interfering with this. Sorry I'm not able to solve it. Regards, Pete

Running WinXP? Right. In that case I cannot understand what you mean by "losing FS9.cfg". I can't see how that can happen. Whilst developing software for FS I am often crashing FS or leaving it in odd states, but never once have I had to resort to a backup of FS9 or delete it and lt it make a new one. It really sounds as if something rather odd is going on with your system. Have you considered re-installing FS9 from scratch? It might be well worth it. Whatever you do with FSUIPC is easily reversible just by deleting the FSUIPC.INI file, or in this case, at least its [buttons] sections. It doesn't hide anything anywhere else, nor affect anything else, only its own behaviour. I'd not used this before, but I just went into my test installation version of FS9 (one which gets really mucked about with all my tests, crashes and all), connected a little Saitek gamepad which has a "hat", told FS to revert to default assignments, and the hat controls now views in 2D mode and pans in VC mode, in all 4 directions. Checking the Assignments, the setting there is simply "View (pan) == Hat Switch". There are no separate assignments for each direction. Possibly that where yours is going wrong? The entry in FS9.CFG that this makes is: POV_MOVE_EVENT_00=PAN_VIEW POV_MOVE_REPEAT_00=1 I really cannot understand how anything, even FS crashing in midstream, can mess up the FS9.CFG file! What actually happens to it? I am finding your experiences most perplexing and quite outside anything I've ever heard of. And please, what do you mean "the key commands .." causing a problem? I am extremely worried about your experiences with FSUIPC and GF buttons. It is quite the opposite of all the other reports I have, and although it is a very much minority finding, it is enough to prevent any further FSUIPC general release until it is resolved. I am therefore utterly dependent upon you for trying to understand what is happening, why it is only on your system, so that I can resolve it between now and the next release. I understand it may be frustrating, but if you are prepared to try some tests please let me know. To start with, the reults of again including the "PollInterval=66" line in the FSUIPC.INI file's [buttons] section would be useful, please. Regards, Pete

The ones used in gauges are the FS controls, the same as those which can be assigned in FS Options-Controls-Assignments, and the same as listed in FSUIPC Keys and Buttons pages for assignment. The complete list of all of these is given in my FS Controls list documents, one for each version of FS -- see . In fact the names used there (and in my drop-down lists) are mostly the same as the Gauge SDK Key names but without the KEY_ part at the front. No. Offsets 3200-320B are for sending key strokes to FS, emulating the keyboard, exactly as it says in the FSUIPC Programmer's Guide. The facility to send FS Controls is at offsets 3110-3117. Regards, Pete

Yes, but it serves to show you what a problem I face when naming or describing the values I find. The ones you have been referring to are, I think, all directly derived by tracing them through from panel type values, through the PANELS.DLL into SIM1.DLL, which is the module which owns them and maintains them as private data. Unless folks find otherwise, all I can assume is that the way they are named in the Microsoft SDKs is somehow descriptive about what they do. Not being an aircraft designer or even a user of any of these variables, I can only add to the Guide the information I can glean from things like SDKs and things folks tell me. Mine too. This is why I referred you to the SDKs so you could see the source of the confusion! :wink: Regards, Pete

Erthat is very odd, as this is the precise version that several other GoFlight users have confirmed works most responsively and consistently! There have been problems in some of the development versions beteen 3.22 and 3.229, and the one I sent you resolves all of them for my other testers, and performs excellently here too! No, that problem is most definitely removed. There is no possibility of it occurring with 3.229, as the code responsible is binned. Sorry, I cannot imagine what is going on there. Losing your FS9.cfg file?!?! What on Earth does that mean? FSUIPC has absolutely nothing to do with the FS9.CFG file. It cannot get "lost" in any case -- if one doesn't exist when you load FS, it gets generated again. Are you sure you are looking in the correct place to check/edit/delete the FS9 file? It isn't in the FS folder you know! Assuming you are using WinXP it is in your Documents and Settings\\Application Data\Microsoft\FS9 folder. Sorry, your panning in VC mode is completely beyond me. I don't even use VC mode (never have) so I'm not sure what to expect. But if you cannot get FS to obey its own controls in any case it sounds as if something is corrupted. If it is simply that you have a messed up FS9.CFG file, which you may have, then try locating it and dealing with it. However, you have me very worried about the GoFlight button recognition, as that has been subject to much improvement between FSUIPC version 3.22 and the 3.229 I sent you. I am currently delighted with the much more sensitive response I now get (a quick touch on a button is now detected whereas previously I had to press and hold a short time). Other testers have also found 3.229 an improvement! Can you tell me more about your system please? I'm rather curious to know why your experience is so different from everyone else's. You can also try again adding the PollInterval=66 line into the main [buttons] section of FSUIPC.INI. This effectively reverts the response time for all buttons to 3.22 levels. Regards, Pete

You've almost hit the nail on the head. FS actually does a lot less when minimised. It also (as implied earlier in the thread) gets a much lower timeslice priority from Windows. One of the things it does less is call the gauges in the panels with updated values for display. In fact, I don't think it even bothers to do this. Now, FSUIPC uses these same calls (well, the same origin) to maintain many of the values -- not all of them, as FS itself does still provide some directly (very few these days, less with each release), and others have been mapped by FSUIPC directly into the memory locations where they are updated by FS. But there are quite a few values which FSUIPC actually has to get at regular intervals by calling FS procedures or by calculating them from other things, or both. When FS is minimised, FSUIPC reverts to the FS timer tick calls (18 per sec) for operations -- it uses these in any case for all of its time-related operations. But because it then knows FS is minimised, it only goes and gets the variables at about a 4-8 fps rate. None of this affects how fast you can call FSUIPC and get a response. All that will happen is that, for the now infrequently maintained variables, out of your 31 to 47 calls per second, the same values will be provided for perhaps 4 to 11 calls in a row. (The attitude indicator values are such variables BTW). This is part of the reason you will get a higher rate with FS minimised -- FSUIPC is doing less. The other reasons are that FS is doing less, and your program gets a higher priority, being foreground, so gets control back quicker after each call. Regards, Pete

Well, FS doesn't provide any separate axes for reverse at all. In fact it doesn't even provide reverse on the standard throttle axis, only only the separate engine throttles. Currently you can get separate reversers basically by reserving a zone on each of the separate throttles. You calibrate the axis to give the "idle" zone where you have it fixed on the quadrant. If you are building your own hardware it probably isn't too hard to arrange for the extension to the throttle lever which is the reverser lever to allow the same axis to return values below idle -- i.e. in the reverse zone. That would be the correct way to do it. The reason I provided a separate single reverser input for all engines was that those using a single throttle lever assigned normally to all engines had no easy way to engage reverse otherwise, except either using the F2 keypress or mapping the single throttle to the 4 separate ones. Since it is most unlikely that someone would actually allocate 2 or more axes for reverse whilst only having a single throttle lever, the facility for multiple reverser axes never gained any level of priority on my list. In fact if you do have separate throttles you more or less have to deliberately calibrate the reverse zone out of them to make a separate reverser useful. Anyway, it is still on the list, though I don't really know whether it should be raised in priority. Maybe you can review what I've said here and give me an argument for its greater importance? Thanks, Pete

I'm not sure which ones you mean, but many of the labels used for variables in FS are derived from one type of simulation and just re-used for others when it seems applicable. If you'd like to be rather more specific I can perhaps be more explicit. For more information on the sorts of names and labels used in FS you could try getting the Panels SDK from the Microsoft website. You'll find the documentation on gauge making interesting (and confusing if you tend to like things rigidly compartmentalised). Also a browse through the Gauges.h header file is illustrative. Regards, Pete

Thank you! I will add some more explanatory text to the Guide, along the lines you have provided. Thanks again, Pete

Yes, fine, but those are probably for selecting what you want the GPS to output to the PC or whatever it is you want to receive GPS data. It is most unlikely to be anything to do with its input capabilities, but I would love to be proved wrong. In most cases you would need two if not three of the sentences -- the inefficiency is when listing more than the unit can understand, especially at a slow connection rate. The default 4800 NMEA rate is too slow for many sentences in any case. I noted that your unit can support faster than 9600, so there should be no problem -- just set it and GPSout as fast as both will go. How did you tell the unit to switch its own GPS off and feed the display from the NMEA input? Is it even possible? This is where I have my doubts -- I still think you are trying to make it do something it is not designed to do. Regards, Pete

That's okay, they are alternatives. I can see that, like most GPS units, it can provide NMEA 0183 output. You use that for driving a moving map, or even, as it says, for an autopilot. The picture showing the COM port configuration has a checkbox for NMEA input too, I see, but nowhere does it mention what it is for. It may simply be for the transfer of waypoints or something. Can you actually find anything that switches the GPS's own satellite reception and indications off so that external data can be accepted and used instead? Obviously it cannot accept and show positions from NMEA at the same time as it does its main job as a GPS! Ooops! Is that old error still there? Sorry. Yes -- there's no GPRMZ. It's a typo for PGRMZ. PGRMZ is okay. Sorry -- I sent the first reply too hastily. But there's no support for PGRMS. I don't even know what it is (a typo? :) ). Originally I used the sentence names as they are generally known in the NMEA spec -- RMC, RMA and so on. The "GP" is a prefix common to all the standard ones, so it isn't used. But the "P" series are "Proprietary" -- PGRMZ is "Proprietary", "GaRMin", "Z". I assume Garmin have others too, this is just its "Z" one. I really don't know -- this is a matter for the GPS and its manual I think, and it doesn't seem to say. I really do doubt that it will do what you want it to, but you may need to go to their tech support to find out. Regards, Pete

Sorry, I don't understand this -- can you elaborate please? Pete

I doubt if the numbers of pumps decrease -- it is whether the data has been located in the innards of FS that dictates whether FSUIPC can offer it! Is there an "Ok" in the "FS2004" column? If not then it hasn't been verified. Check it yourself and if works let me know and I'll add the "Ok". This is the way it works -- I simply cannot test every entry myself even if I did understand them all, which I don't. If there is an "Ok" then it is Ok. That's what it means. There is also a column for FS2002 -- but of course some of the entries were added after FS2002 was released, so then you'd get the confirmation in the text. I simply haven't got time to edit all the text and say "FS2000/FS2002 only, but maybe also FS2004 when someone confirms that it works there too". Sorry. this was why the columns were added several years ago. I think it defines the type of engine. Maybe some engineers here can tell you, otherwise I'd neede to refer to a dictionary. Sorry. Not sure, but it possibly tells you the number of fuel tanks in use or available on the current aircraft? Can you check this? If so then I'll add that explanation. I would think that a fuel tank selector selects fuel tanks whilst the number of fuel tanks counts them, but I'm sure you could verify this or not by using FSInterrogate and experimenting. Regards, Pete

I very much doubt that your GPS recognises all these -- and certainly the AV400 format will muck the NMEA sentences up somewhat in any case as that isn't NMEA at all. Additionally you have lots of errors. There are no entries GPRMZ, PGRMZ, VTGGGA at all. There are RMZ, VTG and GGa but you aren't listing them correctly at all. The only sentences you can ask for are those listed -- please check the documents provided more thoroughly, and you will see. No one here can tell you which of your connectors are which -- if they are not labelled then the documentation that came with your PC or its motherboard should tell you. Generally the top one (the one nearest to the power supply) is COM1. FS. GPSout is loaded when FS loads, and it reads the INI file then. No. No idea -- you'd need to see if the GPS has some sort of test or display mode. To be brutally honest I very much doubt whether your GPS is capable of being used with NMEA input. Not many are. Why do you think it mught work in the first place? GPSout is designed to make FS look like a GPS for moving map programs which are designed to accept the output from GPS units. It was never designed to feed satellite type signals into an actual GPS, though there are apparently a few which can apparently override their own signals with inputs, but only via AV400 format so far, not NMEA. This was a surprise to me in any case. Regards, Pete

There is a potential problem with the 'repeat' action in FSUIPC 3.22 -- it can run away. But this would be the opposite of the symptom you are mentioning. However, just in case this is the problem I am emailing you an interim test version of FSUIPC to try. Otherwise please tell me exactly what you've tried to program and I'll see if I can reproduce it. The panning versus view-change operations in FS2004 are rather confusing in any case, and are different between normal and virtual cockpit views. If you want FS to pick up and re-configure itself for your joystick connections you may need to delete the FS9.CFG so it effectively starts again. The "reset defaults" option in Options-Controls-Assignments doesn't seem necessarily to re-establish joystick parts which it has stopped dealing with. Regards, Pete

Why not program these in FS assignments -- or even let them default. I think Fs assigns pan views to hats in any case, doesn't it?? Are you programming them in FSUIPC using Keypresses or FS Controls? Did you make sure your buttons (hat switch values) are not also programmed in FS anyway -- it sounds as if your have more than one action going on with the left/right? FSUIPC cannot stop FS reading button presses just because they are detected in FSUIPC as well. It is different for key presses as FSUIPC can actually intercept those. Let me know exactly how you programed them please. Regards, Pete