Jump to content

SkyMaxx Pro 3.2 crashes X-Plane


RLBrooks
 Share

Recommended Posts

Version 3.2 crashes X-Plane 10.45 reproducibly when I try to select "Always" in the Real Weather Connector configuration. I'm on an iMac Retina, latest OS, with 32 GB RAM and 4 GB video memory. I use the exact same settings that worked without a hitch with SMP 3.1.2. The crash also occurs if I reset to the default SMP configuration. I also use the NOAA plugin.

Within a second or two of selecting "Always" in RWC, X-Plane crashes hard - every time. In case you are wondering if my cloud area setting is too high, let me repeat. It happens with the default SMP settings (cloud area 2500 sq. km) and with the exact same settings that never caused trouble with SMP 3.1.2.

Outside of updating SMP, nothing has changed on my computer or with X-Plane. This bug was introduced in the SMP 3.2 update.

Log.txt

X-Plane crash log.txt

Link to comment
Share on other sites

I am also seeing this crash with 3.2 and Log.txt also ends with:

SkyMaxx Pro: Parsing METAR data

I have been running 3.2 since day of release also with "Always" set in RWC. It worked ok initially but stopped working today. I am unable to start XP10 without temporarily zipping up Plugins\SiliverLining. Maybe it is a METAR parsing bug that has only surfaced now.

Link to comment
Share on other sites

I was able to resolve the problem by:

1) Uninstalling the NOAA Weather python scripts

2) Restarting xplane (no crash)

3) Shutting xplane down

4) Reinstalling the NOAA python scripts

I don't see the crash anymore, the only difference in my NOAA Weather Configuration is the METAR source has changed back to the default. It is now set to NOAA, it was previously set to VATSIM. Setting the METAR source back to VATSIM results in the SkyMaxx crash occurring again.

Link to comment
Share on other sites

I'm the OP and I found a clue to what's happening from the user standpoint (I'm not a programmer). If "Never change visible weather" is checked, then also checking "Always" will crash X-Plane every time. But if I first uncheck "Never change..." I can safely check "Always." In other words, "Never change..." and "Always" are incompatible if both are checked.

I thought I had the METAR source in the NOAA plugin set to NOAA, but I will check that again. Maybe it somehow switched to VATSIM without my realizing it.

Link to comment
Share on other sites

Okay Gents,

After doing a reinstall of the Real Weather Connector and it seems to work BUT only if you remove the NOAA weather plugin and set XP to grab real weather.

The moment I reinstall the NOAA plugin and touch the RWC setting and put it on "Always" XP crashes to desktop again.

It appears that there is a big compatibility issue here!?

Lastly, I have also noticed XSquawkBox stared to crash my X Plane recently and it too contains a weather feature that might clash with the RWC? I have now switch the XSquawkBox feature off (it does not check for weather anymore) and the "XSquawkBox crashing XP" problem seems to have also gone away for now but it would be interesting to hear if this issue was also related to RWC??

I am looking forward to a fix for this! Would be nice to use NOAA again. XSquawkBox weather is mostly irrelevant when you use NOAA but then we should really just know about the issue and advise other users, if applicable.

Looking forward to your response

Nico

 

 

Link to comment
Share on other sites

Please send us your log.txt file after experiencing this crash. There are a lot of people using RWC with NOAA successfully, so I suspect you have some sort of other plugin conflict at play, or an out of date plugin that has bug fixes available for it. The log may tell us more.

NOAA and XSB don't actually interact directly with RWC at all.

 

 

Link to comment
Share on other sites

Thanks Andre,

I have done that a few times today :)
By using a process of elimination I have come to the conclusion that it is NOT RWC causing this problem. RWC is in fact just the product that is showing us that there is a problem and Sundog is right in my opinion. There must be another reason for this issue... I am still testing BUT my attention is now almost entirely focused on the NOAA weather plugin as the actual source of the problem causing RWC's behavious as well as that of xSquawkbox and X Plane crashing to desktop while interacting with RWC.

The fact that my system works perfect now without the NOAA plugin makes me feel better but I am still not 100% happy as the system worked perfectly until this morning.

Regards,

Nico
 

 

 

Link to comment
Share on other sites

1 hour ago, Skymatix said:

Thanks Andre,

I have done that a few times today :)
By using a process of elimination I have come to the conclusion that it is NOT RWC causing this problem. RWC is in fact just the product that is showing us that there is a problem and Sundog is right in my opinion. There must be another reason for this issue... I am still testing BUT my attention is now almost entirely focused on the NOAA weather plugin as the actual source of the problem causing RWC's behavious as well as that of xSquawkbox and X Plane crashing to desktop while interacting with RWC.

The fact that my system works perfect now without the NOAA plugin makes me feel better but I am still not 100% happy as the system worked perfectly until this morning.

Regards,

Nico
 

 

 

Ok Nico just sharing what helped my local situation, I had removed every plugin and slowly ad those to the mix.

RWC was the problem local here.

Link to comment
Share on other sites

I've found a fix that so far is working. I'll have to see if it holds up over time.

1) Remove the NOAA plugin scripts.

2) Start X-Plane and configure RWC to "Always" and "Never change..." In other words, check both. I get no crash with NOAA removed.

3) Quit X-Plane and restore the NOAA scripts.

Now I'm back to using the NOAA plugin, plus RWC is configured with both of the above enabled. So far, no crash. Incidentally, my METAR source is NOAA, not IVAO or VATSIM, in case it matters.

Link to comment
Share on other sites

Gents,

I tried the idea that Martin.S suggested as soon as I found this post. RLBrooks your suggestion is pointing to the same idea BUT on my system it took me almost the whole day to implement due to the fact that I needed to do more housekeeping in my system. (thanks Sundog).

Also by just stopping there seemed like a short term solution and I really wanted to get right to the bottom of this (lol I sometimes go overboard :) )

So after optimizing my system, going back to basics so to speak and removing unnecessary add-ons and plugins the answer that worked for me was exactly the one that Martin.S suggested! The key to this whole puzzle, for me as with Martin.S, lies in NOAA.... DO NOT USE VATSIM AS THE SOURCE FOR WEATHER INFORMATION.

I tested my system with the NOAA plugin. RWC and xSquawkbox many times over and they all work together as long as the NOAA plugin uses NOAA as its source for the weather

Setting the METAR source back to VATSIM results in the SkyMaxx crash occurring again.

Since this change was implemented I have also not had a xSqauwkbox crash again :D

So if you are as stubborn as me, have fun, but this appears to be the answer for me.

Thank you one and all for your suggestions!

Link to comment
Share on other sites

Hi Frank,

Just had X-Plane crash with SkyMaxx 3.2 and RWC. Now I am VRAM constrained (just 2GB), so wouldn't be surprised if because of that. However, as attached log suggests, it may be related to METAR file processing. I am using X-Plane to inject weather (no NOAA). Timestamp of METAR.rwx and log.txt is same, so I guess crash happened just when X-Plane did weather download.

Unfortunately, when it crashed I was away, so I don't know if it was accompanied with framerate drop, but I have to say that with 3.2 framerates are pretty stable for me and I think this is big improvement compared to previous versions (especially for VRAM constrained users like me).

Log.txt

METAR.rwx

GizmoLog.txt

Link to comment
Share on other sites

Same with me today, on an iMac 5K running 10.11.5.  4GB graphics card.  Seemed to be OK since I installed 3.2 of SkyMaxx Pro (with RWC).  I use X-Plane's weather.

I was flying along (and had been for half an hour) when the sim crashed.  I was on PilotEdge.   The sim repeatedly refused to start without crashing.  I restored the "output" folder from Time Machine, but that didn't help.  Then I looked at log.txt and saw the crash was from SkyMaxx, after parsing the weather.  I deleted metar.rwx and the sim started OK.  After a minute or two, it crashed again.  Running it after disabling real weather was fine. 

Maybe X-Plane is currently downloading some corrupt weather, as we are all complaining at a similar time.  Or something, somewhere, is not parsing the reports from NOAA or X-Plane's source.  Very odd.  After all, 3.2 was installed several days ago, and has been stable up till now.

Edited by diamonddriller
Link to comment
Share on other sites

Same problem, Skymaxx V3.2 and RWC causing crash to desktop. Was running fine until I bought and installed the V3.2 update and RWC (got them at the same time).

For me, the sim won't load at all - crashes just at the 'blue load screen'  near the end of the load sequence - it feels like a few seconds before the load would normally complete.... last line before crash is as follows:

SkyMaxx Pro: Parsing METAR data
--=={This application has crashed because of the plugin: SkyMaxx Pro}==--

 

Windows 10 (64)

Can provide full system specs if required...?

Thanks

 

Log.txt

Link to comment
Share on other sites

It should be OK now. There was some bad data in the METAR.RWX file provided by NOAA for the previous hour that seems to have been corrected in the latest weather data.

Start with real weather off, then go to the weather screen and download fresh METAR data, and it should work OK.

Looking into why the previous hour's weather caused a crash though. Even bad data shouldn't cause that to happen. It appears to be a bug in the METAR parsing library we use, but haven't tracked it down yet.

Link to comment
Share on other sites

OK; the bug inside the METAR parsing library we are using that led to a crash in the 2PM EDT METAR data has been identified and fixed. With a future update to SMP, this particular case won't happen again.

It had to do with how somebody entered remarks indicating tornadic activity, if you're curious.

 

 

Link to comment
Share on other sites

Join the conversation

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

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

  • Recently Browsing   0 members

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