specify the same texture in the "foo.lighted" and "foo.unlighted" material
entry. This also allows to drop the state cloning and thereby solves the
most urgent apt_signs.cxx TODO. :-)
exactly how the material lib was designed for. Better would be selectable
sub-states within one material. But as long as only the signs need it, I'd
say we can live with that.
I got a new joystick, a Speedlink Black Hawk (USB) with force feedback for
which I have written a setup xml file (see attachment) since with the default
setup, the rudder control didn't work.
Perhaps you could include it in the next version of Flightgear, such that
other users with the same joystick could immediately use it. The xml file
contains a description of the axis/button setup and should be self-explanatory.
I am using Windows XP but I guess the configuration should at least work on
all Windows platforms, no idea whether it works under Linux.
It would be great if one could get the vibration function to work (for
touchdown, running over uneven ground, plane stalling and the like) but I
frankly don't know how to do it. Has anybody already implemented force feedback?
Let me stress that Flightgear is a great sim and that I really enjoy it a lot!
You all are doing a great job!
- if the selected model is the sign placeholder (Aircraft/ufo/Models/sign.ac;
first entry in the m-key dialog), then the export writes an OBJECT_SIGN
entry with the legend as contents (rather than the path).
Note that the input field for legend/comment is invisible if it doesn't
contain any text. You find it if you click right over the status line
entry in the lower left corner. Usability bug by design. :-)
(The dialog can also be dragged to another place.)
load the export file directly into fgfs via --config option:
--config=$HOME/.fgfs/ufo-model-export.xml (An fgfs wrapper could add
this option automatically if the file exists. Mine does. :-)
- import all /models/model[n] objects into the UFO's model manager, so
that they become editable
Both features together allow to save an UFO object session and to continue
it next time.
Y ... black on yellow -> direction, destination, boundary
R ... white on red -> mandatory instruction
L ... yellow on black with frame -> runway/taxiway location
B ... white on black -> runway distance remaining
<close> block, remove autopilot helper file autopilot.nas and (re)implement
its functionality in autopilot.xml
- make AP dialog "bidirectional" and "live": all input fields are <live>
(i.e. they are updated as the autopilot settings are changed, for example
by panel actions or property browser changes)
- dialog input is only forwarded to the AP; no direct checkbox/radiobutton
handling through widget operation, instead:
- changes to the AP properties operate checkboxes/radiobuttons
This makes the AP dialog always reflect the AP state. If the AP refuses
one setting and sets it back to something else, then the dialog will
immediately react and show the actual setting.
