Some doubt about ambient parameters

[Cristiano]

1) I don't know much how FSUIPC works, so I'd like to know whether these offsets

0x11D0 (total air temperature)

0x30D8 (dynamic pressure)

0x28C0 (ambient air density)

0x28C8 (ambient air pressure)

are directly calculated by FS2004 or by FSUIPC, because the dynamic parameters seem not in full agreement with the correction for the mach number.

Also, the air density seems different from the expected one.

2) The structure NewTemp (in the header NewWeather.h) is formed by integer numbers (c short data type).

I read, for example, that the second temperature layer begins from 12 meters and that the temperature is 25 °C.

I'd like to know whether the altitude is exactly 12 meters and the temperature is exactly 25 °C.

Thanks and sorry for my English :oops:

Cristiano

[Pete Dowson]

I'd like to know whether these offsets

0x11D0 (total air temperature)

0x30D8 (dynamic pressure)

0x28C0 (ambient air density)

0x28C8 (ambient air pressure)

are directly calculated by FS2004 or by FSUIPC

FSUIPC just maps them into locations in FS which have been identified as containing these things. Quite honestly I don't know much about them myself. If you know more, please tell us.

The structure NewTemp (in the header NewWeather.h) is formed by integer numbers (c short data type).

Yes, to make them nice and compact so I could allow more layers. They are converted to floating point values when submitted to FS.

I read, for example, that the second temperature layer begins from 12 meters and that the temperature is 25 °C.

I'm not sure the term "begins from ..." is correct there. I think Fs uses these temperature points to define its temperature gradient. There shouldn't simply be a layer of one temperature then a layer of another, and so on. these are sample positions on the gradient to define it.

I'd like to know whether the altitude is exactly 12 meters and the temperature is exactly 25 °C.

Well, those are the numbers I submit to FS's Weather DLL. Why would I change them? But as I say, these are only sample positions to define the required temperature gradient.

[Later]

If you mean when READING the weather via the NWI, then obviously FSUIPC has to round the temperatures and altitudes to the nearest whole degree and metre, respectively.

Regards

Pete

[Cristiano]

Hi Pete, thanks for the prompt reply,

FSUIPC just maps them into locations in FS which have been identified as containing these things. Quite honestly I don't know much about them myself. If you know more, please tell us.

I just know how to calculate the dynamic parameters and the air density, but I don't know how FS2004 calculates them.

According to my calculations, the dynamic values are inconsistent with the static values and with the dew point (from which I calculate the air and the dry air density).

For that reason I asked whether the values in the structure NewTemp exactly match the FS values.

I'm not sure the term "begins from ..." is correct there. I think Fs uses these temperature points to define its temperature gradient. There shouldn't simply be a layer of one temperature then a layer of another, and so on. these are sample positions on the gradient to define it.

I totally agree. I myself interpolate those values to calculate them at the plane altitude. My term "layer" is simply wrong.

I now read your "later"

If you mean when READING the weather via the NWI, then obviously FSUIPC has to round the temperatures and altitudes to the nearest whole degree and metre, respectively.

Is there any way to read the exact values?

Thank you

Cristiano

[Pete Dowson]

Is there any way to read the exact values?

OAT at aircraft altitude is at 0E8C to 1/256th of a degree. You just need to move your aircraft to the altitude at which you wish to measure it.

The values I read from FS internally are of course more accurate, but there's been no need for such in a complete and general weather reading/setting context, which is what the interface is for.

Regards,

Pete

[Cristiano]

The values I read from FS internally are of course more accurate, but there's been no need for such in a complete and general weather reading/setting context, which is what the interface is for.

I'd like to have access to the accurate values of the dew point because I need to calculate the water vapor pressure (needed for the dry air density). But if it's not possible... :cry:

Regards

Cristiano

[Pete Dowson]

I'd like to have access to the accurate values of the dew point because I need to calculate the water vapor pressure (needed for the dry air density). But if it's not possible... :cry:

Ah, the dew point. At the aircraft? I could provide that in the same units as the OAT if you wish. Is that accurate enough? I'd just need to look for a suitable 16-bit word somewhere. Let me know.

Regards,

Pete

[Cristiano]

Ah, the dew point. At the aircraft? I could provide that in the same units as the OAT if you wish. Is that accurate enough? I'd just need to look for a suitable 16-bit word somewhere. Let me know.

Yes, the dew point at the aircraft, exactly like the OAT in 0E8C; 1/256th of a degree would be very good.

Thank you very much

Cristiano

[Pete Dowson]

Ah, the dew point. At the aircraft? I could provide that in the same units as the OAT if you wish. Is that accurate enough? I'd just need to look for a suitable 16-bit word somewhere. Let me know.

Yes, the dew point at the aircraft, exactly like the OAT in 0E8C; 1/256th of a degree would be very good.

I've done some checking and I can't actually find the exact dew point at the aircraft altitude, except by extrapolation given its altitude and the temperature layers below and above. I could do it assuming a linear gradient between the two (or a fixed temperature above the uppermost layer). Would that do the job for you? Otherwise I can't see any way of getting it I'm afraid.

Also, I have to limit the frequency at which I read the weather at the aircraft as it does affect performance. Currently it is set to get it once a second.

Given these restrictions, will it still be of use?

Regards,

Pete

[Cristiano]

I've done some checking and I can't actually find the exact dew point at the aircraft altitude, except by extrapolation given its altitude and the temperature layers below and above. I could do it assuming a linear gradient between the two (or a fixed temperature above the uppermost layer). Would that do the job for you? Otherwise I can't see any way of getting it I'm afraid.

Currently I'm interpolating the temperature read in the NewTemp structure, but I get a different temperature w.r.t. the OAT (as in 0E8C).

I guess I get different OAT's because of the rounded values of altitude and temperature in that structure. But if you can interpolate the dew point using the accurate sample values, I guess that the interpolated dew point will be good.

Do you confirm that you can read the accurate values of the altitude and dew point samples?

Also, I have to limit the frequency at which I read the weather at the aircraft as it does affect performance. Currently it is set to get it once a second.

I don't think it will be a problem. If you are able to get an accurate dew point at the a/c altitude, then that frequence will be good.

Regards

Cristiano

[Pete Dowson]

Do you confirm that you can read the accurate values of the altitude and dew point samples?

Well, they are as accurate as stored in FS's weather data arrays. There's no other values that I know of. They use 32-bit floats. If my results are inaccurate this will be because of different interpolation methods -- I'm assuming linear, but I don't know if that is correct. Have you checked whether the temperature gradients are linear between the specific layer levels?

The other area where it will be wrong is below the lowest temperature layer. I've nothing to interpolate it with there.

Anyway, try it and let me know. In the attached interim version 3.504 you can read my interpolated value in the 16-bit word following the OAT. i.e. offset 0E8E.

Regards,

Pete

FSUIPC3504.zip

[Cristiano]

Have you checked whether the temperature gradients are linear between the specific layer levels?

No, I still haven't checked it, but I'm not expecting that it is linear.

I think it is linear between two samples (but I can be wrong).

Anyway, try it and let me know. In the attached interim version 3.504 you can read my interpolated value in the 16-bit word following the OAT. i.e. offset 0E8E.

Your dew point seems to work fine.

The density in 28C0 is about 3 or 4% smaller than I expected even with the correction for the vapor pressure.

I need to investigate, but now it's time to do some sleep. :)

Thank you very much for your valuable support

Cristiano

[Cristiano]

The density in 28C0 is about 3 or 4% smaller than I expected even with the correction for the vapor pressure.

I need to investigate, [...]

Finally, I'm able to say that FS2004 gives the air density without any correction for the humidity (this leads to a density altitude which is lower than the expected and, in the real life, it could be a problem).

Now that I have the corrected dry air density, I'd like to use it in FS. Do you know whether it is possible to write "my" density so that FS use it in all its calculations?

Regards

Cristiano

[Pete Dowson]

Now that I have the corrected dry air density, I'd like to use it in FS. Do you know whether it is possible to write "my" density so that FS use it in all its calculations?

I really doubt whether that is possible without actually patching code someplace. Even if it were possible, to find the correct place to patch in a new value so that it gets used consistently would involve another nightmare of tracing through hideous C++ compiles code at machine level, trying to recognise things as they crop up. Even if I understood this area it would be very difficult, and would be many many hours of tortuous hacking.

The best you could possibly get easily would be if FS responded at all to you writing to offset 28C0 (FSUIPC does allow this). If you can induce any effects whatsoever writing there (and you'd probably need to do it as frequently as possible), then I could try to provide a way for FSUIPC to sustain the writing at closer quarters (i.e. faster and in time with FS's recalculations) to try to override FS's own computed values. I have done this for some other areas, notably the vertical wind component (used to simulate lift for gliders, for example), and it can work, but getting the timing right is important to stop fluctuations.

Regards,

Pete

[Cristiano]

The best you could possibly get easily would be if FS responded at all to you writing to offset 28C0 (FSUIPC does allow this).

It works! :-)

Writing, for example, a density 10 times bigger, the a/c (MD-11) has many problems to reach Vr (because of the incredibly big drag).

It seems strange to me that the engines are not affected by the air density (while I know that the thrust should change with the density at least when the a/c is moving, but this could be a "bug" of the .air file).

If you can induce any effects whatsoever writing there (and you'd probably need to do it as frequently as possible), then I could try to provide a way for FSUIPC to sustain the writing at closer quarters (i.e. faster and in time with FS's recalculations) to try to override FS's own computed values. I have done this for some other areas, notably the vertical wind component (used to simulate lift for gliders, for example), and it can work, but getting the timing right is important to stop fluctuations.

I use a Windows timer to call FSUIPC_Write with the parameter "Elapse" (the time-out value) = 1 ms and it seems to work fine without any noticeable effect on FS fps or fluctuation. Also 50 ms seem good.

Do you have a sort of flag which can tell me when it's the time to write my calculated density?

Regards

Cristiano

[Pete Dowson]

It works! :-)

Oh, right. Good.

I use a Windows timer to call FSUIPC_Write with the parameter "Elapse" (the time-out value) = 1 ms and it seems to work fine without any noticeable effect on FS fps or fluctuation. Also 50 ms seem good.

Do you have a sort of flag which can tell me when it's the time to write my calculated density?

No, because I don't know. For most things you get best results by trying to match the FS frame rate, so setting FS's frame rate limiter to, say, 25, and writing every 40 mSecs should be okay. But having said that, some things in FS do seem to be updated at a faster rate. FSUIPC doesn't get to know about these because it, too, is triggered by the frame rate (with a standby 55 mSec timer for paused and minimised periods).

Experiment some more. If you find FS is interfering too much between your writes then I can look at doing the same as I did for the vertical wind -- take the last value you wrote and repeatedly write it for you till you write another, or until a timeout expires (which could be 10-14 seconds, allowing your program to also run on WideFS from a client).

Could you tell me the exact application of this? What is it you are doing with it?

Regards,

Pete

[Cristiano]

Experiment some more. If you find FS is interfering too much between your writes then I can look at doing the same as I did for the vertical wind -- take the last value you wrote and repeatedly write it for you till you write another, or until a timeout expires (which could be 10-14 seconds, allowing your program to also run on WideFS from a client).

That could be interesting. I'll do more experiments.

Could you tell me the exact application of this? What is it you are doing with it?

Nothing but what I said. :)

I wrote a "panel" (no needles, just numbers) to see many parameters usually unavailable in the real planes.

With my panel, I seen strange values for some parameters (TAT, dynamic density and pressure) and I seen that the air density doesn't care about the humidity. I just want to fix the strange parameters.

Unfortunately, few parameters seem unavailable with FSUIPC (like CG_AFT_LIMIT and CG_FWD_LIMIT at the offsets 2F00 and 2F08), but it's not a problem, I'll use the FS panel lookup_var() function).

With my fixes I hope to improve the simulation realism.

Regards

Cristiano

[Pete Dowson]

Unfortunately, few parameters seem unavailable with FSUIPC (like CG_AFT_LIMIT and CG_FWD_LIMIT at the offsets 2F00 and 2F08)

Most of the variables listed in the second table of the Programmer's Guide can be made available if needed. It's just that the can't be mapped directly, so extra code is needed to obtain them at regular intervals and place them into mappable memory. They were all mappable in FS2000, which is how they ended up being listed.

I only tend to add such extra code when requested with good reasons, because it all adds to the performance limiting path through my code.

Obviously if you are using the Panels interface directly there is no advantage in asking FSUIPC for them -- I would probably have to do the same as you (though I tend to bypass the PANELS.DLL call indirection and ask the Sim engine directly).

Regards,

Pete

[Cristiano]

Ooops! Sorry, by mistake (in my rush before going on holiday) I edited your message instead of adding a reply! Many apologies.

I've posted the reply to your now lost message below.

Pete

[Pete Dowson]

After extensive simulation, your new dew point variable (0E8E) seems to work fine. The only "strange" thing happens when there is no layer below my altitude (as you already said).

The best fix I have in mind is to use the slope of the segment which interpolates the 2 lowest samples; with that slope, you should calculate the dew point below the lowest sample, the same should be done with the highest samples (I hope that it is clear enough :) ).

Please, could you fix that?

Yes, sounds reasonable. But I'm afraid it will have to wait now till I get back from holiday, i.e. after October 12th.

I'd like to try with the Sim engine. Do you have any tutorial or code sample for that?

No, sorry, It represents many hundreds of hours of hacking through disassembled parts of FS, and has to be repeated for each FS release -- even the 9.1 patch needed further hacking. This is really the main part of the benefits of using FSUIPC -- I do thousands of hours of such work for each release then disguise it all so each FS version looks similar but more extensive than the last.

If you would enjoy such work and have the tools (a good disassembler like IDA and the NuMega Soft-Ice debugger at a minimum) then have a go and get back to me when you think you've mastered it. Then maybe we can discuss you taking over FSUIPC etc at some point in the future so I can retire properly! ;-)

Sorry, not a good joke, but it is half serious. Volunteer experts in "hacking" and assembly code analysis will be sought to take over in not many years -- I am 62 now and don't want to have to do this for many years more!

Regards,

Pete

[Cristiano]

Yes, sounds reasonable. But I'm afraid it will have to wait now till I get back from holiday, i.e. after October 12th.

Good! Then, have a nice holiday! :-)

I'd like to try with the Sim engine. Do you have any tutorial or code sample for that?

No, sorry, It represents many hundreds of hours of hacking through disassembled parts of FS, and has to be repeated for each FS release -- even the 9.1 patch needed further hacking.[...]

No problem, we have your great UIPC. :)

Bye bye

Cristiano

[Pete Dowson]

After extensive simulation, your new dew point variable (0E8E) seems to work fine. The only "strange" thing happens when there is no layer below my altitude (as you already said).

The best fix I have in mind is to use the slope of the segment which interpolates the 2 lowest samples; with that slope, you should calculate the dew point below the lowest sample, the same should be done with the highest samples (I hope that it is clear enough Smile ).

Please, could you fix that?

This is now done and available in the interim test version 3.507, see top announcement above. Could you try it and let me know if it works as you'd expect, please?

Regards,

Pete

[Cristiano]

After extensive simulation, your new dew point variable (0E8E) seems to work fine. The only "strange" thing happens when there is no layer below my altitude (as you already said).

The best fix I have in mind is to use the slope of the segment which interpolates the 2 lowest samples; with that slope, you should calculate the dew point below the lowest sample, the same should be done with the highest samples (I hope that it is clear enough Smile ).

Please, could you fix that?

This is now done and available in the interim test version 3.507, see top announcement above. Could you try it and let me know if it works as you'd expect, please?

The calculations seem good (also when the a/c is placed below the lowest temperature sample or above the highest and also when there is just one temperature sample).

Thank you very much.

I think you could be interested in a strangeness (a bug?) in the structure _NewTemp.

When a temperature sample is negative, the member Alt is wrong (because it's an unsigned short).

Try, for example, to place the a/c at KBWC (which is below the sea level) using the weather theme "Building Storms".

You should see the lowest temperature sample = 214885 ft and the second sample = 4134 ft. A bit strange... :-)

I think a float type for Alt would be the right choice.

For the other members (Day, DayNightVar and DewPoint) why don't you use something like _NewTemp.DewPoint = dew_point * 256 (like with the new offset 0E8E)?

Cristiano

[Pete Dowson]

I think you could be interested in a strangeness (a bug?) in the structure _NewTemp.

When a temperature sample is negative, the member Alt is wrong (because it's an unsigned short).

Try, for example, to place the a/c at KBWC (which is below the sea level) using the weather theme "Building Storms".

You should see the lowest temperature sample = 214885 ft and the second sample = 4134 ft. A bit strange... :-)

Ah, this is just a carry-over from earlier FS versions which didn't allow negative altitudes in weather data. I think it should only affect read-outs, not weather being set through FSUIPC. For read-outs just treat it as a signed short instead.

Is it affecting the new dew point calculations? If so I'll check that and fix it before a full release.

I think a float type for Alt would be the right choice.

There are no float types fitting in 16 bits.

For the other members (Day, DayNightVar and DewPoint) why don't you use something like _NewTemp.DewPoint = dew_point * 256 (like with the new offset 0E8E)?

Just a desgn decision at the time, mostly from historical usage. There's no way any of this will be changed now -- too late, too many dependencies. Sorry.

Regards,

Pete

[Cristiano]

Is it affecting the new dew point calculations? If so I'll check that and fix it before a full release.

No, the calculations are good.

For the other members (Day, DayNightVar and DewPoint) why don't you use something like _NewTemp.DewPoint = dew_point * 256 (like with the new offset 0E8E)?

Just a desgn decision at the time, mostly from historical usage. There's no way any of this will be changed now -- too late, too many dependencies. Sorry.

No problem. :)

Is there any way to read the exact values?

Cristiano

[Pete Dowson]

Is there any way to read the exact values?

Not without hacking into FS code. None of the weather data is exported at all.

Regards,

Pete