diff --git a/Aircraft/Generic/Logos/pumpkin.png b/Aircraft/Generic/Logos/pumpkin.png new file mode 100644 index 000000000..98edaa7b7 Binary files /dev/null and b/Aircraft/Generic/Logos/pumpkin.png differ diff --git a/Aircraft/Generic/Logos/pumpkin.xml b/Aircraft/Generic/Logos/pumpkin.xml new file mode 100644 index 000000000..fe685794d --- /dev/null +++ b/Aircraft/Generic/Logos/pumpkin.xml @@ -0,0 +1,12 @@ + + + + + + + Pumpkin + ../../Generic/Logos/pumpkin.png + + + + diff --git a/Aircraft/Generic/WalkView/walk-view-keys.xml b/Aircraft/Generic/WalkView/walk-view-keys.xml new file mode 100644 index 000000000..5471e9026 --- /dev/null +++ b/Aircraft/Generic/WalkView/walk-view-keys.xml @@ -0,0 +1,198 @@ + + + + + + + + + W + Walk view: Run forward. + + nasal + + + + + nasal + + + + + + + w + Walk view: Walk forward. + + nasal + + + + + nasal + + + + + + + d + Walk view: Side step right. + true + + nasal + + + + + nasal + + + + + + + D + Walk view: Fast side step right. + true + + nasal + + + + + nasal + + + + + + + a + Walk view: Side step left. + true + + nasal + + + + + nasal + + + + + + A + Walk view: Fast side step left. + true + + nasal + + + + + nasal + + + + + + + s + Walk view: Walk backwards. + + nasal + + + + + nasal + + + + + + + + diff --git a/Aircraft/Generic/WalkView/walkview.nas b/Aircraft/Generic/WalkView/walkview.nas index cecd081c6..8ed1bb61f 100644 --- a/Aircraft/Generic/WalkView/walkview.nas +++ b/Aircraft/Generic/WalkView/walkview.nas @@ -97,10 +97,12 @@ var active_walker = func { # [19.5, 0.3, -8.85]); # var walker = walkview.walker.new("Passenger View", constraint); # +# See Aircraft/Nordstern, Aircraft/Short_Empire and Aircraft/ZLT-NT +# for working examples of walk views. +# # NOTES: # Currently there can only be one view manager per view so the # walk view should not have any other view manager. -# var walker = { new : func (view_name, constraints = nil, managers = nil) { var obj = { parents : [walker] }; @@ -124,7 +126,7 @@ var walker = { view.manager.register(view_name, obj); walkers[obj.view.getPath()] = obj; - debug.dump(obj); + #debug.dump(obj); return obj; }, active : func { @@ -216,6 +218,8 @@ var walker = { ############################################################################### # Constraint classes. Determines where the view can walk. +# + # The union of two constraints. # c1, c2 - the constraints : constraint @@ -256,26 +260,55 @@ var makeUnionConstraint = func (cs) { return ret; } +# Rectangular plane defined by a straight line and a width. +# The line is extruded horizontally on each side by width/2 into a +# planar surface. +# p1, p2 - the line endpoints. +# width - total width of the plane. +var linePlane = { + new : func (p1, p2, width) { + var obj = { parents : [linePlane] }; + obj.p1 = p1; + obj.p2 = p2; + obj.halfwidth = width/2; + obj.length = vec2.length(vec2.sub(p2, p1)); + obj.e1 = vec2.normalize(vec2.sub(p2, p1)); + obj.e2 = [obj.e1[1], -obj.e1[0]]; + obj.k = (p2[2] - p1[2]) / obj.length; + + return obj; + }, + constrain : func (pos) { + var p = [pos[0], pos[1], pos[2]]; + var pXY = vec2.sub(pos, me.p1); + var along = vec2.dot(pXY, me.e1); + var across = vec2.dot(pXY, me.e2); + + var along2 = max(0, min(along, me.length)); + var across2 = max(-me.halfwidth, min(across, me.halfwidth)); + if (along2 != along or across2 != across) { + # Compute new XY position. + var t = vec2.add(vec2.mul(along2, me.e1), vec2.mul(across2, me.e2)); + p[0] = me.p1[0] + t[0]; + p[1] = me.p1[1] + t[1]; + } + + # Compute Z positition. + p[2] = me.p1[2] + me.k * along2; + return p; + } +}; + # Mostly aligned plane sloping along the X axis. +# NOTE: Obsolete. Use linePlane instead. # minp - the X,Y minimum point : position (meter) # maxp - the X,Y maximum point : position (meter) var slopingYAlignedPlane = { new : func (minp, maxp) { - var obj = { parents : [slopingYAlignedPlane] }; - obj.minp = minp; - obj.maxp = maxp; - obj.kxz = (maxp[2] - minp[2])/(maxp[0] - minp[0]); - return obj; - }, - constrain : func (pos) { - var p = [pos[0], pos[1], pos[2]]; - if (pos[0] < me.minp[0]) p[0] = me.minp[0]; - if (pos[0] > me.maxp[0]) p[0] = me.maxp[0]; - if (pos[1] < me.minp[1]) p[1] = me.minp[1]; - if (pos[1] > me.maxp[1]) p[1] = me.maxp[1]; - p[2] = me.minp[2] + me.kxz * (pos[0] - me.minp[0]); - return p; - }, + return linePlane.new([minp[0], (minp[1] + maxp[1])/2, minp[2]], + [maxp[0], (minp[1] + maxp[1])/2, maxp[2]], + (maxp[1] - minp[1])); + } }; # Action constraint @@ -366,3 +399,33 @@ var closerXY = func (pos, p1, p2) { var l2 = [p2[0] - pos[0], p2[1] - pos[1]]; return (l1[0]*l1[0] + l1[1]*l1[1]) - (l2[0]*l2[0] + l2[1]*l2[1]); } + +var max = func (a, b) { + return b > a ? b : a; +} +var min = func (a, b) { + return a > b ? b : a; +} + +# 2D vector math. +var vec2 = { + add : func (a, b) { + return [a[0] + b[0], a[1] + b[1]]; + }, + sub : func (a, b) { + return [a[0] - b[0], a[1] - b[1]]; + }, + mul : func (k, a) { + return [k * a[0], k * a[1]]; + }, + length : func (a) { + return math.sqrt(a[0]*a[0] + a[1]*a[1]); + }, + dot : func (a, b) { + return a[0]*b[0] + a[1]*b[1]; + }, + normalize : func (a) { + var s = 1/vec2.length(a); + return [s * a[0], s * a[1]]; + } +} diff --git a/Docs/README.local_weather.html b/Docs/README.local_weather.html index 505308079..d7f0a25d3 100644 --- a/Docs/README.local_weather.html +++ b/Docs/README.local_weather.html @@ -7,7 +7,7 @@ -

Local Weather Package - v0.85

+

Local Weather Package - v0.9

1. Introduction

@@ -15,7 +15,7 @@ The aim of a local weather system is to simulate weather phenomena tied to speci This is in contrast to the current (v.2.0.0) weather system of Flightgear where weather changes affect the weather everywhere in the simulated world and are (with few exceptions) not tied to specific locations. In such a system, it is impossible to observe e.g. the approach of a rainfront while flying in sunshine.

-The local weather package ultimately aims to provide the functionality to simulate such local phenomena. In version 0.85, the package supplies various cloud placement algorithms, as well as local control over most major weather parameters (wind, visibility, pressure, temperature, rain, snow, thermal lift, turbulence...) through interpolation routines and event volumes. The dynamics of the different systems is tied together - clouds and weather effects drift in the specified wind field. The package also contains a fairly detailed algorithm to generate convective clouds and thermals with a realistic distribution. Unfortunately, as of v0.85, there is no interaction yet between the windfield and the cloud-generating algorithms, i.e. while the placement algorithms create a realistic configuration of thermals and convective clouds, the wind will simply move this configuration, not create, destroy or move clouds in altitude dynamically (which would be realistic).

+The local weather package ultimately aims to provide the functionality to simulate such local phenomena. In version 0.9, the package supplies various cloud placement algorithms, as well as local control over most major weather parameters (wind, visibility, pressure, temperature, rain, snow, thermal lift, turbulence...) through interpolation routines and effect volumes. The dynamics of the different systems is tied together - clouds and weather effects drift in the specified wind field. The package also contains a fairly detailed algorithm to generate convective clouds and thermals with a realistic distribution. In addition, there is a simulation of realistic interaction of the convective cloud system with the terrain as a function of time. Clouds drifting in the wind flow over obstacles, i.e. they change their altitude dynamically. Convection is implemented with a life cycle model of clouds - they are generated, evolve for a given lifetime dependent on the underlying terrain and decay at the end of their life cycle. Thermals associated with the clouds follow the same pattern. In particular, in the presence of wind favourable spots for convection generate 'alleys' of dense cloud cover downwind, or thermals and clouds generated over land decay rapidly once they reach open water.

For long-range flights, the system automatically provides transitions between different weather patterns like fronts and low and high pressure areas. However, basically all features currently present can and will eventually be improved.

@@ -24,13 +24,18 @@ For long-range flights, the system automatically provides transitions between di The package needs to be unpacked in the Flightgear root directory. It writes content into the Nasal/, gui/, gui/dialogs/, Shaders, Effects/, Docs/, and Models/Weather/ subdirectories. The installation does not overwrite any of the default Flightgear files, but to be accessible from the menu, one must copy gui/menubar.xml.alt to the default menubar.xml or copy the last two lines of the environemnt menu calling local_weather and local_weather_tiles into the default file.

-This adds the items Local Weather, Local Weather Tiles and Local Weather Settings to the Environment menu when Flightgear is up. Most of the basic functionality is contained in local_weather.nas which is loaded at startup and identifies itself with a message, but does not start any functions unless called from the GUI.

+This adds the items Local Weather, Local Weather Tiles and Local Weather Settings to the Environment menu when Flightgear is up. Most of the basic functionality is contained in local_weather.nas which is loaded at startup and identifies itself with a message.

+ +Unless asked to do so from the menu, local weather does not run any process in the background. Upon loading, the package does not set any properties already existing, but only generates properties necessary for the menu entries in its own subdirectory /local-weather/ in the tree. The package also does a features check on startup if particular functions are available in hard-coded form. If the features are not present, the package will still function properly using slower Nasal fallbacks.

+

3. Functionality

-The general rule is that the gui is not hardened against problematic user input, for example it will not reject meaningless input like negative windspeeds or unphysical windshear. It is recommended to watch the console, because some level of warnings and errors are passed to the console. Placement calls may sometimes take a significant time to execute especially for large numbers of clouds tied in a complicated way to the terrain. Placing 500 barrier clouds against a small barrier may take a minute to compute. During this time, a reduced framerate is to be expected

+The general rule is that the gui is not hardened against problematic user input, for example it will not reject meaningless input like negative windspeeds or unphysical windshear. It is recommended to watch the console, because some level of warnings and errors are passed to the console if the log options is on. Crucial warnings are also printed on-screen.

-The first menu contains the low level cloud placement functions. Its purpose is mainly for developing cloud patterns without having to resort to re-type the underlying Nasal code every time. Currently five options are supported: Place a single cloud, Place a cloud streak, Start the convective system, Create barrier clouds and Place a cloud layer.

+Placement calls may sometimes take a significant time to execute especially for large numbers of clouds tied in a complicated way to the terrain. Placing 500 barrier clouds against a small barrier may take a minute to compute. During this time, a reduced framerate is to be expected

+ +The first menu Local Weather contains the low level cloud placement functions. Its purpose is mainly for developing cloud patterns without having to resort to re-type the underlying Nasal code every time. Currently five options are supported: Place a single cloud, Place a cloud streak, Start the convective system, Create barrier clouds , Place a cloud layer and Make a cloudbox.

@@ -93,26 +98,45 @@ The second menu is used to place complete weather tiles based on low-level calls

-Weather is created in a series of 40x40 km squares, called tiles. Tiles are classified by airmass, such that the sequence of tiles can describe for example the transition from a high pressure area to a low pressure area. The dropdown menu is used to select the type of weather tile to build initially. The menu contains two groups of tiles - the first are classified by airmass, whereas the last two are scenarios intended for soaring.

+Weather is created in a series of 40x40 km squares, called tiles. Tiles are classified by airmass, such that the sequence of tiles can describe for example the transition from a high pressure area to a low pressure area. The dropdown menu is used to select the type of weather tile to build initially.

Below are entries for three parameters. The first two are the simplified version of wind direction and speed for the user who is not interested in specifying many different wind interpolation points. -The third parameter, the altitude offset, is to manually adjust the altitude level of clouds in the absence of terrain presampling. Cloud layer placement calls are then specified for absolute altitudes and calibrated at sea level. As a result, layers are placed too low in mountainous terrain, hence the need for an offset. The offset may at present also be useful for dynamical weather, as convective clouds with terrain presampling follow terrain altitude, which looks strange when the clouds are allowed to drift in the wind without altitude correction.

+The third parameter, the altitude offset, is to manually adjust the altitude level of clouds in the absence of terrain presampling. Cloud layer placement calls are then specified for absolute altitudes and calibrated at sea level. As a result, layers are placed too low in mountainous terrain, hence the need for an offset.

The dropdown menu for the wind contains various models for how the windfield is specified which require a different amount of user-specified input. The options are described further down when the windfield modelling is described in more detail.

-The dropdown menu for the tile selection mode controls the long-range behaviour of weather. It specifies according to what rules tiles are automatically generated once the aircraft reaches the border of the original tile. The option 'single tile' creates a single weather tile as specified without automatic generation of further tiles. The option 'repeat tile' creates new tiles of the same type as the originally selected tile. This does not mean that weather will be unchanged during flight, as both parameters like pressure, temperature and visibility as well as the positioning of cloud banks are randomized to some degree. In addition, each tile typically contains 2-5 different cloud scenarios, so five repeated generations of 'low-pressure-border' tiles may never result in the same arrangement of cloud layers. Necertheless, the option will keep weather conditions roughly the same. This is different with the (somewhat optimistically named) 'realistic weather'. This option allows transitions between different airmasses, thus one may select 'low-pressure-core' initially, but as the flight goes on, eventually a region of high pressure and clear skies may be reached. Currently this change between airmasses does not include transitions across fronts. Moreover, it does not cover transitions to arctic or tropical weather conditions - those will be covered in a future release. Note that 'realistic weather' does not work for the two soaring scenarios, 'repeat tile' does not work for any tile which is part of a front.

+The dropdown menu for the tile selection mode controls the long-range behaviour of weather. It specifies according to what rules tiles are automatically generated once the aircraft reaches the border of the original tile. The option 'single tile' creates a single weather tile as specified without automatic generation of further tiles. The option 'repeat tile' creates new tiles of the same type as the originally selected tile. This does not mean that weather will be unchanged during flight, as both parameters like pressure, temperature and visibility as well as the positioning of cloud banks are randomized to some degree. In addition, each tile typically contains 2-5 different cloud scenarios, so five repeated generations of 'low-pressure-border' tiles may never result in the same arrangement of cloud layers. Necertheless, the option will keep weather conditions roughly the same. This is different with the (somewhat optimistically named) 'realistic weather'. This option allows transitions between different airmasses, thus one may select 'low-pressure-core' initially, but as the flight goes on, eventually a region of high pressure and clear skies may be reached. Moreover, it does not cover transitions to arctic or tropical weather conditions - those will be covered in a future release. 'repeat tile' does not work for any tile which is part of a front.

-The final option, 'METAR', generates weather according to parsed METAR information. This information must be made available in the property tree. Currently this is not done automatically and the METAR system does not work with real-weather-fetch, this needs some work on the Flightgear core.

+The final option, 'METAR', generates weather according to parsed METAR information. This information must be made available in the property tree. Currently this is not done automatically and the METAR system does not work with real-weather-fetch, this needs some work on the Flightgear core. Future versions will be able to use parsed METAR to generate weather tiles.

-Below the menu are five tickboxes. 'Terrain presampling' finds the distribution of altitude in the terrain before placing a cloud layer. As a result, the layers or clouds are automatically placed at the correct altitude above ground in level terrain. In mountain regions, cloud placement is fairly tricky, and the algorithm analyzes quantities like the median altitude to determine what to do. The appendix contains a detailed description of the algorithm. If the box is ticked, the altitude offset specified above is not parsed.

+Below the menu are six tickboxes. 'Terrain presampling' finds the distribution of altitude in the terrain before placing a cloud layer. As a result, the layers or clouds are automatically placed at the correct altitude above ground in level terrain. In mountain regions, cloud placement is fairly tricky, and the algorithm analyzes quantities like the median altitude to determine what to do. The appendix contains a detailed description of the algorithm. If the box is ticked, the altitude offset specified above is not parsed.

+'generate thermals' is an option intended primarily for soaring. It determines if thermals will be placed whenever a convective clouds is generated. Since managing a large number of thermals costs some amount of resources, it is recommended to generate thermals only if they are needed, i.e. definitely for soaring, possibly for added realism in small aircraft.

-'Worker threads' is an option to distribute the work flow. Usually, the local weather package will compute a task till it is done before starting the next. Thus, creating a new weather tile may lead to a few seconds freeze, before Flightgear continues normally. With 'worker threads' selected, computations will be split across several frames. The advantage is that Flightgear stays responsive during loading and unloading of weather tiles, and in general the flight continues smoothly, albeit with reduced framerate. However, selecting this option does not guarantee that an operation is finished by the time another is beginning - thus there may be situations in which the loading of a new tile blocks unloading of an old one and so on, in essence leading to processes competing for access to the weather array, resulting in an extended period of very low framerates. Dependent on system performance, this may or may not be acceptable to the user. 'asymmetric range' is an experimental performance-improving option (see below). Finally, 'detailed clouds' will change the technique for generating Cumulus clouds from a multilayer model to multiple cloudlets filling a box. This improves the visual appearance of the clouds significantly, albeit at the expense of a (significant) loss of framerate. Rendering multiple tiles of dense Cumulus development with detailed clouds will quite possibly freeze even a powerful system.

+'debug output' determines if the system writes status messages to the console. Unselecting the option suppresses normal status messages (warnings and errors will still be written). However, in many cases the log of status messages is needed to trace bugs, so if you switch it off and experience a problem, it is likely that the problem cannot be traced.

-The option 'dynamical weather' ties all clouds and weather effects to the windfield. If that option is not chosen, the wind is still generated according to the chosen model, but only felt by the aircraft. This makes e.g. soaring unrealistic, as the aircraft continuously drifts out of a static thermal below a static cap cloud. When 'dynamical weather' is selected, aircraft, cloud and thermal are all displaced by the wind.

+'detailed clouds' will change the technique for generating Cumulus clouds from a multilayer model to multiple cloudlets filling a box. This improves the visual appearance of the clouds significantly, albeit at the expense of some loss of framerate. Rendering multiple tiles of dense Cumulus development with detailed clouds will quite possibly slow down even a powerful system.

+ +The option 'dynamical weather' ties all clouds and weather effects to the windfield. If that option is not chosen, the wind is still generated according to the chosen model, but only felt by the aircraft. This makes e.g. soaring unrealistic, as the aircraft continuously drifts out of a static thermal below a static cap cloud. When 'dynamical weather' is selected, aircraft, cloud and thermal are all displaced by the wind and follow elevation changes to some degree.

+ +The final option 'dynamical convection' requires both 'terrain presamling' and 'dynamical weather' to be on (if not, a warning is given and the system aborts). If this option is chosen, all convective clouds and thermals have a life cycle - clouds are continually spawned and decay after a while. This preserves realistic cloud configurations over islands even with wind drift on and improves the realism of the soaring experience as the thermals change over time, but again uses somewhat more performance - switch it on if you need it, for fast planes the visual gain is almost non-existent.

The slider 'Thermal properties' is mainly relevant for soaring scenarios. It governs the rato of maximum lift to radius of a thermal. A setting close to 'low convection' creates large thermals with relatively small lift and virtually no turbulence, a setting close to 'rough day' creates very narrow, turbulent thermals with large lift. However, it also affects the Cumulus textures to be used. 'low convection' creates well-formed, smooth Cumuli whereas 'rough day' biases the texture selection towards more rugged and diffuse clouds.

+The difference is apparent from the following pictures: Smooth and well-formed clouds characteristic of a calm day:

+ +

+ +

+ +Rough clouds characteristic of windshear and more turbulent conditions:

+ +

+ +

+ +As for the buttons, 'Ok' starts the local weather system with the selected options (note that all options in this menu are startup-time options, they are read once and changing them without restarting the system will not affect the behaviour of the system). 'Clear/End' clears all clouds and ends all local weather functionality - the button brings the system back into the state before it was started. No loops or other subroutines are executed after the button is pressed. 'Close' closes the dialog without starting the system.

+ The button 'Show winds' brings up the detailed wind menu which is needed for the wind models 'aloft interpolated' and 'aloft waypoints':

@@ -125,14 +149,14 @@ In principle, the waypoint information inserted so far can be seen using the pro -The following pictures show the results of tile setups 'Low-pressure-border' and 'High-pressure-border':

+The following pictures show possible results of tile setups 'High-pressure-border' and 'Low-pressure':

- +

- +

Performance settings

@@ -162,11 +186,20 @@ All performance setting menu-options work at runtime, but are processed over tim The package contains a number of different cloud models, both static ones for Cirrus and Cirrocumulus clouds as well as rotated ones for Altocumulus, Cirrostratus, Cumulus, Cumulonimbus, Stratus and Nimbostratus cloudlet models. Neither the cloud textures, nor the models nor the transformations are perfected, and any aspect can be improved.

+Static clouds project textures onto curved sheets into the sky. The advantage of the technique is that cloud layers consisting of thousands of cloudlets with different sizes can be modelled. However, the sheets do not look equally well from all perspectives and somewhat unrealistic from close up.

+ +

+ +

+ +Rotated cloud models have the advantage that they look much better from close up and hardly unrealistic from any perspective, but the size distribution of cloudlets is somewhat restricted and they use a lot more performance than static clouds.

+ +

-These are rendered by a different technique: While the default Cumulus models consist of multiple layers rotated around the center of the model, the detailed Cumulus clouds consist of multiple (up to 24) individual cloudlets, rotating each around its own center, randomly distributed into a box. This not only improves the visual appearance, but also leads to a more realistic distribution of cloud sizes and shapes in the sky. In addition, when circling below the cloud (as done when soaring) the effect of the cloudlet rotation is less pronounced. The price to pay is that rendering detailed clouds costs about a factor 4 more performance, so they may not be suitable for all systems.

+These are rendered by different techniques. While the default Cumulus models consist of multiple layers rotated around the center of the model, the detailed Cumulus clouds consist of multiple (up to 24) individual cloudlets, rotating each around its own center, randomly distributed into a box with different texture types used for the cloud bottom. This not only improves the visual appearance, but also leads to a more realistic distribution of cloud sizes and shapes in the sky. In addition, when circling below the cloud (as done when soaring) the effect of the cloudlet rotation is less pronounced. The price to pay is that rendering detailed clouds costs more performance, so they may not be suitable for all systems.

More complex clouds are rendered in sandwitched layers of several different textures. An example are Cumulonimbus towers, which use diffuse textures on the bottom, changing to more structured textures in the upper part of the cloud. With up to 2000 cloudlets, skies with multiple thunderstorms may not render with sufficient framerates on every system.

@@ -178,7 +211,7 @@ The general problem is finding a good balance between spending a lot of CPU time -Currently all clouds which need to be rotated are treated in the Shaders using a view-axis based rotation by two angles. This generally looks okay from a normal flight position, but rapid change of the view axis (looking around), especially straight up or down, causes unrealistic cloud movement. Any static picture of clouds however is (almost) guaranteed to look fine. This means that shader effects need to be 'on' in order to see most of the clouds.

+Currently all clouds which need to be rotated are treated in the shaders using a view-axis based rotation by two angles. This generally looks okay from a normal flight position, but rapid change of the view axis (looking around), especially straight up or down, causes unrealistic cloud movement. Any static picture of clouds however is (almost) guaranteed to look fine. This means that shader effects need to be 'on' in order to see most of the clouds.

5. Local weather parameters

@@ -208,11 +241,11 @@ Volumes 2 and 3 are nested inside volume 1, therefore all settings of 2 overwrit Effect volumes are always specified between a minimum and a maximum altitude, and they can have a circular, elliptical and rectangular share (the last two rotated by an angle phi). Since it is quite difficult to set up event volumes without visual reference and also not realistic to use them without the context of a cloud or precipitation model, there is no low-level setup call available in the menu. Effect volumes can be created with a Nasal call

-create_effect_volume(geometry, lat, lon, r1, r2, phi, alt_low, alt_high, vis, rain, snow, turb, lift, lift_flag);

+create_effect_volume(geometry, lat, lon, r1, r2, phi, alt_low, alt_high, vis, rain, snow, turb, lift, lift_flag, sat);

- where geometry is a flag (1: circular, 2: elliptical and 3: rectangular), lat and lon are the latitude and longitude, r1 and r2 are the two size parameters for the elliptic or rectangular shape (for the circular shape, only the first is used), phi is the rotation angle of the shape (not used for circular shape), alt_low and alt_high are the altitude boundaries, vis, rain, snow, turb and lift are weather parameters which are either set to the value they should assume, or to -1 if they are not to be used, or to -2 if a function instead of a parameter is to be used. Since thermal lift can be set to negative values in a sink, a separate flag is provided in this case.

+ where geometry is a flag (1: circular, 2: elliptical and 3: rectangular), lat and lon are the latitude and longitude, r1 and r2 are the two size parameters for the elliptic or rectangular shape (for the circular shape, only the first is used), phi is the rotation angle of the shape (not used for circular shape), alt_low and alt_high are the altitude boundaries, vis, rain, snow, turb and lift are weather parameters which are either set to the value they should assume, or to -1 if they are not to be used, or to -2 if a function instead of a parameter is to be used and -3 if a function for wave lift is used. Since thermal lift can be set to negative values in a sink, a separate flag is provided in this case. sat finally determines the light saturation - it can be used to dim the light beneath cloud layers (which is not done automatically as objects don't cast shades in Flightgear, and given that most cloud models are rotated, their shade would look rather odd on any case).

-In version 0.85, thermal lift is implemented by function. There is no easy way to implement any weather parameter by function in an effect volume, as this requires some amount of Nasal coding. +In version 0.9, thermal lift and wave lift are implemented by function (wave lift is not yet automatically placed, but can be easily from Nasal). There is no easy way to implement any weather parameter by function in an effect volume, as this requires some amount of Nasal coding.

6. Wind models and dynamical weather

@@ -245,9 +278,9 @@ The internal state of the local weather system is found in the property tree und The local-weather folder contains various subdirectories. clouds/ contains the record of all visible weather phenomena (clouds, precipitation layers, lightning...) in a subdirectory tile[j]/cloud[i]/. The total number of all models placed is accessible as local-weather/clouds/cloud-number. Inside each cloud/ subdirectory, there is a string type specifying the type of object and subdirectories position/ and orientation which contain the position and spatial orientation of the model inside the scenery. Note that the orientation property is obsolete for clouds which are rotated by the shader.

-The local-weather/effect-volumes/ subfolder contains the management of the effect volumes. It has the total count of specified effect volumes, along with the count of currently active volumes for each property. If volumes are defined, their properties are stored under local-weather/effect-volumes/effect-volume[i]/. In each folder, there are position/ and volume/ storing the spatial position and extent of the volume, as well as the active-flag which is set to 1 if the airplane is in the volume and the geometry flag which determines if the volume has circular, elliptical or rectangular shape. Finally, the effects/ subfolder holds flags determining of a property is to be set when the volume is active and the corresponding values. On entry, the effect volumes also create a subfolder restore/ in which the conditions as they were when the volume was entered are saved.

+The local-weather/effect-volumes/ subfolder contains the management of the effect volumes. It has the total count of specified effect volumes, along with the count of currently active volumes for each property.

-local-weather/interpolation/ holds all properties which are set by the interpolation system, as well as subfolders station[i]/ in which the weather station information for the interpolation are found and subfolders wind[i] where wind information in the case of 'aloft interpolated' or 'aloft waypoints' is stored. Basically, here is the state of the weather as it is outside of effect volumes. Since parameters may be set to different values in effect volumes, the folder local-weather/current/ contains the weather as the local weather system currently thinks it should be. Currently, weather is actually passed to the Flightgear environment system through several workarounds. In a clean C++ supported version, the parameters should be read from here.

+local-weather/interpolation/ holds all properties which are set by the interpolation system. Basically, here is the state of the weather as it is outside of effect volumes. Since parameters may be set to different values in effect volumes, the folder local-weather/current/ contains the weather as the local weather system currently thinks it should be. Currently, weather may be passed to the Flightgear environment system through several workarounds, dependent on the Flightgear core version.

local-weather/tiles stores the information of the 9 managed weather tiles (the one the airplane is currently in, and the 8 surrounding it). By default each directory contains the tile center coordinates and a flag if it has been generated. Tiles are not generated unless a minimum distance to the tile center has been reached. Once this happens, the tile type is written as a code, and the cloud, interpolation and effect volume information corresponding to the tile is generated.

@@ -261,7 +294,7 @@ The first important call sets up the conditions to be interpolated:

set_weather_station(latitude, longitude, visibility-m, temperature-degc, dewpoint-degc, pressure-sea-level-inhg);

-The cloud placement calls should be reasonably familiar, as they closely resemble the structure by which they are accessible from the menu. Note that for (rather stupid reasons) currently a randomize_pos call must follow a create_streak call.

+The cloud placement calls should be reasonably familiar, as they closely resemble the structure by which they are accessible from the 'Local Weather' menu.

If the cloud layer has an orientation, then all placement coordinates should be rotated accordingly. Similarly, each placement call should include the altitude offset. Take care to nest effect volumes properly where possible, otherwise undesired effects might occur...

@@ -281,7 +314,8 @@ With default settings, the local weather package generates a 40x40 km weather ti

  • if this does not help, try avoiding scenarios with large cloud count. As a rule, low pressure areas have high cloud count, high pressure areas have a low cloud count. Do not use 'detailed clouds', which tend to generate large cloud counts.

    -

  • a different issue is a characteristic small pause every second. This is caused by the interpolation loop resetting the weather parameters. Currently, a computationally expensive workaround is needed to do so, causing the problem. Work on a better environment controller is on the way, however until that modification to the core Flightgear code is implemented, the best solution is to set the loop time in Nasal/local-weather.nas to a larger value.

    +

  • a different issue is a characteristic small pause every second. This may be caused by the interpolation loop resetting the weather parameters or by the altitude correction of convective clouds when cloud count is high and wind drift is on. The first issue only occurs when the system did not find hard coded support. There is no easy fix for the second problem, except to avoid dynamical weather in situations with large cloud counts. +

  • dynamical weather uses a lot of performance. If framerate is low and you don't need it, don't use it! From fast planes, cloud drift is almost impossible to see against the relative motion of cloud and airplane anyway.

    @@ -297,7 +331,7 @@ With default settings, the local weather package generates a 40x40 km weather ti

  • Rain and snow may not start properly. For me, rain is only generated when I switch 'Shader effects' on and off in the menu on startup, otherwise neither moving the menu slider nor entering an effect volume generate rain. This seems to be a bug of some Flightgear versions, not of the local weather system.

    -

  • Especially with multiple overcast layers and weather fronts, loading and unloading weather tiles may take a long time / cause severe drops in framerate. Please refer to performance tuning to solve such problems. In general, overcast layers and tropical weather tiles do require a system on the high end of the performance scale to render properly.

    +

  • Especially with multiple overcast layers and weather fronts, loading and unloading weather tiles may take a long time / cause severe drops in framerate. The problem is much worse in GIT than in 2.0.0. Please refer to performance tuning to solve such problems. In general, overcast layers and tropical weather tiles do require a system on the high end of the performance scale to render properly.

  • The local weather package is able to occasionally trigger errors like 'Warning:: Picked up error in TriangleIntersect'. These seem to be a problem in the core Flightgear code - the package does nothing but placing normal (rather simple) AC3D models into the scenery.

    @@ -307,6 +341,8 @@ With default settings, the local weather package generates a 40x40 km weather ti

  • Large tile creation distances can cause problems in low visibility weather, because Flightgear loads terrain only if it is within visual range. Thus, trying to sample the terrain for a tile 55 km away in 8 km visibility doesn't work because the terrain elevation and altitude is not known. This may cause improper placement of clouds - chiefly convective clouds, but also layered clouds may not appear on the proper altitude. Currently, there is a limit which restricts tile loading range to 3 times the visibility, but presumably a better solution can be found.

    +

  • Using the 'aloft interpolated' wind option, it is possible to turn the wind direction sharply over a small distance (for example, one may turn the wind by 90 degrees from one tile to the next). Such sharp wind changes are (in most situations) unphysical, and they may cause problems for local weather because they rotate the coordinate system to a degree that the neighbouring tile may not be identified correctly. In essence, the system may not generate new tiles because the nearest tile is still the last generated one. There will be a future fix to address the problem, for the moment just avoid rotating the wind strongly.

    +

  • The thermals in the soaring scenarios need GIT to work.

    @@ -314,9 +350,9 @@ With default settings, the local weather package generates a 40x40 km weather ti This section describes the more complicated cloud placement algorithms in some detail. It is intended for readers who are interested in understanding (and possibly modifying) what creates the weather they get to see. -

    The convective algorithm and the properties of thermals

    +

    The convective startup algorithm and the properties of thermals

    -The convective algorithm is used to place Cumulus clouds as well as thermals. Thermals are by default not placed to save CPU time unless a tile designed for soaring is selected, but they can be generated for any weather tile by setting local-weather/tmp/generate-thermal-lift-flag to either 1 (constant-strength thermals) or 2 (detailed thermal model).

    +The convective startup algorithm is used to place Cumulus clouds as well as thermals. Thermals are by default not placed to save CPU time unless the flag is set in the menu.

    At the core of the convective algorithm is the concept of locally available thermal energy. The source of this energy is solar radiation. The flux of solar energy depends on the angle of incident sunlight with the terrain surface. It is possibly (though computationally very expensive) to compute this quantity, but the algorithm uses a proxy instead. The daily angle of the sun at the equator assuming flat terrain is modelled as 0.5 * (1.0-cos(t/24.0*2pi)) with t expressed in hours, a function that varies between zero at midnight and 1 at noon. There is a geographical correction to this formula which goes with cos(latitude), taking care of the fact that the sun does not reach the zenith at higher latitudes. Both the yearly summer/winter variation of the solar position in the sky and the terrain slope are neglected.

    @@ -368,6 +404,32 @@ At sunset around 19:00 pm, the number of clouds decreases quickly, but there is While not accurate in every respect, the model works fairly well to reproduce the actual time dependence of convective clouds and thermal lift during the day.

    +

    The convective dynamics algorithm

    + +The convective dynamics algorithm is responsible for modelling the life cycle of convective clouds, dependent on the terrain type underneath. It meshes well with the convective startup algorithm, and its long-term zero wind limit is just the situation set up by the initial convective placement.

    + +At its heart is the idea of fractional cloud lifetime. A cloud is born with fractional lifetime zero, and it decays once its fractional lifetime reaces 1. The translation of real time to fractional lifetime is given by sqrt(p) where p is the landcover dependent probability defined above. A cloud over landcover with maximum p of 0.35 has a lifetime of 30 minutes, so if a cloud spends 10 minutes over this terrain type, its fractional lifetime is increased by 1/3. If the landcover is different, the lifetime is reduced according to sqrt(p_1/p_max).

    + +A cloud field is initialized with fractional lifetimes randomly distributed between zero and 1. To compensate for the decay of clouds, clouds are periodically respawned as in the startup algorithm, but with placement probability sqrt(p) instead of p. In the limit of no wind, the cloud density over a terrain type is then given by placement probability times lifetime, i.e. sqrt(p) * sqrt(p) = p as it should be. The presence of a windfield distorts the cloud distribution, dense clouds are then found preferably downwind of suitable convection sources.

    + +

    The thermal lift model

    + +The model of the distribution of lift inside a thermal is quite complex.

    + +

    + +

    + +Vertically, is is characterized in addition to height and radius by two parameters, 'coning' and 'shaping', which make it cone-shaped and wasp-waisted. From zero to 200 m above ground, the lift is smoothly fading in, above the cloudbase it is smoothly faded out to zero at 10% above the nominal altitude. Horizontally, there is an outer ring where the air becomes turbulent, followed by a region of sink which in turn is followed by the inner core of lift.

    + +The distribution of lift and sink is time dependent. + +

    + +

    + +In a young thermal, lift starts to develop from the ground, sink is initially absent. When the lift reaches the cloudbase, sink starts to develop from the ground and rises up as well. Only in a mature thermal are sink and lift in equilibrium. When the thermal starts to decay, lift initially decays from the ground upward, till it reaches the cloudbase. At this time the cap cloud dissolves. For a time there is a residual distribution of sink decaying from bottom to top till the thermal evolution is over and the thermal (and the associate turbulence field) is removed.

    +

    The terrain presampling and cloud altitude determination algorithm

    While the meaning of a cloud layer altitude is rather obvious in level terrain, this quickly becomes a highly non-trivial question in mountaineous terrain where the elevation of the terrain is more difficult to define. Observation of weather patterns in mountain regions suggests that clouds follow changes in terrain elevation to some degree, but not all cloud types do to the same degree. While convective clouds follow a change in elevation more readily even on small distance scales, layered clouds don't do so. The purpose of the terrain presampling and cloud altitude determination algorithm is to capture this behaviour as closely as possible.

    @@ -434,10 +496,10 @@ Realistically, the boundary layer should also depend on terrain coverage. Due to

    Credits

    -The model of a thermal has been developed by Patrice Poly. The shader code used to transform clouds is heavily based on prior work by Stuart Buchanan.

    +The model of a thermal has been developed by Patrice Poly. The shader code used to transform clouds is heavily based on prior work by Stuart Buchanan. Hard-coding of some features by Torsten Dreyer is greatly appreciated.

    -Thorsten Renk, June 2010 +Thorsten Renk, October 2010 diff --git a/Docs/clouds-detailed01.jpg b/Docs/clouds-detailed01.jpg index e380880e3..4136b78b3 100644 Binary files a/Docs/clouds-detailed01.jpg and b/Docs/clouds-detailed01.jpg differ diff --git a/Docs/clouds-static.jpg b/Docs/clouds-static.jpg new file mode 100644 index 000000000..0ac9c194d Binary files /dev/null and b/Docs/clouds-static.jpg differ diff --git a/Docs/detailed_clouds04.jpg b/Docs/detailed_clouds04.jpg new file mode 100644 index 000000000..5ac837f4e Binary files /dev/null and b/Docs/detailed_clouds04.jpg differ diff --git a/Docs/detailed_clouds05.jpg b/Docs/detailed_clouds05.jpg new file mode 100644 index 000000000..a06faed01 Binary files /dev/null and b/Docs/detailed_clouds05.jpg differ diff --git a/Docs/high_pressure_border.jpg b/Docs/high_pressure_border.jpg new file mode 100644 index 000000000..e9b77f635 Binary files /dev/null and b/Docs/high_pressure_border.jpg differ diff --git a/Docs/low_pressure.jpg b/Docs/low_pressure.jpg new file mode 100644 index 000000000..5670c4123 Binary files /dev/null and b/Docs/low_pressure.jpg differ diff --git a/Docs/menu2.jpg b/Docs/menu2.jpg index 226d0a4b9..97714ac0c 100644 Binary files a/Docs/menu2.jpg and b/Docs/menu2.jpg differ diff --git a/Docs/thermal_lift.gif b/Docs/thermal_lift.gif new file mode 100644 index 000000000..dd35cdb6f Binary files /dev/null and b/Docs/thermal_lift.gif differ diff --git a/Docs/thermal_lift_time.gif b/Docs/thermal_lift_time.gif new file mode 100644 index 000000000..e1b273f54 Binary files /dev/null and b/Docs/thermal_lift_time.gif differ diff --git a/Effects/urban.eff b/Effects/urban.eff index f8eecd141..d73d5b2ea 100644 --- a/Effects/urban.eff +++ b/Effects/urban.eff @@ -7,6 +7,7 @@ 0.008 0.75 0.59 0.05 /sim/rendering/quality-level + 10 15 @@ -68,12 +69,24 @@ texture[2]/filter texture[2]/wrap-s texture[2]/wrap-t - - texture[2]/internal-format - + texture[2]/internal-format 2 + texture[2]/image + nearest-mipmap-nearest + texture[2]/wrap-s + texture[2]/wrap-t + texture[2]/internal-format + + average + average + average + min + + + + 3 noise @@ -102,10 +115,15 @@ sampler-2d 1 + + QDMTex + sampler-2d + 2 + NoiseTex sampler-3d - 2 + 3 depth_factor @@ -132,6 +150,11 @@ float snow-level + + max_lod_level + float + max-lod-level + diff --git a/Huds/Custom/default.xml b/Huds/Custom/default.xml deleted file mode 100644 index d70f42710..000000000 --- a/Huds/Custom/default.xml +++ /dev/null @@ -1,40 +0,0 @@ - - - - - - - - Fighter Hud - - - - - Huds/Instruments/Custom/hudladder.xml - - - - Huds/Instruments/Custom/hudcard.xml - - - - Huds/Instruments/Custom/instrlabel.xml - - - - - diff --git a/Huds/Default/default.xml b/Huds/Default/default.xml deleted file mode 100644 index 848f6203c..000000000 --- a/Huds/Default/default.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - - Default Aircraft Hud - - - - - Huds/Instruments/Default/hudladder.xml - - - - Huds/Instruments/Default/hudcard.xml - - - - - Huds/Instruments/Default/instrlabel.xml - - - - Huds/Instruments/Default/fgtbi.xml - - - - Huds/Instruments/Default/gload.xml - - - - - - - diff --git a/Huds/Engineering/default.xml b/Huds/Engineering/default.xml deleted file mode 100644 index a84c28a34..000000000 --- a/Huds/Engineering/default.xml +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - - - Default Aircraft Hud - - - - - Huds/Instruments/Default/hudladder.xml - - - - Huds/Instruments/Default/hudcard.xml - - - - Huds/Instruments/Engineering/instrlabel.xml - - - - Huds/Instruments/Default/fgtbi.xml - - - - - diff --git a/Huds/Instruments/Custom/fgtbi.xml b/Huds/Instruments/Custom/fgtbi.xml deleted file mode 100644 index cde8f9f8f..000000000 --- a/Huds/Instruments/Custom/fgtbi.xml +++ /dev/null @@ -1,22 +0,0 @@ - - - - - - fgTBI_Instrument - 290 - 200 - 60 - 10 - 45.0 - 5.0 - 5 - true - true - 150.0 - - - - - - diff --git a/Huds/Instruments/Custom/hudcard.xml b/Huds/Instruments/Custom/hudcard.xml deleted file mode 100644 index fe1f08f61..000000000 --- a/Huds/Instruments/Custom/hudcard.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - - - - - - - - - - - - Gyrocompass - 260 - 248 - 120 - 28 - heading - 4 - 360.0 - 0.0 - 0.1 - 10 - 5 - 360 - 60.0 - tape - false - false - false - false - false - false - false - false - 10.0 - false - fixed - line - variable - true - 40.0 - 12 - 0 - - - - AOA - 180 - 100 - 28 - 100 - aoa - 6 - 20.0 - 0.0 - 1.0 - 4 - 2 - 0 - 20.0 - tape - false - false - false - false - false - false - false - false - 10.0 - true - moving - circle - constant - true - 30.0 - 12 - 0 - - - - - NormalAcceleration - 140 - 110 - 18 - 100 - anzg - 6 - 9.0 - -3.0 - 1 - 2 - 1 - 0 - 12.0 - tape - false - false - false - false - false - false - false - false - 10.0 - true - moving - line - variable - false - 40.0 - 12 - 0 - - - - - VSI - 430 - 50 - 28 - 150 - climb - 10 - 1000.0 - -1000.0 - 1.0 - 200 - 100 - 0 - 2000.0 - tape - false - false - false - false - false - false - false - false - 10.0 - true - moving - line - variable - true - 40.0 - 12 - 1 - - - - - - diff --git a/Huds/Instruments/Custom/hudladder.xml b/Huds/Instruments/Custom/hudladder.xml deleted file mode 100644 index dd09558a7..000000000 --- a/Huds/Instruments/Custom/hudladder.xml +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - - - - - Climb/Dive Ladder - 260 - 150 - 120 - 180 - 12.6316 - roll - pitch - 45 - 5.0 - 70 - 0 - true - false - true - true - true - true - true - true - -4.0 - true - true - true - 1 - 1 - 1 - - - - - - diff --git a/Huds/Instruments/Custom/instrlabel.xml b/Huds/Instruments/Custom/instrlabel.xml deleted file mode 100644 index 00e0c3aa6..000000000 --- a/Huds/Instruments/Custom/instrlabel.xml +++ /dev/null @@ -1,209 +0,0 @@ - - - - - - digitalkias - 130 - 265 - 40 - 30 - speed - %5.0f - NULL - blank - 1.0 - 4 - 2 - 0 - false - false - false - true - - - - machno - 140 - 245 - 40 - 30 - mach - %5.2f - NULL - blank - 1.0 - 4 - 2 - 0 - false - false - false - true - - - - pressurealtitude - 430 - 265 - 40 - 30 - altitude - %5.0f - NULL - blank - 1.0 - 4 - 0 - 0 - false - false - false - true - 1 - - - - radioaltitude - 430 - 245 - 40 - 30 - agl - %5.0f - NULL - R - 1.0 - 4 - 0 - 0 - false - false - false - true - - - - xposn - 560 - 440 - 40 - 30 - aux4 - %5.0f - NULL - m - 1.0 - 4 - 0 - 0 - false - false - false - true - - - - pla - 560 - 430 - 40 - 30 - throttleval - %5.0f - NULL - pla - 130.0 - 4 - 0 - 0 - false - false - false - true - - - - FrameRate - 0 - 25 - 60 - 10 - framerate - %3.1f - NULL - blank - 1.0 - 4 - 1 - 0 - false - false - false - true - - - - acceleration - 140 - 90 - 20 - 30 - anzg - %1.1f - blank - NULL - 1.0 - 1 - 0 - 0 - false - false - true - true - - - - - lattitude - 40 - 40 - 1 - 10 - latitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - true - false - false - true - - - - longitude - 550 - 40 - 1 - 10 - longitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - false - true - true - - - - - - diff --git a/Huds/Instruments/Default/fgtbi.xml b/Huds/Instruments/Default/fgtbi.xml deleted file mode 100644 index 522a76217..000000000 --- a/Huds/Instruments/Default/fgtbi.xml +++ /dev/null @@ -1,21 +0,0 @@ - - - - - - fgTBI_Instrument - 290 - 45 - 60 - 10 - roll - sideslip - 45.0 - 5.0 - 5 - true - - - - - diff --git a/Huds/Instruments/Default/gload.xml b/Huds/Instruments/Default/gload.xml deleted file mode 100644 index f7ff03dee..000000000 --- a/Huds/Instruments/Default/gload.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - - - - G Load - 41 - 345 - 40 - 30 - anzg - %4.2f - NULL - g - 1.0 - 4 - 0 - 0 - true - false - false - - - - - diff --git a/Huds/Instruments/Default/hudcard.xml b/Huds/Instruments/Default/hudcard.xml deleted file mode 100644 index 932715265..000000000 --- a/Huds/Instruments/Default/hudcard.xml +++ /dev/null @@ -1,285 +0,0 @@ - - - - - - Gyrocompass - 220 - 430 - 200 - 28 - heading - 4 - 360.0 - 0.0 - 1.0 - 5 - 1 - 360 - 25.0 - tape - false - false - true - true - true - false - false - false - 0.0 - true - fixed - line - variable - true - - - - AMSL - 565 - 140 - 35 - 200 - altitude - 6 - 5000.0 - -1000.0 - 1.0 - 100 - 25 - 0 - 250.0 - tape - true - true - false - false - false - false - true - false - 0.0 - true - fixed - line - variable - true - - - - RadioAltimeter - 438 - 165 - 25 - 150 - agl - 6 - 1000.0 - 0.0 - 1.0 - 25 - 5 - 0 - 200.0 - tape - true - true - false - false - false - false - true - false - 0.0 - true - fixed - line - variable - true - - - - KIAS - 40 - 140 - 28 - 200 - speed - 10 - 200.0 - 0.0 - 1.0 - 10 - 5 - 0 - 50.0 - tape - true - true - false - false - false - false - false - true - 0.0 - true - fixed - line - variable - true - - - - Gauge1 - 270 - 310 - 100 - 20 - aileronval - 136 - +1.0 - -1.0 - 100.0 - 50 - 0 - 0 - 2.0 - gauge - false - false - true - true - false - true - false - false - 0.0 - true - fixed - true - - - - Gauge2 - 182 - 190 - 20 - 100 - elevatorval - 138 - -100.0 - +1.0 - -1.0 - 50 - 0 - 0 - 2.0 - 0.0 - gauge - true - true - false - false - false - false - false - true - true - fixed - true - - - - Gauge3 - 270 - 150 - 100 - 20 - rudderval - 132 - +1.0 - -1.0 - 100.0 - 50 - 0 - 0 - 2.0 - gauge - false - false - true - true - true - false - false - false - 0.0 - true - fixed - true - - - - Gauge4 - 15 - 165 - 20 - 150 - throttleval - 134 - 1.0 - 0.0 - 100.0 - 50 - 0 - 0 - 1.0 - gauge - true - true - false - false - false - false - true - false - 0.0 - true - fixed - true - - - - Gauge5 - 172 - 190 - 10 - 100 - elevatortrimval - 134 - -100.0 - +1.0 - -1.0 - 50 - 0 - 0 - 2.0 - 0.0 - gauge - true - true - false - false - false - false - false - false - true - fixed - true - - - - - diff --git a/Huds/Instruments/Default/hudladder.xml b/Huds/Instruments/Default/hudladder.xml deleted file mode 100644 index ca96a9b70..000000000 --- a/Huds/Instruments/Default/hudladder.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - Pitch Ladder - 260 - 150 - 120 - 180 - 2.68 - roll - pitch - 45.0 - 10.0 - 70 - 0 - false - true - false - false - false - false - false - false - 0.0 - false - false - true - - - - - diff --git a/Huds/Instruments/Default/instrlabel.xml b/Huds/Instruments/Default/instrlabel.xml deleted file mode 100644 index af2a47cbf..000000000 --- a/Huds/Instruments/Default/instrlabel.xml +++ /dev/null @@ -1,45 +0,0 @@ - - - - - - latitude - 110 - 430 - 1 - 10 - latitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - true - true - false - - - - longitude - 530 - 430 - 1 - 10 - longitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - true - false - true - - - - - diff --git a/Huds/Instruments/Default/runwayinstr.xml b/Huds/Instruments/Default/runwayinstr.xml deleted file mode 100644 index fc474c8dc..000000000 --- a/Huds/Instruments/Default/runwayinstr.xml +++ /dev/null @@ -1,19 +0,0 @@ - - - - Runway Hud - 0 - 0 - 480 - 360 - true - 5 - 5.0 - false - 1.0 - 50.0 - -1 - 64250 - - - diff --git a/Huds/Instruments/Engineering/fgtbi.xml b/Huds/Instruments/Engineering/fgtbi.xml deleted file mode 100644 index 522a76217..000000000 --- a/Huds/Instruments/Engineering/fgtbi.xml +++ /dev/null @@ -1,21 +0,0 @@ - - - - - - fgTBI_Instrument - 290 - 45 - 60 - 10 - roll - sideslip - 45.0 - 5.0 - 5 - true - - - - - diff --git a/Huds/Instruments/Engineering/hudcard.xml b/Huds/Instruments/Engineering/hudcard.xml deleted file mode 100644 index 7cd2402aa..000000000 --- a/Huds/Instruments/Engineering/hudcard.xml +++ /dev/null @@ -1,247 +0,0 @@ - - - - - - Gyrocompass - 220 - 430 - 200 - 28 - heading - 4 - 360.0 - 0.0 - 1.0 - 5 - 1 - 360 - 25.0 - tape - false - false - true - true - true - false - false - false - 0.0 - true - fixed - true - - - - AMSL - 565 - 140 - 35 - 200 - altitude - 6 - 5000.0 - -1000.0 - 1.0 - 100 - 25 - 0 - 250.0 - tape - true - true - false - false - false - false - true - false - 0.0 - true - fixed - true - - - - RadioAltimeter - 438 - 165 - 25 - 150 - agl - 6 - 1000.0 - 0.0 - 1.0 - 25 - 5 - 0 - 200.0 - tape - true - true - false - false - false - false - true - false - 0.0 - true - fixed - true - - - - KIAS - 40 - 140 - 28 - 200 - speed - 10 - 200.0 - 0.0 - 1.0 - 10 - 5 - 0 - 50.0 - tape - true - true - false - false - false - false - false - true - 0.0 - true - fixed - true - - - - Gauge1 - 270 - 310 - 100 - 20 - aileronval - 88 - +1.0 - -1.0 - 100.0 - 50 - 0 - 0 - 2.0 - gauge - false - false - true - true - false - true - false - false - 0.0 - true - fixed - true - - - - Gauge2 - 182 - 190 - 20 - 100 - elevatorval - 90 - +1.0 - -1.0 - -100.0 - 50 - 0 - 0 - 2.0 - gauge - true - true - false - false - false - false - false - true - 0.0 - true - fixed - true - - - - Gauge3 - 270 - 150 - 100 - 20 - rudderval - 84 - +1.0 - -1.0 - 100.0 - 50 - 0 - 0 - 2.0 - gauge - false - false - true - true - true - false - false - false - 0.0 - true - fixed - true - - - - Gauge4 - 15 - 165 - 20 - 150 - throttleval - 86 - 1.0 - 0.0 - 100.0 - 50 - 0 - 0 - 1.0 - gauge - true - true - false - false - false - false - true - false - 0.0 - true - fixed - true - - - - - diff --git a/Huds/Instruments/Engineering/hudladder.xml b/Huds/Instruments/Engineering/hudladder.xml deleted file mode 100644 index ca96a9b70..000000000 --- a/Huds/Instruments/Engineering/hudladder.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - Pitch Ladder - 260 - 150 - 120 - 180 - 2.68 - roll - pitch - 45.0 - 10.0 - 70 - 0 - false - true - false - false - false - false - false - false - 0.0 - false - false - true - - - - - diff --git a/Huds/Instruments/Engineering/instrlabel.xml b/Huds/Instruments/Engineering/instrlabel.xml deleted file mode 100644 index e53139378..000000000 --- a/Huds/Instruments/Engineering/instrlabel.xml +++ /dev/null @@ -1,140 +0,0 @@ - - - - - - machno - 25 - 130 - 40 - 30 - mach - %4.2f - blank - NULL - 1.0 - 4 - 2 - 0 - true - false - false - - - - lattitude - 110 - 430 - 1 - 10 - latitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - true - true - false - - - - longitude - 530 - 430 - 1 - 10 - longitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - true - false - true - - - - alpha - 530 - 70 - 1 - 10 - aoa - %4.1f% - alpha: - blank - 1.0 - 4 - 0 - 0 - true - false - false - - - - beta - 530 - 55 - 1 - 10 - sideslip - %4.1f% - beta: - blank - 1.0 - 4 - 0 - 0 - true - false - false - - - - nlf - 530 - 40 - 1 - 10 - nlf - %4.1f% - nlf: - blank - 1.0 - 4 - 0 - 0 - true - false - false - - - - framerate - 530 - 25 - 1 - 10 - framerate - %5.1f% - framerate: - blank - 1.0 - 4 - 0 - 0 - true - false - false - - - - - diff --git a/Huds/Instruments/Minimal/fgtbi.xml b/Huds/Instruments/Minimal/fgtbi.xml deleted file mode 100644 index a309996c7..000000000 --- a/Huds/Instruments/Minimal/fgtbi.xml +++ /dev/null @@ -1,21 +0,0 @@ - - - - - - fgTBI_Instrument - 290 - 55 - 60 - 10 - roll - sideslip - 45.0 - 5.0 - 5 - true - - - - - diff --git a/Huds/Instruments/Minimal/gload.xml b/Huds/Instruments/Minimal/gload.xml deleted file mode 100644 index 6e17dd705..000000000 --- a/Huds/Instruments/Minimal/gload.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - - - - G Load - 11 - 294 - 40 - 30 - anzg - %4.2f - NULL - g - 1.0 - 4 - 0 - 0 - true - false - false - - - - - diff --git a/Huds/Instruments/Minimal/hudcard.xml b/Huds/Instruments/Minimal/hudcard.xml deleted file mode 100644 index 8b076b733..000000000 --- a/Huds/Instruments/Minimal/hudcard.xml +++ /dev/null @@ -1,189 +0,0 @@ - - - - - - Gyrocompass - 220 - 430 - 200 - 28 - view_direction - 4 - 360.0 - 0.0 - 1.0 - 5 - 1 - 360 - 25.0 - tape - false - false - true - true - true - false - false - false - 0.0 - true - fixed - line - variable - true - - - - Gauge1 - 270 - 390 - 100 - 20 - aileronval - 136 - +1.0 - -1.0 - 100.0 - 50 - 0 - 0 - 2.0 - gauge - false - false - true - true - false - true - false - false - 0.0 - true - fixed - true - - - - Gauge2 - 20 - 190 - 20 - 100 - elevatorval - 138 - -100.0 - +1.0 - -1.0 - 50 - 0 - 0 - 2.0 - gauge - true - true - false - false - false - false - false - true - 0.0 - true - fixed - true - - - - Gauge3 - 270 - 25 - 100 - 20 - rudderval - 132 - 100.0 - +1.0 - -1.0 - 50 - 0 - 0 - 2.0 - 0.0 - gauge - false - false - true - true - true - false - false - false - true - fixed - true - - - - Gauge4 - 600 - 160 - 20 - 160 - throttleval - 134 - 100.0 - 1.0 - 0.0 - 50 - 0 - 0 - 1.0 - 0.0 - gauge - true - true - false - false - false - false - true - false - true - fixed - true - - - - Gauge5 - 10 - 190 - 10 - 100 - elevatortrimval - 134 - -100.0 - +1.0 - -1.0 - 50 - 0 - 0 - 2.0 - 0.0 - gauge - true - true - false - false - false - false - false - false - true - fixed - true - - - - - diff --git a/Huds/Instruments/Minimal/hudladder.xml b/Huds/Instruments/Minimal/hudladder.xml deleted file mode 100644 index d92c9db20..000000000 --- a/Huds/Instruments/Minimal/hudladder.xml +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - artificialhorizon - 260 - 150 - 120 - 180 - 2.68 - roll - pitch - 45.0 - 0.0 - 0.0 - 70 - 0 - false - true - false - false - false - false - false - false - 0.0 - false - false - true - - - - - diff --git a/Huds/Instruments/Minimal/instrlabel.xml b/Huds/Instruments/Minimal/instrlabel.xml deleted file mode 100644 index a25e07f30..000000000 --- a/Huds/Instruments/Minimal/instrlabel.xml +++ /dev/null @@ -1,160 +0,0 @@ - - - - - - Label1 - 40 - 25 - 60 - 10 - framerate - %7.1f - Frame rate = - NULL - 1.0 - 4 - 0 - 0 - true - - - - Label2 - 40 - 40 - 90 - 10 - fov - %7.1f - FOV = - NULL - 1.0 - 4 - 0 - 0 - true - - - - Label3 - 480 - 70 - 60 - 10 - aoa - %7.2f - AOA = - Deg - 1.0 - 4 - 0 - 0 - true - - - - Label4 - 480 - 55 - 40 - 30 - speed - %5.0f - Airspeed - Kts - 1.0 - 4 - 0 - 0 - true - - - - Label5 - 480 - 40 - 40 - 10 - altitude - %5.0f - Altitude - units - 1.0 - 4 - 0 - 0 - true - - - - Label6 - 480 - 25 - 40 - 10 - agl - %5.0f - Elevation - units - 1.0 - 4 - 0 - 0 - true - - - - Label7 - 480 - 10 - 60 - 10 - heading - %5.1f - Heading - Deg - 1.0 - 4 - 0 - 0 - true - - - - lattitude - 110 - 430 - 0 - latitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - true - true - - - - longitude - 530 - 430 - 1 - longitude - %s% - blank - blank - 1.0 - 4 - 1 - 0 - true - true - - - - - diff --git a/Huds/Minimal/default.xml b/Huds/Minimal/default.xml deleted file mode 100644 index 95d2de920..000000000 --- a/Huds/Minimal/default.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - - Minimal Aircraft Hud - - - - - Huds/Instruments/Minimal/hudladder.xml - - - - Huds/Instruments/Minimal/hudcard.xml - - - - Huds/Instruments/Minimal/instrlabel.xml - - - - Huds/Instruments/Minimal/fgtbi.xml - - - - Huds/Instruments/Minimal/gload.xml - - - - - diff --git a/Huds/Sets/autopilot.xml b/Huds/Sets/autopilot.xml index 512262d98..4be2ba32b 100644 --- a/Huds/Sets/autopilot.xml +++ b/Huds/Sets/autopilot.xml @@ -4,10 +4,26 @@ + + + - - - - - - - - - - - - - - - - - - - - - - - -