but as this is an integral part of FlightGear, I don't want to push for it.
Try out and comment. It's available under "Debug/Property Browser". Note,
that this isn't the slow pure-Nasal implementation, but a regular dialog
using a c++ based widget. Only the handling is done in Nasal, so there should
really be not performance degradation compared with the old dialog.
Easter Eggs: some entries work differently when the Control-key is pressed:
"." -> toggle output of SGPropertyNode flags
".." -> go to root (not just one dir level)
bool entry -> toggle bool entry value
has to be given before a --wp or --flight-plan option to work.)
- let the "Remove" button remove the first entry by default, not the last.
(Note that you can remove any entry if you selected it in the list first.
Likewise you can insert a new waypoint at any position by selecting the
respective entry.)
<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.
not only more consistent, but also makes the autopilot dialog act more like
the real device). Add a few rules. Move the checkboxes to the left, as it's
usually done in GUIs for switches that enable/disable a group of widgets.
leave edit field!, press <Return> to execute; as an example try
screen.log.write("hello world"), or f16.canopy.open() in the F16,
or bo105.doors[3].move(0.3) in the Bo105 etc.
- gui.nas: use 4-space indents like the rest of the file; waste slightly less
cycles: checking for the property shouldn't be done in a loop at
all, it only serves as a temporary solution
overwritten by C++ code before displaying. These are written in
upper case letters, but this is only a hint for editors of this
file and doesn't impress ATCDialog.cxx.
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.
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.)
I have made the
'Select Airport from List' option in FlightGear work
(I think) properly. I have some concerns about the
solution, which could be broken by changes to plib (if
they re-use the value I have assigned to
PUCLASS_LIST), but for the moment it seems to work OK.
Erik Hofman:
A request has been sent to John Fay to include the puList
code in the puAux subdirectory of plib so expect some
changes for future version of FlightGear.
Although this doesn't work anywhere but on my machine ... OK/Cancel
is completely out of place for this dialog. This has to be Apply/Close
or something.
I've finished the emigration of the radiostack, and I've also removed it
completely. It turned out that the comm radio is completely implemented in
the ATC subsystem. I've changed the affected ATC files to point
to /instrumentation/com, but I guess that the maintainer of the ATC code
should decide wether to make it configureable, and how.
I also had to change some files in Network and Main. The changes in network
should be obvious, but the changes in Main were a bit suspect. The files
included radiostack.hxx, but they weren't directly depending on
radiostack-hxx. They were depending on other files that were included by
radiostack.hxx. I got it to compile, but I'm not sure if I included the
correct directly depending file.
For the data directory I changed every occurrence of /radios/
with /instrumentation/ with this simple one-liner that I found on the net:
find -name '*.xml' -type f | xargs perl -pi -e
's/\/radios\//\/instrumentation\//g'
Instead of me sending all the files that got changed by this I suggest that
you execute the one-liner yourself. Of course I can not guarantee that this
will work perfectly, but I considered hand editing to be not an option (I'm
lazy). I don't want to test every aircraft to see if everything still works,
I think it's better to wait and see if anyone complaints about broken nav
radios/instruments.
