Change fonts; make use of the new feature to allow fonts to be specified using property from dialog xml.
Ensure that all fonts are defined within the style.
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())
