There is a bug in 10.32r1 Steam Edition – some kind of interaction between Steam and Gizmo causes Gizmo to crash. Since Gizmo is loaded on startup, this means users of popular add-ons like Skymaxx Pro can’t fly.
We are working on this now and I am hopeful we’ll have some kind of fix tomorrow. I’ll also post more details about the bug once we have more info. The crash affects X-Plane 10.32r1, Steam edition on OS X only, as far as we know.
In the meantime: if you get a crash on start with X-Plane 10.32r1, please file a bug. Please include your Log.txt file and any crash logs that you see go by. In particular, if a plugin is having problems only on the Steam edition (but not the Global edition of 10.32r1) or if a plugin besides Gizmo crashes, I would like to see it!
UPDATE: We have determined that the crashes are caused by Steam introducing an ABI breakage of the libstdc++ runtime when we use one of their distribution tools. We are now working with an engineer at Valve software to solve this. In the meantime, the Steam distributed X-Plane has been rolled back to 10.31.
UPDATE 2015-01-21: Thanks to quick help from Valve software, we were able to re-release X-Plane 10.32r1 on Steam today which now gets along fine with plugins again.
Sweet! I helped report this bug and now it’s famous ;).
Seriously though, dearest readers, if you’re wondering if reporting a bug to Ben through the normal forms is a good idea… here’s living proof that it is. I mean, I reported this one Friday night (I assume I wasn’t the only one), and they got back to me over the weekend to work this out.
Kudos to Ben, and the whole team, for getting on this so quickly. Hopefully Valve helps you guys work this out pronto so it’s ready for 10.35 :).
We definitely appreciate that Jay:
– Reported the bug, including log files
– Was kind enough to not drop the F-bomb too many times in the process and
– Responded when asked for feedback.
It definitely helped get this firedrill resolved faster!
What?! Swearing was an option! I should have taken that one up! Next time Ben, next time…
you make tones of updates in the past, thats great, but why your are not trying to fix some REAL IMPORTANT Things as AA und Distance too ???
There are an lot of X-Plane videos on Youtube, and every time the MSFS Communtiy see always the same bluring textures in high altitude and HDR flickering.
I think if you would put a little work also in this part of the X-Plane system, you will win a lot of new X-plane user !!!!
Please consolidate to 1 comment next time.
There will, at some point, be improvements to AA – I think I already commented on that in another post’s comments section.
Changes to distance and AA will ship when they are finished and ready to ship; the order that features ship is a function of who is working on them and how long they take to develop, not just their priority.
Kopelent,
the priority and the importance of certain new features or bug fixes is decided by the development team based on the evaluation of a variety of elements, including (but not limiting to) the wishes of the users. The fact that you consider AA and distance improvements important does not guarantee that other users think the same way. For example, I use X-Plane essentially as an IFR trainer, so when I use it I fly most of the time in night or low visibility conditions, so distance improvements matter almost nothing to me. Yeah, they will be welcome when they come, since I sometimes simulate VFR flights, but they are by no means show-stoppers. The same for AA, since my hardware configuration would not allow me to take much advantage of it anyway (not enough GPU power). This just to say that if AA and distance improvements have not yet come, it could be because you are the only one asking for them and/or the code changes needed to support them are very complex and/or the development schedule is already filled with other higher priority tasks that have been waiting. Last but not least, when you recall the MSFS Community as a benchmark, don’t forget that MSFS is a radically different product than X-Plane, because the two products are aimed at a totally different target of users, so the priority of their wishes and needs is in turn totally different. And I say this owning and having used both of them for a long time.
As I have said before, the best way for users with differing priorities for features to resolve what is most important is physical violence, e.g. a cage match.
The advantage of this system is two fold:
– Since only one user will survive the tournament of death matches, there won’t that be many features for me to code and
– I will be -absolutely terrified- of that one remaining user, and will most certainly code ANY feature requested immediately, for fear of my life.
(I probably shouldn’t joke about this to a heavily-armed US audience…)
Thanks for the laugh Ben.
I’m printing this out and taking it to my stake holders as our new development policy. It would be fun to see VPs having a cage match methinks…
What a great inspiration, Ben! I will also use this as our new priority-poker system
Thank you Jay & Ben for posting some info regarding this crash issue.
I have been playing XPlane10 via Steam (OSX) for the last little while & have been experiencing system crashes (freeze) on final approaches to my destination airport. After searching for awhile & finding these posts, it is very encouraging that the issue is being looked at. My only concern is noticing the mention of XSquawkBox(Gizmo) possibly being the cause which I don’t have installed. Not sure I completely understand the circumstances to my crashes but I;ll try my best to provide a crash or bug report via the request method.
Thank you gentlemen!
Good day,
there is an issue with the 10.32r1 and apple and the ASAL i sent the info via the org
with Apples problem report and a log txt
captbullett
XP.org
Hi,
Please FILE A BUG. The bug report form link is on the right side of this page. There is no other useful way to get us info. Sending info “via the org” is not useful.
Sending the report right now.
So, where was the bug exactly?
There’s a tool in the Steam distribution toolchain that injects code into the app binary which we ourselves don’t need but which caused plugins using certain functions of the C++ standard library to crash. The solution was to tell that tool not to screw with our binaries.
Because that happens in the distribution process, i.e. getting the app ready for uploading to Steam servers, we never saw the problem on our machines because we don’t normally upload and download the app first to test something.
So steam replaces parts of your libstdc++ with its own, with a different abi?
At least on Linux I didn’t experience any crashes due to this bug, as I bypass the steam runtime when running x-plane.
We don’t know the exact mechanism of what Steam was doing, but all of the failure parts were in parts of standard libraries, e.g. dynamic_cast or std::string(). It was super weird; I couldn’t code a plugin to fail that way if I wanted to!