Emesary: Difference between revisions

'''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.  

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

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

That's all that is required to ship properties between multiplayer modules via emesary. There is a limit of 128 bytes on a string which limits the amount of outgoing messages. Outgoing notifications are queued and transmitted as space permits. The way the bridge works is to publish the notification, encoded into an MP string, for a period of time to allow for lagging clients and network issues. If a notification IsDistinct then the bridge will transfer just the last message received; otherwise the bridge will transfer all received notifications over MP, to allow for In this sense IsDistinct indicates that the contents of the notification are accurate and definitive (e.g. surface position), so the last value is the most accurate. Other notification (e.g. button 12 pushed will always need to be transferred). Obviously using this technique a variable number of properties can be transmitted, and importantly it's up to the modeller to decide what to transmit. There is a flag that I've temporarily added (sim/multiplay/transmit-only-generics) that doesn't transmit the standard properties, just chat and the generics (to make more space in the packet). There can be different types of notifications sent at a different schedule (so you could have a 10 second update of very slow moving items).<ref>{{cite web

What Richard Harrison is working on now is how to make (possibly multiple) slaves communicate back to a master craft, initially the F-14 backseat. The design goal is that the same code should work for both the master and the slave, and that there should not need to be any extra logic. At the highest level this would be (master craft): 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The model receives the notification and the appropriate property is changed. 3. The property changed will be sent over Emesary to all slaves. Slaves will not transmit this data back to the master as there is no outgoing bridge configured to do this. For the slave aircraft 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The notification is bridged over MP and received by the master craft.<ref>{{cite web

ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also  be used for scenery to player or  MP to MP illumination, and Richard is toying with the idea of using the emesary MP bridge for the job.<ref>{{cite web

any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web

It's now part of the base package and available automatically

Richard has now got the Emesary multiplayer bridge working ref: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear <ref> {{cite web

Richard's emesary framework would be ideal for this sort of thing. The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it.<ref>{{cite web