derived from: https://github.com/Zaretto/Emesary/tree/master/src/Emesary/EmesaryC++
This is a similar implementation to that in Nasal; currently this is only for use in C++ modules as there is no Nasal interface - however this is something that may be added later.
The basic premise of the Emesary messaging system is to allow the decoupled operation of the various components that comprise any system - usually within the same process.
The basic unit of communication is a Notification, which is passed around to any and or all objects that implement the IReceive interface (pure virtual class). Using Interfaces and ihneritance
it is possible to pass around Notifications that have special meanings to certain objects and allow them to perform the appropriate function.
Notifications are created and sent via a call to NotifyAll. Any object within the system can inherit from IReceive and register itself with a Transmitter to receive all notifications that are sent out.
The underlying concept is that one part of a system knows that something needs to be done without needing to know how to do it. The part of the system that needs something done simply creates a notification and sends it out. Once received by the part of the system that is capable of performing the requested Notification the relevant actions will be carried out and a status of OK or Finished returned.
The return code from the Receive method must follow the guidlines as follows:
If a notification is not recognised in the recipient must return ReceiptStatusNotProcessed. Normally a recipient will return ReceiptStatusOK, sometimes ReceiptStatusFail to indicate that the recipient could not properly process the notification.
The overall result of a call to NotifyAll is a composite of the results of each individual recipient's return value; and generally OK or Fail. It is acceptable to use the return code to ascertain success or failure and take appropriate action.
It is generally recommended that more detail specific to the particular purpose be included within the Notification to allow more control.
Notifications can be modified during processing to permit a multistage process; however this needs to be designed correctly.
* ReceiptStatusOK : Notification processed fine by Receive, transmitter continues with next recipient
* ReceiptStatusFail : Notification processed but failed, transmitter continues with next recipient
* ReceiptStatusAbort : Notification processed and the receive method declares a fatal error; the transmitter will stop notifying recipients
* ReceiptStatusFinished : Notification processed and the recipient declares that the processing is completed, the transmitter will stop notifying recipients
* ReceiptStatusNotProcessed : receive method does not recognise the notification
These status are for later implmentation.
* ReceiptStatusPending : (future ues); notification been sent but the return status cannot be determined as it has been queued for later processing, transmitter continues with next recipient
* ReceiptStatusPendingFinished : Message has been definitively handled but the return value cannot be determined. the transmitter will stop notifying recipients
- change to always use the SG create mipmap function as it works better (no purple clouds)
- when enabled always generate a mipmap even if the file couldn't be compressed
- adjust level of log messages
- move lru_cache into its own header file.
The following changes fixes a case for me where I hear the sound change levels up and down for each pause un-pause cycle.
Patch provided by daniel.c.wickstrom@gmail.com.
Effect schemes are a way of rendering an object in different ways depending on the Compositor pipeline. A new <scheme> tag in the Compositor pipeline definition allows the user to choose which Effect scheme is going to be used for that pass. Every Effect will then be rendered using the technique that has a matching scheme name. If no valid technique is found, it won't be rendered. Since it would be a pain to define a valid technique for every scheme and for every Effect, the file '$FG_ROOT/Effects/schemes.xml' is introduced:
<scheme>
<name>test</name>
<fallback>Effects/test</fallback>
</scheme>
If an Effect doesn't have a valid technique for the 'test' scheme, the 'Effects/test.eff' Effect will be merged with it. This process is done at initialization when techniques are being realized.
Previously, these two files were only added when SG was built with
-DUSE_AEONWAVE:BOOL=OFF, because the SG code in use when USE_AEONWAVE is
set to ON doesn't need readwav.hxx nor readwav.cxx. However, readwav.hxx
and readwav.cxx are not only used in SG, but also in FG (at least by
flightgear/src/Sound/VoiceSynthesizer.cxx), and this was causing a build
failure when SG's USE_AEONWAVE and FG's ENABLE_FLITE flags were both set
to ON:
https://forum.flightgear.org/viewtopic.php?f=45&t=35672#p346633
and
https://sourceforge.net/p/flightgear/mailman/message/36645567/
This commit should fix this build failure.
- remove the old svn properties; a scan of FGAddon and FGdata showed these are not in use except for the dialog
- new property "active" - which is true when the worker thread is running.
- changes to enabled now take effect immediately; whereas before a reinit had to be issued. This could lead to confusing GUI state as the enabled property would be true but without closing the dialog (e.g. cancelling it) terrasync could be in a different state.
- use property nodes (performance optimisation)
Extend the command API to allow posting commands from arbitrary threads,
for deferred execution on the main thread. Additional pieces on the FG
side to follow shortly.
changed to use const char* rather than const std::string & as this doesn't work on GCC; and besides std::string converts nicely to const char* and most of the times this is used it is actually a string literal.
Set the filename back to what it was after loading - seems sensible and as yet no side effects.
Also the previous commit that included the handling of sgio_exceptions also broke the DDS-TC pretty much completely.
