Emalice

Ok, but who cares whose fault it is, really ? Indeed the choice was probably reasonnable at the time and nobody is questionning the judgment of the developpers for making it. The only thing that matters now is this : is there any practical way this issue can be fixed ? I don't know, through a patch to the CRJ, with an update to the formats the FMC can read, who knows. Is there a potential solution, and if yes, is it ever going to be applied ? Yes or no will do, but we, as users, want to know where we stand and don't want to modify our XML files with all the necessary careful backup and all if a fix is underway, right ? Thanks again, Tristan.

Confirmed then, this is another manifestation of a previously known problem, mentionned in this thread : Once again, is anything going to be done to address this issue ? I'm only asking since, given the choice between waiting a few months or editing my waypoint file, I'd choose the former. Thanks, Tristan.

I know you are not responsible for the CRJ release. But in the thread I mention, you suggested a possible patch fixing the problem associated with identically named waypoints in the CRJ. I was wondering if that was still happening. Whether it is happening or not, I'll keep on waiting patiently for the CRJ release as I have been for the past months. Thanks, Tristan.

Hi. Could this problem be similar to the one described in this other thread : http://forums.x-pilot.com/index.php/topic/3274-setting-star-in-fmc-causes-weird-display-issues-in-xplane/ Where do we stand on that potential fix, Philip ? Cannot wait to get my CRJ back, it is such an amazing product.... Thanks, Tristan.

Hi Philipp. So, I am currently patiently waiting for the release of CRJ200 64bit from x-pilot. I'm just wondering if that fix you mentionned for the problem discused in this thread will be incorporated in the upcoming version ? Thank you, Tristan.

I know, I was just joking ;-) But to alleviate the general frustration I still think it would be great if there was an annoucement about the situation, just a little pinned post in the CRJ forum. Keeping a crowd of impatient customers in the dark is the best way to make sure ten similar topics will be created each day. Cameron ? E.

Oh, so that's the hold up then, good to know. In a similar post yesterday, Cameron advised to read the topic on the matter, but I couldn't find said topic. Maybe it should be made sticky. Ok, so I guess it's time to rant on SASL's forum now. E.

I understand your frustration, however, x-plane 64bits is still beta. X-aviation will not release the crj200 while under beta. I get the feeling it has been their policy all along : to deliver completed quality products, even if it means waiting a long time for them (cf. MU-2). If they release the CRJ 64b now and something breaks with the next xplane update, users will be very frustrated and x-aviation will have to take the blame for something they have no control over. I am sure they have not been idle during this time, and that the 64bit version is almost out of the door. Once xplane 10.20 64bits goes final, I am sure they will give the CRJ a thorough test flight and then release it in a flash. So, just like me and many other impatient users, all you have to do is wait, patiently. T.

Got it yesterday evening. I havn't opened the file though, i'm not finished reading the manual... (take this as a compliment, Javier ;-) ) Thanks a lot, Javier, for this wonderful christmas present from me to me. And thank you Cameron for the early sale discount, this is a nice gesture on your part for faithfull customers. Merry christmas to all. T.

Ha, you know, many users (including myself) are more than willing to forgive any delay on the Moo when they see what you are doing to the ixeg 737 in the mean time. Plus, when the 737 gets released (anytime now, i guess, right ;-) ) we will all be so busy playing around with it, flying it, crashing it and what not, that we may forget about the moo altogether until we receive notice of the update (anytime now, right ?). Keep up the good work, Tom. E.

Ok, wonderful. Now I'll go over to xplane.org and bug Austin about the release date for that kit . Cheers, Tristan.

Hi Philipp. Well, it's a matter of statistics I suppose. Take a population of CRJ users, remove all those that use computers that can handle the "identical waypoint names error" without visible adverse effects, then remove all those that never fly to London or Berlin, or any other place where that problem may arise, then remove all those that fly to those destinations not using the incriminated procedures, or no procedures at all, that leaves you with a fairly small sample, right ? And still, from those who encounter the bug, you can only count on an even smaller sample that will recognize it as a bug and report it to support. And even after that, it took some thought process, and help from several people, to locate the probable cause of the malfunction. But that is not the most relevant question here, I guess. The fact is, we identified a malfunction in the CRJ, so the question is : what will the CRJ team answer to that problem be ? I really like the idea of being able to use industry grade nav_data at some point, and I totally support the incentive, but this is very long term. On the short term, I have the feeling that correcting the current problem is only a matter of a few extra lines of code to have the FMC double-check waypoint identity by using the ID number contained in one of the tags (but again, I never coded in C, so I may be very wrong here). I am not being passive-aggressive here, I just really want to know if the problem can be solved easily enough so that you can release a small patch, at some point in the near future, or if I will have to go through thousands of lines of XML to manually edit all procedures with identical waypoint names. I really appreciate flying the CRJ, please help me enjoy it even more. Thank you. Tristan.

Well, that is probably a very good point, and that's when input from the CRJ staff will be appreciated : 1) either the nav_data is wrong, all points should have clearly distinct names, and there is nothing to do but rename them, or ask for a corrected nav_data 2) or identical names is perfectly acceptable, and the FMC should be able to read them properly. In the latter case, then I guess we should wait for Philipp to tell us if the FMC can be modified to become robust to identical names (i suppose it should check for waypoint name AND waypoint ID). If the modifications is easy, then it is probably better to wait for it than to start renaming waypoints in the whole nav database. T.

Cessna, you're a hero. Too bad I made that flight last night, when I had to manually fly the published star. I guess I still have a lot of practicing to do, because it was not pretty. Glad I wasn't flying online I will edit my nav_data with different names, and see if I can do the same trick for the star to EDDB. Thanks again. T.

All right, now I get it. The coordinates for each "BIG" waypoint are the same because they all correspond to the coordinates of the VOR station. they are distinguished by their radial intercept or dme intercept relative to that station. Also, the hdg_crs_value is the heading of the plane required above the waypoint, so they should be tangential to the flight path. In that case, I agree, the nav_data does not seem too bad, so there is something wrong in the way the FMC interprets it. Also, even when I remove the bogus waypoint, the flightplan is still not the way it should be, but the stuttering disappears, and I can't understand why that is. Maybe it is time one of the developpers chips in an opinion, an idea on things to do or try to help solve, or at least identify, the problem ? So, Cessna, in the mean time I will try playing around with the nav_data for that STAR and see if I can find something. Thanks. T.

I downloaded that manual from aerosoft some time ago, and maybe the numbers are corrected, but the method still looks odd. Also, the example shown in the manual is such atypical (one very seldom flies with three passengers) that it is not really helpful to check if i am doing it right. Anyway, for me that calculation sheet is still systematically producing numbers that are below the charted range for the index. Best, T.

Hi Cessna729. So, that snapshot of the MFD you show is exactly what I have when I load that STAR, with the nav_data cycle I mention in a previous post. When I delete that bogus point, i.e. BIG off the top right corner of the MFD, everything goes back to normal, or at least I no longer see an adverse effect on my general display, meaning that maybe there is still a problem but with no visible consequences. Also, looking at that excerpt of the nav_data you show, I see that points ID 3, 4, 5 and 6 are all the same : same type, same coordinates, only heading course values and speed/alt restrictions are different. I cannot see the one that offsets to the top right of the MFD. I don't know much about the syntax of STARs, but my feeling here is that the FMC acts silly trying to deal with a course impossible to follow. Deleting that mysterious point from the legs menu acts as a "manual takeover" from the user and the FMC no longer needs to try and figure out how to solve that puzzle. And indeed, I jsut tested that and realized taht removing ANY point from the star, manually, from the FMC's "LEGS" page stops the freezing display issue. So, is uptading with navigraph to the latest nav_database likely to solve that issue ? T.

Hi Joga. So, one thing we must try when you have the original nav-data is to see if problems appear with similar flight plans for both of us : I will try loading sid BERT1W from LJLJ and report. In the mean time, try loading star BIG1E to EGLL, RWY 27, transition BIG and see if that triggers the problem. If it does, delete (BIG) in the flightplan and see if that solves the problem (and I mean the point which is actually between parenthesis on the LEGS page, anyway when you look at the flight plan on the FD, this point clearly appears as bogus). Cheers, T.

Very quickly, I should say that I did not get any newer airnav database, I am currently using the one I got with the CRJ-200, which I bought around the 20th of April. Ok, I checked directly on the FMS, it says "active database 25AUG2011 21SEP2011", so I suppose that's navigraph cycle 1108 or 1109. I know at some point, long before I got the CRJ, I downloaded Robin's database for Xplane, so could there be a conflict with that ? Joga, are you also able to resolve the problem by removing one bogus point from your flight plan ? Are we sure we have the same problem ? For exemple, I do not suffer any zooming problem, the distances remain correct, and trouble appear when I enter waypoints in the FMC, not when I start flying the route. Ok, I realize it is really possible each computer could have it's own way of dealing with the same problem, but we really have to make sure that we are really talking about the same issue, if not we should create a separate thread I suppose. T.

OK, so i've tried removing all plugins, and the problem remains. But it is getting even weirder : the problem only appears when I choose some particular transitions : Planning a route to london heathrow, I chose star BIG1E, RWY ILS27, the display is fine, then if I selct transition BIG, I get this frozen display issue, but if I choose transition BNN, then the freezing is gone. Ok, then looking closer at the flight plan displayed on the ND, I saw one point that was clearly out of the way (labeled (BIG) in the FMS). So I deleted that point and the freezing disappeared. So is there any possibility that the FMC reacts to stupid flight plans ? Anyway, I also checked my previous flight route (LIMC-EDDB) where the problem first appeared, and it so happens that STAR RUD5S, RWY ILS07 trans KLF07 has a point labeled (557) right after EDDB (in case of a missed-approach). Deleting this point stopped the freezing. Is something wrong with the nav database ? For what it's worth, I also removed/reinstalled the aircraft from my XP folder. but that did not solve the problem. Any insight on what is going on ? T.

Ok, I did not go back to the CRJ since that post, but one thing I did when the problem first appeared was to make sure I closed as many programs and services in the background. The only thing I had opened anyway was acrobat to keep an eye on my charts. But even closing this one did not change a thing. I will see about the plugins, but anyway, I never use both at the same times so I always disable the one I am not using. I understand disabling and taking the plugin out of your plugin folder are different things, but I never had any crashes due to X-ivap / Xsquawkbox so far. Anyway, I will do what you suggest and see what happens.

Hi Tom. Thank you for the update. I also believe you made a sound decision. However, I am probably a 1%, meaning I enjoy the whole flight preparation phase, pushing buttons, pulling levers, typing numbers and so on, and the best part is when you fire up the engines. But, as much as I would have loved to see the full featured engine in the update, releasing sooner rather than later is in my opinion a better strategy right now. Annoying people like me will cut you a lot of slack and you'll be more free to work on all your projects and keep the moo on the back burner for as long as you need. Oh, and just to make sure, what you call the props lock, is it that feature where the props will feather on improper shutdown procedure and you then have to press the unfeather button at startup ? That sounds like the kind of feature made just for me, where you have to follow a procedure in the simulator not just for the sake of it but because otherwise it has consequences. E.

Ok, I know, this will sound strange. I have been using the CRJ200 for a very little time but I love it and did a half-dozen flights with Freeworld VA, and everything was fine. But yesterday, I flew LIMC-EDDB and at some point I realized that the display was acting weird. It is difficult to describe, but it was like when you play a videotape on a vcr at half-speed : it shows a picture, then freezes for a half-second then jumps to the next picture. Well, it was the same here, making any manipulation very difficult. I tried reducing the window size, some rendering effects, low visibility etc, it didn't seem to affect the issue. And anyway, the fps number was at its usual 30. Eventually XP crashed during that flight (no connection, that was my fault), so I made it again today, and that's when I realized that the mysterious freezing problem started right after I programmed my chosen STAR in the FMC while still on the ground. So I reloaded the plane, started the flight with my usual display, then upon reaching transition I entered the STAR and the freezing started immediatly after I pressed the EXEC button. I have absolutely no idea how one could affect the other, but maybe someone can help me here ? Some info : XPlane 9.7, windows 7 64bit Mobo : asus M4N98TD EVO, phenom II X4 3000+, 8 Gb ram GPU : nvidia Geforce 250 GS I have the latest version of the CRJ file. The flight as entered in the FMC : LIMC SID ABESI UN851 MASEK T200 RUDAK STAR EDDB STAR : RUD5S, transition KFL07. Also providing the log.txt Hope someone can help me. Log.txt

Hi Javier. Thank you for answering. I know that %MAC is not necessary for the CRJ in Xplane, and that it is onlythere to show what it is like to be a pilot in real life. But still, they make little sense to me as they are, and that really bugs me I will look at the aerosoft tutorial then. As for the passengers positioning, I suppose you know Jack's Q400, where he has implemented such a feature. Maybe a collaboration between you and him is in order ? Aaah, imagine two of the best aircrafts in XP marching hand in ha... eer, wing in wing towards brighter skies and better than life models... Take care, Javier, and thanks again for a wonderful aircraft. E.

Hi. Two things : 1) I still have a problem with the manual way of calculating the stab trim setting : unless the aircraft is nearly empty, my lizfw value is always very low. Minus fuel indexes, i am always out of chart to get the %MAC. Quick example : let's say 50 passengers (all adults) with 35 bags (1015lb ; index 8), total A = 22.8 + 10.2 + 1.1 = 34.1, total B = 36.84 + 7.4 + 8 = 52.24 => LIZFW = - 18.15 (and yes, this is using the forward lavatories instead of aft, or 14 pax max in section A and 12 pax max in section D. So here the index is already out of range, and that's not even counting the fuel. Also, total A can never exceed total B (max total A = 34.1, and DOI itself is already larger than that), so why is lizfw = total A minus total B ? Is it a typo ? Should it be total B minus total A, or maybe is it a plus ? Anyway, if someone could figure it out, i'd be grateful. 2) With a recent update there is an excel sheet to calculate performance and stab trim index. There are a few mistakes in this one : for the bags, the weight is calculated in pounds (x * 29) but the table to get the index (Sheet 2) is in kg. Also, it is not performing the calculations of total A and total B correctly. Finally, the take-off fuel index is calculated as the subtraction between the total fuel index and taxi fuel index. But the index and fuel weight values are not linear : 7000lb fuel – 772 (taxi burn up) = 6200 lbs. The index for 6200 lbs is 6.25, while index for 7000 – index for 772 = 6.3 – 0.9 = 5.4 I've made a corrected spreadsheet which I will upload tonight. Apart from calculating that index (which is only a minor thing, all considered) I am really having a lot of pleasure flying this beautiful aircraft all across Europe. Thank you for a lot of good work. E.