Litjan

Thank you for the report - it does look indeed like there is a slight gap. We will check it out and add it to the list for 1.1! Jan

Tom is awake and aware - a fix is coming up shortly - we just need to decide if this one is the only fix for the hot-hotfix or if we should squeeze in another one or two that also cropped up... Jan

Yep, known, thanks! Will be fixes soon as possible! Jan

This is very weird and you need to provide some more details about this. Load the plane, and as soon as the first console pops up, stop X-Plane and post your gizmo log, IXEG_FMC_debug.txt and log.txt here. Thanks, Jan

Hi, this is the same error we see over and over - the other ones are just follow-up crashes. I am not sure you can revert (you could before by putting in the code number for previous hotfixes), but I expect this one to get fixed within a very short timeframe. Tom is still asleep (it´s 05:40 a.m. in Texas)... Jan

Don´t delete stuff on the CLIMB page, it is mostly for viewing your current limitiation - you can delete/edit the speed restriction altitude and speed, though. To manage your restrictions, go to the LEGS page and change them there. Your mileage with procedure turns and teardrops may vary - I am not quite sure how they hold up right now ;-) Jan

Hi, the "4 dots" doesn´t work anymore, it never did reliably - instead the FMS will constantly update the IXEG_FMS_debug.txt in the aircraft root folder, supplying that should be sufficient. After you get one "softcrash", nothing will work reliably anymore, so only report the first occurance, then reload the aircraft (or reboot gizmo). We did some sweeping updates to the FMS logic, so I expect to see the occasional bug that our small team couldn´t find in time. Thanks for reporting, this is helping us immensely to narrow down on the lingering problems and hopefully fix them very rapidly! Thanks, Jan

Yes, we had some problems with this before - we save the airplane´s fuel level on exit - and sometimes, somehow this gets set to 0 - I am hoping that this is cured now with the new patch 1.0.6 - install it and let me know how it goes? Thanks, Jan

Hi rlawrence, let us know how 1.0.6 does for you! Thanks, Jan

Thanks, Gary. We will investigate this! Jan

The "kink" is the attempt of the FMS to re-intercept the direct line between the initiation of the turn and the target waypoint. I don´t know the description of the MAP, but it could be that the bearing inbound to the holding fix could be specified. Jan

Hi and I disagree. It works fine for me. Check your X-Plane datarefs (data output) to see how much brake input you have. Jan

Yeah, this is due to the way we calculate the "runway centerline" - sometimes the resulting number differs a bit - don´t let it throw you off, the succession of waypoints it the accurate line... Jan

The real FMS were a bit laggy - but we got some CPU upgrades in late 90´s and that made it a bit faster. The problem is that in the real plane - the FMS runs on one system, the outside visuals and the airplane runs on another system (reality!!) - so even if the FMS is laggy, the visuals and aircraft will stay crispy . Or as someone once put it: Life is a stupid game, but the visuals rock! In X-Plane, everything runs on one computer, so if your FMS becomes laggy due to a too large database, chances are that the rest of the simulator comes down with it... Jan

Hi Richard, sorry to hear about your troubles! We had some reports where X-Plane key mapping went south - for example people reported that the B key will not only apply brakes, but also toggle the Beacon on and off... I think it is an X-Plane quirk, remapping usually helped. If you get a gizmo-soft-crash (window pops up), the code has failed. At that point we would love to get the gizmo_log.txt file and the IXEG_FMS_debug.txt files (available after next update to 1.0.6) from you, so we can find the reason and cure the crash. After that event, the code will not work right, anymore, and your best bet is to continue with conventional navigation (like you did). 1.0.6 is pretty imminent, and I would suggest waiting for that one before you go through the trouble of reporting any further code-crashes, that one should fix up quite a few of those again. We don´t have plans to add the older "paddle" type AP panel at this point - the current combo (new panel, steam gauges) is in use in real life, and the old panel with it´s constant clicking of the lockouts would drive people nuts . Cheers, Jan

It has been a while, but I think we limit the navigational database not with absolute mileage but with a certain "maximum allowable difference in latitude and longitude". Therefore the database will be bigger around the equator, smaller towards the poles. The reason we did this is performance. The database has to be accessed all the time, and having too many entries will slow down searches a lot. This does not only affect FMS entries, but we also need to check if a certain fix is on the map to display it... this quickly becomes a burden. The maximum fuel load is about 16.000 kgs. Under favourable conditions (light aicraft, good winds) this will let the plane fly about 3.300 NM (no reserves). A more realistic range, which the plane will be able to do with reliability is ca. 2200 NM (normal load, average winds, reserves). Most airlines have databases in the FMS that covers their area of operation - there can be quite a difference in memory available. I will add the request for a larger database, but we have to check how performance holds up for that... Jan

Ok! Jan

Yes, this is exactly like it works in the real plane. I am sorry, I didn´t build that plane . I guess it could be argued that it is more safe to continue the approach to the runway (with a single-channel autoland) than to maybe level off at a lower altitude that someone set by accident and fly over the runway and into a mountain on the other side... Anyway, I am sure the designers thought long and hard before making it that way - if you intend to fly a LOC approach or break off the ILS for a circling, don´t use APP, but instead use VOR/LOC and V/S. Jan

Hi - the little light will stay on after the next update... You should be able to engage autopilot modes, though - so I am not sure what is going on, there. I am sure you flew and mastered all the included tutorials on that subject? Let me know once that is completed, if you have any additional questions that are not covered in the tutorials. Cheers, Jan

Tchou is right - the only way to get out of APPROACH (VOR/LOC + GS) mode after GS is captured is to turn off both AP and FD... Jan

Aircraft updates (at least for now) should not affect this at all. At any rate, you COULD roll back to a previous "hotfix" if desired. Jan

Alright, let´s see... 1.) The autopilot will normally target V2+15 (actually up to V2+25, iirc). V2 is the speed that will be flown exactly if you have an engine failure, thats why it is being set with the orange cursor. V2 is Vstall x 1.2 - but it won´t allow more than 15 deg bank, thats why V2+15 is flown under normal conditions (bank up to 30 ok). 2.) You should be able to resume LNAV and VNAV navigation upon rejoining (or going direct to a point) of your old arrival. VNAV is still under improvement works - so keep an eye on how that performs and be ready to revert to V/S or FL CHG if it is unsatisfactory. 3.) The MCP hard barrier does not apply for the G/S pitch mode. 4.) The green circles are calculated taking diminishing performance with altitude into account (the plane is not climbing linearly). The "banana" is always "present ground speed vs present climbrate" - so it will be too optimistic during climbs, and too pessimistic during descents (since the groundspeed diminishes when lower). 5.) This should show distance to current active waypoint - but it is currently still missing and will be added in 1.1 6.) That is still being tuned - but the first descent after the T/D will be an idle-power gliding descent. The autothrottle retards the engines to idle, then goes to armed. The autopilot will keep the plane on the pre-planned path - ideally the slope is such, that the plane can "glide" at the precomputed speed without any engine thrust. If things don´t work out (too much headwind, etc.), the engine will spring back to life (FMC SPD) to boost speed back to the desired level. Then it will go dormant again... 7.) The E/D point is the last and lowest point in the route (usually the runway altitude + 50 feet) - the MCP ALT has nothing to do with the FMS´ path calculation - but will be heeded by the autopilot for level-off, if the pilot is not quick enough to "dial it out of the way". The three labels should actually be FPA (current flight path angle), VBA (vertical bearing to next altitude restriction) and V/S (required vertical speed to make the next restriction). This will be fixed and tuned in future updates. 1719.8 is the predicted time in Zulu time for CBY. Q1: The terrain display overpowers the wxr display - if both are on, terrain will be shown. Q2: There is a maximum wiper speed, but I don´t remember it right now. It is pretty high, though, so it is not a real limitation (since you will only use the wipers during approach, takeoff and taxiing. Q3: Engine out FMS mode is not modeled yet. Q4: Limitations say minimum 1000 feet agl, but you can already engage that at 400 as well. Hope this helps, Jan

Yes, I think its "engine one mixture up a bit" and so on... Jan

Hi Noslen, I read that far - and will answer you in detail when I have a second (or actually half an hour...) . Cheers, Jan

Glad everyone is making some progress with this - rest assured we will continue to investigate and work on this so special "workarounds" will not be necessary in the future... Cheers, Jan