- Fix: runtime exception in remove_failure_mode()
- Fix: keep failure & trigger status on teleport.
- Fix: allow random failures from the gui to be enabled/disabled multiple times.
- Fix: mcbf/mtbf are set to zero when they fire, so they can be reactivated from the gui.
- Fix: string casts of several trigger types had syntax errors.
- Usability: screen messages related to failures now use positive logic:
"condition 100%" instead of "failure level 0%"
- Performance: Time triggers now use internal timers, instead of requiring being polled.
- Reviewed Trigger interface for more rational usage. reset() is replaced by arm()/disarm()
- Added a subscription interface to listen to FailureMgr events.
- Added an internal log buffer to keep a record of relevant events and present them to gui elements.
- Several usability improvements to the FailureMgr Nasal API.
- Making run_tests accept a target namespace as an argument.
- Fixed asynchronous trigger callback mechanism.
MCBF triggers working again.
- Fixed numerical problems when calculating standard deviation
for rand triggers.
Includes a simple automated testing framework for Nasal
(Aircraft/Generic/Systems/Tests/test.nas) and a collection of unit tests
for the failure manager, mostly for the different triggers.
Replaces existing Nasal/failures.nas script with a programmable failure
manager. The failure manager allows dynammic creation and removal of
failure modes, on demand activation and a flexible set of triggers.
The public interface can be found in Nasal/FailureMgr/public.nas
Aircraft/Generic/Systems/failures.nas provides a library of triggers and
failure actuators ready to use for programming the failure manager.
A compatibility layer is included under
Aircraft/Generic/Systems/compat_failure_modes.nas.
This compatibility layer is currently loaded on startup and programs the
FailureMgr to emulate the former behavior (same set of failure modes and
compatible interface through the property tree).
This first milestone is only intended to replace the failure management
engine underneeth with minimum visible changes, and hopefully no aircraft
breakages. Future milestones will build upon this to add a Canvas based
procedural GUI and example integration on aircrafts.
A Nasal library for implementing instruments that are specific for soaring.
This version supports:
+ Total Energy compensated variometers
+ Netto variometers
+ Relative (aka Super-Netto) variometers
+ Configurable dampener for simulating mechanical needles
+ Averager
+ Speed to fly computer
+ Speed Command variometer
+ Yaw string (it's an instrument, isn't it?)
Effects/model-combined.eff fix techniques numbering. Make active under rembrandt too. add model-combined-deferred as a stub for now for specific
Rembrandt use.
Users of model-combined with normalmaps should change the technique number to 9, and duplicate that entry for technique 8.
Fix some longstanding png warnings. Provide null_reflectdir.png for model-combined
This should fix part of bug #726
Signed-off-by: Emilian Huminiuc <emilianh@gmail.com>
Provide templates for various aircraft components or complete aircraft
types. Better to have this stuff available/adaptable than hard-coded
somewhere inside fgfs.
doesn't need to do this on the fly. OpenGL requires that texture dimensions
be a power of 2 (32, 64, 128, 256, 512, 1024, 2048, etc.) so if we feed in
something else, OSG will rescale it on the fly before registering it as an
OpenGL texture.
- Added support for additional manager objects, e.g.
for animating a 3d model or move a JSBSim pointmass.
- Improved the documentation.
- Some bugs removed.
They are not perfect as the Equipement is not good enough, but though they works quite good!
RealLife-images, Images made in FGFS and Custom-Gimp-made.
Signed-off-by: Heiko Schulz aka HHS <Heiko.H.Schulz@gmx.net>
The new A/P implementation does not contain the hardcoded "helper" functions
anymore. The properties created in these helpers are now generated by
autopilot components defined in generic-autopilot-helper.xml which is
included by default in preferences.xml
Currently, there are some hard coded autopilot helpers.
They can (and should) easily be modeled in an external XML file.
The filter in this file produce the exact same output as the hard coded
filters.
This is just a preparation step for a smooth transition at a later time.
