Pete Dowson

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

You didn't attach any CFG file? Pete

You didn't attach any CFG file? Pete

Hmm. I don't know. That does sound wrong. Which aircraft is it? I'd like to reproduce it here if I can. Can you list the flap positions for me so I can set it up the same here, please? And also, if you can, the range of inputs for each output that you are getting. I'll certainly check to make sure there's not a bug in FSUIPC. It seems unlikely as the code is the same for each movement, it is only a simply calculation. Pete

Hmm. I don't know. That does sound wrong. Which aircraft is it? I'd like to reproduce it here if I can. Can you list the flap positions for me so I can set it up the same here, please? And also, if you can, the range of inputs for each output that you are getting. I'll certainly check to make sure there's not a bug in FSUIPC. It seems unlikely as the code is the same for each movement, it is only a simply calculation. Pete

Ah, by linking it by wires, yes. But it is still the client computer playing the sounds so it still needs a sound card. Of course it still seems to me that re-mixing the ATC into the general FS sounds spoils much of the whole point of running RC on the client. Pete

Ah, by linking it by wires, yes. But it is still the client computer playing the sounds so it still needs a sound card. Of course it still seems to me that re-mixing the ATC into the general FS sounds spoils much of the whole point of running RC on the client. Pete