Pete Dowson

If the makers of these panels have not provided any keyboard shortcuts or other controls, and don't support the standard FS controls for these aspects, then you cannot, I'm afraid, except possible with something like Luciano Napolitano's "Key2Mouse" which allows you to convert keypresses to programmed mouse clicks. Because PM provides a means of doing this. In fact it provides TWO methods -- keyboard shortcuts, and a more direct method via FSUIPC offsets -- both of which are clearly published. Regards, Pete

I'm sorry, but I can't get my head around this one. Where are you getting the extra lever movement for reverse from, or do you just want it to go immediately from idle to full reverse? Wouldn't two levers in series do the job, with some sort of mechanical method of stopping the reverse lever moving back before the main lever was at idle? I'm not saying your idea won't work, but I don't know how at present. Maybe you need to conduct an experiment? Pete

I'm sorry, but I can't get my head around this one. Where are you getting the extra lever movement for reverse from, or do you just want it to go immediately from idle to full reverse? Wouldn't two levers in series do the job, with some sort of mechanical method of stopping the reverse lever moving back before the main lever was at idle? I'm not saying your idea won't work, but I don't know how at present. Maybe you need to conduct an experiment? Pete

The version of FliteStar (actually FliteMap) I have was purported to be 8.51 (the update was received only a few weeks ago), but the Help-About details say it is "Version 8.5 (Build 5204)". FStarRC 1.82 is working fine with it both under Win98SE and (for the first time) in Windows XP. Please check your Help-About details and let me know. I know of at least two other users who are using 8.51 + FStarRC 1.82 with no problems -- the only problem previously reported turned out to be due to wrong/different options chosen for the Nav Log. Unfortunately, FStarRC is very fussy about this -- the only way I could get at the data was to intercept the printing commands to Windows and recognise data according to context, page position, and also bycounting fields to some extent. There's some flexibility in format allowed, but not a lot. Check my previous reply here and see if the Nav Log options are set like mine. If still no joy, set "Log=Debug" in the INI file and do a short FliteStar session (print the Nav Log of an existing plan). Zip up the resulting Log file (it will be quite big), along with your INI file, and send it to me. Also please FAX the resulting printed Nav Log to +44 1782 379017. Please don't scan it and send it as an image. I'm only on dial-up and such files are far too big! Regards, Pete

The version of FliteStar (actually FliteMap) I have was purported to be 8.51 (the update was received only a few weeks ago), but the Help-About details say it is "Version 8.5 (Build 5204)". FStarRC 1.82 is working fine with it both under Win98SE and (for the first time) in Windows XP. Please check your Help-About details and let me know. I know of at least two other users who are using 8.51 + FStarRC 1.82 with no problems -- the only problem previously reported turned out to be due to wrong/different options chosen for the Nav Log. Unfortunately, FStarRC is very fussy about this -- the only way I could get at the data was to intercept the printing commands to Windows and recognise data according to context, page position, and also bycounting fields to some extent. There's some flexibility in format allowed, but not a lot. Check my previous reply here and see if the Nav Log options are set like mine. If still no joy, set "Log=Debug" in the INI file and do a short FliteStar session (print the Nav Log of an existing plan). Zip up the resulting Log file (it will be quite big), along with your INI file, and send it to me. Also please FAX the resulting printed Nav Log to +44 1782 379017. Please don't scan it and send it as an image. I'm only on dial-up and such files are far too big! Regards, Pete

Okay, so far so good. Hmmm --- this IS the Navigation Log selected by the "Reports" isn't it? Can you make a note of what report options you've got set -- with the Navigation Log displayed on screen, right click. In the menu which items are ticked? Then click on 'Optional Blocks'. Which items are ticked there? There may be some dependency on the formatting. I've not heard from anyone else with a problem, but just in case, try setting the same options as I have -- select "Expanded Log" and "Medium" in the first right-click menu, and the ALL of the optional blocks (not "Hide All"). If still no joy please send me your FStarRC ini file. In the worst case I shall ask you to edit it to turn on a Logging facility. Pete

Okay, so far so good. Hmmm --- this IS the Navigation Log selected by the "Reports" isn't it? Can you make a note of what report options you've got set -- with the Navigation Log displayed on screen, right click. In the menu which items are ticked? Then click on 'Optional Blocks'. Which items are ticked there? There may be some dependency on the formatting. I've not heard from anyone else with a problem, but just in case, try setting the same options as I have -- select "Expanded Log" and "Medium" in the first right-click menu, and the ALL of the optional blocks (not "Hide All"). If still no joy please send me your FStarRC ini file. In the worst case I shall ask you to edit it to turn on a Logging facility. Pete

No, they are not inverted in FSUIPC. FSUIPC merely pulls the names out of CONTROLS.DLL. The actual control names are inverted in FS. I have noted that somewhere I think. I cannot fix MS code, sorry. That's because the repeat is set differently. I have a fixed repeat rate in FSUIPC, which is suited to mundane things like flap changing. I could probably offer a repeat rate adjustment for each control, but I am not considering any more enhancements this year. Ask again after Christmas please. Meanwhile, why not use FS assignments? FSUIPC is really only intended for those things you can't do in FS without it. No. The PM side is totally different in any case -- there is it a matter of cycle time on WideFS. WideFs operates at the FS frame rate at maximum. But PM's MCP needs to read the bit changes then send bit changes to the ND which then has to read them. Each PM component has its own cycle time (set in its INI), usually 100-150 mSecs. Add it all up and you probably can only get about 2 changes per second. If that's no good for you use KeySends and local keypresses for PM's ND. Maybe it would be better for each PM component to read the commands directly, but you'll have to discuss that with Enrico. Pete

No, they are not inverted in FSUIPC. FSUIPC merely pulls the names out of CONTROLS.DLL. The actual control names are inverted in FS. I have noted that somewhere I think. I cannot fix MS code, sorry. That's because the repeat is set differently. I have a fixed repeat rate in FSUIPC, which is suited to mundane things like flap changing. I could probably offer a repeat rate adjustment for each control, but I am not considering any more enhancements this year. Ask again after Christmas please. Meanwhile, why not use FS assignments? FSUIPC is really only intended for those things you can't do in FS without it. No. The PM side is totally different in any case -- there is it a matter of cycle time on WideFS. WideFs operates at the FS frame rate at maximum. But PM's MCP needs to read the bit changes then send bit changes to the ND which then has to read them. Each PM component has its own cycle time (set in its INI), usually 100-150 mSecs. Add it all up and you probably can only get about 2 changes per second. If that's no good for you use KeySends and local keypresses for PM's ND. Maybe it would be better for each PM component to read the commands directly, but you'll have to discuss that with Enrico. Pete

No. FSUIPC saves all its setting in its INI file. You don't have to. When you select it, the options are set that way for you in the INI file. They'll only change if you change them. That's what INI files are for, to remember options for each load. No idea. Sorry. Either a faster processor or maybe tweaks to WidevieW? Perhaps this is a question for the WidevieW forum? No, it can't be. It has no control over graphics. If you have exactly the same scenery installed in all the FS's then it's a graphics card or driver problem. If the two clients are identical they should perform identically. Compare the graphics card drivers, et cetera. Pete

No. FSUIPC saves all its setting in its INI file. You don't have to. When you select it, the options are set that way for you in the INI file. They'll only change if you change them. That's what INI files are for, to remember options for each load. No idea. Sorry. Either a faster processor or maybe tweaks to WidevieW? Perhaps this is a question for the WidevieW forum? No, it can't be. It has no control over graphics. If you have exactly the same scenery installed in all the FS's then it's a graphics card or driver problem. If the two clients are identical they should perform identically. Compare the graphics card drivers, et cetera. Pete

Did you get "Flightmax Remote"? I think you need both parts. It is rather complex -- check the Flightmax website. I know it can be done, but it isn't simple. Pete

Did you get "Flightmax Remote"? I think you need both parts. It is rather complex -- check the Flightmax website. I know it can be done, but it isn't simple. Pete

I'm not familisr with FDC. Have you tried FDC support? Else I hope someone else can chip in here. Pete

I'm not familisr with FDC. Have you tried FDC support? Else I hope someone else can chip in here. Pete

A known bug in ActiveSky? I don't know it, but I don't use ActiveSky. Has he determined the cause?

A known bug in ActiveSky? I don't know it, but I don't use ActiveSky. Has he determined the cause?

Do you want the positions of the airport's as defined by where the visual scenery is placed, or where the AFD (airport facility data) says things are? They are distinct and come from separate types of BGL file. The airport runway thresholds, taxiways, parking spots and tower positions are defined in the AFDs. Programs like AFCAD and Trafficboard are capable of reading those and displaying maps. I have a program which scans them all and produces databases for FStarRC and for Radar Contact 3. The FStarRC file is binary, but the RCV3 one is CSV (comma separated variable format) and can be read easily. It also produces a text file giving most details, but this becomes huge. For visual scenery there used to be a number of programs around which could decode or disassemble them and provide source-type readable definitions, but I've forgotten their names now. They may not even work any more. Last I was interested in this stuff was FS5. Maybe a Google search will get you somewhere. If you are thinking of writing your own BGL decoder to get information you want, then the MS Scenery SDKs are needed. Regards, Pete

Do you want the positions of the airport's as defined by where the visual scenery is placed, or where the AFD (airport facility data) says things are? They are distinct and come from separate types of BGL file. The airport runway thresholds, taxiways, parking spots and tower positions are defined in the AFDs. Programs like AFCAD and Trafficboard are capable of reading those and displaying maps. I have a program which scans them all and produces databases for FStarRC and for Radar Contact 3. The FStarRC file is binary, but the RCV3 one is CSV (comma separated variable format) and can be read easily. It also produces a text file giving most details, but this becomes huge. For visual scenery there used to be a number of programs around which could decode or disassemble them and provide source-type readable definitions, but I've forgotten their names now. They may not even work any more. Last I was interested in this stuff was FS5. Maybe a Google search will get you somewhere. If you are thinking of writing your own BGL decoder to get information you want, then the MS Scenery SDKs are needed. Regards, Pete

Sorry, I cannot answer questions on future products yet. Ask again in August or so. I may have time to look at GPS programming some months *after* FS9 release, but certainly none before. However, if FS9 provides the controls (FS2002 didn't), the GPS buttons on the PFC Avionics stack could be re-programmed by the user through FSUIPC in any case. All PFC buttons and knobs can be programmed through FSUIPC, the only thing stopping the GPS being used this way in FS2002 is that Microsoft provided no controls for it at all. The Cirrus II itself, with no Avionics stack, will never be amenable to a GPS control console of course. It just hasn't got the right buttons and knobs. Pete

Sorry, I cannot answer questions on future products yet. Ask again in August or so. I may have time to look at GPS programming some months *after* FS9 release, but certainly none before. However, if FS9 provides the controls (FS2002 didn't), the GPS buttons on the PFC Avionics stack could be re-programmed by the user through FSUIPC in any case. All PFC buttons and knobs can be programmed through FSUIPC, the only thing stopping the GPS being used this way in FS2002 is that Microsoft provided no controls for it at all. The Cirrus II itself, with no Avionics stack, will never be amenable to a GPS control console of course. It just hasn't got the right buttons and knobs. Pete

I assume "InnerMk.wav" exists in the default sounds folder? ENGINE1_STARTER_SWITCH_POS is *always* >= 0, so there's never the change occurring which you are expecting. You need to understand the values you are testing in order to use them. Esound only triggers a sound on the condition changing from FALSE to TRUE. If it is always TRUE you won't hear a thing. Pete

I assume "InnerMk.wav" exists in the default sounds folder? ENGINE1_STARTER_SWITCH_POS is *always* >= 0, so there's never the change occurring which you are expecting. You need to understand the values you are testing in order to use them. Esound only triggers a sound on the condition changing from FALSE to TRUE. If it is always TRUE you won't hear a thing. Pete

You only show part of the story. There will be a different point at which the change of flaps is made in each direction -- there's no "specific" value for each, but a range. For example, I've just calibrated an ordinary throttle axis as a flaps control. With the default 737 I get: Min = -16193, Max = 16192 (same as you!) Increasing IN OUT = Flap Decreasing IN -16193 0 0 -14567 -14026 2047 1 -10232 centre -12129 -9691 4094 2 -6439 centre -8065 -5898 6141 5 -2104 centre -4001 -1563 8188 10 1968 centre 202 2476 10235 15 6032 centre 4252 6540 12282 25 10096 centre 8318 10604 14329 30 13652 centre 12128 14160 16376 40 You see that because there are 8 intervals between the 9 flap positions, the average "space" per position for a range of 32385 (-16193 to 16192) is 32385/8 = 4048, which is approximately shown by the ranges used and the centres thereof. The two ends will half the range one way (complementary ways), as clearly seen. I don't know why you are expecting things to change on a 2048 increment, it could be up to 4096 at the extreme, for a clibrated range of -16384 to +16383. Really, I think, as I stated before, that you are expecting this to work in a way which was never intended. The idea behind it was that you calibrate the LEVER to suit the sim, not calibrate the sim to suit a pre-made notched lever. I think that is your only problem. As far as I can see there are only two possible solutions, one is to write a program to convert your specific range of readings into specific flap selections, using FSUIPC interface (or waiting till I have time to add such a facility), or to replace your potentiometer by a rotary switch with 9 different fixed or trimpot resistors, calculated to get near the centre of each flap position range. Regards, Pete

You only show part of the story. There will be a different point at which the change of flaps is made in each direction -- there's no "specific" value for each, but a range. For example, I've just calibrated an ordinary throttle axis as a flaps control. With the default 737 I get: Min = -16193, Max = 16192 (same as you!) Increasing IN OUT = Flap Decreasing IN -16193 0 0 -14567 -14026 2047 1 -10232 centre -12129 -9691 4094 2 -6439 centre -8065 -5898 6141 5 -2104 centre -4001 -1563 8188 10 1968 centre 202 2476 10235 15 6032 centre 4252 6540 12282 25 10096 centre 8318 10604 14329 30 13652 centre 12128 14160 16376 40 You see that because there are 8 intervals between the 9 flap positions, the average "space" per position for a range of 32385 (-16193 to 16192) is 32385/8 = 4048, which is approximately shown by the ranges used and the centres thereof. The two ends will half the range one way (complementary ways), as clearly seen. I don't know why you are expecting things to change on a 2048 increment, it could be up to 4096 at the extreme, for a clibrated range of -16384 to +16383. Really, I think, as I stated before, that you are expecting this to work in a way which was never intended. The idea behind it was that you calibrate the LEVER to suit the sim, not calibrate the sim to suit a pre-made notched lever. I think that is your only problem. As far as I can see there are only two possible solutions, one is to write a program to convert your specific range of readings into specific flap selections, using FSUIPC interface (or waiting till I have time to add such a facility), or to replace your potentiometer by a rotary switch with 9 different fixed or trimpot resistors, calculated to get near the centre of each flap position range. Regards, Pete