Pete Dowson

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

All the process of updating is: simply copy FSUIPC.DLL into the modules folder. There is nothing else to do. Do NOT remove or change any other FSUIPC file like the INI or KEY file. If, when you do install 3.22 correctly, you only have the main "About" page and the "Logging" page, what does it say on the About page please? Show me the Log files with 3.129 and 3.22 so I have a chance to see what is going on. Regards, Pete

Great! Glad you got it sussed! Pete

Possibly this is part of why I have problems with it. I've never liked higher level languages at all in any case. C is about as far away from the machine as I ever want to be -- C++ is too far! :) I grew up from the machine code (hardware & bits) end of things and have always programmed bottom-up, not top-down. I hate not knowing what my programs are really doing with the machine. Windows is enough of a barrier for me without adding more artificial ones. It all depends on your viewpoint, I guess. :wink: I'll have to take your word for that :D :D Regards, Pete

Ouch! When FS is running minimised most of the information which it would normally provide for panel gauges and so on is not supplied very often -- the calls it makes into FSUIPC notifying of these are completely diminished and FSUIPC switches over to timer based operation and maintains an effectively low update rate. Really? That's odd as FSUIPC won't be running at more than about 5 fps ("frames" here in terms of values being updated) whilst FS is minimised. Regards, Pete

FSUIPC is reading and setting the value of the pitch and bank for the attitude indicator on every single frame. It sounds like not so much FSUIPC not keeping up, but your program not getting enough processing time to see all the values in such busy periods. And if you are alllowing FS itself to get up to 64 fps, I am not surprised! If you are using a Pentium 4 with hyperthreading you can try assigning FS to one of the virtual processors and your program to the other. That can work. But otherwise, if you want both FS and your program to run smoothly I can only suggest that you force FS to share resources by limiting its frame rate -- Options-Settings-Display-Hardware. Set the Frame Rate Limiter to something acceptable but far more reasonable, like 20, 25 or possibly 30 fps, depending on your processor. The general method of obtaining fluid and consistent performance with FS is to set the Limiter to unlimited initially, and try to assess the average frame rate you get. Then set the limiter to something below that. This advice is from Microsoft themselves, and is for FS running alone. With other programs needing time I'd reduce the limit further. Regards, Pete

Hey, good catch! The AXIS_controls for separate engines were recent additions to FS (i.e. mean in FS2002 probably). When I first added joystick facilities the only one for Prop2 was "PROP_PITCH2_SET" (65924), so that's what FSUIPC actually processes on the 4-props page. To save re-programming lots of things when the new AXIS commands were added, I simply converted all the new ones to the equivalent old ones. Of course, my mistake, when adding the code to look for things like reverser assignments, was to place this code AFTER the conversion to old numbers, not before. I will rectify this in the very next release of FSUIPC. In the mean time there are two possible work-arounds: 1. Declare the reverser axis in the FSUIPC.INI file as number 65924 instead of 66424. You don't have to also change the FS assignment to PROP_PITCH2_SET, but if you don't you will need to remember to change back to 66424 on the next version of FSUIPC (not 3.22 which is out at present). or 2. If you aren't in need of the propeller axes in any case, simply go to the main single controls page and check the "map to 4 props" option. When the single Prop Pitch axis is mapped to the other 4 there is no conversion of the new codes to old in any case, so the problem doesn't arise. Sorry about the hassle. It's on my list, but as no one has actually asked for it until now it keeps getting pushed down. I'll get to it one day. Regards, Pete

WideServer can load programs for you, but it is probably better done with FSUIPC. It's a matter of editing the INI file -- for FSUIPC it is described in the Advanced User's Guide, or made simpler by Jose Oliveira's nice utility "FSUIPC Run Options" available from http://www.schiratti.com/dowson. On a Client PC, you add entries to the WideClient.ini file to get it to load programs. See WIDEFS.DOC. You can use "Run" or "RunReady" parameters to load immediately or load when FS is ready. But in either case there are no facilities for moving windows about. This sounds like some sort of mouse and key sequence. I'm afraid there's nothing in WideFS or FSUIPC which will do that. Doesn't the program remember where it should be and do this itself? If this is Project Magenta's PFD it certainly should do -- I have three copies running on one Client PC using three screens on a Parhelia, and each one (Captain's PFD/ND, Eicas and First Officer's ND/PFD) come up on their correct screen in the correct size, each time WideClient loads them. Regards, Pete

Do you mean you had included "PostKeys=Yes", and now you've taken it out, or the other way round? Here Notepad, for instance, doesn't work with 'PostKeys=Yes'. No problem, glad it is solved. Regards, Pete