Zitat

Version 4.254 includes these changes:

1. The first 10 readings in an FSX session from an FSUIPC4-assigned axis are now discarded, in case of spurious data. The covers around the first half-second or so only so will not be noticeable.

2. A facility is provided on the Miscellaneous options page to enable the Mouse Wheel as an elevator trim wheel.

3. Wind gust and variance effects are now emulated (when wind smoothing is enabled) using targets with a normal distribution of greater standard deviation, so allowing the METAR-stated extremes to actually be reached occasionally (which was very unlikely before).

4. The Visibility options are now removed by default. The entire options page is deleted. It can be brought back by setting "VisibilityOptions=Yes" in the INI file, but I don't think there is any point. Try as I might I cannot get those facilities to work reliably enough to be of much use. Maybe they'll just have to lie dormant till FSXI.

5. By default FSUIPC4 now does not write FSX METARs when no weather filtering options are set apart from those related to wind smoothing and its effects. This is to try to counter the problems reported of spurious zero visibility events.

However, I still need to understand how these are occurring, so there are two INI file options to bring the main two parts of the automatic METAR-writing actions back. These won't appear of their own accord in the INI, you would need to add them for testing:

RewriteSavedMetars=Yes: this makes FSUIPC4 rewrite the METARs for WX stations now dropping out of the surrounding matrix and therefore no longer a candidate for local weather filter actions.

FixBadMetars=Yes: This is the regular action FSUIPC4 was doing when it found FSX METARs with lots of spurious wind and temperature layers.

6. An additional facility for testing, to see if it eliminates the spurious zero visibility events, or has any side effects, is enabled by:

PatchVisibilityValues=Yes: this activates yet another "hack", this time into the WEATHER.DLL in FSX, to try to overwrite its internal visibility setting with the one predicted and desired according to the METARs. In my experiments it doesn't have any direct affect on the visuals on screen, but it might just possibly avert the zero visibility problem.

7. A third stab has been made at making the wind effects (turbulence, gusts and variance) more "realistic", and less likely at non-severe FS settings to upset aircraft such as the PMDG 747X. This is what is now done:

There are two INI file parameters, providing 6 values. These are the current (test) defaults:

TurbulenceRate=1.0,5.0
- The first number is a multiplier for the turbulence wind directional range
- The second is the muliplier for the turbulence wind speed range.

Previously both would have been the same, defaulting to 1.0. The range of both is 0.0 to 10.0.

TurbulenceDivisor=20,20,40,40
- The first number is the number of steps needed to change the turbulence wind direction from one extreme to the other (something most unlikely ever to actually happen, but this controls the speed of all changes).
- The second number is the same, but for the turbulence wind speed.
- The third number is the same, but for wind direction variability (variance).
- The fourth number is the same, but for wind gusts (the range from 'normal' to 'max gust').

The maximum range of wind direction and speed changes to be experienced in turbulent conditions is obtained by multiplying the relevant TurbulenceRate value by the FSX turbulence severity setting in FS (0-4), and, for wind speed only, by 2% of the intended ('normal') smoothed wind speed. So, for a 50 knot wind, moderate turbulence (2), the default Rate parameter of 5.0 gives +/- 10 knots for speed changes.

This value is the extreme range. FSUIPC4 then computes a random target using a Normal, or Gaussian, approximation, giving values clustering strongly close to the 'norm'. The increment computed from the maximum range and the relevant Divisor parameter is used, linearly at present (though a sinusoidal system is being considered) to move the current value towards the new value. When reached, a new target is computed, and so on.

Note that this is all done independently for wind direction, speed and vertical effects, and separately too for gusts and variance (which both have an imposed range, of course).

The increment rate is based on the frame rate for turbulence, but on an average of 5-10 Hz for gusts and variance.

Feedback needed, please, folks!

8. An error in the Toggle Traffic Density control added by FSUIPC has been corrected. It was previously not correctly keeping the GA and Shipping values in their proportion relative to the Airline traffic value.

9. The AI traffic TCAS information has been changed to provide assigned gate details. These replace the "key" field in the TCAS_DATA2 structure. In FS9 the key field gives the flight identifier, but it isn't available in FSX.

Details will be published in an update to the SDK in due course. Meanwhile, please ask Pete dowson if you need more information.