Client PFD altitude

[Hardy Heinlin]

Hi JP,

thanks! I can now reproduce this error too, and I think I've found the cause. It has been introduced in version 10.0.2 with modification 0.2-0053.: Funnily, the METAR scanner and parser for the radio ATIS wasn't 100% isolated from the METAR scanner and parser for the physical weather model. So, certain ATIS events were able to influence the PSX client's weather model for a fraction of a second, and then remained wrong until the next correct update from the PSX server came in.

(I don't think this has anything to do with Carl's ATC problem; my problem above lies within the PSX client only, and that doesn't send data to add-ons.)


Cheers,

|-|ardy

[JP59]

Good morning Hardy,

Good news. I will stress the next Beta along a 13 hours trip and report

...and then remain wrong until the next correct update from the PSX server comes in.

It will explain why this issue only occurs above default planet zone. When coming back to WX stations area, a new METAR is sent over the network ("wake-up" event), and the client synchronize.

Thanks again for your devotion.

Cheers,

[Hardy Heinlin]

Good morning JP,

getting this on the planet zone might have been just coincidence. If my analysis is correct, it happens if:

+ This instance is a client
+ "Set zones by flight track and downloaded METARs" is OFF
+ New radio ATIS stations are loaded (every 8 track miles, or at situ load or net start)

The radio ATIS model uses its own internal weather zone data record which has a data pointer. This pointer is set on the Instructor's focussed zone if "Set zones by flight track and downloaded METARs" is off. If not, it uses its internal data record. The METAR parser copies METAR text data to the binary zone data. But it should do this only if the pointer points at the internal data record, not when it points at the Instructor's focussed zone. But it does, and that's the bug. When the client receives a new radio ATIS METAR string, it parses this string and copies the data to the Instructor's focussed zone data record (internally), even if "Set zones by flight track and downloaded METARs" is off. I simply forgot to add an "if" statement in my code. It's fixed now. (It affected the other zone variables like wind, clouds etc. as well, not just the baro pressure.)


Cheers,

|-|ardy

[JP59]

Hardy, your explanation above gave me some doubts :

getting this on the planet zone might have been just coincidence.

I always saw this on planet zone. Never over WX station zone, during I think 50 hours+ flight.

+ This instance is a client

Agree.

+ "Set zones by flight track and downloaded METARs" is OFF

In my yesterday test, it was ON for both server and client. I am 95% sure server and clients are ON in my simulator also, but I'll check this when back to home and report.

The first time I saw this offset, I was using PSXWx which was injecting a smoothing command like PSXAloft. Now I use PSXAloft for every flight, I get this offset every time I fly over planet zone. In my own opinion, this issue has also something to do with the WxSlowTransit command used by add-on like PSXAloft. Or maybe with tropopause data injections via WxAloft variable. To confirm or infirm I'll need to fly the same 13 hours flight with PSXAloft disconnected. I'll do this when possible.

But to be on the safe side, you may track and log all the WxSlowTransit and WxAloft process all over the network, by simulating and add-on injection every 5 seconds, over planet zone, during about 30-60 minutes and check if something goes wrong with client. Or if you want to send me a tracer I can run the stress test myself and send you the log. Again, just my humble newbie "advice"

Cheers,

[Hardy Heinlin]

50 hours do not prove as much as 500 hours do when it comes to random effects.

WxSlowTransit is not a factor because the internal target value is wrong, not just the drifting value.

Also, version 10.0.2 didn't have the WxSlowTransit feature.

Anyway, if I correct this bug that was introduced in 10.0.2 (it is clearly a bug), the problem is no longer reproducible. If I remove the bug fix, the problem re-appears instantly.


Cheers,

|-|ardy

[JP59]

Ok. I'll stress the next Beta and report. Fingers crossed

Cheers,

[Hardy Heinlin]

Hi Jean-philippe,

when my brain was waking up this morning I realized (theoretically) that the problem can indeed still occur on the client even when "Set zones by flight track and downloaded METARs" is ON.

It's hard to reproduce in practise, but in theory it's possible.

I need to fix that too ...


Thanks!

|-|ardy


P.S.: The previous bug fix just fixed the client's problem. In fact, the problem may occur on the server as well when "Set zones by flight track and downloaded METARs" is ON. Users just couldn't notice the problem when both client and server had the same problem. But add-ons could notice it by comparing the received Instructor data with the PFD data.

[JP59]

Hello Hardy,

I can't reproduce the issue since using 10.0.7. Thanks a lot for this fix.

Cheers,