Sign in to follow this  
Guest DSandberg

Does Barometric Pressure Have an Effect in Fly!2?

Recommended Posts

I noticed yesterday that I loaded a METAR with the barometric pressure at 30.21. When I set that on the Kolsman Knob (Altitude adjustment), it incorrectly reported the altitude for my airfield. It turns out that the altitude is only correct when set to standard pressure (29.92). Does anyone know if barometric pressure changes "work" in Fly!2? Are they linked to the weather settings and METAR imports?Thanks everyone...Dan Larson

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

G'day Dan,Just checked it out on the Hawker. Works perfectly! (in manual mode ) So pressure changes do work correctly in Fly!II. I usually fly in a standard atmosphere. :-)As for auto metar I can't comment as I don't use it, but if you are given the new barometric pressure (30.21) then just set it manually and all should be fine. I feel that you are only using the Kollsman knob. That only tells the altimeter what pressure to use as a referrence. The sim has to be told what the new pressure actually is via the weather/other drop-down menu.Cheers,Roger @YSSY

Share this post


Link to post
Share on other sites

Dan & Roger,I have also seen that Fly!2 is not working properly when a metar is imported. I use metars all the time, so it is frustraing when setting of the Kollsman knob to match local pressure results in an improper altitude.Roger, when the metar is loaded, the weather menu is updated properly with the new pressure. However, the only way to get a proper altimeter reading is to leave the altimeter setting at 29.92. As you have verified that barometric pressure response is correct when entered manually, it appears that there is a bug in Fly!2 with the metar import system. It may be indicating the correct level but is not actually changing the sim's environment?

Share this post


Link to post
Share on other sites

This may also have to do with the aircraft. I should have mentioned my flight was in the Skyhawk. I will also try and test by loading the METAR, and then manually changing/updating the barometric pressure to see if it kicks in.

Share this post


Link to post
Share on other sites

G'day Randall,Thanks for the explanation Randall. I understand the problem now :-)Have you tried just opening the weather/other drop down menu and clicking the OK button manually?. That should force the change. If that doesn't work because Fly! checks and thinks it's already at that pressure then try manually resetting the pressure to a different value and then manually re-entering the new metar value you want. It should work as I had no problems manually changing the barometric setting. At least that works within Fly!If by some weird chance that doesn't work then the metar load routine has completely stuffed up the barometric pressure settings within Fly!.Wouldn't David S... of info metar have stumbled accross this??Cheers,Roger @YSSYCheers,

Share this post


Link to post
Share on other sites

Thanks Roger - I'll give it try in the next few days.I had the pleasure of testing a lot of metar-related issues with David in the beta sessions. The fact that the metar data was appearing in Fly!2 certainly had us convinced that it was working, though we were concentrating mainly on weather-related items such as winds, cloud representation, precipitation, etc.

Share this post


Link to post
Share on other sites

(sounds of me straining my brain cells to remember what transpired 20 months ago during the beta)I don't recall how thoroughly we (Randall, myself and others) tested this. I do remember doing flight tests of wind directions and speeds to see if they were having the appropriate effect, but it may be that we only checked the import of altimeter settings by checking the ATIS reports and presumed that everything thereafter would be handled correctly. Unfortunately I suppose it is not beyond the realm of possibility that there could be a disconnect between the altimeter reports being correct in ATIS and the altimeter gauge and flight engine actually using that information correctly.Here's something: I do seem to have a fleeting memory of some sort of rare problem with altimeter readings from imported METARs not being used by the sim (can't remember which version) unless one then opened and immediately closed the weather settings dialog thereafter, as if the import code wasn't forcing a refresh of the part of the engine that drives the gauges. So you may want to try that trick to see if it still works. (I think this may be the same thing that Roger has suggested elsewhere in this thread, except that it has been so long since I looked at Fly2's interface that I don't remember the names of the dialogs.)For what little it is worth, I hope to finally have a machine in the next week or so that is capable of actually running Fly2 well enough for me to look at things like this myself (after years of going without!), so if nothing else I'll try to check this out once my box is up and firing on all cylinders. On the other hand, my new machine will need to have the latest DirectX version installed, and didn't I read something here recently about Fly2 not working properly with the latest DirectX version? (Please do correct me about this if my memory is in error.)- David Sandberg

Share this post


Link to post
Share on other sites

Hi David,until now the only problem I had with FLY! and new hardware or drivers was a common IRQ used by the graficcard and 1 usb-port (problem has been discussed in this forum). After de- and reinstalling that usb-port and getting another IRQ all works well.I run FLY!2 (all patches) underAMD Barton 2500+768 MB system RAMGeForce FX 5600XT with 8x AGP, 128 MB memoryNVidea driver 53.03 (DirectX version 9.x (the newest German version, I think 9.a)Windows XP Home (now with service pack 1)I also made some tweaks with nVHardPage V 1.95.2b with positive influence on FLY!s performance.I do NOT have to check the compatibility box of Win XP as some people have to as they reported earlier.RegardsGeorg

Share this post


Link to post
Share on other sites

Thank you for the info, Georg. (This is going to be quite a shell shock for me, I'm certain ... going from a P3-550 running WinME that I've had for about 4 years to an Athlon 64 3000+ w/Radeon 9800 Pro 256MB and WinXP Pro.)Back to waiting on pins & needles for the FedEx guy ...- David Sandberg

Share this post


Link to post
Share on other sites

I can verify that the pressure readings in the weather settings dialog are correct after importing the metar (as brought in by Infometar) and that the C4TO ATC controllers also access this info and give appropriate pressure changes along the flight route. However, it isn't making it into the environment engine and being properly represented on the altimeter, so I'll play around a bit with Roger's suggestion.As far as your new computer is concerned, my first upgrade to a more powerful machine running XP Pro went off without a hitch as far as Fly!2 is concerned. It runs beautifully and I have the latest DirectX.

Share this post


Link to post
Share on other sites

G'day Randall,Somethings not quite right with the pitot/staic system on the Malibu.On my computer there is a 17 knot discrepency (low reading) between the co-pilot and and pilots ASI... :-eek :-eekDamn mud wasps are at it again. :-)cheers,Roger

Share this post


Link to post
Share on other sites

I have spend many hours on the altimeter problem during SquawkBox Beta sessions :- after importing a single airport METAR, the baro pressure is wrong most of the time, so I force it through the SDK after importation- after that, the value shown is correct in weather window- The altimeter value is correct, but at 29.92 setting (so it's wrong)- The only way I found to refresh must be done manually : open the "weather->other" window, then click OK button without any change. After a few seconds, the altimeter switch to the correct value regarding the Kollsman setting.- I've tried many different things with the SDK functions to do the same refreshoperation without successBut the manual refresh operation must be done after each new METAR import :-(I've tried also to import the METARs with the direct download from NOAA server in Fly! (after connecting to multiplayer server) : the behavior is exactly the same.If you use InfoMetar for importation, the behavior is again the same.So I'm afraid that it's a common bug in the weather system importation.- roland -* AirFeedback 1.0 ** DragPoder 1.0 ** SquawkBox 3.1 *

Share this post


Link to post
Share on other sites

Yes, since version 1.0 Fly has had problems with single-METAR imports (I mean in general, not just the observed barometric problem, which is most likely unrelated) because of the interpolation "feature" (which I was never a fan of, and which InfoMETAR was largely written to circumvent).The "Clear Existing Weather" checkbox, added in the final beta patch, was intended to help minimize the interpolation problem by forcing the interpolation routine to ignore weather data that hadn't been loaded in the METAR routines but which was instead just hanging around from either initialization or previous weather settings (an unavoidable consequence of the way Fly's weather engine was designed). When I proposed it as a solution, the greatly-missed Richard H. concurred that such a thing should have been in the code from day one. Unfortunately only Richard had access to many parts of the code where this needed to be implemented, so I don't know how he implemented it and whether it works as intended. As we found during the beta, it is nearly impossible to be able to test the weather results empirically; to know for certain that the checkbox worked as intended, one would have needed to trace the actual execution of the code through the interpolation routines, something that could only be done with a debug build, which would require access to the entire code base, or at a minimum all of the object files (alas, I had neither). I also don't think Richard had the time to add anything to the SDK to allow this same checkbox to be selected "virtually" ... if that is so, the checkbox solution unfortunately wouldn't be of help for add-on utilities even if we did know it was working.I'm saddened to hear that you found no other method to refresh the barometric information through the SDK (and I imagine this may go for temperature and dewpoint effects on the flight engine as well, although they would be far more subtle). That was pretty much the only hope I held out for improving on this situation in the future (I hadn't yet had an opportunity to explore the idea for myself). Thank you for passing your results along.- David Sandberg

Share this post


Link to post
Share on other sites

Thanks for the explanations David,A few remarks: - It seems that the check box is effective when APILoadMetar() is called because each time SB import a new METAR, the old one disapear (seen in the Flight planner with cloud and temperature...)- I'm quite sure that the altimeter bug is constant, if a single METAR is used or a strong list.- Last week in SB, I tried to cumulate all the METAR SB load during a flight session and along the flight path. Then as the time pass, the temp METAR file grow up until I disconnect SB.After a while I have large METAR covered zone but the problem is still there. So I'm not sure that the altimeter bug comes from an interpolation problem.- roland -

Share this post


Link to post
Share on other sites

Roland,Yes, we are in agreement that interpolation is probably unrelated to the altimeter problem. I tried to say as much in my previous post (to quote myself, "barometric problem, which is most likely unrelated"), but probably I wasn't being sufficiently clear. I've been told that my "conversational" style of writing can be difficult for people for whom English is a 2nd language - so my apologies for that. The bulk of my post was on the topic of "problems wth single METAR import" that you had mentioned.Regarding the effect when APILoadMetar() is used, were you testing this by loading METARs for different location each time, or always for the same location? If the latter, that should always have erased old weather at the same location, even before the checkbox was added.To test the functioning of the "checkbox code" with the SDK function, I believe one would need to do as follows: load a single METAR for some location, verify that the data for that location was correct in the sim, then load a single METAR for a different location (one at least 300 miles away from the first), and finally check the weather at both the original and new locations. If on the 2nd check the weather at the new location matches what was just loaded for it, AND if the weather at the original location had either reset to default values or had changed to match that at the new location, then one could infer that the code associated with the checkbox is always being treated by the SDK import function as if the box had been "checked". However, if the weather at the original location still matches the values that were loaded during the original METAR load for that location, then the code associated with the checkbox is apparently not being used by APILoadMetar(). I would expect the latter to be true, but I haven't tested this myself (yet).Let me also apologize for my slowness in responding to this thread. Well, actually I'm not THAT sorry, since my reason is that I've been busy building my new system for the last day or so (woohoo!). It's shaping up pretty well so far, and hopefully in another day or so I'll be posting from it.- David Sandberg AMD Athlon 64 3000+ MSI K8N Neo Platinum MB 1GB Kingston DDR400 RAM ATI Radeon 9800 Pro 256MB Samsung 160GB Spinpoint P80 drive Samsung 16X DVD-ROM Pioneer DVR-107 8X DVD+/-RW burner Antec TruePower 380S PSU Antec Sonata case WinXP Pro

Share this post


Link to post
Share on other sites

No need for apologies David, my low english skill is probably the cause ;-)I've verified that the 'clear checkbox SDK' is OFF (I was wrong).Fly! keep all the single METAR importation.- roland -

Share this post


Link to post
Share on other sites

Thanks for checking, Roland. Alas, that's what I had expected would be the case. If memory serves, Richard Harvey had a reason for wanting to at least maintain that behavior ... and as we all know, the man wasn't permitted the time to implement both methods for the SDK, along with many other things. :(- David

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this