philipp

Great you got it working by reading the manual. It was just about the same with Nova - we tried it, and it worked right away. The next time I have a guy on the phone showing me a no-bug, this guy is going to owe me a beer! Philipp

1. What causes the crash? The crash is caused by a well known problem of the Mac OSX font engine, that affects a variety of applications besides the CRJ, like Photoshop CS4, Adobe Flex, Cubase and ArchiCAD. Various fixed have been applied throughout the lifetime of OSX 10.6 that fixed some, but not all of the issues. With the CRJ 1.1 version I changed some minor details in how the displays are drawn, to make the fonts look nicer and make appearance more consistent between Windows and OSX. Apparently, one of those details triggers the dreaded "HandleOFAScalerMessage"-crash that we are talking about. I also had this crash once, but was able to fix it for my Mac completely by following the advice at http://support.apple.com/kb/ht2509 "validate problematic fonts" The crash itself occurs in a library provided by Apple, not by the CRJ or the Qt Framework the CRJ uses. Thus the underlying issue can not be fixed by us, we have to rely on Apple to fix this in the OS. 2. What we do about it in the short term As we didn't get any complaints about the displays looking a bit less smooth on OSX than on Windows, I am going to release a hotfix for OSX that just rolls back the change to the display font. Don't worry, you are not going to lose any of the fixes provided in 1.1, the functionality remains entirely the same. You are just going to see the old display font again that you are used to from the 1.0 version (also I got some request to restore it anyway, as someone liked the old version better. Well, this is apparently a matter of personal taste). 3. What we do about it in the long term If I report the problem to Apple, chances for a fix are very dim. So I'm going to report the issue to the provider of the Framework, Nokia. So far I already reported some issues there and the responses have always been very productive. So we can hope the issue gets escalated to the guy who glues the Qt libraries to the Apple libraries, and if this guy reports the Apple, chances for a fix are higher by orders of magnitude than if anyone of X-Avation does this. 4. What you can do about it while we prepare the hotfix If you google for "HandleOFAScalerMessage" you will find various suggestions. As I said, I was able to eliminate the issue on my Mac completely by just deleting a duplicate font. You are not going to speed up the process by sending me private email or forum messages. Philipp

The display frames are now tga files in the "CRJ200" subfolder of the JRollonPlanes folder. The process however is the same: rename them to e.g. DisplayFrame.tga.backup and they will not be loaded anymore. Philipp

I seriously doubt it has to do with the installed C++ runtime. If the C++ runtime has an error, the CRJ won't load. It is highly unlikely that it would cause inserting waypoints to fail. EDIT: I sent you a PM.

Can not reproduce here. I have no problem entering any of this routes. Can you please confirm that when you clean install, you also remove your updated navdata beforehand? After a clean install with the navdata shipped with the CRJ, do the routes work then? Does it break when you update the navdata? Philpp

Of course I need to update the X-Plane datarefs to maintain a consistent state - but this is a one-way-road: The CRJ software has control over what the state is right now. It is the authoritative instance and tells X-Plane what to do, dataref-wise. The other way round won't work, since X-Plane cannot tell the CRJ what should be going on, as this may very well violate the CRJs internal logic. If you go through the datarefs I published, you can be sure that you use the CRJ logic as the authoritative instance. However, I try to reproduce your problem: You said you assigned a keystroke to the autopilot speed button. Does that mean you assigned a keystroke via a Command-to-dataref plugin to the "CRJ/autopilot/speed_button" dataref? And X-Plane crashes when you push this button? You used exactly what to assign the keyboard press to the dataref? xjoymap? Please go with me through your setup and explain to me all stuff I have to install. I still have no clear picture on what you are trying to accomplish and what you are using to do so. Philipp

We have indentified the possible culprits: 1. Old debris from the CRJ 1.0 installation An old version of vascore cannot work with the CRJ 1.1 avionics software. Please be sure to follow the installation instructions of the 1.1 installer carefully. Don't move old files along or have several versions of the CRJ installed in parallel. This WILL Crash! 2. XPushback XPushback seems to consume messages not intended for it. The CRJ exchanges a lot of messages with the vascore plugin. The codes used are randomly selected, so it is highly unlikely that XPushback and vascore share message codes. XPushback seems to consume ALL kinds of messages and chokes up on that. I can not do anything about that. This will need to be solved in co-work with the developer of XPushback. However, as the XPushback homepage states development is stopped, so I don't know if there will be any response. If all else fails, you need to remove XPushback for flying the CRJ. 3. Other plugins?? If you have a crash while not using XPushback, please report. 4. Broken fonts I have seen two crash reports in this thread related to broken fonts in OSX. You can identify them by a crash involving the "HandleOFAScalerMessage" function. If you google for this fault, you will find that this is related to having either duplicate or incorrectly converted fonts installed. To fix this: 1. Open Fontbook 2. Select All (Cmd + A) 3. Select "Validate Fonts" from the file menu. 4. Remove any fonts marked as invalid or duplicate For more info, please consult this article at Apple Support: http://support.apple.com/kb/ht2509 Philipp

We have indentified the possible culprits: 1. Old debris from the CRJ 1.0 installation An old version of vascore cannot work with the CRJ 1.1 avionics software. Please be sure to follow the installation instructions of the 1.1 installer carefully. Don't move old files along or have several versions of the CRJ installed in parallel. This WILL Crash! 2. XPUIPC with certain applications - not XPUIPC itself. FWIW I can not crash the CRJ with XPUIPC. So I need detailed information about the setup you have with XPUIPC. If you experience an XPUIPC related crash, please give me a detailed list of all applications running that use XPUIPC. Then please try if the CRJ also crashes when NONE of XPUIPC-driven software is running. 3. XPushback XPushback seems to consume messages not intended for it. The CRJ exchanges a lot of messages with the vascore plugin. The codes used are randomly selected, so it is highly unlikely that XPushback an vascore share message codes. XPushback seems to consume ALL kinds of messages and chokes up on that. I can not do anything about that. This will need to be solved in co-work with the developer of XPushback. However, as the XPushback homepage states development is stopped, so I don't know if there will be any response. If all else fails, you need to remove XPushback for flying the CRJ. 4. Other plugins?? If you have a crash while not using either XPUIPC or XPushback, please report. Philipp

Hi folks, to help me analyzing your problems I absolutely need BOTH logfiles: 1. The Log.txt from the X-Plane main directory 2. the crash_log.txt from the X-Plane main directory The crash_log.txt on Mac is also avialable in the moment of the crash, when the reporter window is active. When you click the "Report" button, you also get the crash log. I absolutely need both files or I have no means to help you. Also, please be sure to post in the right thread and help me keeping issues on Windows and Mac separated. Thank you for your collaboration, Philipp

As long as you use only CRJ datarefs, you should be fine. Writing to standard datarefs might cause any kind of confusion in the CRJ avionics, from a crash to unwanted autopilot behavior. You are definitely on the right track assigning all values based on the dataref list I published. You say Your crash file says otherwise. There is a plugin at work called "SerialFP2_XPLM.xpl". It tries to write "SET_sim_cockpit_autopilot_airspeed1" - this is not the VT dataref. This is X-Plane standard stuff. Seems you still have some writes to standard datarefs in there. When you get those eliminated, there is no reason why the CRJ wouldn't work with your hardware. Philipp

No, this is entirely unrelated to openGL vs. directX. Since the fonts are pre-rendered using means of Qt before they are handled by openGL. The openGL stuff does exactly nothing font-wise. I know of the issue with UFMC and I can assure you that this has nothing in common with the CRJ software. Philipp

To be more precise, it is a limitation of the way how the operating systems prepare the font glyphs to multi-threaded applications. On Linux there is a technology called libfontconfig which is part of the X11-servers since the early 2000's, and it works marvelous. This is why you get the best frames by far on Linux. Also Mac OSX does a good job preparing the fonts for access. The font system of OSX can get confused by incorrectly imported OTF fonts or duplicate fonts, which my lead to a crash, but apart from that it works great. On Windows there is a lot of synchronization overhead internally (in the OS libraries, nothing which we can influence from the CRJ side) which makes rendering the displays slower compared to OSX and Linux. I did my best to provide some shortcuts on Windows to make the rendering as fast as possible given those limitations. So unless Steve Balmer wakes up tomorrow and phones his windows department telling them to enhance threaded font-access in Windows 7, this is about as fast as it gets. Philipp

I think you are right and this is simply an error. The speeds are displayed in the wrong order. We will correct this. Philipp

Your logfile shows the DirectSound module is crashing. The CRJ doesn't use DirectSound at all. If I remember correctly, X-Plane on Windows uses it instead of openAL. So I think you should have your system undergo a general checkup with all regarding to sound: -check the drivers for your sound chip -check for a DirectX runtime update -check the DxDiag sound pane for issues As I never used DirectSound and the CRJ doesn't interfere with X-Plane's sound system at all, this is about all advice I have for you. It seems more likely that this is an issue with the XSquawkbox, which of course uses sound. Philipp

You need at least 85%N2 on the other engine to produce enough bleed air pressure for a cross-start. This is explained in the manual. Philipp

I'll keep that suggestion in mind for future development. Personally I don't have this problem since on my mouse it takes quite an amount of rotation against a resistance and a noticeable click-click-click to turn it, so i never accidentally set the throttles. However, I know it is different with the Mighty Mouse - which I find pretty awkward to scroll. Philipp

Then there is probably nothing that can be done about that - other than reassigning all operations to work on the CRJ Datarefs instead of the default ones. Philipp

I checked and found a slight difference in the navdata format between the one I had when developing and the one now shipped. It is however easy to fix and the fix will make it into the 1.1 update. Philipp

Simon, I admire your patience with your Windows installation. If this had been mine, I would have "format c:"ed it already No, seriously you seem to have some confusion with interfering Windows updates. And since you are the only one with this problem there is really nothing we can do on the CRJ side. Philipp

See "confirmed bugs" list. The trick with renaming the frame currently doesn't work on OSX, only on Windows and Linux. Fixed in the upcoming 1.1 update. Philipp

This is exactly the same error as above: The currect CRJ software apparently has an incompatibility with the C++ standard library included in OSX 10.5. The upcoming CRJ 1.1 version is built with some compatibility options that should make it work on 10.5 also, but as Cameron already pointed out, there is really no reason to stick to 10.5, as the Snow Leopard update is both inexpensive and also a great improvement in overall usability. Philipp

You should see the "crash on incoming message"-error solved in the next update. However, I can make no guarantee how the CRJ software will behave when another plugin (Saitek panels plugin) makes changes to the standard datarefs. The CRJ software is not designed for that. Philipp

The log file shows it is not a CRJ routine crashing, but rather X-Plane crashes processing the scenery. As you read various posts in this forum you will find that that you are more likely to encounter out-of-memory errors due to faulty sceneries or just too high resolution settings, when you use the CRJ compared to other airplanes. The CRJ does not cause these problems, it rather makes it more likely that those problems show up earlier. Simply because the model uses a lot of high resolution textures that consume both VRAM and memory. See especially the thread about identifying scenery errors. http://forums.x-pilot.com/index.php?topic=2103.0 Philipp

The F/D has a known transformation error, as indicated in the "confirmed bugs" list. The same with the distance of the destination airport. This is fixed in the upcoming patch. However, I have no idea what you mean by "Also, is there any way to get rid of the objects that float on the screen in 'full screen view with or without HUD'?" Can you elaborate on that? Philipp

Fixed along with some other radio peculiarities in the 1.1 version, which should be out really soon now. Philipp