I was going through the Ai scenarios and see that some of them are not
necessary.
Also, I've added some documentation to the other scenarios. And I moved the
thunderstorm over San Francisco, so you don't have to take off to see it.
The files are attached.
they want the feature or not, based on what they see. Having to click on
"Apply" every time is cumbersome.
- show the slider values
- remove the now obsolete buttons (KISS)
- added "my" title bar, albeit without close button (I was *very* tempted :-)
- new and updated sources for the new volumetric clouds
- 2 new textures for the clouds
- an update to the render dialog to enable/disable and change a few parameters
for the new clouds
Implement simple help system with global and aircraft specific dialogs:
The gui.nas changes have been discussed with Andy. All ac have a help dialog,
but some are empty. (This wouldn't have been necessary, as the system falls
back to the "Common Aircraft Keys" if an aircraft has no help defined, but an
empty dialog is less confusing and encourages to be filled with interesting
information. :-) I scanned all aircraft files for interesting performance
data and added some to the dialogs (stall speed, etc.) The Concorde and the
p51d have (over?)complete dialogs and can serve as examples. The format is
documented in $FG_ROOT/Nasa/gui.nas.
There is also a couple of other, minor fixes.
The following files have ugly MSDOS line endings:
$FG_ROOT/Aircraft/Hunter/hunter{-2tanks,}-set.xml
$FG_ROOT/Aircraft/A380/A380-set.xml
The Concorde-jsbsim.nas file is a useless copy of the real */nas file, which is
in Nasal/. I'was debugging the Concorde and wondered why changes to this file
had no effect ...
(Fixed Concorde in the help-ac.diff patch: don't use "interpol" keyword as
variable.)
Implement simple help system with global and aircraft specific dialogs:
The gui.nas changes have been discussed with Andy. All ac have a help dialog,
but some are empty. (This wouldn't have been necessary, as the system falls
back to the "Common Aircraft Keys" if an aircraft has no help defined, but an
empty dialog is less confusing and encourages to be filled with interesting
information. :-) I scanned all aircraft files for interesting performance
data and added some to the dialogs (stall speed, etc.) The Concorde and the
p51d have (over?)complete dialogs and can serve as examples. The format is
documented in $FG_ROOT/Nasa/gui.nas.
There is also a couple of other, minor fixes.
The following files have ugly MSDOS line endings:
$FG_ROOT/Aircraft/Hunter/hunter{-2tanks,}-set.xml
$FG_ROOT/Aircraft/A380/A380-set.xml
The Concorde-jsbsim.nas file is a useless copy of the real */nas file, which is
in Nasal/. I'was debugging the Concorde and wondered why changes to this file
had no effect ...
(Fixed Concorde in the help-ac.diff patch: don't use "interpol" keyword as
variable.)
The one hat axis should be 4 for Unix/Linux and 6 for windows (according
to someone on IRC), while the other hat axis is apparently 7 for all
systems. Changed the throttle to Nasal, too.
I didn't nasalify the rest, because that's error-prone and I wouldn't
be able to test it.
- lights are by default off (what was I thinking?!?)
- setters return "me" reference by default, for easier code obfuscation:
foo = aircraft.light.new("/foo").prop().switch(1); :-)
- a few mebmers renamed; light.set() -> light.switch(); nodes are named *N
to avoid collisions and to show relations (switch() <-> switchN)
- yet more (too much?) documentation
- light class added (for lights and other pulsing/blinking objects)
- fixed and improved documentation
- all property args may be path strings or nodes
- existing nodes aren't overwritten any more
- better naming of class vars (for outside access)
Tested with the bo105 (which I fully ported to use aircraft.nas) and
the fokker70 (which are the only aircraft using the new classes :-)
Re-organisation: <diffuse>, <ambient>, <emission>, <specular> are
now groups with members <red>, <green>, <blue>, <factor>, <offset>,
and their <*-prop> forms. Additionally, there's an option <property-base>
that can be used to set a path that is prepended to all <*-prop> paths.
It defaults to an empty string. Rationale: see model-howto.html.
Changes:
o new skids (yet again)
o sun shield for the panel
o beautified exhausts
o new door handling:
"d" ... toggle selected door (default: pilot door)
"D" ... select next door (indicated with popup)
"Ctrl-d" ... remove selected door if opened (all bo105 doors can easily
get removed in RL; it is even flown without doors!)
o dropped shadow boxes (once necessary workaround for the disappearing
shadow problem, and the reason why the bo105 was so tiny in fgrun)
o automatically selects the emblem of the national Red Cross/Red Crescent
society on startup
o 5 variants, that can be switched at runtime, with different emblems,
colors(!), and extra equipment:
"c" ... switch to next variant
"C" ... pop-up material dialog, as a demonstration of the new
"material" animation, well ... and for entertainment
purposes :-)
The bo105 was and is a testbed for the "material" animation. It uses one to
change a texture at runtime. This has the advantage, that only the currently
selected texture uses up memory (unlike the textranslate method), and it
saves a lot of disk space because it doesn't duplicate all textures (unlike
the current <texture-path> method. You can change the texture in the browser:
http://localhost:5501/sim/model/bo105/material/emblem/texture
(choose one of: emblems/{red-cross,red-crescent-[lr],star-of-life}.rgb
(the built-in property browser doesn't grok it, because I used quite long
path names. Needs to be fixed in the GUI.)
I suggest to add the material.nas file to the global Nasal/ dir, not only
because the bo105 update expects it. The Nasal module creates a dialog for
material editing, which is quite useful for development purposes, for gaining
better understanding of the OpenGL color properties, and finally: it's fun.
http://members.aon.at/mfranz/material.jpg [45 kB]
The dialog needs to be initialized with a property dir where material
redirects are placed. It isn't available from the menu, but may be useful
for other aircraft. Also, it's quite small and doesn't get in the way.
If people want it removed, I can still move its contents into bo105.nas.
The bo keyboard binding says:
material.showDialog("/sim/model/bo105/material/fuselage/", "Bo105");
This is documented on top of the *.nas file.
here is the promised material animation. It looks a bit longish, but that
wasn't avoidable -- there are simply too many parameters to consider. I tried
hard, though, to make the animation fast by only doing the necessary stuff.
It doesn't affect the frame rate here with my test model. The animation is
heavily based on Jim's "material-emission" animation.
* implementation of the "material" animation (this required to make the
texture path available) + documentation update ($FG_ROOT/Docs/)
* fix some more return values (texture animations, and select) for the
shadow problem (and some in anticipation of other problems :-)
* fix compiler warning
I have done some cleanup where I moved some values out of classes where they
do not belong and such stuff.
Also the fols offsets are now named in the carrier xml file with a more
verbose name (flols-pos/offset-*) than before (only offset-*).
There is a little preparation for definitions of parking positions on the
carrier which should later be used for starting flightgear directly on the
I attach the long-promised improved version of the USS Nimitz.
It includes an improved version of the FLOLS, which requires the attached
diff to be applied to AICarrier.cxx and AICArrier.hxx.
I've made lots of eye-candy in the form or the flightdeck crew.
Unfortunately, it about doubles the size of the tarball. I'll send it to you
later; when I've figured out some way of only loading on request (any advice
would be very welcome).
I could provide a \u2018bare\u2019 version to cut down on the vertex count for
less capable systems however, the count isn\u2019t huge in the first place.
I've cut the textures down as far as I can without losing definition.
