philipp

You are probably not using 10.21beta1 then. 10.21 is a Beta, you don't normally get it via the X-Plane update. You have to run the updater manually and have it check for new betas. Which I DONT recommend right now, as 10.21b1 will NOT work!!!

10.21 Beta 2 will be available tonight and fix the error.

The error is confirmed and is investigated by Ben and me. Please only report here if you are on Windows or Linux and are experiencing problems after updating to 10.21.

As you are using Mac, you will have a much more meaningful crash report file available at the Error Console. To see this file, open /Applications/Utilities/Console and select "User Diagnostic Reports". There you will see a list grouped by applications, sorted by name. Scroll down to X-Plane and select the crash report whichs date/time coincides with the last CRJ crash. Post that report. However, I'm almost 100% sure that the the factors MAC+32bit+VATSIM add up to an out-of-memory condition. It'd be very surprised if the crash log showed otherwise. Mac OSX allows for a maximum of 3GB RAM to be used by X-Plane, regardless how much physical RAM you actually have installed in your Mac, which could well be 16GB. Using X-Plane with detailed scenery, plus the extra load of all the aircraft loaded through the CSL of VATSIM will easily run X-Plane out of memory, with the CRJ of course much sooner than with other aircraft with less texture detail.

It doesn't make any change whether the joystick is plugged in, it is about the X52 plugin being loaded. The X52 plugin would not be the first one to to exhibit errors when used in conjunction with the CRJ, just remember the XPUIPC plugin. The crash report speaks a very clear language: The X52 plugin crashed.

That's exactly the problem. If you have the X-Plane TCAS and scalable weather radar, you get the red line, and there is no way to get rid of it. That means, the only chance to get this, is I have to code the possibility to get rid of the red line in X-Plane itself. Which means I must code this in X-Plane, not in the CRJ. However, Laminar hired me for a lot of other things to do in X-P, which are far more important for them before they let me mess around with the X-Plane navdisplay. Philipp

According to the crash log, this crash has nothing to do with the CRJ at all. It is a plugin crashing on startup, that lives in the namespace "X52", which makes me think it is for the Saitek X52 joystick: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread0 ??? 0000000000 0 + 01 libunwind.dylib 0x99e9bed6 unw_get_proc_info + 252 libunwind.dylib 0x99e9bf07 _Unwind_GetLanguageSpecificData + 243 libc++abi.dylib 0x94ee3b62 __gxx_personality_v0 + 1984 mac.xpl 0x1f55d9e6 _Unwind_RaiseException_Phase2 + 1025 mac.xpl 0x1f55daad _Unwind_Resume + 1096 mac.xpl 0x1f554bdb x52datasource_t::x52datasource_t(char const*) + 3157 mac.xpl 0x1f554cd3 x52data_t::add_datasource(char const*) + 678 mac.xpl 0x1f559f26 x52time_t::set_datasources(std::map<int, std::string, std::less<int>, std::allocator<std::pair<int const, std::string> > >*) + 1189 mac.xpl 0x1f55a907 x52time_t::x52time_t(char const*, x52out_t*, x52data_t*) + 98310 mac.xpl 0x1f552372 x52session_t::create_defaultpages() + 30611 mac.xpl 0x1f55254d x52session_t::x52session_t() + 14112 mac.xpl 0x1f5520fe XPluginStart + 22213 XPLM 0x1f36b902 LoadOnePlugin(std::string const&, int) + 50614 XPLM 0x1f36bd87 LoadFatPlugin(std::string const&) + 11515 XPLM 0x1f36c268 XPLMFindAndLoadPlugins(char const*) + 120616 XPLM 0x1f36a311 XPLMInitializePlugins + 16917 com.laminar_research.X-Plane 0x0086b6dd XPPInitializePlugins(char const*) + 350118 com.laminar_research.X-Plane 0x00440a1d MACIBM_init(int, char const* const*) + 1095719 com.laminar_research.X-Plane 0x0057cccb init_sim(int, char const* const*) + 2720 com.laminar_research.X-Plane 0x0057d55b main + 4321 com.laminar_research.X-Plane 0x003f6f39 start + 53

Please avoid posting the same question in two places at the same time. You got a good answer twice now. Generally speaking, you should post the questions at the website where you also bought your copy of the plane. That helps keeping the support local and fast. Philipp

Probably. I just added the code to catch it to both keys for 1.5.4.

Interesting. But unless the OP is pressing the FMC up arrow key in uninitialized state on purpose, it doesn't change anything, right? Nevertheless I just fixed that for the final 64bit update - which will not be out before Laminar declares X-Plane 10.20 final. More info on that here: http://developer.x-plane.com/2013/01/whats-left-in-the-10-20-betas/

This is an entirely different thing - it refers to the entry method of the holding, once the holding is active. It has nothing to do with the sequencing of waypoints, even if one of them is a holding. EDIT: Changelogs for each major version can be found in the Manuals folder of the CRJ.

Well, if it's not the GPU I accept any bet this issue will not occur anymore once there is a stable 64bit version of X-Plane available.

The crash log is inconclusive, but given the fact that your run -Mac -32bit -additional scenery makes it _very_ likely that it's an out-of-memory. Try reducing texture resolution as well as world detail distance to conserve memory. X-Plane 10.20 will be out of beta one day, then we can all use 64bit and no longer have these kind of problems. Philipp

yes, the 32bit version is 1.4.5. There is no such thing as a 1.5.3 for 32bit. I'm not entirely sure, but there might well be a difference between 1.4.5 and 1.5.2.

There was no change in HOLD logic from 1.5.2 to 1.5.3. So if it doesn't occur for your friend with 1.5.2, it is because you are doing something different.

Please avoid posting the same question at multiple places in the future.

Sometimes X-Plane over-eagerly saves state across sessions. Go to Settings -> Operations&Warning. Un-check the box "save preferences". Restart X-Plane. Re-check the box.

Quoting from Chapter 2 "Limitations" of the CRJ-200 Airplane Flight Manual, section 4 "Operating Limitations": That is, even if you could start the engines, you couldn't legally take off there.

Take a look at the liveries/CRJTemplates folder!

You are mixing two different issues here: 1. The initial position reads a nonsense value, like minus a million degrees. That is caused by a change to how X-Plane initializes values when starting, it changed in 10.10 and was subsequently solved with a CRJ update, in 1.5.x 2. The initial position cannot be read from the database (you enter an airport and it shows up as "INVALID ENTRY") then you have a problem with either faulty navdata, incorrect installation of navdata, or a broken navdata cache. The latter can be fixed by deleting the four files in CRJ-200/plugins/CRJAvionics/cache/. The former can be fixed by carefully reviewing the navdata installation process, comparing to how it looks when the CRJ is clean installed. Philipp

The resource monitor is not a reliable indication of _virtual_ memory usage. See item 14 of the X-Plane 64bit FAQ: http://www.x-plane.com/?article=x-plane-64-bit-faq

FJCC is not a problem. As long as both FMCs are not being used at the same time, it'll be no conflict. However the amount of scenery errors is likely to be related to memory consumption, or worse, a memory leak. The remedy here is either get rid of the scenery or wait for 64bit where 3GB memory is no longer an issue.

This problem was introduced by X-Plane 10.10 and was solved in CRJ 1.5.2

Please don't post the same question on mutliple forums. Check the other forum for the answer. Generally it is best to post the question on the same site where you bought the software. Philipp

Perhaps the server is blocked from opening the port by the firewall. I can't give much advice regarding Ubuntu, as I'm using SuSe.