Pete Dowson

I use FliteMap by Jeppesen, linked to FS by my GPSout on a serial cable. This is a realy professional solution, but it is expensive. There's a program called Nav3 by Ted Wright which I used to use. Maybe it is Nav4 or something later by now. Nav3 dates back to FS98 at least. There are programs like FlightMax, which had a "FlightMax Remote" part which would work on WideFS, but I understand that the website is now closed. Maybe a search for FSutilities would get results? If you are dead set on FS Navigator, the best solution is to add a second monitor to your main FS PC and move its screen there. Most modern video cards support two monitors (two VGA or a DVI and a VGA), or you could get a cheap PCI card for the second monitor. There are quite a few folks who've adoped this solution. Pete

Yes, it shows that FStarRC is not able to hook into the printing routines on your system. Are you using Win2000 or NT? I don't think it will work on those. I only just narrowly managed to make it work on XP -- but maybe you have to be the Administrator. The techniques it uses are probably not allowed otherwise. They are the same techniques used for debugging programs and hacking into others, so I think an ordinary XP user might be prevented from doing this. No don't bother. It is not getting anywhere close to even looking at that. If it cannot hook the routines it can do nothing. Of course, because it is not able to hook into it. The only reason I would have wanted to look at the output was if the format of the printing had changed between the version of FliteStar I am using and the one you have. As I said, the method is very sensitive in this regard. If you can get it working by running on Win98/Me or by using XP as administrator, let me know how please. I've never actually logged into XP as anything but me, so I'm not aware of what's involved. Maybe I need to adjust the FStarRC documentation. Pete

Yes, it shows that FStarRC is not able to hook into the printing routines on your system. Are you using Win2000 or NT? I don't think it will work on those. I only just narrowly managed to make it work on XP -- but maybe you have to be the Administrator. The techniques it uses are probably not allowed otherwise. They are the same techniques used for debugging programs and hacking into others, so I think an ordinary XP user might be prevented from doing this. No don't bother. It is not getting anywhere close to even looking at that. If it cannot hook the routines it can do nothing. Of course, because it is not able to hook into it. The only reason I would have wanted to look at the output was if the format of the printing had changed between the version of FliteStar I am using and the one you have. As I said, the method is very sensitive in this regard. If you can get it working by running on Win98/Me or by using XP as administrator, let me know how please. I've never actually logged into XP as anything but me, so I'm not aware of what's involved. Maybe I need to adjust the FStarRC documentation. Pete

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

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