Problems accessing flight director fields with FSUIPC.

[Guest fustflum]

I've noticed a problem while attempting to read from a few fields. The flight director pitch, and flight director bank fields in particular (0x2ee8, 0x2ef0) do not seem to contain the information that I had expected. The flight director pitch will remain stuck at a fixed value which is not consistent with the controls in Flight Simulator. The flight director bank is always zero.

At first I suspected this was an error in my client, but I've confirmed this using fslook.

Have you noticed or has anyone else reported this bug before? These two fields are quite critical for the application that I am using FSUIPC for, so I'd like to know if you know of any workarounds or other ways in which I can obtain this data. I'm vaguely proficient in C & C++, so if there's any way in which I can help, I'd love to.

Thanks!

-=Joshua Pollack

[Pete Dowson]

I've noticed a problem while attempting to read from a few fields. The flight director pitch, and flight director bank fields in particular (0x2ee8, 0x2ef0) do not seem to contain the information that I had expected. The flight director pitch will remain stuck at a fixed value which is not consistent with the controls in Flight Simulator. The flight director bank is always zero.

HmmmI don't know those fields, personally. I'm just providing what FS provides -- as you have detected with FSLook, it is in fact what FS provides to allow the FD needles to be programed in gauges.

In the cases where they are not correct, are you saying that the FD bars in FS's gauges are not the same? If you are checking this on an aircraft not equipped with a flight director, then I don't think you'd expect the needle values to be updated. You don't need it to have a gauge with FD, but the AIR or Aircraft.CFG file must show it to be so equipped -- for instance, the [autopilot] section will have "flight_director_available=1". Did you check this? Also, of course, the FD should be active, else the needles won't be updated either.

I've just checked all this with the default FS aircraft with FDs and they seem fine.

Regards,

Pete

[Guest fustflum]

I'm using using the 737-400, which does have flight_director_available=1 in the [autopilot] section of it's aircraft.cfg. The flight director in the simulator window seems to more around just fine, but FSUIPC_Read constantly reports 0 and 0.2868537... for fd bank and fd pitch, respectively.

Thanks!

-=Joshua

[Pete Dowson]

I'm using using the 737-400, which does have flight_director_available=1 in the [autopilot] section of it's aircraft.cfg. The flight director in the simulator window seems to more around just fine, but FSUIPC_Read constantly reports 0 and 0.2868537... for fd bank and fd pitch, respectively.

... and the same in FSLook? They are both simply reading the same thing the gauge must be reading. I cannot make it go wrong here at all -- only in pause or slew mode do the values stop being updated. This is with the default 737-400. It seems to be behaiving just fine.

I really can only pass on to applications what FS passes on to me, or in this case also to the gauges. FSUIPC isn't doing any calculation or derivation at all here. It is merely the "window", not touching anything. And FSLook does not do it from the locations you mentioned, it actually reads the gauge token values in EXACTLY the same way as gauges do!

Regards,

Pete

[Guest]

Out of curiosity, how does FSLook get its data? I thought it was through FSUIPC, through message passing and the like. Can an external non module call lookup_var?

Yes, FSLook reports the same fixed values, while the gauges in the airplane move around normally. On your system, the values in FSLook change?? Ick. Fixing this may be harder than I thought... I'm using FS2K2 running on windows 2000, and I've confirmed this error on two different computers running the same. What version of Flight sim & Windows are you using? I know that it's outside the scope of FSUIPC's involvement but do you have any ideas on what might be causing this, or how I can try to pin the problem down?

Thanks

-Joshua

[Pete Dowson]

Out of curiosity, how does FSLook get its data? I thought it was through FSUIPC, through message passing and the like. Can an external non module call lookup_var?

It uses a special non-supported call to FSUIPC, to do a "lookup_var". It was an original experiment to try to make external gauges using the same sort of system. But it is far too inefficent. FSLook can bring FS to its knees. It was never followed up for that reason. Worse, it cannot be used through WideFS -- WideServer needs to keep scanning values for changes, this method is too slow. I kept FSLook available just as an assist for gauge makers, not for real time use.

Yes, FSLook reports the same fixed values, while the gauges in the airplane move around normally. On your system, the values in FSLook change??

Certainly, they work fine. That's what I don't understand. These values are used by others quite successfully.

I'm using FS2K2 running on windows 2000, and I've confirmed this error on two different computers running the same. What version of Flight sim & Windows are you using?

FS2002 under WindowsXP, another on Win98SE and another on Win2000Pro (I need multiple setups for testing).

I know that it's outside the scope of FSUIPC's involvement but do you have any ideas on what might be causing this, or how I can try to pin the problem down?

Try using FSUIPC IPC logging (see the Technical page) -- you can ask it to log Reads or Writes from your program. Use FSInterrogate also to verify what you are seeing. It doesn't sound right at all. This is not a problem area, not something that ever didn't work. the values are simply there, they don't need processing or coaxing or anything.

Did you confirm which version of FSUIPC you were using? Do you think you may have any other add--in modules which could be interfering with this?

Regards,

Pete

[Pete Dowson]

Something suddenly occurred to me, from an earlier message. One question, Joshua, before this goes possibly way off in the wrong direction, when you say:

The flight director in the simulator window seems to more around just fine, but FSUIPC_Read constantly reports 0 and 0.2868537... for fd bank and fd pitch, respectively.

Can you tell me exactly what modes you have set for the FD to direct? The values you quote sound suspiciously like the exact values which a non-directing FD would show -- the non-bank because there's no heading mode selected, the 0.2 something is a normal default pitch when there's no climb or descent involved.

Is this merely a case of misunderstanding what the FD does? Make sure you set HDG mode on the A/P and adjust the heading so that the FD indicates a turn -- does the Bank still stay zero? Set ALT mode and adjust the Altitude to indicate a climb.

Bank is +ve for right bank, -ve for left, pitch is negative for pitch up, +ve for pitch down.

The values are not NEEDLE positions, they are the pitch and bank values which the needles should direct the pilot towards. How they actually do that, graphically, then depends on the current aircraft pitch and bank, the IAS (probably), and of course the type of inidicators used -- crosshairs and chevrons operate slightly differently. You aren't expecting these values to tell you specifically WHERE to draw the lines, are you?

Please confirm that you HAVE tested all this with an actively directing FD?

Regards,

Pete

[Guest]

I'm awfully sorry it took me so long to follow up on this, I'm spread far too thin....

Is this merely a case of misunderstanding what the FD does?The values are not NEEDLE positions, they are the pitch and bank values which the needles should direct the pilot towards. How they actually do that, graphically, then depends on the current aircraft pitch and bank, the IAS (probably), and of course the type of inidicators used -- crosshairs and chevrons operate slightly differently. You aren't expecting these values to tell you specifically WHERE to draw the lines, are you?

Yep. Yes, yes, yes, you guessed it exactly. I expected the values to be the horizontal and vertical positions of the indicators. Perhaps the variable names were poorly chosen, perhaps the fact that I'm a math geek pretending to be a programmer and not a pilot is finally becoming relevant. =)

Regardless, thank you so much for your patience and your help.

Cheers,

-=Joshua