philipp

No, there are no coordinates displayed, but the frequencies should be unique. That they are displayed incorrectly, is a known bug, see http://forums.x-pilot.com/index.php?topic=2111.0 Philipp

http://forums.x-pilot.com/index.php?topic=2111.0 This unfortunately can't be fixed. If the ICAO route requires user interaction, it won't load the rest. How should the FMS "guess" which waypoint it shall use? Of course, one could just select the "nearest" one, but remember the American Airlines Flight 965. Controlled flight into terrain caused by just that - simply selecting the waypoint that was nearest. Philipp

http://forums.x-pilot.com/index.php?topic=2111.0

Obviously there was a lock in the transformation routine. Fixed for 1.1 Philipp

If I read your posting correctly, you are referring to the Second Waypoint Select page. There is a known bug with the VOR display, as mentioned in the sticky thread. Fix is underway for 1.1 Philipp

XFLOW Override is implemented, both gravity and powered. Take a look at the manual. Philipp

Absolutely great! Now this is a marvelous addition to the pilot's handbook! Philipp

Folks, I read an hilarious comment by Simon on xplane10's blog today: "Philipp, the FMC and plugin guru is ageing decades this week, performing an amazing job responding to everyone on the forum. So do them a justice and read their good work." You would not believe how true this is, unless you've seen these top-secret before and after shots from the development headquarter: Guys, patch 1.1 is progressing really well. But I definitely need some sleep now. Philipp

No, it should not increase... Basically it's like Tom Kyler said, I'm removing fuel from some tanks and adding it to others. Perhaps it's those little "buffer" tanks and the gravity-crossflow. I will take a look at it sometime, but now it's not highest priority. Philipp

I have to work around X-Plane's fuel system because X-Plane always wants all tanks to be equally filled and uses fuel from all three tanks. With the CRJ in contrast, first the wing tanks are filled and then the center tank. And when consuming fuel, first the center tank is transferred to the wing tanks, then the wing tanks are used. To do that, I'm doing quite an amount of manipulation on the fuel tanks. Apparently, FSE senses this as "cheating". Sorry, there is nothing I can do about that. Philipp PS: The link above returns an error, I may not access this page.

You are seeing two entirely different problems here: The pdf shows that at first, you haven't captured the flightplan at all - the magenta text line (active waypoint) is still showing 29, which is the departure runway. This means you didn't couple the FMS before takeoff. But you can easily solve this by entering a direct-to, as you did. On the last page however, I cannot see what your problem is - the direct-to is working, the aicraft is heading to the GRZ VOR. The line that is drawn in PLAN mode sometimes is completely unrelated to this. The latter is definitely a bug. The former seems like pilot error. Philipp

As I don't know the procedures of KRDU, I can only speculate: There are a lot of STARs out there that are not to be combined with an approach transition. Like, there is a STAR for the non-RNAV equipped aircraft (that ends at the IAF), while the RNAV-equipped aircraft usually fly an RNAV approach transition (or, as most common in the U.S, are vectored in) that starts at some intersection and not at the IAF. Selecting a STAR and an RNAV approach transition where the STAR is not related to the transition will confuse the FMS. So either you are selecting an inappropriate transition or there is something wrong with the procedure data at KRDU. An error in the FMS is unlikely, since the very same algorithm is used in vasFMC for like 5 years now, and if it was wrong, someone would have noticed before. Philipp

No, the FMS certainly flies the right path - it is only a display bug on the PLAN mode of the MFD.

This is most likely the same problem that prevents loading with the x737 or XPUIPC present. Fix is underway. However, the Saitek panels will be of no use with the CRJ anyway, as they can only write to the standard datarefs, which will most likely confuse the CRJ logic and lead to unpredictable results. Philipp

So I have been investigating this issue thoroughly. Guess what? It's not me! I cross-checked with my CRJ AOM and I'm sure I implemented the cabin pressure controller correctly. I then cross-checked with another X-Plane aircraft that is pressurized and found that it is X-Plane that calculates the DP wrong. So I wrote an email to Austin, and he instantly replied that this is a bug in X-Plane 9 and he is implementing a fix for X-P 10. However, he was not so positive including the fix in an upcoming patch of v9 I fear. So for the time being, the CRJ 1.1 patch will just increase the margin that will allow you to open the door somewhat. Not realistic, but the best we can do with X-Plane 9. Philipp

Thanks for the report. Looks like renaming the tiffs on Windows/Linux works, but not the TGA on Mac. Strange issue. But definitely not your fault. Will investigate. Philipp

I have seen this also on some occasions. It is a bug a could not yet find in a reproducible way. Rest assured I think it is not your fault. Philipp

Y/D illumination is wrong. Someone already told me. Emergency lights is on-off for now. Philipp

This is normal. We are using a different font on Mac than we use on Windows and Linux. We have to, to be compatible with OSX 10.5. There are still people using 10.5 out there, so when we had to decide between "same looks, but crashes on 10.5" and "slightly different look, but works everywhere" we opted for the latter. This may change in future, especially with the arrival of 10.7, when statistics indicate that fewer users are running 10.5 Philipp

Looks like another plugin conflict to me. Can you try proceeding as laid out in the sticky thread and try if CRJ works without REX present? Philipp

If X-Plane crashed, this file is supposed to be in the X-Plane main folder, just like the Log.txt. However, past experience shows that 99% of the crashes are plugin conflicts, as explained in the sticky thread. Please refer to there: http://forums.x-pilot.com/index.php?topic=2110.0 Philipp

As you already own the CRJ, why don't you put your CRJ-equipped X-Plane installation on a USB-pendrive and go to your nearest Apple store and try it out yourself? Philipp

256MB VRAM are definitely too low for using an external monitor. As for the display refresh rate, have a look here: http://forums.x-pilot.com/index.php?topic=2098.msg20802#new It is crucial that you have as little as possible programms running in the backgorund. Browser, Skype, PDF Viewer, they all steal CPU time from the display threads and especially with a second monitor, force graphics context switches that slow down the displays. Philipp

Give me the crash_log.txt please...

You'd be surprised how much hardware rendering is in modern browsers. All CSS transformations are done on the GPU these days, as is webGL, and also some HTML5 stuff like Canvas, SVG, .... Browser do use the GPU a LOT these days! Well, I think you can either buy an IPad, or use some old-school browser without the hardware acceleration features, like Internet Explorer 7. But who would want to use THAT???? Philipp EDIT:And also the Browser on a second monitor... Imagine the number of context switches going on there... No surprise the displays were slow.