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

Community Reputation

4 Neutral

About fmop17

  • Rank
    Flight Student - Groundwork

Recent Profile Visitors

753 profile views
  1. For those who have updated their TropicalSim LPPD airport to the latest 2019 version, here is how to keep AES working with that version: 1. Look for the file AESA_LPPD_TPS.CFG file in the main Aerosoft/AES/AIRPORT folder. 2. Open it with Notepad and edit the 3 lines DEFAULT=..., SEARCH9=..., AND SEARCHX=... as follows: DEFAULT=TropicalSim\LPPD2019 SEARCH9=lppd2019_lib_fsx,lppd2019_placers SEARCHX=lppd2019_lib_fsx,CVX_lppd2019apt Save and close the file. You're done. Eventually, open AESHelp and resync/repair the database. Have fun... and safe landings at LPPD.
  2. To FrankF... and all other fellow flightsimmers: Below is the trick to make AES work with the latest LEBB 2018 by tropicalSim: 1) Open the "Airport" folder of the main "AES" folder located in your "FSX/Aerosoft" folder. 2) Look for the file AESA_LEBB_TPS.cfg 3) Open it (with wordpad) and edit the 3 lines DEFAULT=..., SEARCH=... and SEARCHX=... as follows: DEFAULT=TropicalSim\LEBB2018 SEARCH=lebb2018_jetwaystatic_fsx_placer SEARCHX=lebb2018_fsx_lib 4) Save the file and close the folder You're done.
  3. Hi there, At least on my system (FSX+Acc SP2 on Win 7/64), it looks like v1.13 does'nt fix the ground marking issue at the North (D) terminal - gates 60 to 89 - when the sim automatically switches to either spring or fall times depending on the date you start your flight: the gate numbering on the ground does match the gate numbering on the jetways in winter and summer, but does'nt in spring and fall times. Reading through the posts related to Oslo v2, I understand that back in June 2018 this issue was identified by the dev and a fix was in progress. V1.13 was released in July 2018. Was it supposed to fix that "seasonal" ground marking issue or do I (we) have to wait for the next update? In the meantime, by the way, and for those interested in always having the correct gate numbering on the ground whatever the season they are departing from or arriving to Oslo, the trick is to copy the file (summer ground marking at North D terminal) in the Oslo 2.0 texture folder, rename it to and, and copy/paste those into the Oslo 2.0 texture folder (backup the two original files prior to doing that replacement). Regards, Frank
  4. Hi again Oliver... if you're not dead (kidding). I, of course and sincerely, hope you're not. Well - and this is for you all AS people - with special mention to the management - and with all due respect - I've been working in a variety of (professional) business sectors - worldwide - for more than 30 years where (of course!) you just can't leave ANY request un-answered. Apparently, this simthings business is forgiving enough for you to just ignore your customers. Too bad for you, IMO, since you won't get any chance to become professionals, or at least reliable people.. MA Oslo v2 is an AS product. AES is an AS product. How can you leave it un-supported? and this without any formal notice/statement, that I (we) could accept? But this only is entertainment, right? So no worry; We all - or at least I - can leave with an unreliable service from an unreliable company and still enjoy flightsimming. Cheers guys. Enjoy your easy life with paying customers that don't call too much for a decent support.
  5. Hi Oliver, I've just updated MA Oslo 2.0 to v1.13 (FSX+Acc) and unfortunately the jetway numbers of the North Pier (gates 60 to 81) don't match the gate marking on the ground any longer (e.g. jwy 80 at gate 60, jwy 76 at gate 64, etc). Those jetway and gate numberings do match without AES but don't with AES activated. Apparently, the gate numbering at North Pier has changed in v1.13 and the related AES file for the gate animation (AES-ENGM20-LIB?) has'nt been updated accordingly. Would you therefore please look at this? Would be much appreciated. Many thanks in advance for your kind support. Regards
  6. Hi mtlt, I don't wanna be prying, but, There is no data for the VPTA RWY20 approach to LFKJ, as this is a VISUAL approach. Passed the IS NDB at 4,000 ft - which actually is the MDA for that approach - you have to switch off the AP and handfly the whole thing down to heading 203 at 870ft at 2 nm to THR 20, with NAV1 mode set to AC LOC (110.30) for distance reference and CRS set to 203 for the (very ) final alignment ref on RWY 20 (see VPTA plates for RWY 20). This should dramatically reduces chances for FMS, AP or whatsoever fatal error. My 2 cents, guys, Cheers,
  7. Oops! Here you are again. Thanks
  8. Here you are. Page 1, NavDataPro. Page 2, Navigraph. Please excuse the poor quality of the picts. More readable if you zoom in. Thanks, transition windows.pdf
  9. Dear support team, I've been using FSC and NavDataPro for many years and, as the latest FSC 10 (for FSX) came out with the Navigraph Airac 1801, I had a chance to compare both. I noticed that with NavDataPro most airports in FSC are showing only one transition where Navigraph - and the official IAC's - show all possible transitions to the short final. For example, Cagliari LIEE ILS32. Navigraph shows all available ILS32.W EPIDA, ILS32.X CAG1 (2,3,and 4), ILS32.Y CAL1 (and 2) and ILS32.Z CAR while NavDataPro only offer "ILS32 EPIDA". And this repeats at many (most) airports. Of course and fortunately, all those options are present in the NavDataPro FMS database for aircrafts. This limitations only affects FSC (on my system at least). Is there any reason for it? Would be great if we could have all available options when it comes to planning one's flight with FSC. I have to say that I'll keep using NavDataPro because its database packages match actual European airports data WAY better than Navigraph's do (i'm using official, up to date AIP's and charts from Eurocontrol). Thanks and regards, Frank
  10. Hi Michel, As all other NPA's (Non Precision Approaches), those RNAV21 and VORD21, approaches actually end at the Missed Approach Point (MAPT). Nantes LFRS has this special that SouthWest approaches show a 13 deg offset with the runway so as to avoid flying over the city center. You fly the short final heading 221 all the way down to the MAPTs. Passing 1,000 feet, you switch the AP off and flight your bird manually. At the MAP, you MUST have full visual of the runway (PAPI and approach lights) or you MUST abort landing (this actually is the definition of the MAP). Should you have that visual, then you gently turn left 13 deg until aligned on 208 and prepare for upcoming flare and touch down. To make the long story short, there is no "leg" per say between the MAP and the RWY THR. I have attached the complete and latest official airport information for you. Cheers, LFRS_AIP & Charts.pdf
  11. Thanks Mathijs. I appreciate it. Enjoy your week end. Frank
  12. Dear Mathijs, I totally agree with you, that is simply not true. And this basically is what I tried to clarify in the second post I've issued right after I went aware of it (see 5 posts behind). When I look at your reaction and at the hell of downvotes that I got for this post, there obviously is a misunderstanding. I did'nt want to offend anyone, nor to criticized anything. Should I looked so, though, please accept my apology. I'm very careful in maintaining my system and my sim in good condition. And they do work really stable and fine. What happened is, I stupidly installed the fix on top of a version which I mistakenly thought was the But it appeared this was not the right version. My mistake. I carefully uninstalled this "faulty" version, carefully installed the "true", then the fix on top of it and everything went back OK. This basically is what I recommended to chasndav to do in my second - supposedly corrective - post; he apparently did so and fixed that "non issue", too. As simple as this. Now for the words to Hans in the same post, this was supposed to be a straight, plain compliment. I am one of those guys who have had terrible LNAV issues with previous versions. Until that one, v1.0.5.0, which so far has been and is working fine on my system. Would I congratulate and thank again Hans for the determination in his work and the resistance to the strong pressure we have been quite a number to put on him? Yes Mathijs, I'll be much more careful next time and think twice before posting what happened to be a wrong and sweeping statement. My mistake. With best regards, Frank
  13. Andy, ckovoor, Confirmed. Works fine with my FSX+Acc platform, too (please, don't ask me why I got this issue before I posted chasndav (and possibly others), would I recommend you to check whether you actually have 1) the latest v1.0.5.0 installed 2) after a clean and complete uninstall of any previous version? Cheers, Frank
  14. Thanks Hans for the prompt response. And quite understood, loud and clear. The issue however is that we - FSX users - can't run this fix as we get a FATAL "Sound system error" (as MS Windows says) when it comes to loading the CRJ with the v1.0.6.0 fix. It appenrently calls for some sound files presumably located in the aerosoft\Digital Aviation CRJ\Sounds folder that just don't exist (e.g. TSS-Bumpx.wav (x=1 to 10), or AvioFan....wav, or...). Are we missing something? Are we doing anything wrong?... we just can't use this v1.0.6.0 fix. By the way, I'm still in my (long) testing process for this (brave and awaited) 1.0."whatever" update that should fix this damned LNAV issue. I still have a series of test flights to perform but so far, Hans, it looks pretty good. Thanks for your efforts under such a pressure. Should you give a look at this sound error issue with the hot fix (for FSX user, at leat presumably)... much appreciated. Tshüss, Frank
  15. Oops! It should read 'Hans" instead of "Herman". Don't know how "Hans Hartmann" could have turned into "Herman". Very sorry about that, Hans.
  • Create New...