"- Administrator privileges removed"

I think worth mentioning.

If the app that communicates with the sim is not also at the same privilege level the value cannot be changed by the app. Starting FFTFd in admin and then starting the sim without admin would result in no changes to the value taking place.

If FFTFd is started for example from exe.xml it automatically runs at the matching privilege of the sim and the value will be changed reliably.

If the sim is started with admin privileges, and FFTFd is started from the desktop make sure also to set it to Run as.

 

Go to

"C:\ProgramData\Lockheed Martin\Prepar3D v4"

open exe.xml and add a section like this:

 

 <Launch.Addon>
  <Name>FFTF Dynamic P3Dv4</Name>
  <Disabled>False</Disabled>
  <Path>C:\Program Files\FSPS LTD\FFTF Dynamic P3Dv4\FFTF Dynamic P3Dv4.exe</Path>
  <CommandLine></CommandLine>
 </Launch.Addon>

Path must reflect your system.

I've been testing the app. Works nicely, in fact it's pretty sweet.

Does this App let you change the FFTF manually on the fly? In other words, can I pause the sim, use it to change the FFTF value, then unpause the sim and continue to fly? My understanding is that to change the FFTF value in the Prepare3d.cfg you have to restart the sim. I realize it changes the value automatically as you fly, but I would like to do it first manually to determine the settings I want to use.

Thanks,

Ted

Hi Ted,

There is no FFTF entry in Prepar3D.cfg unless you have added it yourself. The value assumed by Prepar3D is 0.33 and this will remain the case throughout a flight irrespective of altitude.

FFTF Dynamic allows this value to be adjusted automatically based on your preferred settings within the App. Therefore no requirement for that manual entry in the cfg. Since this happens on the fly while the sim is running during initial testing, I expect to be able to pause at any time and make adjustments to my preferred settings within the App to suit the prevailing circumstances until I achieve a good compromise. The App offers 2 Modes of operation and it’s up to you to discover which delivers the best results on your setup.

Regards,

Mike

 

5 hours ago, SteveW said:

Go to

"C:\ProgramData\Lockheed Martin\Prepar3D v4"

open exe.xml and add a section like this:

 

 

 <Launch.Addon>
  <Name>FFTF Dynamic P3Dv4</Name>
  <Disabled>False</Disabled>
  <Path>C:\Program Files\FSPS LTD\FFTF Dynamic P3Dv4\FFTF Dynamic P3Dv4.exe</Path>
  <CommandLine></CommandLine>
 </Launch.Addon>

 

Path must reflect your system.

Hi,

I will force the installer to add the above lines inside exe.xml and control the false and true flag from inside application in order to have the ability to start or not the application when p3d starts.

 

I have also some requests to add ground speed as an extra scenario. What community think?

 

Regards,

Achilles

Edited April 12, 20188 yr by Achilles Philippopoulos

11 minutes ago, Achilles Philippopoulos said:

Hi,

I will force the installer to add the above lines inside exe.xml and control the false and true flag from inside application in order to have the ability to start or not the application when p3d starts.

 

I would not like to have this mandatory. I prefer to start FFTF Dynamic (and some other tools) using SimStarter instead.

Making the exe.xml entry as an option, that would be okay.

Kind regards, Michael

42 minutes ago, Achilles Philippopoulos said:

Hi,

I will force the installer to add the above lines inside exe.xml and control the false and true flag from inside application in order to have the ability to start or not the application when p3d starts.

 

I have also some requests to add ground speed as an extra scenario. What community think?

 

Regards,

Achilles

 

Can I chip in there to explain the reason why I made this request and hopefully gain support: it's given that the terrain engine has to load a certain number of scenery tiles per frame and that this number depends upon ground speed, i.e. while stationary there would be zero tiles/frame needed whereas high ground speed needs more tiles/frame as we are covering more ground. We know that FTFF controls the proportion of CPU time given to the terrain engine so surely when travelling fast we should raise FTFF so that this increased number of tiles can be loaded by the engine in the longer time it is now being allocated.

Of course using altitude also results in this increase but by a second order effect as generally when altitude increases then we also increase ground speed...however what if I'm in a fast-jet at 700 feet travelling at 700 knots? Using the AGL Height Scenario your app may be starving the terrain engine of CPU cycles as FTFF will still be set at a low value...

...that's my 2c anyways.

After a certain altitude and speed you can't do anything with ever higher FFTF, it's saturated. You have to be able to rob Peter to pay Paul.

Hi Boez,

I think we have to accept that there are limits as to what can be achieved by using this App. If you are seeing problems now while speeding at low altitude over the landscape then raising the FFTF value higher than 0.33 will run the risk of inducing major stuttering....probably.

Regards,

Mike

Honestly , I think that the program is now good as it should be.

 

Edited April 12, 20188 yr by GSalden

9 minutes ago, Cruachan said:

....probably.

Heh. That's a get out clause I often use Mike!

E&OE

55 minutes ago, SteveW said:

After a certain altitude and speed you can't do anything with ever higher FFTF, it's saturated. You have to be able to rob Peter to pay Paul.

I'm not suggesting both at same time but an alternative scenario...you choose either on height or speed.

1 hour ago, Cruachan said:

Hi Boez,

I think we have to accept that there are limits as to what can be achieved by using this App. If you are seeing problems now while speeding at low altitude over the landscape then raising the FFTF value higher than 0.33 will run the risk of inducing major stuttering....probably.

Regards,

Mike

Where in my post did I say I was seeing any problems? I'm well aware that this app is just balancing the load between CPU cycles being expended on terrain loading and other CPU tasks such as physics, avionics systems, etc.

My argument is that the same number of terrain tiles/frame need loading for a given ground speed whether you are at 700 ft or 35000 ft so why base FTFF on altitude? Surely it makes more sense to base it on speed (as an alternative option)?

 

Edited April 12, 20188 yr by boez

5 minutes ago, boez said:

I'm not suggesting both at same time but an alternative scenario...you choose either on height or speed.

Going faster means you will need a lower FFTF to keep the framerate as high as possible and avoid stutters. Flying faster means a lower framerate.

However , you will need more loading time as you are flying faster , to avoid blurries.

You probably end up with a higher FFTF value and use less 3D objects.