him225

Always found the in between empty flat building and tree terrain textures sore to the eye so with 5.3 HF2 performance improvement decided to try AUTOGEN_BATCH_LOD=1 and AUTOGEN_TREE_LOD=1 to bring back autogen to full FSX level, and the improvement was nice with full coverage, one step closer to MSFS realistic look with no odd empty patches. Also did POP_FREE_AUTOGEN=0 to gain some additional performance as it looks better trade off than the missing autogen here and there.

Reverted to 5.2 HF1 client but now autogen is not working at all, what did I miss?

Noticed the few times p3d session started stuttering happened when browsing in Edge for a while with p3d in background during cruise, interestingly found one of the Edge processes priority was Above Normal. May be the new UPGRADE_PROCESS_PRIORITY= entry is related and there for a reason but default is set to 0. The EFHK issue seems to be unrelated as it causes unusually high gpu load and fan noise even in 5.2.

Also getting very fluid 30 fps where it can attain >30, but just noticed getting strange 4-5 fps lower fps on airport in full screen, if I put p3d in background by say opening start menu or alt-enter p3d to windowed mode then fps increases and is able to hold at 30 as before. Dont know which version of 5.3 this started, already tried disabling full screen optimization and updating latest nv driver. Edit: Changing gpu power management to maximum performance fixed it, odd as this is the first time needed to change that from driver default.

Putting 0,1,2 also gave improvement here. Seems the other two working threads also need to be away from interference of terrain loading cores and rather be shares on single core as the terrain loaders are quite aggressive and fluctuating in their xpu demand. The default value 2 and 4 has them share one core each with the terrain jobs, but LM did not give entry to core distribitution of terrain jobs for complete control leaving users to achieve above indirectly that much reduces the optimum AM possibilities.

Unless fs2020 is able to surpass the depth of p3d in all areas rather than just scenery and looks eg game ish ground handling, camera, controls, ai, atc, weather, sdk for aircraft systems etc this is going to be a short term high from the casual gamers that will wear off of the sim after 2-3 years like any other game no matter what because there is not much game things to do in a sim, then the devs will be back to p3d. If not then long term simmers will be moving to fs2020 only for the better if it manages to pull it off. So no need to panic I guess.

I have non hdr monitor and after manually disabling hdr in cfg I notice dry colours and reduced intensity of surface illumination by dynamic lights which looked more noticeable with hdr on, is this correct level for no hdr mode or could p3d be overcompensating assuming the hdr to be always on?

The main thread is maxing out in 5.3 in scenario where previously it wouldn't so there is likely some performance reduction compared to older versions. As for the FSL if you have HT enabled better to not let it remove your p3d cpu affinity and instead use no ht equivalent AM in the cfg for appropriate performance result. The A32X is messing the p3d thread scheduler, for eg even if you put p3dcoreaffinity to 85 p3d will spread to all LPs with the aircraft, unnecessarily hurting performance.

Strange I see no difference from previous other than now the street lights also turn on/off at the wrong timing along with the sky. Did you also try comparing light level realtime at your location?

Thats a relief to hear cause I can make do without the new clouds but hard to step back from the new EA lighting. The inaccuracy of dawn dusk timing bothers me more, havent checked it yet but from the list of fixes looks like LM might have done the other way round by changing street light timing than correcting the sky transitioning timing.

Is that also with volumetric clouds off?

Very much looking forward to it as well. But afraid the A32X seem to disrupt the P3D threading system similar to when trying to change the affinity when the sim is running. So unless a no HT equivalent AM is used the FSL causes an unwarranted performance drop to the sim. If they are able to improve the thread handling method of their own processes in the next update hopefully will be able to performance benefit from this new facility in 5.3.

Thanks, that's good to hear. You'd expect them to address such issue by now, was beginning to thing if it was a glitch left somewhere on my install after the updates.

It used to coincide pretty closely with the real world in FSX and earlier versions of P3D, but perhaps since P3D5 the dawn/dusk are occurring like 30min late/early and transition bit quickly. The new included city street lights seem to turn on/off correctly for the outside light while the sim sky is full dark which indicates the underlying system is still running as before while something has broken in adding the new EA layer with both the EA on/off sky system. Is there any settings than can be tweaked to get the sky to match the real thing more closely again? In initial versions of P3D5 the sky used to begin transitioning correctly but weirdly reverse again to start over and finally make a delayed transition, which with the later updates got fixed but it appears has been left only with the delayed part and the correct point of transition missing.

Interestingly the monitor doesn't seem to be running even at the stock rates of 50 and 24hz either, giving the same frame sync issue which I have been trying to mention. I do run at 30hz but with the addon aircraft and airports that I fly the system is able to manage on an average fps in the mid 20s only so thought I would give 48hz a shot. In addition I wanted to avoid stuttering in the 24 fps movies as well as turn up some more eye candy in games by playing them at 48fps than 60 as I find it fluid enough than always running at 60 which it drops below sometimes.

Using the U2417h monitor which has native refresh rate of 60hz, I am trying to run it at 48hz by creating a custom resolution in the nvidia control panel. The other refresh rates available by default are 50 and 24. The monitor is able to run at rate down to 20hz as is also readable in its OSD status, however the issue is in neither of those refresh rates it produce smooth motion on the online UFO refresh rate motion test. The smooth motion only happens at like 30 and 60hz, other than those refresh rates it gives motion stutter problem as if the actual monitor is still running at 60hz. How does the custom refresh rate work, is it a software only thing or does this monitor not support any other refresh rate than 60hz?

They could have just enable mouse wheel zoom function only when mouse right button is pressed just like with view panning, which would have made more sense.

Watching the p3d cpu usage it seems there might be a problem with the method fsl uses to assign its processes to the cpu, as with the a32x loaded all cpu cores get used near equally in task manager which is similar to what happens when changing the p3d cpu affinity there while the sim is running that leads to the primary and other threads circulating on all selected cores. This makes the affinity mask useless, perhaps that is why it is recommended to have only either no AM or HT off equivalent AM with the aircraft. This becomes a problem with 4 core systems as former does not allow main p3d thread to have an entire core resulting in lower than possible average fps and the latter limits the cores available for terrain loading and other secondary tasks causing long frames. If fsl could fix this so that the p3d cpu thread assignment does not malfunction, which for instance FSUIPC already handles correctly, it would allow some performance benefit to quad core CPUs with the bus.

Did they fix the GMT time bug in the startup screen when using system time for default flight? As v5.2 seems to mix up local time with GMT time having to manually correct it, used to work fine up to the last version.

Given how p3d AI works, it might be preferable to have landing north and takeoff south since south runway has aprons on both sides whereas having this runway assigned for landing would lead to long waiting time for crossing AI or chances of runway collisions if you chose to override holding by removing the hold short nodes.

I agree getting off runway tarmac should be the best check for runway vacation for both arriving and departing AI, but sometimes AI making a U turn also trigger the same which would also need addressing. That criteria is true for smaller airports or in normal density operations yes, but at larger busier airports it is now not uncommon to have next takeoffs being cleared earlier or on lift off, at EGLL for instance. The option may be specifically enable for busy airports.

Not a good idea as it is highly variable how much time a landed AI will stroll on the runway before vacating depending on the model and taxiway layout, if this takes too long then the lined up AI will cause go around to an incoming landing due to just sitting and not leaving the runway before the landing AI comes near. The current method of triggering a fast rolling takeoff just after landing runway vacation along with the check for minimum distance of incoming landing is more reliable. Better way to make takeoffs clear faster instead and take better advantage of fast rolling takeoff feature would be to force next takeoff clearance as soon as preceding departure lifts off the runway, as currently the AI still wait lined up till preceding departure reaches a certain height causing a delay and greatly limiting the instances where benefit of the fast takeoff ability is possible.

Got to listen to taxiway instruction rap first on FS2020 ground FM radio.

Still miss the horizon sky color variation at dusk and dawn near and away from the sun, its all uniformly lit with EA. The dusk/dawn timing is still off, starts to get dark/brighten correctly then steps back again. Seems new cpu issue in latest version, the terrain loading cores always working now even when stationary causing occasional micro stutters, in previous versions used to be dormant when aircraft not moving.

The msfs vnav is simplified, it seems it just targets the STAR altitudes regardless of at or above/below suffix, that makes the atc instruct to descent abnormally and the vnav to dive or slow descent sometimes.