This is the initial commit for a reworked environment controller.
The main intention is to decouple the individual modules like
metar fetch, metar properties, environment interpolation etc.
to make it easier for other weather module developers to modify
environment settings.
As a side effect, the dialogs for weather-scenario, weather-conditions,
clouds and precipitations have been merged into a single dialog
The new A/P implementation does not contain the hardcoded "helper" functions
anymore. The properties created in these helpers are now generated by
autopilot components defined in generic-autopilot-helper.xml which is
included by default in preferences.xml
If /sim/menubar/autovisibility/enabled is true, show the menubar when the mouse hits the upper edge of the window and hide the menubar on click outside a pui element.
Incorporated changes to effects file syntax. Changed Till's landmass
to mix in the base terrain texture. Some shader cleanup.
Also, add a GUI control for enabling shaders.
can lead to extreme performance reduction in a relatively short time.)
Let's set the default mode to "off".
Users can turn on the various components of this features according to
their own preferences and those preferences are then autosaved.
- Removes the cloud type re-use code - I think they aren't worth the graphical artefacts that they cause in light of Tim's improvements
- Changes the transparency of the clouds. Previously, the clouds were transparent at 0m distance, opaque at 200m, then gradually more transparent to the fog limits. This meant they were generally quite transparent. Now, they are opaque from 200m to 15km, then become transparent at 20km. A side effect of this is that the current textures could probably benefit from being made slightly transparent to improve the blending of the sprites against each other.
- Replaces simple shader attributes with vectors (this was missed out of the last patch by mistake)
- Includes Yon's Fog update code (Thanks!)
- Fixes a bug since 1.0 where --enable-real-weather-fetch stopped the other weather scenarios from working.
This provides the following enhancements & bug fixes
- Fix the chequer-board bug.
- Add proper cloud coverage function - so scattered clouds are now truly scattered.
- Add real-time control for visibility range.
- Use a limited set of clouds rather than generating a completely new Geode for each cloud. This saves sorting and display time.
- Add controls to Rendering dialog to allow fine-tuning of the number of sprites, cloud visibility and the number of different types of cloud.
- Add some variance to the sort back-off to avoid all clouds being sorted at the same time.
- Pack attributes into vectors for performance
- Re-order the cloud type determination code so that if a cloud layer could either be stratus or cumulus, cumulus is used.
- Lowered the cloud level in the standard cloud configuration slightly so a cumulus layer is generated rather than stratus.
These last two mean that you should see some 3D cumuli if disabling real weather fetch.
My thanks to Yon Uriarte for his help with performance work.
(/sim/rendering/precipitation-gui-enabled) *and* if the aircraft wants it
(/sim/rendering/precipitation-aircraft-enabled). Some aircraft model rain
on the windshield and want to turn rain off for interior views.
- new parameter naming (left/right instead of min/max; signs are ignored)
- fix wrap-around skips
- use regular constructor so as not to confuse people ;-)
If a <view> contains a <limits> block, then a view handler gets attached to
it, which limits head turns to a given range, whereby headings beyond a given
threshold cause an additional sideways movement. This is turned off by default
for now.
distracting blury when viewed from nearly edge on (as runway textures almost always are.) This can be adjusted to individual preferences with the
--texture-filter={0,1,2,4,8,16} command line option.
- Update redout level every frame
- Replace reading of properties every iteration with listeners
- move -onset and -complete properties into a parameters subtree
are set in controls.nas since ages)
controls.nas: avoid repeated querying of /sim/input/selected/engine[*]
properties; this isn't supposed to change at runtime and is a rather
costly process, especially in axis handlers
- Disable the 737 AI demo (because it uses the user 737-300, which is
currently not part of the base package).
- New version number
- Add some more 747 size parking areas at KSFO.
These are then skipped with view.stepView(n), unless the second, optional
argument is set to 1: view.stepView(n, 1);
Whether a view is enabled or not, is saved in $FG_ROOT/.fgfs/autosave.xml
(system views) or $FG_ROOT/.fgfs/aircraft-data/<aircraft>.xml
- allow turning on/off extra widgets for developers (HUD dialog: colors,
rendering dialog: visualization of shadow edges), and to turn on/off new
- property key handler ('/'-key)
Both features are off by default, and their state is saved to autosave.xml.
/sim/current-view/dynamic-view. There are additionally <dynamic-view>
settings per view, but those only enable it for that view if it's
globally turned on.
populated are: KHAF, KHWD, KOAK, KSJC, and KSFO. Includes traffic for
two to three major US based airlines for each aircraft type. Traffic
is included for the 737, 747, 767, A320, A333, and an assorted selection
of smaller aircraft.
are. /sim/view[0] .. /sim/view[99] are reserved for the system, the rest
can be used by aircraft. That way nobody has to update all configs only
because a generic view was added.
us3_mbrola doesn't lack some phonemes, causing interrupted messages
- use us2_mbrola for the pilot (seems to be rather complete, too;
pity that the female voice us1_mbrola sounds so ugly :-)
by debug.nas to turn on/off syntax coloring for dumped data (which
is desirable as compound data types can fill several screens with
rather hard to read data). Unfortunately, it can't be reliably deduced
from the OS whether ANSI colors are available or not.
- move "multiplayer chat" properties to where they belong
preferences.xml gui/menubar.xml gui/dialogs/rendering.xml
Added Files:
Nasal/multiplayer.nas gui/dialogs/chat.xml
gui/dialogs/chat_full.xml:
the data part of Stuarts multiplayer/chat patch
many as you like, but not at runtime. Some aircraft may especially want to
change the first ("day") color, as the predefined green is IMHO a bit dark
and should possibly be more white-ish.
correctly to an existing Boeing 737 (the new 737-300). Also updated
the aircraft_demo.xml to reflect this change. Added an initial version of
a logical ground network file for KSFO airport.
aircraft *-set.xml files. Otherwise someone could offer an aircraft
for download that sets the host to one of their machines and lets a
nasal script write arbitrary information there. (Not that we had a lot
of sensible information. Yet.)
switch-position=1, so let's set it here for all others. This shouldn't be
done in aircraft *-set.xml files (unless there's a *very* good reason),
because this overwrites the settings that were made by the --dme option,
and thus breaks it.
mf:
- some minor modifications to Stuart's version :-)
- select all engines per default. This may seem less realistic (who starts
all engines on the b29 at once?), but it'll prevent oodles of bug reports.
And those who want it realistic shouldn't rely on engine 1 being selected
by default, anyway, but rather actively select every single engine.
Also: this new behavior is in line with the original intentions (see cvs
log to preferences.xml -r1.51)
Limit the maximum time we spent in the simulation loops.
That means, if the /sim/max-simtime-per-frame value is strictly positive
you can limit the maximum amount of time you will do simulations for
one frame to display. The cpu time spent in simulations code is roughtly
at least O(real_delta_time_sec). If this is (due to running debug
builds or valgrind or something different blowing up execution times)
larger than the real time you will no more get any response
from flightgear. This limits that effect. Just set to property from
your .fgfsrc or commandline ...
local changes. People are used to modifying this file, and seem helpless
without it. Further explanations will be added to README.Joystick.html.
The dummy entry is necessary because EasyXML aborts without at least one
entry, and segfaults without <PropertyList> entry.
