flydav Posted December 10, 2013 Report Share Posted December 10, 2013 Before I go out and purchase an aircraft that will probably sit in my hanger can I ask you flydav to give me a hand here? Sure, go ahead. Quote Link to comment Share on other sites More sharing options...
flydav Posted December 11, 2013 Report Share Posted December 11, 2013 I completed a flight with the 757, without NOAA and with python interface disabled, had no problem with the switching weather. It was all the time on "grab real weather" Will test again to be 100% sure. 1 Quote Link to comment Share on other sites More sharing options...
FogGobbler Posted December 12, 2013 Report Share Posted December 12, 2013 I´ve got the same "switching" problem and I also use the a320NEO V2. Real weather simply disappears and is overridden by some general weather conditions. Very strange. Quote Link to comment Share on other sites More sharing options...
lord_helmet Posted December 12, 2013 Report Share Posted December 12, 2013 I´ve got the same "switching" problem and I also use the a320NEO V2. Real weather simply disappears and is overridden by some general weather conditions. Very strange.You dont't happen to be using the Dispatcher tool also? It seems to happen most often for me when I use those two.Sent from my iPad using Tapatalk HD Quote Link to comment Share on other sites More sharing options...
flydav Posted December 12, 2013 Report Share Posted December 12, 2013 I've unistalled Skymaxxpro completely and still have the switching ONLY if I try to use NOAA with python so I believe the cause of this switching shouldn't be Skymaxx at all. I have the A320 neo but haven't tried with it also people are having the same issues with totally different plugins so at this point I believe there is something wrong with X plane itself and should be reported. Also it would be helpful if people reporting the weather switching problem would post a a screenshot or a list of the plugins they use. Without this it will be just a useless complaining. Quote Link to comment Share on other sites More sharing options...
JohnMAXX Posted December 12, 2013 Report Share Posted December 12, 2013 I agree with flydav, something else is at play here........I have been chasing my tail with this one guys and the only time I say this problem was with the NOAA plugin..... There may be a problem with plugins that write to the weather engine. SkyMAXX does not write to the weather engine, it only reads from..... Quote Link to comment Share on other sites More sharing options...
FogGobbler Posted December 13, 2013 Report Share Posted December 13, 2013 @lord_helmet: I am using the new tool, EFASS together with the a320neo. Last flight was very strange. I started in LIRF, Metar was CAVOK and blue sky was rendered. Climbing enroute to 30.000ft the sky looked like a grey blob, nothing else was to be seen. Decending towards LSZA there was thick fog, visibility near null, but the metar read also CAVOK for this place. I .. ehm .. crashed on my attempt to land :-( and loaded LSZA again as a starting point. This time the sky was clear. It is as though the SkyMaxx didn´t pick up the latest metar for my destination on the flight and rendered something else (?). I really don´t know. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 Same problem here, something is changing the weather settings. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 Smyaxx, A320 Neo, EFASS by the way (uninstalled all of them, same problem - all since installation of Skymaxx. Easily reproducible, because its not happening in 32 bit). Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 OK guys, this doesnt help a lot but of you go to plugin admin, deactivate SASL, you can switch back to real world weather, so SASL is doing something wrong here, have contacted the dev and told him, he is chekcing at the moment. Quote Link to comment Share on other sites More sharing options...
flydav Posted December 28, 2013 Report Share Posted December 28, 2013 (edited) OK guys, this doesnt help a lot but of you go to plugin admin, deactivate SASL, you can switch back to real world weather, so SASL is doing something wrong here, have contacted the dev and told him, he is chekcing at the moment. I see people with different plugins have this same exact problem and even at the org people are starting to notice something wrong. Personally I only had problem when I used python and NOAA and was able to switch back to real weather just deactivating python interface, I've never had problem with SASL, I'm no longer having this problem since I deleted NOAA. It appears to be more than one the cause of this issue: there is python (in my case) there is SASL, there is always X plane in both cases. I've used the 757 a lot these days and zero times the A320 so if it was SASL fault I would have noticed that because SASL is the same for both planes. To me there is a problem with X plane itself and the way it "talks" with the plugins so it doesn't really matter if it's me switching off python or somebody else switching off SASL, somehow X plane behaves again and as a result it is possible for the user to switch back to real weather. To me this is a bug and I'm gonna report it to LR, maybe you guys should do the same. Edited December 28, 2013 by flydav Quote Link to comment Share on other sites More sharing options...
Ben Russell Posted December 28, 2013 Report Share Posted December 28, 2013 Personally, I suspect XSquawkbox, but seeing as no one ever posts a log file, who's to actually know. One things for sure, it won't be a bug in X-Plane itself. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 It seems not to be squawkbox. Its clearly reproducable when you fly, go to weather, set it to "grab form internet"; go back, see it has changed to "set uniformly", go to plugins, deactivate SASL, and there it works. Quote Link to comment Share on other sites More sharing options...
Ben Russell Posted December 28, 2013 Report Share Posted December 28, 2013 If the SASL scripts are not encrypted try searching them for the string: sim/weather/use_real_weather_bool If you find it, change it to something like: sim/weather/use_real_weather_bool_DISABLED There's very little reason for any plugin to write to this dataref. XSB and IVAO need to because they have the ability to set "network weather". Something like an aircraft should never write to this as it is not a WX injector, I'd be very surprised if I found a package that was doing so. It's also not the kind of thing that could happen randomly, you'd be far more likely to see the simulator crash than to have this exact dataref be written with a sane value... Strange, very strange. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 They are encrypted (a320 neo). No chance to reverse engineer for me But i can pass this info to the a320-dev so he can check. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 theres no chance to log this event somehwhere? Quote Link to comment Share on other sites More sharing options...
Ben Russell Posted December 28, 2013 Report Share Posted December 28, 2013 Not easily... better off waiting for the developer to respond. FWIW;I checked the SkyMAXX plugin for this string: does not exist.I check the Gizmo source code for this string: does not exist. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 It isnt happening with the 777. So I blame SASL for it. Quote Link to comment Share on other sites More sharing options...
Cameron Posted December 28, 2013 Report Share Posted December 28, 2013 It isnt happening with the 777. So I blame SASL for it. Pretty sure the 777 uses SASL. Rather than it being a SASL issue, I think this is an A320 NEO specific issue where the developer needs to chime in and explain what he's doing with weather datarefs. I wouldn't be so quick to blame SASL as a whole. 1 Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 excuse me, thats what I meant. Sorry! I already skyped with JAR, showed him whats happening, and he will adress it. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 Fix available, since I dont know how to upload here please check the support-forum of the org. (ouch... org.. I know.. ) Quote Link to comment Share on other sites More sharing options...
Cameron Posted December 28, 2013 Report Share Posted December 28, 2013 Fix available, since I dont know how to upload here please check the support-forum of the org. (ouch... org.. I know.. ) Glad to hear of a fix! Direct link to topic is here. Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 Beta.. for me its working, but I was the only beta tester Please try and report, thanks! Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 28, 2013 Report Share Posted December 28, 2013 Attention: Tested with 2.1b only! Quote Link to comment Share on other sites More sharing options...
xplaneorgisdumb Posted December 29, 2013 Report Share Posted December 29, 2013 second try - available in the above mentioned org.thread Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.