Jump to content

Recommended Posts

Posted

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.

  • Upvote 1
Posted

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

Posted

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. :)

Posted

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.....

Posted

@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.  

  • 2 weeks later...
Posted (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 by flydav
Posted

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.

Posted

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.

  • Upvote 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...