Here are files to get automated contrails working. I've set up contrails for
the 737, using my simple, untextured contrail model. Vivian has made another
contrail model, but I'm still trying to get his to work. I'm hoping others
will try to make contrail models also.
Here's some code that defines a top to thermals. When the top of a thermal is
reached the strength is phased-out linearly over the next 100 feet of
altitude. At first I tried just capping the thermal at the top, but the
change in thermal strength was too fast for the FDM to handle well.
Included is a new version of the thermal scenario that includes a top
(height-msl) to the thermal. The default value is 5000 feet.
on the ground) -- this is based on some wild guesses, but it seems
reasonable for now.
The next step will be to give the compass some angular momentum so
that it does not snap instantly to a heading, and so that it can
overshoot a heading and oscillate.
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-status={level} --show-aircraft
whereas "level" can be anything between
"alpha","beta","early-production" and "production"
Of course running something like
fgfs --min-status=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required
<status></status>
tag - but you can easily give it a try by adding something like
<status>alpha</status>
The tag should be placed as a sub-tag within <sim> - so directly behind
the <description> tag would be just fine and straight-forward.
As a result of recent requests, I've implemented the ability to switch off
aerodynamic stabilisation:
This has to be added to the submodel.xml files:
<aero-stabilised>false</aero-stabilised>
When false the submodel retains the pitch given at instantiation.
It defaults to true.
I've made an encoder and a transponder. The transponder gets C-Mode altitude
information from the encoder. These two might not be very usefull right now,
but I think they might come in handy when the ATC network gets going.
input.cxx allocates memory for js->getNumAxes() axes and for jsCaps.wNumButtons
or MAX_JOYSTICK_BUTTONS buttons per joystick. But it doesn't check if some
xml config defines bindings for more axes/buttons, in which case it writes
to unallocated memory and causes crashes. This is a real world example:
sidewinder-force-feed-pro.xml defines 7 axes, but only newer versions of
this js do actually have that many. Older ones (-> gameport) don't. The patch
drops unused and unusable bindings.
I've added two new debug log types for the instrumentation and systems. They
used to use the autopilot debug log, because I couldn't figure out how to
make new log types. Well, now I have figured it out. ;-)
This will modify menubar.cxx/hxx so that it exports the
entire menubar (from menubar.xml) to the property tree, so that it can
now be changed dynamically using Nasal's setprop() instruction and
afterwards running a newly added fgcommand to update the menubar
based on those changes using the appropriate menubar path within
the property tree.
By default the menubar from menubar.xml will be stored within:
/sim/menubar/default
Erik:
I have moved the loading of menubar.xml into preferences.xml and
made sure that the menubar is destroyed every time a new menubar
is created.
I think I found the problem in props.hxx. I have an exception when copying properties. An alias to a property that has no value trigger this exception. The code that generate that is in AIManager.cxx :
void FGAIAircraft::bind() {
FGAIBase::bind();
props->tie("controls/gear/gear-down",
SGRawValueMethods<FGAIAircraft,bool>(*this,
&FGAIAircraft::_getGearDown));
props->getNode("controls/lighting/landing-lights", true)
->alias("controls/gear/gear-down");
}
controls/gear/gear-down has no value ( _type == NONE ) and controls/lighting/landing-lights is copied somewhere.
Erik:
Frederic's fix was to change props.hxx but he has expressed his doubts.
For now I've commented out the line that causes the problem so we have more
time to look deeper into the problem.
cvs -z4 -q diff -u props.hxx (in directory I:\FlightGear\cvs\SimGear\simgear\props\)
Index: props.hxx
===================================================================
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/props/props.hxx,v
retrieving revision 1.4
diff -u -r1.4 props.hxx
--- props.hxx 19 Sep 2004 09:08:12 -0000 1.4
+++ props.hxx 21 Oct 2004 07:10:54 -0000
@@ -622,7 +622,7 @@
/**
* Test whether this node contains a primitive leaf value.
*/
- bool hasValue () const { return (_type != NONE); }
+ bool hasValue () const { return (_type != ALIAS && _type != NONE) || (_type == ALIAS && _value.alias->_type != NONE); }
/**
Don't overwrite user settings from config files.
fgfs had in any case set bump-mapping to false, no matter if this
node did already exist (because it was defined in a config file).
compilation without ENABLE_SP_FMDS defined gave me a lot of link errors. It appeared that symbol used by ADA was still in use in the HUD.
There is also a typo from Curt in instrument_mgr.cxx where he #include "kr_87.cxx" instead of "kr_87.hxx"
This is a patch to make display list usage optional. They are on by default.
Use --prop:/sim/rendering/use-display-list=false to use immediate mode.
There is also a change in exception handling in main.cxx and bootstrap.cxx
This is a patch to make display list usage optional. They are on by default.
Use --prop:/sim/rendering/use-display-list=false to use immediate mode.
There is also a change in exception handling in main.cxx and bootstrap.cxx
Instrumentation and systems are now configureable from xml files. The two
generic configurations generic-systems.xml and generic-instrumentation.xml
configures the systems and instrumentation as it was hardcoded. You can
override the generic configurations in a similar way as you override the
autopilot configuration.
I've added some digital filters to the autopilot. They are all low-pass
filters that filter away high frequency signals/noise. There are 4 different
filters:
1. Exponential - The algorithm is essentially the same as the one used in the
fgGetLowPass() function.
2. Double exponential - Two exponential filters in series. This filter has a
"steeper" frequency response curve. It filters "better" than the single
exponential.
3. Moving average - Averages a number of inputs.
4. Noise spike - limits the amount that the output value can change from one
sample to the next.
Filters 1 and 2 are characterised by it's filter-time in seconds. For filter 3
you have to set the number of input samples to average over. For filter 4 you
set the maximum allowed rate of change as [1/s]. Since the sampling interval
(dt) isn't constant we have to calculate the maximum allowed change for every
update.
Example of a double exponential filter with filter time 0.1 seconds, that is
1/0.1 = 10 Hz.
<filter>
<name>pressure-rate-filter</name>
<debug>true</debug>
<type>double-exponential</type>
<input>/autopilot/internal/pressure-rate</input>
<output>/autopilot/internal/filtered-pressure-rate</output>
<filter-time>0.1</filter-time>
</filter>
This would go in the autopilot configuration file.
I've also removed the filtering of the "pressure-rate" helper value, use the
new filters if you want to filter it! ;-)
