Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Sabretooth78

  • Birthday July 7

Profile Information

  • Gender
  • Location
    Western New York

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
  • Virtual Airlines

Recent Profile Visitors

936 profile views
  1. Please lighten up. Your reaction is a bit much, as if I made a personal attack against you. It's an honest question directed to the developer. I'm sure there are many airlines worldwide where that would be a reasonable option to go along with the several other SOP-specific options that are already present in this and the other FS2Crew products. If the developer doesn't see reason to add it, then so be it. I can continue saying "no" at 10,000 feet without becoming indignant. It's their prerogative, not yours.
  2. Is there a possibility of making the FO's initial request of "would you like to release the cabin?" a configuration option? Possible choices being say "10000 feet", "at cruise", or "Off". My reasoning is that I typically fly SWA flights when I'm using the NGXu, and from my experience they don't turn off the seat belt signs until reaching cruise - so I'm always saying "no" when he asks around 10000 feet and then kind of feel bad for him when he replies with his rather sheepish "ok" lol. I do usually reply "yes" when he asks again within 1000 feet of cruise, unless I'm in turbulence or some other condition which would preclude turning the signs off.
  3. OK, so it sounds like my issue in both cases is because I didn't re-run the approach brief or checklist. Good to know - I'd rather it be because I'm doing something wrong than a bug! I made a summary "handbook" of sorts of the calls and flows and for some reason I put "cycle to <landing>" after running the After Takeoff Checklist, even though now I look and I don't even see that in the manual, so I don't know where I got that from. Yeah, I realize save files can be goofy, but sometimes it's necessary either to recover from a CTD, or in this particular case, practice a tricky approach without having to go through the whole process of getting the aircraft into the air. For the record, FS2Crew seems to perform pretty well off a save file; at least in the instances I've done so I haven't noticed any ill effect. The only issues I've had with such were I think with the NGX where the FO wouldn't respond audibly but would still seem to perform all the actions, so as long as you're familiar with the flows and timing you'll be OK.
  4. I've noticed a possible bug with the flap selection on the A320 after my last couple of flights - most recently with version 3.6. The FO will set flaps 1 and 2 when requested, but will not set flaps 3 or full when either: loading mid-flight from a save file (and then cycling forward to the appropriate flow) attempting a 2nd approach after a go-around (and cycling forward to the "landing" flow) Everything has always worked perfectly for the initial landing attempt. Also, the green bar shows that the system is "hearing" the commands. This only seems to happen on subsequent landing attempts. It's as if the FS2Crew system gets reset and recognition of those commands is dependent on some action that's not being performed because its flow is being skipped.
  5. I've seen this on my last few flights and I was going to report it. I suppose the sim must be reporting "snow" even though I didn't see any. That said, your explanation makes sense. That being said, is there a way to instruct the FO to retract them fully from 15? I commanded both "flaps up" and "flaps zero" and he ignored me so I did it myself. I'm assuming "that's the way it's supposed to be"?
  6. I know I saw it in the documentation for something I added recently. Can't recall which; thought it was a little ridiculous, but also didn't think the setting would hurt much either so I went with it. I know there are some airports that require 5 m, mostly due to taxiway bridges and such. Probably more of an appearance issue than functionality I would imagine. A relief in the sense that it's a known bug, a pain-in-the-xxx considering that it's something that can't really be fixed, even if on an individual basis. I've seen some occasionally (most recently some smallish ones just southwest of SLVR) but I'd have to defer to someone who is more of a "settings expert" to answer that. Having a basic knowledge of how it in other applications, I think it's possible that pushing that slider to the left might actually cause more of them, or at least cause those that do occur to perhaps be a little more prominent?
  7. Yes, as have I, although nothing like this yet. Turned it off and it still happens... As I was beginning to suspect from the ORBX thread, this was indeed the case. I actually had the mesh resolution set to 2 m! Changed it to 5 m - still happened. Changed it to 10 m - no longer happened. There was also a problem with FlyTampa KBOS in this regard I believe as well. I hit it once on a RWY 9 takeoff. Turned out there was a fix for it in their support forum. Creating a flatten to extend the airport polygon didn't help, either.
  8. I hear you! 😣 Unfortunately it's not that - all ORBX files (including AEC) were already disabled - and the airport otherwise "appears" normal at all times, unlike as is usually the case where those Vector AEC issues are quite apparent. (I tried turning the ORBX fix "on" and it quite visibly broke things - floating runway, etc.) I believe I may have found the culprit through a little research: https://orbxsystems.com/forum/topic/161013-from-the-inca-shores-to-rapa-nui-bonus/ It seems to be that the terrain mesh complexity can't be set higher than 10 meters or else you hit "invisible" terrain. What I experienced does seem consistent with a crash (with detection turned off) where the plane just bounces off in some completely improbable manner...and I usually set mesh complexity to 5 for the sake of some add-on airports that require it. I guess I should be happy that I hard landed and didn't instead get flung to 1000 feet up at 300 kts as is usual when you faceplant. I'm curious if creating a slightly longer airport polygon would correct this. I hate having to remember to change a sim setting just to use a particular item of scenery. I'll have to wait until later to confirm this - I'll report back.
  9. I ran into an issue landing at SCIP last night; wondering if anybody else has experienced this: On final approach (Captain Sim 757), all is fine and stable, until crossing the fence/runway threshold. Then, just as I'm preparing to flare and cut the throttles, the aircraft suddenly drops 50-100' onto the runway (well short of the TDZ) for a 600-700 fpm landing. Needless to say, quite a frustrating way to end a 5 hour flight! The initial attempt was made flying into Carlyle Sharpe's otherwise excellent "SCIP - Isla de Pascua & Mataveri Intl - Easter Island" scenery (https://library.avsim.net/download.php?DLID=185106) This is completely repeatable loading from a FSUIPC autosave file. It also seems to occur with the FSoftware Easter Island scenery. I did a little searching through my scenery folders and didn't find any obvious conflicts (particularly ORBX) nor was I able to pin down the culprit file(s). It was already well past when I should have been in bed, so my testing wasn't exhaustive (file isolation, different plane, etc.) but I intend to try to dig a bit more this afternoon. Using ORBX Vector and Pilot's FS Global 2010 mesh. It doesn't occur when attempting a landing at the default airport. Anybody else see/seen this and any suggested leads?
  10. I've noticed since the update that FS2Crew no longer automatically clicks the external power pushbutton at initiation of pre-flight, and that the automatic control of the doors no longer seems to be working (i.e. I have to close them manually through MCDU3). It seems as though something in the SDK might have changed, requiring an FS2Crew update? This was the update that added Connected Flight Deck. Thanks and please advise!
  11. I may be coming in too late, but there are a couple ways to fix the hill issue: Officially, email TropicalSim support and they will provide a fix (at least they did me). As for why it's not been officially disseminated; I can't say. Unofficially, while I was awaiting a response from TropicalSim support, I diagnosed the problem and interim fixed it myself - last post on this thread over at ORBX: https://orbxsystems.com/forum/topic/160332-tist-st-thomas-elevation-issue/?do=findComment&amp;comment=1412315
  12. On my past couple of flights (which have required wiper use), I've noticed an apparent bug with the "set wipers to ___" command - they seem to work OK, but the wiper setting knobs (on the overhead panel) seem to get pegged into the far right (clockwise) position, and no amount of left-clicking them turns them back counterclockwise towards off - only a fast scroll of the middle mouse wheel seems to free them. I don't recall noticing this before, so I'm suspecting there may have been some change in the 1.2.2.x update pushed out by Aerosoft?
  13. I encountered an issue today where the 3rd step climb of the flight somehow caused all the VNAV speed and altitude calculations on the LEGS page to go blank. During preflight I programmed the SimBrief steps into the LEGS and the FL330 and FL350 steps worked flawlessly. As for the FL370 step, it was programmed to TULAG but upon reaching TULAG the FMC was still recommending FL350. Finally, around YQD it was still recommending FL350 but with an OPT of FL367 and a MAX of FL375 so I judged it was pretty close to turning over (as it eventually did). I dialed FL370 into the MCP and selected FLCH and it wasn't until trying to reengage VNAV after pressing altitude intervention at FL370 that I realized something was amiss as VNAV would not activate. The ECON SPEED on the VNAV CRZ was flashing magenta and white. I made several attempts to fixing the issue by switching between RTE 1 and RTE 2 to no avail. Eventually I was able to regain the VNAV information by entering a lower FL on the VNAV CRZ page, at which point the VNAV information was still showing the FL370 data and recommending a climb to FL370. At this point the CDU was in VNAV cruise descent mode, which I could not bring it out of (until eventually descending to FL330). At this point I was just avoiding modifications in the event I ended up causing a CTD or something. Could there be a step that I'm not aware of that I missed here? I haven't flow the 777 a whole lot, but I never had this problem before! Flight plan: RKSI/33R N0488F310 SEL2A SEL Y697 LANAT Y51 SAMON Y513 KMC DCT DAIGO Y889 OATIS OTR3 PUTER/N0486F330 DCT PUGAL DCT PASRO A590 POETT/N0481F350 A590 HAMND DCT YESKA NCA13 TULAG NCA13 YQD/N0479F370 J596 YWG J89 OBK/N0479F380 J73 PXV/N0479F370 J73 BNA RMG5 KATL/08L A couple of pictures: In "CRZ DES", with speed intervention using the FL370 LEGS data: http://sabretooth78.east.freepgs.com/FSX/2018-12-14-01.jpg Upon pressing the MCP altitude intervention, the VNAV data disappears. Re-entering FL330 restores it: http://sabretooth78.east.freepgs.com/FSX/2018-12-14-02.jpg Is there a suitable way to exit CRZ DES (that I was evidently not able to find) or could this be a bug?
  14. I'm doing a series of flights in eastern Asia and using the "AS" voice set - when I call "Before Takeoff Checklist", the FO responds "Before Start Checklist". Everything proceeds properly, it just seems like perhaps the wrong audio for that response is being called.
  • Create New...