Recently we have seen a lot of codes used to unlock our products being offered for discounted prices. Almost all of them are bought using stolen credit cards. These codes will all be blocked by our systems and you will have to try to get your money back from the seller, we are unable to assist in these matters. Do be very careful when you see a deal that is almost too good to be true, it probably is too good to be true.

Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Sabretooth78

  1. I know. My question relates to the fact that when it is set to negative (whether correctly or incorrectly), the 00s and 20s disappear. This doesn't occur for positive 00s and 20s.
  2. Just a little "problem" I discovered while setting the altimeter before my last flight - A321IAE on the latest version When at negative altitudes, the minor "00" and "20" seem to disappear when you cycle past them. I'm not sure this is much of a practical concern as I'm sure there are very few usable airfields at these elevations, but I'm noting it nonetheless. Note the altitude readout as the QNH knob is turned: (Edit: I'm not sure why the pictures saved different sizes...)
  3. I actually just noticed something like this last night as well. I had set a DIR to waypoint WIKIR on approach to KFLL/28L and activated LOC while still 4-5 miles from interception (from roughly DEKAL, so about 20-30 degree intercept and roughly on g/s) and the a/c immediately started banking to the left. I quickly turned LOC off and pulled the knob for heading select, then reactivated managed NAV. Then a little closer to intercept, I reactivated LOC, the a/c quickly and slightly banked left but restabilized on the NAV course until getting closer where it did intercept the LOC normally.
  4. I did actually just do a video driver reinstall, and with DDU to chase another issue, so I'll pay more attention next time! If it ultimately requires a reinstall of the Airbus I'll just wait until there's a bigger update requiring a reinstall... It typically only goes 5-digits during the takeoff - certainly not in any other phase.
  5. On my current flight, I just experienced something very similar to this, but on the A320 IAE (not the A321). Again, the GW, fuel burn, and P3D "Fuel and Payload" dialog all seem to be showing the correct numbers; it's just the ECAM and MCDU3 that seem to think the a/c is "refueling itself". This is the first time I've seen this on the A320 IAE, which I use fairly often. There is one thing I did slightly differently during this flight which may or may not be the cause? Typically I fuel up the a/c by selecting "Load Instant" or "Load Fuel" (depending on how I feel like doing it on a particular flight) on the MCDU3 Load and Fuel display. This time, I initiated fueling through the GSX menu and never touched any of the load buttons on MCDU3 (i.e. LSK 1R-4R). Also interesting, after I noticed this happening (about a half hour into the flight), I disabled the GSX integration in the MCDU3 "Gnd Services" page and shortly thereafter the FOB numbers seemed to begin decaying as expected. We all seem to be aware there are still some nagging issues with the GSX integration, perhaps this is one of those? An example; note the time and the discrepancy between fuel burn and FOB:
  6. I've run 2 flights so far with that file (though different routes) and haven't seen the problem recur. I'll update if and when it happens again.
  7. Just a minor problem here: during takeoff and initial climb (i.e. times of high fuel flows) the ECAM displays don't properly show values with 5 digits. I see this with both IAE and CFM models: IAE: CFM:
  8. I still see this "magenta" rollback during climb at or near crossover altitude/speed on almost (if not) every flight (commanding something like 166 kts) but the a/c still follows the correct speed (usually 280-300 kts) and the problem goes away either at TOC or by just playing with the altitude knob (push or pull). Haven't seen it occur at cruise in some time.
  9. Upon further review what I'm seeing here doesn't seem to be a result of my modifications but rather the same issue as this:
  10. Somehow I didn't catch this topic - although I think I've encountered it as well. My initial thought was that it was something I had done, namely modifying the aircraft.cfg and MCDU2c.xml to increase the capacity of the center fuel tank.
  11. OK, I officially don't know what's happening - I turned off the GSX integration and rolled back the modifications to vanilla, loaded a fuel amount well less than the default capacity (say 40.00 klbs), and still seeing the increasing FOB once the transfers from the center tank begin shortly after takeoff. Situation: Load state ready for takeoff at KSFO, Rwy 28L at 1850z+/- 10Jul2019, TRUKN2 departure, ORRCA transition. I get this behavior before hitting ORRCA every time with the A321 IAE - although technically speaking I can also just sit there with nothing programmed and parking brakes on while running up the engines to TOGA and it'll still happen once the wing tanks get low enough, about 13250 lbs. If I use a smaller total fuel quantity (say 35.00 klbs), the FOB doesn't increase but its rate of decrease seems to lag behind the increase in the F.USED. Only seems to be happening to the A321 IAE. Did something break with the update, because I don't remember this happening prior?
  12. More of a notice to others regarding the increased fuel capacity "fix" myself and others have promoted (link below) as I realize it's unsupported. I'm currently running a flight which I believe to be the first I've run where I've filled the aircraft up into the "additional" capacity range (i.e. above 19150 kg total or 2180 gal/14600 lb in the center tank). KSFO-KBOS, with a block of 45900 lb or 20820 kg (GSX actually loaded it to 45940 lb). I noticed during climb out that my fuel wasn't declining as quickly as it should be, whereas my total F.USED was showing the expected amount. Turns out that something is causing the total FOB to increase during periods where the ECAM showed that transfers were occurring. Note that despite this, the following all show correct numbers: The P3D "fuel and payload" dialog F.USED on the CRUISE, ENGINE (though incorrectly in KGS) and FUEL ECAM displays GW in the lower right of the lower ECAM FOB on the MCDU FUEL PRED page Current burn on the flight is also within a few % of where SimBrief says it should be (I track weighted average fuel usage so my perf factors are generally quite good; I use 1.03 for the A321IAE.) Not shown, the fuel panel mode selector is also displaying a fault. I don't believe I've noticed this before. Playing around with that and the center fuel pumps manually doesn't really seem to be causing much of a different behavior, even after getting the center tank to display below 14600 lb and back into the "supported" realm (without going manual it doesn't seem to dip below that value); the value shown in the FUEL ECAM does continue to decline (along with the wing tanks) despite the pumps being turned off. As time goes by without transfers, the gross sum of the reported tank volumes and engine burn does seem to slowly be decaying (currently it's still at a total above the original loading, and for that matter, actual capacity, but I'm not sure the flight will be long enough to catch up if it indeed actually will). I guess the first question is has anybody else who has applied this "fix" encountered this same issue? I've yet to see feedback saying so, but perhaps they, as I did, applied it without ever actually utilizing it. I looked through some of the XML files to see if there was something that stood out but didn't find any smoking guns. Does it make sense that this could happen, and if so, would it be possible to re-code a file somewhere to allow capacities above the standard 2180 gal to just come out of the center tank as those from 1 to 2180, "realism" be damned? (Even if not officially released or sanctioned but rather as a your mileage may vary; I'm not going to open a support request if I knowingly break something! I also keep backups!) I'll try it again sometime without "GSX Services" enabled just to confirm (I used that to load fuel and I have been having some weird results with that regarding PAX loading as well, and just want to rule it out). It happened fairly quickly into the climb out so it shouldn't be a lengthy trial to attempt to replicate it. In the meantime I'm continuing with my flight and just calling it a faulty center tank sensor and if I have a double flame-out over Chicago or have to land a little hot in Boston because the plane thinks its heavier than it is, so be it lol.
  13. Odd issue with the GSX2 integration that I have noticed on a couple of flights. Before takeoff, MCDU3 showed that the aircraft (A321 IAE) was loaded with the correct 176 PAX, although the GW in the lower ECAM was a little lower than it should have been. After taking off, I decided to look at MCDU3 and sure enough, it was now reporting just 174 PAX loaded (cargo was OK). I've noticed this happening in other flights where the last PAX or 2 claims to be loaded but does not show up in the GW calculation, though this is the first time I've actually checked the tally mid-flight. I guess I'll just chalk it up to 2 no-shows! In the past I've typically just used "Load Instant" which has worked without fail.
  14. Yes, green and yellow flashing. Version; Navigraph current AIRAC (1907 I believe). I don't recall the RNP exactly (I did look at it) but I think it was either 0.03 or 0.30. I'll be running another flight today so I'll see if this crops up again.
  15. At some point during each of two flights last night, the green/yellow flashing despite the aircraft apparently following the LNAV course and with an acceptable RNP. First flight: KLGB/12 F330 ZOOMM2 MISEN CLARR3 KLAS/19L <- first noticed sometime after MISEN Second flight: KLAS/26R F300 BOACH8 WHIGG DCT FEYLA DSNEE4 KLGB/12 <- first noticed before BOACH, did not persist through the entire flight. Oddly, both instances seemed to occur in roughly the same geographic area. I'd had that indication pop up in the past, but very infrequently and it would usually seem to go away faster.
  16. I noticed a similar issue last night, but on a turn-around. Everything loaded normally (incorrectly for the cruise as it always does for me, but it did at least populate something) for the initial flight but on the return leg the winds would not populate even after manually updating the plan in ActiveSky, etc.
  17. I think I've posted this before, but I can't seem to find where (and whether it was acknowledged). When in managed climb, the MCDU PERF CLB page gives some quite nonsensical results data for the managed climb predictions: "Expedite" seems to more or less make sense but the "Managed" makes absolutely no sense at all: 3 hours to climb 5500 feet at 800 fpm? The target distance number was fluctuating wildly as well, anything between 500-800 miles only to final settle down once getting closer to the target altitude. A321 IAE,
  18. Just to document another instance (as I said it happens consistently). This time with the A321 IAE; Attached is the activeflightplanwx file and my AS settings if that helps. Everything posted was captured while paused, during preflight so it should all be consistent with the wx picture at that moment. Flight plan: KJFK DCT COATE Q436 RAAKK Q440 SLLAP DCT GRB DCT KINGZ DCT FAR DCT DIK DCT MLP GLASR1 KSEA Note GRB: Note based on the activeflightplanwx file, the entry 160@7(12) leading off the GRB line. If you include that as 6k altitude (when it should in fact be surface?), then it might seem as though the Bus is reading an incorrectly delimited file, or the Bus doesn't skip an entry it should be skipping. It's over my head regardless, so curious to see what you hear back from Hifi. activeflightplanwx.txtCMS_PTA_EF.CFG
  19. I'll check for that file next flight, which will be tomorrow evening - I was previously looking at the activeflightplanwx.txt as mentioned above. Are you sure the "EDDNEDDH.wx" file would be in the PMDG folder? That seems a little odd for instance if you didn't have any PMDG installed.
  20. This now happens for me constantly, whether or not I have a PLN flight plan loaded, after the latest ActiveSky update, etc. I've been inclined to ignore it since there doesn't seem to be a will to address it - and the conditions being one FL off are generally still fairly close and as such for sure more accurate for FMGS calculations than having no wind input at all. Still, I would like to hear some official input from Aerosoft on the matter. It may well be an ActiveSky issue, but it's also in Aerosoft's interest if their product is directly intending to pull data from a buggy feature.
  21. Starting with the update, I've been noticing a "silent" and immediate CTD when loading a saved flight. It happens after I've already loaded normally using the Airbus (and with no problems) but then go to open a saved flight, which in all cases I've tried was saved using the same plane. Upon "OKing" the load scenario dialog, P3D4 will instantly bomb out to the desktop without a trace. For background, I've typically tried this (and in the past it has worked) after landing where sometimes I like to revert back to an FSUIPC autosave of the just-completed flight to practice/reattempt the landing, especially in an interesting weather scenario. It's not a big deal as it doesn't affect any real functionality and I can always just reload the sim and open the save file, but an occasional inconvenience nonetheless.
  22. Here's a copy of my most recent ActiveSky activeflightplanwx.txt, captured during preflight, which I'm assuming is the source of the FMGS wind upload. Please correct me if I'm mistaken. Flight Plan: KBZN/30 N0432F370 BOBKT4 BOY DCT OPPEE TSHNR3 KDEN/16L **** DepartureMETAR=KBZN 150156Z 35012KT 10SM OVC055 06/M03 A2965 RMK AO2 SLP045 T00611033 DestinationMETAR=KDEN 150153Z 31011KT 10SM FEW100 BKN200 14/M04 A2973 RMK AO2 SLP034 T01441039 AlternateMETAR= AverageWinds=291@65 AverageHeadwind=-57.2 AverageTemperature=-45.2 CruiseAltitude=37000 CruiseSpeed=300 KBZN 350@12(6) 267@14(7) 268@19(3) 251@28(-10) 265@45(-22) 269@58(-32) 268@84(-46) 273@102(-55) 277@87(-58) 278@47(-56) 264@27(-54) 283@8(-54) BOBKT 290@14(7) 267@14(7) 271@21(3) 250@33(-10) 270@46(-22) 271@58(-32) 271@85(-46) 275@102(-55) 279@83(-58) 281@44(-55) 269@29(-54) 278@8(-54) ZORKE 290@14(7) 267@14(7) 271@21(3) 250@33(-10) 270@46(-22) 271@58(-32) 271@85(-46) 275@102(-55) 279@83(-58) 281@44(-55) 269@29(-54) 278@8(-54) TOOLS 251@14(13) 251@14(7) 255@18(3) 247@29(-9) 269@49(-21) 271@62(-31) 273@85(-45) 279@101(-54) 281@87(-59) 280@45(-56) 266@31(-55) 275@7(-55) TOC 249@11(13) 249@12(7) 253@13(3) 249@28(-8) 271@49(-21) 272@64(-31) 276@86(-45) 282@101(-54) 284@87(-59) 280@44(-57) 266@33(-56) 269@7(-55) BOY 250@8(10) 250@8(10) 273@4(6) 262@27(-7) 273@47(-19) 277@59(-29) 280@78(-44) 288@93(-54) 291@86(-61) 284@50(-57) 264@33(-57) 251@8(-55) OPPEE 240@15(6) 240@15(6) 273@24(9) 273@40(-6) 280@47(-19) 290@55(-29) 299@76(-45) 306@89(-54) 304@71(-60) 285@44(-58) 271@39(-58) 242@13(-56) HNMAN 240@15(6) 240@15(6) 273@24(9) 273@40(-6) 280@47(-19) 290@55(-29) 299@76(-45) 306@89(-54) 304@71(-60) 285@44(-58) 271@39(-58) 242@13(-56) SOYAR 240@15(6) 240@15(6) 273@24(9) 273@40(-6) 280@47(-19) 290@55(-29) 299@76(-45) 306@89(-54) 304@71(-60) 285@44(-58) 271@39(-58) 242@13(-56) TOD 240@15(6) 240@15(6) 273@24(9) 273@40(-6) 280@47(-19) 290@55(-29) 299@76(-45) 306@89(-54) 304@71(-60) 285@44(-58) 271@39(-58) 242@13(-56) MOLTN 270@16(19) 271@16(13) 272@17(10) 268@34(-5) 282@49(-19) 290@59(-29) 301@75(-45) 310@86(-54) 307@65(-59) 285@43(-59) 273@38(-59) 239@14(-57) WOOKY 272@15(19) 272@15(13) 274@17(10) 268@33(-5) 283@48(-19) 290@59(-29) 302@75(-45) 311@85(-54) 307@64(-59) 285@44(-59) 273@38(-59) 238@14(-57) KDEN 310@11(14) 310@11(14) 304@15(13) 284@25(-3) 288@44(-19) 292@56(-29) 306@74(-46) 313@83(-55) 304@66(-59) 287@47(-57) 272@33(-60) 236@15(-57) **** Is it just me, or are the cruise waypoints (BOY through SOYAR and TOD) showing duplicate first entries? An "extra" first entry might explain why what the Bus expects to be the 18000 entry is actually in the 24000 position? Or am I completely off base?
  23. It was accepting them, and treating them just the same as the waypoint I did try (SITRE) but I had limited success with the navaids selection list killing my entry. It seems in either event it's not working properly, but at least now I know that and have a way around it. I'm curious now to try a PB/PB waypoint and see how that works. I got rather single-minded last night just trying to figure out where the PBD was getting its P from. (The waypoint I was trying to add would be indeterminate from a PB/PB standpoint being as they'd be colinear.)
  24. Following up on a previous topic; lately I seem to be having a lot of trouble with this again: It seems regardless the state of the "default" flight plan, I'm seeing this. There was one instance where, prior to descent, I repeatedly requested and updated the descent forecast and exactly one time it actually gave me the correct match of wind speed/direction and altitude. Am I still the only one experiencing this, or is there perhaps an Active Sky setting which may be causing this? I've tried toggling the MCDU3 options away from and back to "Sim (Default)" (or whatever the exact syntax is; I'm away from my sim PC) but to no avail.
  • Create New...