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.
---------------------------------------------------------------------------
There is also support for transmitting messages over MP which allows models to communicate with each other in a decoupled method using notifications. What happens is that bridged messags simply arrive at the Receive method of recipients in other models on other running instances without the need to do anything special.
This links together the generic MFD and the NavDisplay; it allows a fairly easy method to add a Map page to an MFD device.
----------------------
See: http://wiki.flightgear.org/Canvas_MFD_Framework
----------------------
Instantiate parameters:
1. pfd_device (instance of PFD_Device)
2. instrument display ident (e.g. mfd-map, or mfd-map-left mfd-map-right for multiple displays) - used to map to the property tree
3. layer_id: main layer in the SVG
4. nd_group_ident : group (usually within the main layer) to place the NavDisplay
5. [optional] switches - used to connect the property tree to the nav display. see the canvas nav display.
To add a canvas nav display page simply do
me.some_page = PFD_NavDisplay.new(me.PFD,"Situation", "mpcd-sit", "ID", "jtids_main");
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.
