Traffic limiter for UTL

[DylanM 1,069]

So it's been a while since I've switched over from MT6 to UTL - just wondering if anyone can suggest which traffic optimizer is more efficient / effective with this addon? The traffic limiter within FSUIPC, or the freeware air traffic manager tool?

And any combination of traffic limit settings you'd recommend for UTL + the limiter (I understand P3D needs to be set to 0 traffic with UTL).

Thanks much

 

[Guest]

UTL has a traffic limiter of its own so why not use that one?

[simbol 5,819]

41 minutes ago, J van E said:

UTL has a traffic limiter of its own so why not use that one?

+1

[vp49p3 216]

1 hour ago, J van E said:

UTL has a traffic limiter of its own so why not use that one?

It also has a framerate cutoff that's adjustable so that if your rate drops below what you've set, AI traffic is reduced to get the framerates back up.

[DylanM 1,069]

Thanks all. The reason I asked is the FSUIPC limiter has the following ini parameters to ensure local / airport traffic is preserved (which worked great with MT6); I'm finding it a bit harder to balance volume with performance with just the UTL settings...

The Traffic Limiter’s behavior is controlled by these settings in the FSUIPC4.INI file. There will be a new section, probably added at the end of the file, containing, by default:
[Traffic Limiter]
TrafficLimit=0
GroundPreference=50
PlannedAirportsPreference=50
AirportPreference=50
NearerPreference=50
TargetFrameRate=0

The limit set to 0 switches the facility off. The other parameters determine how to decide which ones to delete when
the limit is breached.

GroundPreference: This is the % probability of nearby (up to 20nm with slight bia to > 0.5nm) ground traffic being deleted provided
they do not already have clearance, or are shutting down after arrival. GroundPreference value determines the probability of excess
aircraft being deleted from any airports within FS's "reality bubble" EXCEPT your departure and arrival airports.

PlannedAirportsPreference: This allows you to set a separate % probability for deleting excess traffic at your planned airports
of Departure and Arrival. For this to operate fully you need to have a plan loaded in FSX/P3D.

AirportPreference: The gives the % probability of aircraft destined for one of the six nearest airports (including the one you may be on)
being deleted if it is a candidate (i.e. furthest, or as determined by the other parameters.

NearerPreference: This is the probability of deleting aircraft which are not necessarily the furthest away. With it set to
anything above 0 the aircraft chosen for deletion might be anything from 20nm away. The idea of this is to give newly added
aircraft in flight, spawned as usual at the far reaches of that “reality bubble”, a chance to follow their plans.

If they are all set to 0 (the original defaults in a pre-release) then the only criteria used when deciding which to
delete is the distance – furthest only, every time. 

TargetFrameRate: This facility, which defaults off (= 0) makes the limiter ignore the Traffic Limit value altogether,
so not deleting any traffic, when the frame rate is greater or equal to the value given here (excepting when this is 0
which turns this facility off).
 

 

 

[Lorby_SI 2,038]

45 minutes ago, DylanM said:

the FSUIPC limiter has the following ini parameters to ensure local / airport traffic is preserved (which worked great with MT6); I'm finding it a bit harder to balance volume with performance with just the UTL settings...

These limiters were programmed for and can only work correctly with BGL based traffic. UTL as an external process will simply ignore these other programs and continue to inject traffic according to its own rules. So you will end up with having two opposing processes fighting each other, which will probably be very bad for performance (AI aircraft generation and removal are rather expensive). It is a lot better to avoid generating too many AI in the first place (=using the sliders in UTL)

Best regards

[jabloomf1230 2,445]

The traffic activity sliders were a bad idea from the start as they only limit the total number of AI flights worldwide. In areas around large international airports, even a lowered activity level may allow generation of far too many AI aircraft within the user's reality bubble. It is better to also limit the maximum number of AI aircraft within the reality bubble.

BTW, traffic limiters can work properly with AI aircraft that are not BGL-based. VOXATC works fine with the FSUIPC traffic limiter. It's just UTL and its proprietary approach to AI that doesn't work. This really isn't an issue since UTL has its own built-in traffic limiter.

[DylanM 1,069]

Thanks very much Jay and Oliver - I think you're on to the root cause of my issue. Enabling the FSUIPC limiter with UTL may certainly have been the cause of the contention I was seeing...

[Pete Dowson 558]

On 11/18/2017 at 6:00 PM, Lorby_SI said:

These limiters were programmed for and can only work correctly with BGL based traffic. UTL as an external process will simply ignore these other programs and continue to inject traffic according to its own rules.

No way does FSUIPC have anything to do with Traffic BGLs.  It deletes AI traffic AFTER they've been injected. It works fine with UTLive, as it did with UT2. It uses the same mechanism as the "Traffic Zapper" control FSUIPC offers.

It doesn't necessarily delete traffic newly added, either. It uses the parameters you set plus a randomizer to select which ones need to be deleted. They may have been injected some time beforehand, and only just recently become eligible according to the parameters.

I see no performace issue with this which I would not already have got with MT6.  Yes, a balance is needed. You don't really want excessive processor time spent generating hundreds more aircraft than you want just for more time to be spent hunting them down and shooting them! ;-). However, UTLive's schedules seem to stop lots being generated at once.

I get better performance with UTLive than with MT6, but then there are less aircraft in any case. No military for example, and very few chartered types (if indeed there are any). I shall probably experiment with mixing them as I did with UT2 (though for that Burkhard provided a built-in configuration option).

Pete

 

[Lorby_SI 2,038]

1 hour ago, Pete Dowson said:

It deletes AI traffic AFTER they've been injected.

Thats good to know. I thought that you might catch them earlier.

On all my ESP simulator installs, creating and deleting AI always gives a little jolt for each single aircraft. If there are a lot of these actions happening, my sim stutters, for example when I am getting close to an airport when en route. So I want to prevent AI from being created right from the start.

Best regards

[Pete Dowson 558]

7 hours ago, Lorby_SI said:

On all my ESP simulator installs, creating and deleting AI always gives a little jolt for each single aircraft.

Strange. I've never noticed a "jolt" from either the creation or deletion. Are you still using ESP? I thought that was sort of frozen, incomplete.

Pete

 

[Lorby_SI 2,038]

6 hours ago, Pete Dowson said:

Strange. I've never noticed a "jolt" from either the creation or deletion. Are you still using ESP? I thought that was sort of frozen, incomplete.

Pete

 

ESP as in FSX, SE, P3D 1.x - 4.x. As we are all using it, saying "ESP" is a generalization on my part.

I have had these stutters on 6 different computers and 5 different simulators in all combinations of hardware and software, every time a simobject is loaded. The more complex the AI models get, the more noticable is the hold-up. When en route, leaving one AI "hotspot" and approaching the next, UT2 used to load a lot of AI at the same time, and that was always very noticeable. It is a little better with BGL based traffic, like MT6, so maybe it is the SimConnect object injection that is so expensive (or the MT6 models are more lightweight)..

Most of the time I just turn traffic off when I've had enough.

Edit: if you notice it or not will probably depend on the personal usage profile. Running other addons that depend on consistent frame rates will make it more obvious. In my case, EZDOK&TrackIR will make me notice every long frame, as do formation flight, network protocols or AI observation. 

YMMV of course.

Best regards

[Pete Dowson 558]

11 hours ago, Lorby_SI said:

Edit: if you notice it or not will probably depend on the personal usage profile. Running other addons that depend on consistent frame rates will make it more obvious. In my case, EZDOK&TrackIR will make me notice every long frame, as do formation flight, network protocols or AI observation. 

It might be more to do with the configuration on your flight sim PCs. I have all external EXE programs, like Active Sky, UT2, UTLive, and my own hardware drivers, running on different processor cores to those in heavy use by P3D.  Using P3D4.1 I am seeing very heavy use of cores 0 and 1, but less so on the other 8. (I don't use HT to avoid clashes). None of the external EXEs appear to have any noticeable affect on performance or smoothness.

I don't use EZDOK , nor trackIR on that PC, especially now that I'm using a curved screen with 210 degree FOV! ;-)

SLI also helps with smoothness on P3D4.1.

Pete