philipp

it's a tga file now, not a tiff. You'll find it in CRJ-200/plugins/CRJAvionics/Resources/

For a complete reset simply enter a new departure airport. That clears all route data. For changing the destination use the ALTN function.

I don't understand this discussion. CRJ 1.4.5 32bit is still available for those using X-Plane 9 or 32bit.

I really don't get it. What is your problem here? You can use the plane in 32bit X-Plane, by installing the 32bi version. You can use the plane in 64bit X-Plane, by installing the 64bit version. If you have trouble installing the 64bit version you should provide a proper problem descsription, like what you tried, what didn't work, and a screenshot of the error you get. Simply saying "it doesn't work" won't help.

Okay, so anyone running a reasonably clean system is good now? If anyone can get me a Mac crash report, I'm curious. Otherwise I consider this case solved. The spurious crash when closing X-Plane with the CRJ/Windows/64bit open is not fixable in the current setup unfortunately. But it can be easily worked around by loading a different plane before shutdown or deactivating the plugin. That's what I meant when I said "lost cause".

I very much doubt that it depends on the number of flightmodels. If your fps is high enough that 1 works for you, it is good. However, most of the time you get better results with two, especially when it comes to the autopilot. The autopilot needs really fast recalculation to work properly.

Oh, here we go again.... But XPUIPC is windows-only. I'd like to see a crash report on Mac. The windows version is a lost cause, anyway.

Okay, so I have been changing the plane a few dozen times now over the last half hour, and did not get one crash. That means it has to be something specific on your setups. I can confirm that it is not Gizmo. If you got the crash on Mac, please do the following: Open Applications/Utilities/Console Go to User Diagnostic reports. Find the entries in the list that start with X-plane. The entries are sorted by date, so by looking at the date you should be able to find the crash report that happened when you changed the CRJ plane. Post this report here.

Then this is something new. However, as no one on X-Plane.org has this problem, it must be something specific to the X-Aviation version or Gizmo. We will investigate.

No wonder, as I'm pretty sure no other aircraft uses Qt. Interestingly, it's a windows-only problem.

I've experienced the same thing when shutting down X-Plane with the CRJ loaded. About one in ten shutdowns, the CRJ plugin would crash on shutdown. However, it would never do this for me if I changed to another plane before quitting X-Plane. So I'm curious if this really happens to you when changing to another plane before quitting X-Plane. Disabling the plugin does the same, of course, and should be the same work-around. Unfortunately, there is no fix for that. I've looked into this with Ben Supnik both on the X-Plane side and CRJ side of things. It seems to be a problem of the Qt library the CRJ is using in combination with changes to the entry point of the 64bit X-Plane application. We cannot fix this, as the Qt library was never intended to work in plugin but relies on controlling the entry point of the application, which is obviously not the case with X-Plane. Qt in the CRJ is a relic from before I even got on the CRJ - that part is still from the programmer who worked with Javier before I came on board. However, I'd have done exactly the same thing back then, so no fingerpoiting. I'd probably have gone for Qt back then, too. No one imagined we'd be using 64bit Qt someday, let alone that 64bit Qt wouldn't play well with 64bit X-Plane. Yet X-Plane evolved and we had to drag everything up to the next level and up to 64bit. The only workaround I see is loading another aircraft before quitting, or, if this fails, disabling the plugin before unloading. That's the price we pay for using an alive platform like X-Plane. In FSX, a program designed and written three years ago will continue to work the same way for as long as there's a computer that runs FSX. In X-Plane, things are evolving.

You can see a fly-over waypoint on the FMC is denoted by an @ before the name. That forces the route to not round out the corner at this point.

Hey guys, this is a good one. Apparently, the limitation on four SID transitions has been there since CRJ 1.3 (previous versions didn't know SID transitions at all) and is still there in the 777. I fixed it now in the latest codebase for my current FMS. So congratulations on reporting a CRJ bug and getting a 777 fix I can't fix it in the CRJ right now as I'm not at home and don't have all CRJ stuff with me. However, you also write "The same thing happens ... for the STAR TRANSITION too", and I cannot replicate that. STAR transitions are selectable no matter how many there are. As far as I can see, the particular bug is only present in the SID transitions. Philipp

sure, starting line 166 in the index.html, docroot folder, you find the image map used to make the clickspots. The click map was created using the generator from http://www.image-maps.com/ so actually it should fit all the buttons precisely. I found that sometimes because you target your index finger on the iPad slightly forward, you end up touch-clicking in front (read, ABOVE in the graphic) of the button. Maybe it is indeed good to make the click zones extend over the actual button zone.

Hey Kyle, I found Google Chrome yielding _significantly_ better results than Firefox in terms of responsiveness and refreshing. As for the keyboard input, the original purpose of the remote CDU was to have it on the iPad to utilize the touch-screen. Obviously, no keyboard input on the iPad. The remote CDU working on other no-touch computers is a nice side effect, but not the main goal. Currently I have no plans to change the remote CDU in favor of seond computers rather than tablets. Philipp

No need to sign up anyone especially, when the time has come, it will be in a normal X-Plane beta, just as you'd expect for any new X-Plane feature.

There is no quick solution to change the CRJ to use a different format right now. Instead, I'm currently working with Laminar to change the infrastructure of navdata in X-Plane as a whole. This will hopefully one day benefit all users of X-Plane who care for IFR and procedures. Groundwork has been laid with the 777. There is no isolated short-term solution for the CRJ. Navigational data is like the foundation of every navigation system, as it defines all the data structures from the ground up. You cannot exchange the foundation of a building without changing the building itself.

I think we got the wires crossed here: -navigraph didn't invent the XML format, it was Level-D simulations for FS9/FSX -Aerosoft navdata is not better/different than Navigraph data here, as they encode the same format -The 6-character limitation is correct, but in fact not enforced by the format, as you can see at airports like EDDF, where the procedures are named XXXXX.YYY where YYY is the runway identifier. So it is not Navigraphs fault, it is our fault from four years ago choosing the Level-D XML format and making design decisions that were reasonable at that time. Philipp

This is a limitation of the XML navdata format. Real world SID/STAR are constructed out of three parts: runway feeders, common segments, and airway feeders. The XML format only knows common segments and airway feeders. There's no possibility to encode runway feeders in the XML format. Hence, SIDs or STARs using runway feeders are encoded "wrong". That's one of the many, many reasons why I switched to the Digital Aviation FMS format in the 777, because it is much closer to reality. When the CRJ was conceived four years ago, a data format with this sophistication just didn't exist. So the XML format was a reasonable choice back then, because it was simply the best there was. I'm afraid there's no possibility to teach the old XML format correct runway feeder encoding. The only workaround seems to be renaming the common segment for different runways to fake runway feeders. Navigraph does this at some of the airports I know, notably all STARs at EDDF. I have no idea why they don't simply do that for all airports. Philipp

I'm the wrong person to ask here. Release of the 1.5.3 update is not my decision.

oops, sorry. Sometimes I just don't realize which forum I'm writing in. Well, I have no news on this, the ball is in Ben Russel's and Cameron's court for this...

-About the STAR: The only change I see is you changed the name? I think it would be more helpful for navigraph if you just show them the difference between the latest known working file and 1304 at the specific airport. I think that will help them a lot more. -console message: thats from X-Plane, not the CRJ. I have seen some of those since X-Plane 10.20 changed the Mac OSX API. According to Ben, they are benign and don't cause any trouble. -crash report: Please use the 64bit version if you can reproduce the crash there.

if it worked in 1303 and doesn't in 1304 you have to ask Navigraph. Because the CRJ hasn't changed - only Navigraph data has.

see post #50 above yours.

the CRJ does not use the SID/*.txt and STAR/*.txt , only the xml files in PROC/. The txt files are included in the Navigraph package for other addons using those files. For the CRJ they are completely irrelevant.