Manage updates when a value has changed more than a predetermined amount. This makes updating displays (e.g. canvas), or performing actions based on a property (or value in a hash) changing by more than the preset amount.
The primary goal of this work is to provide a alternative to multiplayer property transmission, one that is more efficient and event driven. By using notifications in the model bindings these control messages can be bridged and do not require extra code to implement dual controls.
Using this alternative permits the modeller much greater control of which properties are transmitted, how these are encoded, and how often the updates are needed.
Please remember that this is a use case for Emesary, it is not all that Emesary can provide and there are still many other uses for the event driven object oriented system that Emesary provides.
Briefly the changes are:
- New PropertySyncNotificationBase to permit property transfer between ownship and MP versions using notifications instead of the pre-defined MP messages. This gives a much more flexible way to seutp multiplayer property transfer - and can probably support more properties because of the more efficient packing. There is a corresponding parameter (/sim/multiplay/transmit-only-generics) that will only transmit the bare minimum of parameters; making more space for notifications.
- new AircraftControlNotification to allow for animation bindings in the model, these notifications can be easily bridged over MP thus adding a simple method to implement dual controls.
- more efficient packing of encoded notifications over MP saving roughly 30% (by using a much larger encoding space and also changing to use fixed length encoding). This breaks compatibility with previous MP bridges, however at this time I don't think anything is using the current code.
There can be different types of PropertySyncNotification (with unique ID's) sent at a different schedule (so you could have a 10 second update of very slow moving items). However bear in mind that the messages have a lifetime of 10 seconds to ensure receipt - so to optimise space would require > 15 seconds to make much difference, and that is very slow moving.
<message> tags can now contain sprintf() format
strings (%d, %.2f etc), with
<message-param>
<property>/some/prop</property>
</message-param>
used as the substitute value. Could be extended
in the future with perhaps Nasal evaluation?
Don't use the built-in SVG/rect parser, since this bypasses creating
coordinate / command properties which some Canvas users rely upon.
This reverts commit 57a2d21ddf.
- properly referencing the canvas namespace, so that the ND module can be separately included via io.include()
- moving the initialization of aircraft specific SVG elements into the navdisplay.styles file, and the corresponding Boeing/Airbus entries there (see initialize_elements())
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.
