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.
At the suggestion of Gilberto AGOSTINHO, add
button bindings for throttle, mixture and prop
to the joystick configuration dialog.
Specific use-case is users of game-pads, but also
useful to users with a single throttle axis on their
joystick.
- make t/T action press and hold, with some acceleration factor and
clamping to a maximum rate. (Avoids confusing latching-mode of
previous system(
- show the local time of day while adjusting.
Values are based on some experimentation, feedback welcome on the
mailing list.
- Since joystick.PropertyScaleAxis instances have a 'prop' attribute
indicating the property name, it seems logical to have
joystick.PropertyScaleAxis.parse() set this attribute based on the
property name in its argument ('p').
- This commit also tries to improve readability by using a 'bindingNode'
variable instead of repeatedly calling 'p.getNode("binding", 1)'.
- Commit 5bcf58c7d6 forgot to set the
'inverted' attribute when there was no 'factor' node in the argument's
'binding' node. Fix this.
- Also copy the argument's 'factor' value to the 'factor' instance
attribute for consistency, since joystick.PropertyScaleAxis instances
have such an attribute initialized in the constructor.
As far as I can tell, the dead-band setting belongs to <axis> nodes, not
to <binding> nodes using property-scale. This can be seen in
do_property_scale()'s definition (flightgear/src/Main/fg_commands.cxx)
as well as in fgdata/Docs/README.Joystick.html.
joystick.PropertyScaleAxis creates <dead-band> nodes as children of
<binding> nodes in generated joystick binding files under
$FG_HOME/Input/Joysticks which, AFAICT, are completely useless and thus
confusing. The <dead-band> nodes should be created at a different level
to be effective (cf. FGJoystickInput::postinit() in
flightgear/src/Input/FGJoystickInput.cxx).
This commit removes the 'deadband' attribute from
joystick.PropertyScaleAxis, since it has nothing to do there IMHO.
As can be seen in do_property_scale()'s definition in
flightgear/src/Main/fg_commands.cxx, property-scale rightfully uses a
default factor of 1.0. However, if a joystick axis' property-scale
binding has no 'factor' node defined, and one opens the joystick
configuration dialog, then PropertyScaleAxis.parse() creates an empty
'factor' node that implicitely gets a value of 0. This method is called
by joystick.readConfig() when the joystick-config dialog is opened. This
has the effect of rendering the corresponding joystick axis inoperant.
How to reproduce the bug:
- take a joystick such as the SAITEK CYBORG 3D USB, with its default
binding file from
fgdata/Input/Joysticks/Saitek/Cyborg-Gold-3d-USB.xml (this file uses
property-scale for the aileron, with no explicitely defined factor);
- start FlightGear; move the joystick left or right while looking at
the plane wings -> the ailerons move, it works fine;
- now, open the joystick-config dialog and do the same test -> the
ailerons don't move anymore and the 'Aileron' value at the bottom of
the dialog stays at 0 (0.0 or -0.0...). Just opening the dialog to
test the joystick has "corrupted" its setup! This is very confusing
for users.
This fix corrects the problem by avoiding the apparently unneeded
creation of an empty 'factor' node when there is none inside the
<binding>. An alternative would be to create a 'factor' node with value
1.0. In any case, if someone later expands the joystick-config dialog to
allow modification of property-scale's factor, he should make sure to
use a default value of 1.0!
I created a substantial quantity of new work in the New Regional
Textures project and I would like to ask if anyone could review and
perhaps commit them into FGDATA. The modifications are:
- New textures and material definitions for California
- New textures and material definitions for Mexico
- New material definitions for Central America
- New textures and material definitions for Southern Europe
(Mediterranean region: Portugal, Spain, south of Italy, Greece, coast of
Balkans)
- New airport grass texture (global)
- New airport grass texture for Latin America
- New American town texture (global)
- Small improvement to grass blade textures (to better fit the airport
grass texture)
If this will be committed, we must add a note thanking the United States
Geological Survey (USGS) for the satellite images of California (
http://www.usgs.gov/ ) to the Thanks file.
Add generic version of a canvas MFD (based on the F-15)
It has a fairly simple class structure and hopefully is reasonably easy to understand; Thorsten's using it on the Shuttle and Hooray mentioned that it'd be a good idea to make it generic. It provides a device, that has pages and a set of buttons. The set of buttons control the page that is selected (i.e. a menu). Each page has its own set of menus. A menu defines a label and a page that is displayed. I intend to document it on the wiki once its added.
This is merge request #20
MP Patch first step fgdata part: nasal to check wich planes we are
displaying in the futur, with a distance check , one plane each frame.
I was playing with the target tracking and decided to fix an old bug that causes it to behave wrong at higher altitudes.
Background: the script continuously updates values in the autopilot to follow specified target aircraft (AI/MP). It is controlled directly through the property tree under /autopilot/target-tracking.
Issue: the script reads out true airspeed, but autopilot expects indicated airspeed. This is why at higher altitudes, the tracking always overshoots.
I fixed this by introducing an estimate on indicated airspeed of the target, using the ratio between local aircraft true and indicated airspeed.
I also fixed an issue where it ignored minimum speed setting and polished initialization by using props.globals.initNode() instead of dedicated presence check for every property (and also ensured the nodes have correct types, no more bool stored as double). And the last thing I changed was to increase the default tracking distance to a more sane value, with the original value of 0.05nm the tracking was unstable in heading with most aircraft and started oscillating.
With the changes I applied, the distance is now holding precisely at any altitude and with any winds.
Current GUI allows selected mis-matched STAR and approach. Low risk
fix is to detect and deal with this case by just routing direct. Real
fix involves a slicker GUI or inserting a route discontinuity (possible
in FG 3.6 hopefully)
-fix a severe bug which led to unintended hitch releases;
-include the new JSBSim external force location variables;
-improvements for function closeHitch
- 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.
The reason it didn't work for me is that
/sim/rendering/camera-group/camera/viewport/ does not seem to contain
the actual dimensions of the view window... which is odd. Instead I'll
use /sim/startup/[xy]size (and make it into a method so I don't have to
change 3 lines next time :). Now that it works (again), it looks so much
better. Thanks to Alexis Bory for the original idea.
Only show max 50 aircraft by default and provide a "Show More"
button. This prevents locking the GUI for up to nearly 15 seconds
with showing the list of all aircraft.
Rewrite the way scrolling for ScrollAreas is handled: Store
content position instead of scrollbar positions to keep position
on resize and promote moving the content instead of the contents
to as primary API.
Let the mousewheel scroll by fixed content offset instead of
scrollbar offset to make it actually usable (especially with
low scrolling distance).
- Increase default size.
- Run parse_markdown on description to remove multi
whitespace, possible present in catalog.xml and
also support simple, one-level bullet point lists.
- Needs FlightGear compiled with -DENABLE_PACKAGE_SYSTEM.
- Shows only first 100 available aircrafts.
- Now progress indication on install/remove (need to reopen
dialog afterwards)
- 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.
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 simple assert() function is added to the globals namespace.
- io.include() marks the target namespace to avoid dependency loops.
If the namespace is marked before the script to be included is
compiled, a parse error leaves the target namespace marked while
the script has not been loaded. This patch fixes this problem.
Fix the main bugs, add features and convert most of the layers.
Move/refactor some things as well. Add a canvas map dialog next to the
built-in one -- it's not 100% functional but it's quite close actually.
As before, the excitement has been taking place at our team clone.
https://gitorious.org/fg/canvas-hackers-fgdata/commits/0b4cc84
(topics/canvas-map-dialog branch this time, current HEAD in above URL.)
