kriggelb

Does it mean we should point the FSLabs-team towards it or are they already aware of it?

OK, thanks a lot; I'll check that.

Do you mean the light bloom box within FSX-settings? That box is not ticked...

Hello Steve, I've been enjoying your dx10 fixer along with the new A320 and the cockpit shadows work just great! Thank you! Still I've got one question: In the shadow parts of the virtual cockpit I notice some white dots appearing from time to time within the respective area. It's no big deal - it's just as if the shadows were flashing at some tiny parts; the white dots seem to move around and then they disappear. As you can imagine it's hard to take a screenshot :wink: . These are my shadow-settings with the newest fixer version (3.0): - everything ticked except for "Enable Shadow Boost" and "Disable Volume Shadows" - Shadow Boost "0" - Contrast one notch to the right - HD All Aircraft - Shadow Bias 3.0 - Volume Shadow Bias + 3 I hope you can help me with that! Cheers, Chris

Hello Steve! Thank you so very much for your support: Your exclusion of the file mentioned above works great with v3.0! Greeting, Chris

Thanks a lot, Steve! As I know now that it's not a problem it doesn't bother me that much - still thanks for your effort! Kind regards, Chris

Ok, then here is another possibility - thanks for your hint, Steve: There is a file called effect.CFG within the Effects folder which clearly gets updated when starting the Flusifix tool. I checked it: There are no changes made - it is just an updated time behind the files name. So obviously nothing to worry about :wink: . This is the file's text: ; These particle spite limits are applied based ; on the "Special Effect Detail" settings slider. [sprite Limit] Medium=5000 High=9999999999 Low=1000 ; These particle emit rate modifiers are applied based ; on the "Special Effect Detail" settings slider. [Emit Rate] Medium=0.700000 High=1.000000 Low=0.300000 ; If an emitter has its LOD flag set and the viewpoint is ; further away than this at the time the effect is started ; then the emitter will be disabled. [Detail] Forced Distance=250 ; The [Emitter Detail Distance] and [Emitter Detail Modifier] ; tables work together. If an emitter is further away than a ; distance specified in the distance table then the rate it ; emits particles at is scaled by the factor specified in the ; modifier table. [Emitter Detail Distance] Medium=5000 Far=10000 Very Far=15000 [Emitter Detail Modifer] Medium=0.700000 Far=0.500000 Very Far=0.000000 Test=1

Hello Steve, thanks a lot for the answer! I guess I found the file which is triggering the message: Within the Flusifix folder there is a file called "FlusiFix06_de.ffl" and it seems to be an index file. The type name is called "indexcreation-index". Interestingly it is updated each time I open Flusifix - even without changing anything. Maybe that's the reason for the message. As I see it that's not a real problem, is it? Kind regards, Chris

Just a small update: The message seems to appear every time I open fsx.cfg via the Flusifix-tool. I don't need to change anything - it seems to be triggered by simply opening and scrollig in the Fluisfix-tool. As if the scenery fixer-interface interprets the reading of a file as actually changing the effects directory! Quite strange, isn't it?

Hello everybody, I noticed a strange issue lately: Without changing anything in FSX or other addons I get the message mentioned above - I'm referring to the message we certainly all know after changing scenery or aircrafts. For instance it happens when opening the FlyTampa Configurator (without changing anything - just to check the season settings, for example) and then using FlusiFix (a small tool to open fsx.cfg, for example) - also: without changing the fsx.cfg file (just checking settings). Is this something I should worry about? I find it rather strange - as if something was changing the effects directory without having changed something intentionally myself... I hope somebody can give me a hint! Kind regards, Chris

Ok, thanks Andrew!

Hello Dicko, thanks for sharing your experience regarding the older Navigraph cycle! It would be great if you told me how to roll back the navigation data. I use the Navigraph cycles. I haven't found a way to do that so far - is there an option in the Navigraph download manager? Thanks a lot in advance, Chris

Thanks for the clarification! Could you please tell me where to find the KLAX.txt - file in order to edit the missed approach procedures like going direct to CATLY?

I just wanted to post that I had the same problem today: flight from KJFK (22R) to KLAX (25L, RIIVR2 STAR) and I wasn't able to finish the flight. I also used 1503 cycle. I read that someone in the beta team was able to reproduce this issue. It would be great to know if PMDG is keeping an eye on this aspect for a future update... How can a FMC route cause a VAS leak? Or is this something Navigraph has to deal with? By the way my ATC route was: N0480F340 BETTE3 JFK J146 FJC/N0489F320 J146 JOT J18 MZV/N0485F340 J18 ALBRT J64 TBC J128 PGS RIIVR2 (planned with PFPX) Kind regards, Chris

Ok, this is just a little update referring to my last post (#35): The flight I was loading had been saved after updating the PMDG OC. As the VAS level changed rapidly during the flight I tried reinstalling ASN, but that didn't help at first. Then I just deleted the flight and started a new one (EHAM to KJFK), but this time I first updated the OC (last update from Sunday), reinstalled ASN and then started the whole flight. This time the VAS level was stable and I reached my TOD without issues! So there definitely seems to be a leak issue when updating the T7 or the OC without reinstalling ASN SP1B afterwards. Even a saved flight prior to reinstalling ASN kind of transfers this issue to a situation when ASN has already been reinstalled... So the issue is solved on my system, but it is not really a solution to constantly reinstall ASN after updating the T7 or the OC, is it? Kind regards, Chris

Hello everybody, actually I'm running into the VAS-leak issue, too. Without changing anything except for the PMDG OC update and some livery installation through the OC I'm experiencing a rapid increase of VAS during a flight on a NAT (EHAM to KJFK). Even uninstalling and reinstalling ASN didn't help. I would just like to know, if the issues mentioned in this topic have been resolved by the respective pilots and if yes: How did you do that??? Kind regards, Chris

Thanks for the answer, Richard. It'll be interesting to see how this whole "issue" goes on... In my case I solved the VAS-problems by saving my flights at TOD - as I use the pause function - exiting FSX and loading the flight again after restarting the program. It really is no big deal as it takes me around 3 minutes to get back into the VC and start the descent...

Hello stassone, yes, I also can't use virtual cdu with SP1"d", but I read an their website that the virtualavionics team is currently working on an updated version of VAInterface. I guess we just have to wait a little bit. Kind regards, Chris

Hello Slick9, I'm also following this topic very interested in the reports from other T7 pilots out there. The post by denthibbe got me confused quite a bit, because he's even mentioning liveries. I'd just like to ask if you're reinstalling ASN every time you install a new livery through the OC or if you were only talking about reinstalling after "real" T7 updates (like from version "SP1c" to "SP1d"). Kind regards, Chris

As promised here is my update: IT WORKED!! Entering the average wind data for the trip in the CRZ-field on the PERF INIT page during preflight seems to have solved the "issue"! The NGX now pauses again a few miles before the TOD. So I guess not preparing the FMC for the strong tailwind caused some kind of "system confusion". A perfect example for human factor-issues in aviation:-) It is quite easy using the ASN briefing feature: With a flightplan loaded into ASN you get the average wind direction and speed on the briefing page. I know I could do even better by entering data for every waypoint and even adding forecast information, but at least the pausing is there again. Of course, that itself is not realistic, but as a husband and father of three I have to integrate my hobby into daily life... It's so great to see a community willing to help - thanks a lot and merry Christmas to all of you! Kind regards, Chris

Hello, thanks for the answers! Actually I didn't forget to add the STAR in. There was a TOD for the flight and it was shown on the ND as the green "waypoint". And no, I'm not running ACARS. In fact, I just did the flight the way I've been using the NGX without issues for months now. So I keep thinking it must be the special weather with the strong tailwind on that day combined with not entering winds aloft in the FMC. I'm really missing the route data uplink feature just like in the big sister:-) I'll try to repeat the flight with historic weather in ASN, but with at least entering a wind value in the PERF page. I'll report back...

Hello everybody, I just wanted to come up with a strange issue I have never experienced before: Today I was flying from EHAM to EKCH with a flightplan created with PFPX. I've done this kind of flight a lot of times with the NGX, but today there was a really strong tailwind flying to Denmark (using ASN). Even though I've got the "pause at TOD"-feature enabled the sim didn't pause and the 737 simply overshot the TOD. It's the first time this happend and it is very confusing for me. The only thing I can think of is that with the strong tailwind (approximately 70 kts from behind) not entered into the FMC the NGX didn't pause even though there was a destination and a selected STAR. Does anybody have some kind of experience with this issue? As I said: it's the first time I have encountered this problem. "TOD" was definitely on the nav display, but the NGX just kept on flying... Any kind of hint would be greatly appreciated! Kind regards from Germany, Chris

Hello Steve, indeed I only have this problem with PMDG aircraft as far as I tested (FSX SP2; 737 NGX and 777 all updated): The only way to avoid eye movement dependancy of the shadow is to turn off the HD shadow option for me. Then shadows work great in the T7, although as posted before the shadow lines are a bit blurry (due to non-HD, of course), but they don't work at all in the NGX - even when choosing shadow version 5 or turning the zoom option off in the debug window... It´s a pitty, because when choosing the native 737 the HD shadows really look incredible - what an immersion improvement, Steve!! Still, who wants to fly the native model once you got used to PMDG standards, if you know what I mean... Maybe it´s one of those issues, your fixer isn`t intended to fix, so I don't want to demand something, I really don't have to - thanks a lot for all your work, Steve!

Hello CoolP, as you are saying that the 777 works fine on your system, could you share your settings for this aircraft, please? Within "shadow options" I only ticked "reduce fade in poor visibility" (ticked by default) and "Force VC Walls", "HD Shadows" and "EZDOK Compatibility". Furthermore "HD Airliners only" and "Shadow Bias 0.5" is selected. I use Shadow Version 6 (Debug window) and added the new DX10 line in the fsx.cfg referred to in the DX Scenery Fixer 2.5 manual. Of course, I didn't forget to tick the box "aircraft throws shadows on itself" within FSX:-) It would be great to know, which settings you do actually use in order to get HD shadows within the t7 VC without eye movement dependancy... Kind regards, Chris