Bernardo_Gui

i did it all, i have cleared the previous flp and reset everything i could. it seems to have worked and now i have ATS working back on track as before, except "DISENG'D" messages i have at crz

no more ATS for me, it used to work great for a few first flights; then never went back online again. it happened inflight during approach; then after i have landed and used the same airframe the next day, never could i engage the ATS again. when i press ATS it shows "FMC ERR" on the matrix. i don't get the "FAILED" message anymore at all. i did my last fly on full manual throttle, this time after landing i have cleared up all the flp / perf and fuel data from the FMS before leaving the aircraft and saving the airframe before tomorrow. if the ATS will not work on my next flight; then i don't know .. this is very frustrating and must be cleared out, someone please do a video tutorial explaining all the proper ATS conditions. thanks advance.

hello, i have just joined the club of TBM900 owners, can i have the discord please thanks

thanks for the update! i have just ran a quick test flight, i was mostly impressed seeing how accurately the weather radar was displaying the clouds that you see in front of your aicraft (with the xenviro addon) wonder if that was just me or an illusion anyone else with xenviro can confirm this? tia

dang.. i saw that coming in! Perhaps, you could share a sort of a 'how to' tutorial so we can attempt to do it by ourselves (at our own risk) ? if it is that easy to 'mod in' the mouse wheel manipulator by an user by altering the .obj cockpit file, then devs. please, just make that mouse wheel happen, officially, - end of the story and thanks in advance!

hi after a number of flights i have recently done (offline) testing extensively this b737 , here is a number of situations i have experienced the soft gizmo crashes that made the FMS inoperable, each of those crashes are very easy to reproduce if you follow to the descriptions: - when you fly past the last leg/wpt of any flight plan in Lnav (without filling in an arrival rwy and a star), the soft gizmo will crash and will turn your fms inoperable, it will be no longer possible to re program it and this will ruin your whole FMS managed flight that you would need to complete manually/MPC if you want to arrive at your destination , ( in this situation there must be an "--END OF ROUTE--" message on the FMS, with the ability to give you hand to reprogram your flight AND have again the Vnav tables accordingly to what you have entered etc) .. i can't believe such a crucial FMS feature hasn't been implemented since v1.0 .. -when you enter rwy 15 as arrival to VQPR airport, the fms/gizmo will crash (using June's 2016 airac) -it seems there is no ALT ROUTE feature implemented at all; i was flying from EDDF to UUDD, but decided to divert to EETN; since ALT ROUTE was not available as function, i tried to replace uudd with EETN as destination airport on the main route page; nothing much changed... in this situation, i tried then to clear the route legs by deleting manually the wpts from the current route table (EDDF>UUDD), starting from the end (supposed to be mandatory requirement) of the arrival RWY&STAr at UUDD, when i have pressed DELETE & EXEC it resulted as a gizmo crash and rendered the FMS inoperable at FL330 where i was somewhere over Berlin... since the FMS as it is now is tailored to make linear flights from airpoirt A to B, please, can you explain, how this FMS was tested before the release, and if it was, then WHAT should be the 'academic pre-formatted pilot's flight procedure' in order to fly from airport A to B without encountering any of these bugs?? because i absolutely see no redundancy and freedom of operation of this FMS now; please explain what happens in a real life situation when you are on the way from EDDF to UUDD and want suddenly divert to EETN? thanks i find these bugs really incapacitating regards B. * = unserviceable

thank you very much for clarifying this up, it reflects pretty much of what i have expected ... since this aircraft brings in more simulated features, with every new situation i discover and learn to more newer things than i used to have in other products, i believe i will need to revisit my descent management procedures and habits i used to have and this is what makes this aircraft amazing

right.. since i have updated to v1.07 and did a bit more of flights lately, the Vnav seemed to be a bit better, but still there is something that i find bizarre regarding the DESCENT speeds and generally the descent management. When the a/c starts descending in Vnav mode (after the MCP altitude has been reset), i find really curious the way how the speed is being maintained. Are the speeds that are displayed on each legs page ie "294 / FL180A" are being applied during descent or it is generally overridden by the speed that are set in the 'DES' page ? Should i always manually 'confirm' the sppeds by writting 294 / and press 'exec' button for each legs? Because when i have let the Vnav do the descent on its own, i have noticed that i have 'overshoot' several times (different flights/approaches) the intercept localizer fix/wpt (just before aligning on the rwy/final) and that even by applying speedbrakes, that is because i was either too fast and even sometimes too high so i could not properly align to the localizer neither acquire a suitable descent attitude in order to engage the approach/landing mode on the G/S, that resulted in either doing a lousy/awkward fully manual/visual landing or simply approach and landing abortion and then redo the approach again. When i tried to tamper by manually entering the speeds in DES page (while still being in Vnav), after pressing EXEC, i had an incoherent 'UNABLE ALT.. BLALA' message without much changing the speeds or sometimes even a Gizmo softcrash. I have noticed that it was impossible overriding the Vnav descent speeds of the FMC by simply pressing 'SPEED' button on the MCP and adjust the desired speed there while still continuing the descent with Vnav engaged (as i find it so handy and it is possible to do in the FF's 7xx's), is this procedure technically specific to the B737 Classic or.. a bug ? Also, another unacceptable bug that happened very recently (v1.07): when flying past the last WPT on a route (without a STAR and arrival rwy) instead of displaying 'END OF ROUTE' message, there was a Gizmo crash which resulted in a total loss of the FMC itself (Vnav & Lnav), as i was at FL280 i had to pursue the flight fully manually (on the MCP) .. seeing this on an aircraft like that was really gross. And another thing that i find really annoying, since everything in Xplane looks much better at dawn and night and thats when i prefer to fly, please INCREASE the taxi lights intensity! I'm still speaking as to what i used to have in other boeings by FF; in poorly lit airports or taxiways, on the current version of the B737 even by turning on all three landing lights, taxi lights and wing lights, you still just can't see crap in front of you! the way remains dark, thats really awful and not realistic, it is done much better in other boeings by FF, please check that out and do something about it. other than this, i'm enjoying flying this aircraft, i regret certain missing details such as mousewheel button manipulator and missing wing flex of the external 3d model (at touch down and bumpy rnwy/taxiing) - interior cabin & seats would be a cherry on the cake. hopefully everything will improve with time, thanks

Glad to hear these issues are 'bugs' and , hopefully those are temporary and strictly specific to the current version of this new aircraft (v1.05). Because i believe everything i have described, even being as not very standard procedural FMS flight plan programming, the results i have experienced and exposed regarding the Vnav calculations given by the FMS are definitely not following a certain logic. This makes me think that this FMS, as it was programmed and modeled, at this moment, is not freely 'redundant' but must obey to a certain 'procedural framework and envelope' flightplan and performance programming according to what you must carefully enter in it.

hi first of all, i thought i believed i was an avid boeing user, because in the past 3-4 years on xplane, the only aircrafts i used to fly (and still do) were the "other" boeings from that other very popular developer that is out there and i thought i have learned enough to be familiar with boeing style FMS, i always start my flights from cold and dark and i do fully program the FMS manually. after having purchased this new B737 from IXEG and flew it for a few weeks, i can admit that i was blown away with the level of quality and immersion but as well there are many other surprising things that i have never experienced before, those are mostly the way how Vnav and Vapp are interpreted by the FMS in this new aircraft, i don't know if i was doing something wrong or not respecting standard procedures, but here are a few questions: -in order to have the correct Vnav mode calculated by the FMS and then fly the flightplan with the Vnav mode engaged, why there is a need to fully program the flightplan by including the DEPARTURE and ARRIVAL runways (DEP/ARR with SID and STAR) page before activating and executing the route and even starting taxiing ? is it the way how it works irl or is it specific to the way how was modeled this FMS? I have observed that if the departure and arrival runways are not set before activating and executing the route that is fully programmed with correct LEGs etc (and proceeding further into the PERF/takeoff page), once inflight, when the A/P is engaged the Vnav becomes not available. Asking that because, in the other boeings, i always used to program, ACTIVATE & EXECUTE a flight plan/route without entering the dep/arr runways without sid and stars, and this before taxiing and taking off. Because i presumed that the active take off rwy is given by the atc once you are cleared to start up and allowed to taxi to that active rwy, and then only when u got that info , u enter the departure rwy & sid in the FMS and activate/exec it again to have the Vnav mode recalculated properly, but in this case, in this FMS it seems to me that it doesn't work that way. So my experience with the 737 FMS is different. Have i ve been misled flying FF's boeings and believed what i was doing on the FMS was right, need I learn again and change my whole FMS programming procedural habit? Can someone explain the correct FMS flight plan programming procedure then? The other question i have is after a small short flight form EHAM to LFPG i did lately, when i was approaching LFPG, i have decided to change the arrival rwy and star proceedure to another one (compared to the one i have set as different one previously before taking off) , after pressing activate and exec, as result (while being inflight) i got a totally erratic and irrelevant Vnav descent altitudes and approach speeds in the FMS, i have then decided to manually do the descent on the MCP instead of engaging the Vnav, also the Vapp speeds that were displayed were like 30deg flap / 577kts , the question is why is that? isnt the FMS supposed to recalculate the Vnav descent with the new rwy & star procedure i have just entered in the FMS? what i was doing wrong? FMS bizarre Vnav screenshot looking forward for further missing features to be added and other improvements into this amazing and promising aircraft. thanks

hi i tried to export to the IXEG 737 FMS a flight plan i have generated in EFASS using this plugin, but once i loaded it to the FMS, the route was not complete, many legs were missing ! the route was EGLL->LFPG

can't wait to have this, congratulations for the release and lots of thanks!

i hope some last minute change or something else won't instantly ruin our joy

i was just curious to read this forum thread and i'm surprised so many 'problems' are being reported. i run xplane in 4k resolution, i have managed to achieve a decently acceptable and properly balanced visual and performance configuration and except than some usual fps drops that occurs in some of those popular payware highly detailed airports, i can say the rest of the time i have never ever experienced any of those bizarre issues with SkyMaxx that are being exposed here, (i do use MaxxFxx too) not even in the latest beta 10.40b5... most of you should assume your hardware specs are simply inadequate to run this high system resources demanding plugin properly.

i just had xplane v10.30 crashed twice, after i uninstalled skymaxx v2.1 it no longer experienced any crashes after re flying the same routes (KSFO / KSAN) and (KSAN KLAX) every time xplane crashed it was during gathering weather data & clouds drawing ..... mostly during approach phases after about 90% of flight :-/ i have checked the log.txt and there was no crash in the log , it looked very similar to the one of Captain Jainer with some skymaxx activity at the very end of the log i was flying the FF b777 1.7 in xpl 10.30