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.
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.)
Features:
- Various configurable styles.
- Working scroll bars, thanks to Tom
- Adequate REPL-ness.
See the wiki for more information!
http://wiki.flightgear.org/Interactive_Nasal_Console
N.B. This makes some (sane) changes to other Nasal files, including
expanding some of the Canvas API.
Add benchmark_time, rank, and print_rank. Modify benchmark to return/
pass-through the values of the function, appending to a vector if there
are multiple executions.
- Calculate bounding box after adding all children.
- Apply rotation after all SVG defined rotations to use correct
center of rotation (as defined in Inkscape)
This (together with the SimGear and FlightGear commits) fixes
the core problems of #1333.
Implement traffic in MapStructure and use it. Various other hacks and/or
cleanup. Feedback required on whether this is a lot better than before.
Also partially revert 9c018d94c4d88dad7476ec250fa3b52024526f4b to add
feature to geo.PositionedSearch: it me._equals is overridden then the
old mechanism is used instead of the new C++ function, so that the
custom equality can be used. (In particular for the Fixes with the
TrafficModel class).
Make fdm listener single-fire, don't listen to /sim/signals/reinit. This
allows the Canvas to stay with the same placement through reinit, after
both the 777 and 747 were having problems. I don't see any reason for
having to recreate it all, and the cleanup function is still there (e.g.
for independent windows, to have their .del() call the ND's .del()).
renamed handle_reinit() -> del()
This also makes sure the /canvas/by-index/canvas[3/4]/ nodes are removed
and then recrated, as well as making sure the MapStructure del() path is
followed and working. Unfortunately the NDs are still blank after reinit.
The old API is not used with newer versions of FG. If an old
version of FG is used, also the according version of fgdata
should be used, which also includes the correct API wrappers.
In time for 3.0. The API is still not fully complete, and not fully
cleaned up, but this is good enough for this release cycle (and it
should offer benefit longer term, if not now -- hopefully performance as
well).
Many thanks to Hooray as well, who has helped prepare things while I
could not, and often suggested ideas.
