Busy flag offset (&H11D4) and air file path (&H3C00)

[hsors]

Hi Pete,

Is there any possibility with FSUIPC4 to check for the validity of variable reads? A "busy" internal flag was provided in FSUIPC3 (&H11D4) that was convenient so as to avoid post-read processing errors.

Also, "air file path" zone at &H3C00 appears to include the full file path (including FS path) with FSUIPC4 while it only included the partial path with FSUIPC3. Is it a wanted behaviour?

Finally, it appears after testing that many FSUIPC4 offsets you marked as ?-Intl or ?-SimC are working properly. I will send you the list as soon as it will be completed.

Thanks for the great job!

Hervé

[Pete Dowson]

Is there any possibility with FSUIPC4 to check for the validity of variable reads?

Because all of FSUIPC4's "reads" are from an internal area populated by updates automatically sent by SimConnect when they change, variable reads are always valid.

A "busy" internal flag was provided in FSUIPC3 (&H11D4) that was convenient so as to avoid post-read processing errors.

Actually 11D4 was the pointer to the SIM1 modules data area, and was zero when SIM1 wasn't loaded. Since FS2002 the SIM1 module has been resident, so it hasn't really been of much use. I did fiddle it in FS2002 days for internal use, but it really doesn't quite mean what you think it means now.

It is actually marked as "not applicable" for FS2004 and it certainly isn't for FSX.

The best "busy" indicators, which are more likely to show when FS is not changing values (in FS2004 or later especially) are those in bytes 3364 and 3365, which can be read as a 16-bit value and tested for zero.

If you think it would be useful I could simply set 11D4 zero when 3364 or 3365 are non-zero and vice versa. Would that help? I'm not really sure what you mean by "post-read processing errors". Are you getting invalid values in some offsets?

Also, "air file path" zone at &H3C00 appears to include the full file path (including FS path) with FSUIPC4

Yes, as documented.

... while it only included the partial path with FSUIPC3. Is it a wanted behaviour?

It is what SimConnect supplies, and I have retained the whole path in case there is a possibility of referring to aircraft outside the main FS path. Are you suggesting it isn't desirable? I could strip off the FS part if present, or leave it intact if not, but I would think it more generally usable as supplied.

Finally, it appears after testing that many FSUIPC4 offsets you marked as ?-Intl or ?-SimC are working properly. I will send you the list as soon as it will be completed.

Ah! Great! Thank you very much!

I assume you are working from the latest list, downloadable above and updated for FSUIPC 4.067?

Regards

Pete

[hsors]

Thanks for your immediate answer Pete

If you think it would be useful I could simply set 11D4 zero when 3364 or 3365 are non-zero and vice versa. Would that help? I'm not really sure what you mean by "post-read processing errors". Are you getting invalid values in some offsets?

No, it will be ok checking 3364 and 3365 since it works for both. Indeed I had once a division by zero error while repositioning the aircraft in another part of the world (at this time the ambient air pressure at &H3498 was 0 and it was a FSUIPC3 problem).

Are you suggesting it isn't desirable? I could strip off the FS part if present, or leave it intact if not, but I would think it more generally usable as supplied.

Of course, the less code we have to adapt to the FS version, the best it is but it's not a problem to add a If Else ;-). My applications are planed to work on both FS9 and FSX. Apparently, the aerodynamic maths didn't change a lot

I assume you are working from the latest list, downloadable above and updated for FSUIPC 4.067?I assume you are working from the latest list, downloadable above and updated for FSUIPC 4.067?

Yes

Regards

Hervé