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.
