Emesary is a simple and efficient class based interobject communcation system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.
Emesary is all about decoupling and removing dependecies, and improving the structure of code. Using Emesary you can more easily define the what rather than the how. By using what is essential an event driven system it is easy to add or remove modules, and also for extra modules to be inserted that the rest of the aircraft knows nothing about (e.g. FGCamera or the Walker).
see: http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
The AN/SPN-46 is an ACLS implementation using Emesary. ACLS is the Navy's version of ILS.
- Small update to the main hydrodynamics system.
- Added initial versions of two systems for modelling hydrodynamic planing.
Signed-off-by: Anders Gidenstam <anders@gidenstam.org>
- 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.