Emesary: Difference between revisions

Jump to navigation Jump to search
5 bytes removed ,  18 April 2020
+lead section: Moving up the intro section and removing the heading, bolding the page title and rearranging the paragraphs. Also moving up another paragraph. I should not have to skim through half the article to figure out what it is about.
No edit summary
(+lead section: Moving up the intro section and removing the heading, bolding the page title and rearranging the paragraphs. Also moving up another paragraph. I should not have to skim through half the article to figure out what it is about.)
Line 3: Line 3:
[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
{{Nasal Navigation}}
{{Nasal Navigation}}
'''Emesary''' is a simple and efficient class based interobject communication 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.
There are many possible applications for Emesary within the system. It solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].
At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary. http://chateau-logic.com/content/emesary-nasal-implementation-flightgear Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear (documentation is possibly slightly out of date for the most recent developments that are in my fgdata) Richard Harrison has got the transmission of properties working ; using a new notification type.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35894463/
  |title  =  <nowiki> [Flightgear-devel] Emesary / Multiplayer improvements </nowiki>
  |author =  <nowiki> Richard Harrison </nowiki>
  |date  =  Jun 14th, 2017
  |added  =  Jun 14th, 2017
  |script_version = 0.40
  }}</ref>
Richard has finished porting his Emesary system to [[Nasal]] and it's now part of the base package.
There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).
This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/
Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered ontop of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34985731/
  | title  = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
  | author = <nowiki>Richard Harrison</nowiki>
  | date  = Apr 1st, 2016
  | added  = Apr 1st, 2016
  | script_version = 0.25
  }}
</ref>
<references/>


== Status ==
== Status ==
Line 15: Line 47:


Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.
Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.
At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary. http://chateau-logic.com/content/emesary-nasal-implementation-flightgear Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear (documentation is possibly slightly out of date for the most recent developments that are in my fgdata) Richard Harrison has got the transmission of properties working ; using a new notification type.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35894463/
  |title  =  <nowiki> [Flightgear-devel] Emesary / Multiplayer improvements </nowiki>
  |author =  <nowiki> Richard Harrison </nowiki>
  |date  =  Jun 14th, 2017
  |added  =  Jun 14th, 2017
  |script_version = 0.40
  }}</ref>




Line 174: Line 197:


We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>
We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>
<references/>
== Intro ==
Richard has finished porting his Emesary system to [[Nasal]] and it's now part of the base package.
There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).
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.
This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/
There are many possible applications for Emesary within the system, it solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].
Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered ontop of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34985731/
  | title  = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
  | author = <nowiki>Richard Harrison</nowiki>
  | date  = Apr 1st, 2016
  | added  = Apr 1st, 2016
  | script_version = 0.25
  }}
</ref>


<references/>
<references/>

Navigation menu