Framerates

[warbird861 0]

A 20% uplift in frame rates MUST be equated to a similar uplift in CPU processing, RAM access or GPU power demand, or even a reduction, if the fps limiter was somehow a bottleneck and removing it frees up the sim to be all that it can be. The fact that it isn't happening - no significant change at all in CPU, RAM or GPU demand - suggests that FSX is cutting back on one thing, in order to provide prettified pictures. The Szofran statement suggests that you can interrupt a Fiber. The FPS limiter interrupts the, for want of a better word, `prettified picture primary fiber`, and so allows other fibers to compete for CPU time. What those fibers DO may have little or nothing to do with visuals in the direct sense, but they will, individually and cumulatively, engage on some level with the FSX experience.

How do you know this? Is there some statement fron Phil or some other clear evidence from aces or microsoft or from other reliable source that it is so? If there is, why won't you just post a link to that and this hassle might just ease up. If there isn't, how do you know, your right?

[Snave 466]

How do you know this? Is there some statement fron Phil or some other clear evidence from aces or microsoft or from other reliable source that it is so? If there is, why won't you just post a link to that and this hassle might just ease up. If there isn't, how do you know, your right?

There is no reason for me to test this. I have already given my results, so my system will not be seeing any change, just as FSX sees no change. I am maxxed out in areas unrelated to fps. I suggest a testing protocol that would help isolate the effect of the fps limiter as its measured effect in FSX, seen from the frame counter, is not an effective tool for the job. It's no hassle for me to repeat this.

Long ago, and way before this topic came up, I did experiments with CPU, RAM and GPU to see how they were affected by various things in FS. These reports were made and peer-reviewed in a forum to which none here are invited. As hardware has moved on in general terms (if not specifically in my case) it's appropriate to return to the issue, but not if the results are judged by a yardstick that has limited relevance. And at this point there is no consensus even on that so, unless Mathijs has a specific reason for asking, the test and results are pretty much without meaning, except in the most general of terms.

[Cody Bergland 4]

No, there isn't anything to talk about. Here are the facts:

-Some people experience higher FPS with no confirmed effect to their simulator.

-There is as of yet no confirmation that there is any loss elsewhere in the simulator.

-For some people still, this does not necessarily work.

-Many in the industry have found this tweek to work and no official commentary regarding this tweak has been given.

-Many developers have developed with this set to unlimited. If this somehow negatively affected flight dynamics, etc as you suggested, then the designers have already accounted for this unknowingly in their work.

I think the issue is deeper. When FSX was first created, it was built upon the code of earlier versions (FS9, FS2000, etc). I can see it very possible that especially with SP2 released that this slider doesn't necessarily work as it was intended, especially with the new multithreading that FSX does with multiple cores. Considering the often turbulant nature of the ACES development team and the fact that they are working with legacy code (many of the team members that built the engine has since moved to other things) that the slider has some inherent flaws and that the original nature and law of the slider no longer applies to today's technology.

Anyways, I digress. If you choose not to accept my, or others results then so be it. I'm not going to argue with you about it. I just find it interesting you defend your view with a gut feeling without any evidence to support it.

[intrepid 2]

-Some people experience higher FPS with no confirmed effect to their simulator.

-There is as of yet no confirmation that there is any loss elsewhere in the simulator.

Snave ; I tried the so-called fix ,and though I found it hard to believe (sliders till now have always locked @22fps)

I have noticed slightly smoother game operation, I too believe no one gets something for nothing, but as Cody

states " that the slider has some inherent flaws and that the original nature and law of the slider no longer applies

to today's technology." I have to lean toward the perceived smoothness of unlimited frame rates ,as any perceived

level of smoothness is a welcome addition to my simming experience. I will be leaving the FPS at unlimited, might not

work as advertised but I never look a gift horse in the mouth

With all due respect gentlemen.

My 2 cents worth

Randy

[darem 106]

The trick for smoothness is that there is no single trick for it. There are a lot of screws you have to turn, and you have to turn them in relation to each other, just like you do when you collimate a telescope. And I have never seen a piece of software that reacts as individually to different hardware setups as FSX does. I had to completely relearn all tuning after changing from Dual to Quad, after going from 2GB to 4GB and after going from NVidia to ATI. s I wrote, having unlimited framerates with my NVidia was a nightmae of stuttering, having fixed framerates with the ATI was a nightmare as well...

[Snave 466]

The trick for smoothness is that there is no single trick for it. There are a lot of screws you have to turn, and you have to turn them in relation to each other, just like you do when you collimate a telescope. And I have never seen a piece of software that reacts as individually to different hardware setups as FSX does. I had to completely relearn all tuning after changing from Dual to Quad, after going from 2GB to 4GB and after going from NVidia to ATI. s I wrote, having unlimited framerates with my NVidia was a nightmae of stuttering, having fixed framerates with the ATI was a nightmare as well...

And that is the closest thing to Absolute Truth we have yet seen in this topic! The goalposts are not the only thing being moved. The players on the pitch are moving, and as far as FSX is concerned, the Stadium seems to be in a permanent state of motion as well! Even changing drivers can affect which tips work, which don't - and even which ones used to work now don't!

There is no problem with the fps limiter precisely because of this. If it were the case then similar, repeatable results would be seen on most, if not all computers, and the absence of results on those computers which experienced that would show common factors. The mere fact that the results vary is indicative - but not proof positive - that other factors are intervening. No-one seems in the slightest bit interested in looking at this subject in the correct manner, with the correct testing methodology, and therefore the amateurs can continue to play with the sliders without the slightest inkling of what is actually happening, but revelling in the apparent success of it. So long as they're happy, I'm happy. There's nothing worse than a truculent child throwing its dummy out the pram to spoil your stroll in the park.

[ManuelL 71]

I tried with VFR Germany - as I always have problems with blurries when I am using photoscenery with autogen.

FPS limiter; actual FPS; appearance

unlimited; 19-40 (average 30); significant FPS fluctuations, stuttering, blurries (same after doing the scenery library thingy)

35 ; 19-33; no stuttering but blurry textures after a while

30 ; 14-23; still blurries after a while

25; 17-24; still blurries, but not so bad as with FPS limiter set to 30

20; 20 with occasional dips to 17; still slight blurries after a while (similar to the 25 setting)

For me the FPS counter seemed to works with respect to smaller FPS fluctuation and less stuttering. However, I could not see a very significant effect in decreasing blurries in the photoscenery.

(To get rid of the blurries I have to reduce the autogen).

[Snave 466]

Mathematics is wonderful thing: The average frame rate slider is no such wonder. The fps counter is an average - not spot - measurement based on time `x`. So is not suitable for this kind of measurement. If you lower the peak, achievable fps, but retain the lowest attained fps then PATENTLY OBVIOUSLY the average observed fps will fall... Basic math.

There is simply no valid testing protocol in place here, and therefore any results are simply meaningless, except to the individual.

For a start, you should be using the more advanced fps counter. Only those who know how to exchange the default measuring for that should even participate in the discussion. Everyone can test it, it might be a magic pill for your rig, but don't bother reporting it. The reason for this is well-known and established.

Next, not a single post here has mentioned the water slider. http://blogs.msdn.com/ptaylor/archive/2007...-fps-costs.aspx indicates the impact of the position of that slider, and again, without mentioning where you have the slider, your reports are meaningless.

Next, others are using FRAPS, rather than the fps counter in FSX. Again, your results are meaningless unless you can prove that FRAPS measures the same thing, over the same time frame as the default slider (clue: it doesn't, FRAPS uses a different averaging technique).

Next, all baselines are different. Unless you use a default FSX setup, with the same settings on the sliders, any reports are meaningless, except to the individual.

So in one respect at least, Cody is right.

No, there isn't anything to talk about. Here are the facts:

The facts are; here are only iterated personal experiences. Valid for the individual, as after all, it is the individual that ultimately uses, or doesn't use, the unlimited setting to their fancy, but not facts that have any relevance to anyone else. So there is nothing to talk about except to say: "It works for me" or: "It doesn't work for me". After that, without the science and the correct methodology the rest is bunk and should not be used as a basis for suggestions of useless tweaks within the sim. There are better things to do with developer or tweaking time.

The display of distant objects is affected by the availability of the Fiber to complete its cycle. That's a fact. Now figure out how that marries with the statements that the sim offers a smoother experience at higher sustained framerates and it will become obvious that the slider is doing what it can, within the limits of the individuals system.

I am glad that people are happy jiggling the fps slider. I am sure ACES are happy too. That is why that slider - and all the others - are there. Now jiggle some of the others, and enjoy your FS experience better still

[nidr 0]

now this is rare but seams to work for me, can't understand it. i had my frames locked on 20 tested it on ebbl (kleine brogel, belgium), getting a smooth 20 frames with sometimes a drop to 17, getting that with almost every aircraft.

now have the frames set to unlimited and frames are skyrocking, all depending on what view you take, spot, tail, flyby, etc... getting frames from a average 50 frames and most of the times skyrocking to 70 and 80 frames.

what i also seeing is what's already said here, is that if you lock the frames it's like your pc don't get the chance to show everything on your screen, with my frames on unlimited i have more detailed three's and there are more of them.

although i have some hard settings like anti aliasing, etc...

regards

nick

[Para 0]

Go to a location when you got about 20 fps (not so important actually) remember the average fps.

Now click World | Scenery Library and directly [OK] without doing anything on this screen. On some machines we see a much higher (up to double) framerate, on others we see hardly difference and one some we see a drop in fps. If you got a moment try it out and let us know.

I tried so, but there has not been any change at all in the framerate.

Put the F-16 next to Maho Beach in St. Maarten.

System-specs are Intel Q6600, nvidia 8800 GTX, Vista 32 bit.

[assiprinz 1]

WOW!

I just can say it worked for me.

I tried it at Ken Jernstedt Airfield/Hood River (4S2).

• I had my frames locked to 25, giving me an average of 23.
• I removed the lock - gave me around 35 average, but with stutters in turns.
• I then did the 'open scenery library' thing. This gave me around 70 FPS !!!111einseins
• Then I locked down to 30, and it stayed at the top end of that (average of 29.9)

This works! But why does it work? It isn't supposed to! This sim made me angry for about a year, and all I had to do is open the scenery library and close it? Argh!

System: Core2 Duo@2,6Ghz, Radeon HD 2900 XT, 4 Gigs RAM, 1680x1050x32, Vista, without Dx10 preview.

Please, Mathijs, follow this topic, and once there's enough data collected, please forward that to the Developers over at Aces! Start a poll! Do something about that. Is there a topic on this in the German Forums?

Thank you. This is is strange.

regards,

Jan

[Burkhard 23]

Just saw this topic now and have a little to add.

It is well known that the fps counter goes up on systems if you put the framerate delimiter to unlimited. It is also known that this is more the case on systems which are CPU limited, which is the case at large airports for most systems.

What isn't so well known, but when you do support you get reported enough times, is that this gain is not a bug, and is not free. By setting the delimiter to unlimited, you give the grafics subsystem absolute priority over all the other processes in FSX. You do not see what happens in the first few minutes, and maybe you never notice. Other subsystems, which sometimes cannot be offloaded to other cores, get less ticks, and will go into timeouts.

As example the algorithm that calculates which parkings are used for which AI aircraft. It has been observed often enough that this makes wrong decisions with "unlimited", while working perfect with a meaningful delimiter - with unlimited the looping over all aircraft and parkings runs into timeouts and the first best is used.

Another example is ATC. If the ATC process does not get enough CPU ticks, ATC calls get delayed. Since the queue of ATC commands that can be hold is limited, it happens more often that ATC calls get off the stack and forgotten. You then see AI aircraft standing at a crossing of taxiways, even when they are free, long queues piling up behind them, until the aircraft gets blown away eventually.

My conclusion is that with unlimted you cannot expect FSX logic to run properly. If you don't mind that, be happy, but don't complain about the above.

[Snave 466]

And yet people claim to not `see` any difference. Strange eh?

I think this is but one single example, but then one simple single example was all that was needed... You ARE, categorically, reducing your FS experience with the fps limiter at unlimited with current hardware. If you are not seeing it, this indicates either a different limitation within either the hardware or the observer. Nothing more.

But then, as I've said all along, if it works for you, great. There are lots of strange tips that seem counter-intuitive until you try them and find they work. But given the cacophony of unqualified comment that flies about every time someone makes such a suggestion, I think it better to let people find out for themselves. That, after all, is what the sliders in FS are for - personal experimentation.

[assiprinz 1]

What you are saying is absolutely true. But:

I think that was not the topic. What we experience is a very strange phenomenon. please see the first post from Mathijs.

The question was not, how people should treat their sim, but why we experience strange things. Doubled framerates by opening and closing the scenery library that is. The topic is: Where exactly are flaws in the program code, that make things like that happen. There has to be an issue in the program itself, and if we stuck to the topic of this post and try to determine the reasons, we could perhaps reveal somehow (the guys at aerosoft are much deeper into the technical stuff) errors made by the programmers. It doesn't have to be the case, but there could be a certain chance. And in the long run, this could result in an advantage for everyone.

So let us not bother around about people treating their frames limiter wrong, but find out about the strange behaviour of the sim itself. Please. I am really curious about that, because I was angry with the software for about a year now, and I found out all I gotta do is open the scenery library.

regards

Jan

[Aerosoft Team [Inactive Account] 51558]

Just tried it with the new (and stunning) Madeira and with got interesting results:

- reboot system, start FSX, load Funchal, locked fps at 30 fps -> I get 25 fps average

- reboot system, start FSX, load Funchal, locked fps at 30 fps, open scenery manager, click [ok] -> I get 30 fps

- reboot system, start FSX, load Funchal, unlocked fps -> 36 fps

- reboot system, start FSX, load Funchal, unlocked fps, open scenery manager, click [ok] -> I get 42 fps

So with the same scenery settings I go from 25 fps to 42 fps without any negative effect. The weird thing is that the CPU has exactly the same average load during these test (100%, 100%, 100%, 82% on the 4 cores) so obviously things are handled more efficiently with these tweaks. We still are not sure what is causing this effect, I only know it works like this on my main system.

[Snave 466]

I would look in the direction of the cache function of FSX. It's anticipatory algorithm can get `confused` when faced with several simultaneous demands.

However, there may be another way to achieve the same effect - change the mesh density by a single percent.

You can also set the sim to cache scenery elements. Not normal for most users, as there can't be many who didn't do a full install at the initial installation, but if you alter the addon sceneries to `cache this scenery` instead of `use this scenery directly`, you may also see some strange results, performance-wise. Indeed, if you have very large amounts of RAM - >4gb - then this may be the ONLY way to get FSX to use it.

[Aerosoft Team [Inactive Account] 51558]

I would look in the direction of the cache function of FSX. It's anticipatory algorithm can get `confused` when faced with several simultaneous demands.

However, there may be another way to achieve the same effect - change the mesh density by a single percent.

You can also set the sim to cache scenery elements. Not normal for most users, as there can't be many who didn't do a full install at the initial installation, but if you alter the addon sceneries to `cache this scenery` instead of `use this scenery directly`, you may also see some strange results, performance-wise. Indeed, if you have very large amounts of RAM - >4gb - then this may be the ONLY way to get FSX to use it.

Ok, expand on that. I have never heard or read any reasonable explanation of the caching system (including explanations from MS people btw) and I have only seen negative results when it was tried. I do agree that caching of something is a likely cause of the effect/problem.

Did try you tip with the mesh but that does not work here, really needs a rebuild of the scenery database to work, not a reload as a change in a setting would give. Changing the mesh setting did not bring any FPS improvement.

[JamesChams 108]

Just tried it with the new (and stunning) Madeira and with got interesting results:

- reboot system, start FSX, load Funchal, locked fps at 30 fps -> I get 25 fps average

- reboot system, start FSX, load Funchal, locked fps at 30 fps, open scenery manager, click [ok] -> I get 30 fps

- reboot system, start FSX, load Funchal, unlocked fps -> 36 fps

- reboot system, start FSX, load Funchal, unlocked fps, open scenery manager, click [ok] -> I get 42 fps

So with the same scenery settings I go from 25 fps to 42 fps without any negative effect. The weird thing is that the CPU has exactly the same average load during these test (100%, 100%, 100%, 82% on the 4 cores) so obviously things are handled more efficiently with these tweaks. We still are not sure what is causing this effect, I only know it works like this on my main system.

Mr. Mathijs Kok,

Is this a recommended proceedure for using all addon sceneries? I will be installing many of yours shortly and want to know what I can do to ensure optimal peak performance for each of them. As you might already know, I've been purchasing a lot of addons and am starting to notice a decline in my systems FPS and overall performance despite DEFRAGing and a few other house-cleaning conventions. I will try your/Mr. Burkhard's suggestion(s) above and see what happens. As always, Thank you.

[darem 106]

As you might already know, I've been purchasing a lot of addons and am starting to notice a decline in my systems FPS and overall performance despite DEFRAGing and a few other house-cleaning conventions.

I find this pretty strange. My list of entries in the scenery list is 250+, and I haven't noticed a decline in FPS so far. I checked framerates in a region that isn't affected by any addons (except from landclass) after a fresh install, and it's about the same now (of course, with weather set to cloudless, because using something like FEX SHD indeed DOES change framerates a little *g*).

[Cody Bergland 4]

With more addons I haven't noticed a degredation of performace (with the exception of VERY DENSE scenery). Overall, it is the same. The only thing I have noticed is longer loading times.

[Aerosoft Team [Inactive Account] 51558]

Mr. Mathijs Kok,

Is this a recommended proceedure for using all addon sceneries? I will be installing many of yours shortly and want to know what I can do to ensure optimal peak performance for each of them. As you might already know, I've been purchasing a lot of addons and am starting to notice a decline in my systems FPS and overall performance despite DEFRAGing and a few other house-cleaning conventions. I will try your/Mr. Burkhard's suggestion(s) above and see what happens. As always, Thank you.

Recommended? I wouldn't know but sure give it a try. I can only say it seems to solve some bugs in FSX for me as I get seriously better FPS.

[Aerosoft Team [Inactive Account] 51558]

I find this pretty strange. My list of entries in the scenery list is 250+, and I haven't noticed a decline in FPS so far. I checked framerates in a region that isn't affected by any addons (except from landclass) after a fresh install, and it's about the same now (of course, with weather set to cloudless, because using something like FEX SHD indeed DOES change framerates a little *g*).

Well, any addon will take some memory even if not actually loaded in your screen. Every new scenery you add takes a bit of memory in the scenery database but it seems hard to see how this could have a serious (or even noticeable) effect.

[Snave 466]

Ok, expand on that. I have never heard or read any reasonable explanation of the caching system (including explanations from MS people btw) and I have only seen negative results when it was tried. I do agree that caching of something is a likely cause of the effect/problem.

Did try you tip with the mesh but that does not work here, really needs a rebuild of the scenery database to work, not a reload as a change in a setting would give. Changing the mesh setting did not bring any FPS improvement.

OK, here's what I think is happening: FSX tries to reduce hard drive loading times by `forward planning` - it anticipates what it thinks will be coming next AND what is likely to become visible onscreen: Not one, but two anticipatory algorithms. When they work well together, you don't notice.

You can see this differentiation taking place on some systems by holding a fixed POV in a VC on a default model, flying low, then panning left or right: Instead of already having the autogen in view, you will see it being batch-loaded and displayed. This is not the same way the autogen normally batch-loads when, instead of zoning the display in a lateral manner (Left/Centre/Right) it zones it to a distance equation (Near/Middle/Far) which is the accepted explanation of how autogen knows when to display per Phil Taylors explanation of a previous tweak in FSX .cfg

SmallPartRejectRadius=<pixels>

Basically this culls out small model parts (e.g. air conditioners on roofs of buildings, aircraft doors) if their radius would occupy less than the specified number of screen pixels.

The default is 1.0 (i.e. 1 pixel). 2, and 4 are the next 2 settings we advise. Can significantly improve performance but may cause “popping” of small objects

So something is bypassing or superceding the SmallPartRejectRadius algorithm which is inherent to the display .exe

You also see this when you first load an exterior model. The first time you display the exterior - NO MATTER HOW LONG THE SIM HAS BEEN RUNNING WITH THE AIRCRAFT LOADED - there is an appreciable delay before the textures display. Thereafter most of the time the display of the textures is near-instantaneous, proving that the cache only loads the exterior model when it is necessary, but is slow to release it as it assumes it will be `necessary` again, soon. It's being held somewhere in memory... and consuming resources. LOTS of resources if you've got a great big fat polygon-heavy model - like the Bush Hawk. If your system is holding 100 meg of textures to display on 37 meg of mdl, that is a whole heap of resources to lose to other things...

I posit that the scenery cache is, at the same time and independently, doing something(s) similar. When they work in unison, the various caches improve general smoothness and overall performance (I specifically do not say `FPS`). When they work out-of-phase, you get a series of `double-accounting` cached calculations. When both subsume the general seek-load-display of the display model, that's when you get the glitches in fps. Basically, too much is being held in cache, and not enough of what is there is being used. You've `choked` the system. Every system is different, every FSX installation is different, scenery display and complexity will be different - even the weather is different - so there can be no simple remedial step to solve the problem, because first you need to identify that it IS a problem, and not simply a summary effect of overloading. For that reason the solutino is in the hands of the individual. There will be no modifying the cache algorithms in FSX, they're embedded too deep and ACES have moved on to `FS Next`.

Likewise there is no simple way to clear both caches at the same time, but there is the option to `refesh scenery` in the FSX menu system.

Unassigned by default.

Assign a key or combo and you will then be able to achieve the same approach you adopt by forcing the `cache-scenery` to reload, without leaving the main screen.

The reason for the mesh change is that is the only way of forcing the `cache-display` to reset.

However, one further option might be the aircraft cache itself - witnessed by the speed of re-display mentioned above. FSX also provides a unassigned-by-default `aircraft reload` key which may, like the `refresh scenery` be freely assigned to a key combo.

It is possible that one, two or all three caches may be a simple bottleneck, and that in your case the scenery refresh was the key to regaining fps. Ther eis simply no way to state for sure that everyone else will solve the problem the same way, as their problem may in fact be different. However, there may also be a way to reassign the priorities of the various caches, as addon scenery held in cache may assume a HIGHER priority and greater consistency of loading time, due to its requirement to display consistently when loaded at startup of the sim but then held permanently in cache until needed.

Juggling the pack may put an ace on top.

[Aerosoft Team [Inactive Account] 51558]

OK, here's what I think is happening: FSX tries to reduce hard drive loading times by `forward planning` - it anticipates what it thinks will be coming next AND what is likely to become visible onscreen: Not one, but two anticipatory algorithms. When they work well together, you don't notice.

You can see this differentiation taking place on some systems by holding a fixed POV in a VC on a default model, flying low, then panning left or right: Instead of already having the autogen in view, you will see it being batch-loaded and displayed. This is not the same way the autogen normally batch-loads when, instead of zoning the display in a lateral manner (Left/Centre/Right) it zones it to a distance equation (Near/Middle/Far) which is the accepted explanation of how autogen knows when to display per Phil Taylors explanation of a previous tweak in FSX .cfg

So something is bypassing or superceding the SmallPartRejectRadius algorithm which is inherent to the display .exe

You also see this when you first load an exterior model. The first time you display the exterior - NO MATTER HOW LONG THE SIM HAS BEEN RUNNING WITH THE AIRCRAFT LOADED - there is an appreciable delay before the textures display. Thereafter most of the time the display of the textures is near-instantaneous, proving that the cache only loads the exterior model when it is necessary, but is slow to release it as it assumes it will be `necessary` again, soon. It's being held somewhere in memory... and consuming resources. LOTS of resources if you've got a great big fat polygon-heavy model - like the Bush Hawk. If your system is holding 100 meg of textures to display on 37 meg of mdl, that is a whole heap of resources to lose to other things...

I posit that the scenery cache is, at the same time and independently, doing something(s) similar. When they work in unison, the various caches improve general smoothness and overall performance (I specifically do not say `FPS`). When they work out-of-phase, you get a series of `double-accounting` cached calculations. When both subsume the general seek-load-display of the display model, that's when you get the glitches in fps. Basically, too much is being held in cache, and not enough of what is there is being used. You've `choked` the system. Every system is different, every FSX installation is different, scenery display and complexity will be different - even the weather is different - so there can be no simple remedial step to solve the problem, because first you need to identify that it IS a problem, and not simply a summary effect of overloading. For that reason the solutino is in the hands of the individual. There will be no modifying the cache algorithms in FSX, they're embedded too deep and ACES have moved on to `FS Next`.

Likewise there is no simple way to clear both caches at the same time, but there is the option to `refesh scenery` in the FSX menu system.

Unassigned by default.

Assign a key or combo and you will then be able to achieve the same approach you adopt by forcing the `cache-scenery` to reload, without leaving the main screen.

The reason for the mesh change is that is the only way of forcing the `cache-display` to reset.

However, one further option might be the aircraft cache itself - witnessed by the speed of re-display mentioned above. FSX also provides a unassigned-by-default `aircraft reload` key which may, like the `refresh scenery` be freely assigned to a key combo.

It is possible that one, two or all three caches may be a simple bottleneck, and that in your case the scenery refresh was the key to regaining fps. Ther eis simply no way to state for sure that everyone else will solve the problem the same way, as their problem may in fact be different. However, there may also be a way to reassign the priorities of the various caches, as addon scenery held in cache may assume a HIGHER priority and greater consistency of loading time, due to its requirement to display consistently when loaded at startup of the sim but then held permanently in cache until needed.

Juggling the pack may put an ace on top.

Interesting reading. I have the scenery refresh / aircaft refresh assigned to a key by default and press it at least 50 times a day, but it still does not do the same as opening the scenery menu and clicking [ok]. Besides the SDK explains why this does not really help with all things, if I am correct the ESP SDK explains it a bit better. We are meeting with MS next week and we'll ask if they can shine some light on it.

[Snave 466]

It would certainly help to establish once and for all where the caching is coming from and whether it is a simplistic `wholistic` approach or whether in fact there are independent cache functions under different circumstances. I hope it is the former, for I fear if it is the latter there is no `fixing` it as it becomes an individual machine problem, rather than a generic problem in need of a generic solution. I have no doubt that the cache scenery function is separate, but how it fits into the big picture I really can only conjecture.

All I can say in my experience that utilising the scenery menu tweak does absolutely nothing for me. However, setting the scenery cache does have scenery displaying quicker on first load, perhaps because the ordering algorithm is based on anticipated use, not file/folder name which is the order the scenery files should be deposited on the hard drive if a defragmentation utility has been used. But I have no doubt that on faster machines, or machines with greater bandwidth the scenery cache will probably do little.

I still think the `blame` for all this is the outdated rendering engine, and these are just symptoms of the deeper problem of trying to hang on to a game engine past its sell-by date. And that will require a new sim to fix. And Direct3D11 and Windows 7.