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.
This adds a TACAN instrument to the inventory. Range and bearing are calculated
to the TACAN or VORTAC beacon selected by means of the Channel Selector in the E
quipment/Radio pull-down menu.
A TACAN beacon has also been added to the aircraft carrier Nimitz (channel #029Y
).
Changes
=======
- shadowvolume.cxx, renderer.cxx :
- reduced the polygon offset a bit to eliminate some artifact ;
- changed again the cleanup code for objects inside a tile because it could crash on rare occasion ;
- the culling of shadow casters has been rewritten to traverse the scene graph, it should be
a bit faster when there is a lot of objects ;
- the range selector was not correctly handled, sometimes the wrong LOD was casting shadows.
- added the option to display aircraft's transparent objects after the shadows, this will
reduce the problem of shadows being hidden by the transparent object (propeller disk,
rotor, etc). A side effect is that aircraft's transparent objects won't receive shadows
anymore. This is usually a good thing except when the aircraft use a 'transparent'
texture where it should not. A transparent texture in the plib context is a texture
with an alpha channel or a material with alpha <= 0.99.
- model.cxx, animation.cxx, shadowvolume.cxx :
- added an optional <condition> under the <noshadow> animation
- tower.cxx
- correct a rare bug where all occurences of the aircraft are not deleted from the
departure list causing a crash in FGTower::CheckDepartureList function.
Changes
=======
New volumetric shadows for FlightGear.
There is now two new checkboxes in the rendering dialog to enable/disable shadows
for the user aircraft and for static scenery objects (ie those defined in the .stg files).
AI and random objects are not handled for the moment.
known bugs
==========
- ghost objects
This is another update for the cloud code, a lot of lines but this time I have started to add the doxygen doc.
Misc
====
- corrected a bug when RTT is not available, the current rendering context was
altered
- if RTT is not available then 3d clouds are not drawn at all
- impostors lighting is now recomputed when the sun changes position
- distant objects are no more seen in front of clouds
- blending of distant clouds is a bit better now
- litle optimization of code (uses a less cpu time)
- use layer wind speed and direction (no more hardcoded wind)
- fov is no more hardcoded
Changes
=======
- clouds (cu only) are dissipating/reforming (experimental)
- compute a turbulence factor that depends on surrounding clouds and type of
clouds (experimental)
- clouds shapes are defined in cloudlayers.xml
- type of clouds present in a layer is also defined in cloudlayers.xml
- cloud layers are generated from metar and other misc. data (in progress)
- added a rain effect around the viewer (enabled in the rendering dialog and
when the metar property says so)
- added a lightning effect (enabled in the rendering dialog) : cb clouds spawn
new lightnings
- added a dialog to select from different weather source : metar/property,
a 'fair weather' environment and a 'thunderstorm' environment.
There are two <dme> entries in preferences.xml, resulting in two dme branches
under /instrumentation/ (dme[0] and dme[1]). The serviceable property is only
set for the second entry (dme[1]), and that one is not connected to the dme
module. Solution: Remove the first <dme> entry, and set the index explicitly
to 0 for the remaining <dme> entry.
