fly/fgdata
1
0
Fork 0
Code Activity
fgdata/Nasal/emesary.nas

715 lines
26 KiB
Text
Raw Normal View History

Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
#---------------------------------------------------------------------------
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
#
# Title : EMESARY inter-object communication
#
# File Type : Implementation File
#
# Description : Provides generic inter-object communication. For an object to receive a message it
# : must first register with an instance of a Transmitter, and provide a Receive method
#
# : To send a message use a Transmitter with an object. That's all there is to it.
#
# References : http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
# : http://www.chateau-logic.com/content/class-based-inter-object-communication
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
# : http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
# : http://chateau-logic.com/content/c-wpf-application-plumbing-using-emesary
#
# Author : Richard Harrison (richard@zaretto.com)
#
# Creation Date : 29 January 2016
#
# Version : 4.8
#
Emesary: Improve error messages
2020-12-17 22:42:42 +00:00
# Copyright 2016 Richard Harrison Released under GPL V2
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
#
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
#---------------------------------------------------------------------------
# Classes in this file:
# Transmitter
# Notification
# Recipient
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
#---------------------------------------------------------------------------*/
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
var __emesaryUniqueId = 14; # 0-15 are reserved, this way the global transmitter will be 15.
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# add registry so we can find a transmitter by name in genericEmesaryGlobalTransmitterTransmit
move globals.Hash to std.Hash Add std.nas to loadpriority.xml and update related files
2020-07-01 12:46:47 +00:00
var _transmitters = std.Hash.new({}, "transmitters");
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
var _registerTransmitter = func (key, t) {
_transmitters.set(key, t);
}
var getTransmitter = func (key) {
return _transmitters.get(key);
}
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
# Transmitters send notifications to all recipients that are registered.
var Transmitter =
{
ReceiptStatus_OK : 0, # Processing completed successfully
ReceiptStatus_Fail : 1, # Processing resulted in at least one failure
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
ReceiptStatus_Abort : 2, # Fatal error, stop processing any further recipients of this message. Implicitly failed.
ReceiptStatus_Finished : 3, # Definitive completion - do not send message to any further recipients
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
ReceiptStatus_NotProcessed : 4,# Return value when method doesn't process a message.
ReceiptStatus_Pending : 5, # Message sent with indeterminate return status as processing underway
ReceiptStatus_PendingFinished : 6,# Message definitively handled, status indeterminate. The message will not be sent any further
# create a new transmitter. shouldn't need many of these
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# _ident: string; name of the transmitter, used in debug messages
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
new: func(_ident)
{
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
if (!isscalar(_ident)) {
logprint(LOG_ALERT, "Transmitter.new: argument must be a scalar!")
}
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
__emesaryUniqueId += 1;
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
var new_class = {
parents : [Transmitter],
Recipients : [],
Ident : _ident,
Timestamp : nil,
MaxMilliseconds : 1,
UniqueId: __emesaryUniqueId,
};
_registerTransmitter(_ident, new_class);
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
return new_class;
},
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
OverrunDetection: func(max_ms=0){
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
if (isnum(max_ms) and max_ms) {
if (me.Timestamp == nil)
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
me.Timestamp = maketimestamp();
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
me.MaxMilliseconds = max_ms;
logprint(LOG_INFO, "Set overrun detection ",me.Ident, " to ", me.MaxMilliseconds);
return 1;
} else {
# me.Timestamp = nil;
me.MaxMilliseconds = 0;
logprint(LOG_INFO, "Disable overrun detection ",me.Ident);
return 0;
}
},
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
# Add a recipient to receive notifications from this transmitter
Register: func (recipient)
{
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# not inheriting from Recipient is maybe strange but will not crash
if (!isa(recipient, Recipient))
{
logprint(LOG_INFO, "Transmitter.Register: argument is not a Recipient object");
}
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
# Warn if recipient doesn't have a Receive function - this is not an error because
#a receive function could be added after the recipient has been registered - so it is
# deprecated to do this.
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
if (!isfunc(recipient["Receive"]))
{
logprint(DEV_ALERT, "Transmitter.Register: Error, argument has no Receive method!");
}
foreach (var r; me.Recipients)
{
if (r == recipient) {
Emesary: Improve error messages
2020-12-17 22:42:42 +00:00
logprint(DEV_ALERT, "Transmitter.Register: Recipient already registered: " ~ r.Ident ~ " (" ~ r.UniqueId ~")");
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
return 1;
}
}
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
append(me.Recipients, recipient);
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
return 1;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
},
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
Emesary: add new method and tidy up diagnostics.
2018-07-27 22:33:38 +00:00
DeleteAllRecipients: func
{
me.Recipients = [];
},
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
# Stops a recipient from receiving notifications from this transmitter.
DeRegister: func(todelete_recipient)
{
var out_idx = 0;
var element_deleted = 0;
for (var idx = 0; idx < size(me.Recipients); idx += 1)
{
if (me.Recipients[idx] != todelete_recipient)
{
me.Recipients[out_idx] = me.Recipients[idx];
out_idx = out_idx + 1;
}
else
element_deleted = 1;
}
if (element_deleted)
pop(me.Recipients);
},
RecipientCount: func
{
return size(me.Recipients);
},
PrintRecipients: func
{
Remove debug and tidy up messages
2016-05-16 20:06:48 +00:00
print("Emesary: Recipient list for ",me.Ident,"(",me.UniqueId,")");
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
for (var idx = 0; idx < size(me.Recipients); idx += 1)
Remove debug and tidy up messages
2016-05-16 20:06:48 +00:00
print("Emesary: Recipient[",idx,"] ",me.Recipients[idx].Ident," (",me.Recipients[idx].UniqueId,")");
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
},
# Notify all registered recipients. Stop when receipt status of abort or finished are received.
# The receipt status from this method will be
# - OK > message handled
# - Fail > message not handled. A status of Abort from a recipient will result in our status
# being fail as Abort means that the message was not and cannot be handled, and
# allows for usages such as access controls.
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# message: hash; Notification passed to the Receive() method of registered recipients
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
NotifyAll: func(message)
{
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
if (!isa(message, Notification))
{
logprint(DEV_ALERT, "Transmitter.NotifyAll: argument must be a Notification!");
Emesary: add new method and tidy up diagnostics.
2018-07-27 22:33:38 +00:00
return Transmitter.ReceiptStatus_NotProcessed;
}
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
me._return_status = Transmitter.ReceiptStatus_NotProcessed;
me.TimeTaken = 0;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
foreach (var recipient; me.Recipients)
{
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
if (recipient.RecipientActive)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
me._rstat = nil;
if (me.MaxMilliseconds > 0 and me.Timestamp != nil)
me.Timestamp.stamp();
message.Timestamp = me.Timestamp;
call(func {me._rstat = recipient.Receive(message);},nil,nil,nil,var err = []);
Emesary; handle fatal errors during a recipient receive. - the recipient will be removed from the transmitter and appropriate error messages printed. Contributed by Nikolai V. Chr.
2018-11-07 00:53:06 +00:00
if (size(err)){
foreach(var line; err) {
print(line);
}
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
logprint(LOG_ALERT, "Recipient ",recipient.Ident,
" has been removed from transmitter (", me.Ident,
") because of the above error");
Emesary; handle fatal errors during a recipient receive. - the recipient will be removed from the transmitter and appropriate error messages printed. Contributed by Nikolai V. Chr.
2018-11-07 00:53:06 +00:00
me.DeRegister(recipient);
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
#need to break the foreach due to having modified what its iterating over.
return Transmitter.ReceiptStatus_Abort;
Emesary; handle fatal errors during a recipient receive. - the recipient will be removed from the transmitter and appropriate error messages printed. Contributed by Nikolai V. Chr.
2018-11-07 00:53:06 +00:00
}
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
if (me.Timestamp != nil) {
recipient.TimeTaken = me.Timestamp.elapsedUSec()/1000.0;
me.TimeTaken += recipient.TimeTaken;
}
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
if(me._rstat == Transmitter.ReceiptStatus_Fail)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
me._return_status = Transmitter.ReceiptStatus_Fail;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
}
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
elsif(me._rstat == Transmitter.ReceiptStatus_Pending)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
me._return_status = Transmitter.ReceiptStatus_Pending;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
}
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
elsif(me._rstat == Transmitter.ReceiptStatus_PendingFinished)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
return me._rstat;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
}
# elsif(rstat == Transmitter.ReceiptStatus_NotProcessed)
# {
# ;
# }
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
elsif(me._rstat == Transmitter.ReceiptStatus_OK)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
if (me._return_status == Transmitter.ReceiptStatus_NotProcessed)
me._return_status = me._rstat;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
}
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
elsif(me._rstat == Transmitter.ReceiptStatus_Abort)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# this is a final results, e.g. no more recipients will be
# notified but the result is returned as NotifyAll result.
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
return Transmitter.ReceiptStatus_Abort;
}
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
elsif(me._rstat == Transmitter.ReceiptStatus_Finished)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# this is a final results, e.g. no more recipients will be
# notified but the result is returned as NotifyAll result.
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
return Transmitter.ReceiptStatus_OK;
}
}
}
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
if (me.MaxMilliseconds and me.TimeTaken > me.MaxMilliseconds) {
logprint(LOG_WARN, sprintf("Overrun: %s ['%s'] %1.2fms max (%d)",
me.Ident, message.NotificationType, me.TimeTaken, me.MaxMilliseconds));
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
foreach (var recipient; me.Recipients) {
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
if (recipient.TimeTaken) {
logprint(LOG_WARN, sprintf(" -- Recipient %25s %7.2f ms",
recipient.Ident, recipient.TimeTaken));
}
Emesary: added optional overrun detection - This will alert if any individual notifcation takes more than a certain amount of time to process. Works well with the Emesary M_exec to identify where the slow parts of Nasal are.
2019-06-08 08:52:08 +00:00
}
}
return me._return_status;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
},
# Returns true if a return value from NotifyAll is to be considered a failure.
IsFailed: func(receiptStatus)
{
# Failed is either Fail or Abort.
# NotProcessed isn't a failure because it hasn't been processed.
if (receiptStatus == Transmitter.ReceiptStatus_Fail or receiptStatus == Transmitter.ReceiptStatus_Abort)
return 1;
return 0;
}
};
Added queued transmitter. This is a normal transmitter than doesn't act synchronously and instead queues messages for future processing. Can be useful to implement thread safe receive/transmit logic where a sub thread is requiring property changes that can be sent to a queued transmitter that is then processed in the main thread.
2020-06-05 09:12:30 +00:00
var QueuedTransmitter =
{
new: func(_ident){
var new_class = { parents:[QueuedTransmitter], base:emesary.Transmitter};
new_class = emesary.Transmitter.new(_ident);
new_class.baseNotifyAll = new_class.NotifyAll;
new_class.Q = [];
new_class.NotifyAll = func(message){
append(me.Q, message);
return emesary.Transmitter.ReceiptStatus_Pending;
};
new_class.Process = func {
foreach (var m ; me.Q)
me.baseNotifyAll(m);
me.Q = [];
return emesary.Transmitter.ReceiptStatus_PendingFinished;
};
new_class.size = func {
return size(me.Q);
}
return new_class;
}
};
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
#---------------------------------------------------------------------------
# Notification - base class
# By convention a Notification has a type and a value. Derived classes can add
# extra properties or methods.
#
# NotificationType: Notification Type
# Ident: Can be an ident, or for simple messages a value that needs transmitting.
# IsDistinct: non zero if this message supercedes previous messages of this type.
# Distinct messages are usually sent often and self contained
# (i.e. no relative state changes such as toggle value)
# Messages that indicate an event (such as after a pilot action)
# will usually be non-distinct. So an example would be gear/up down
# or ATC acknowledgements that all need to be transmitted
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
# The IsDistinct is important for any messages that are bridged over MP as
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# only the most recently sent distinct message will be transmitted over MP.
# Example:
# position update, where only current position is relevant -> IsDistinct=1;
# 0 = queue all messages for MP bridging
# 1 = queue only latest message (replace any old message of same type+ident)
#
var TypeIdUnspecified = 1;
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
var NotificationAutoTypeId = 1;
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
var Notification =
{
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
new: func(_type, _ident, _typeid=0)
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
{
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
if (!isscalar(_type)) {
logprint(DEV_ALERT, "Notification.new: _type must be a scalar!");
return nil;
}
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
if (!isscalar(_ident) and _ident != nil) {
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
logprint(DEV_ALERT, "Notification.new: _ident is not scalar but ", typeof(_ident));
return nil;
}
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
# typeID of 0 means that the notification does not have an assigned type ID
# <0 means an automatic ID is required
# >= 16 is a reserved ID
# normally the typeID should be unique across all of FlightGear.
# use of automatic ID's is really only for notifications that will never be bridged,
# or more accurate when bridged the type isn't going to be known fully.
if (_typeid < 0) {
if (_ident != nil){
logprint(DEV_ALERT, "_typeid can only be omitted when registering class");
return nil;
}
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# IDs >= 16 are reserved; see http://wiki.flightgear.org/Emesary_Notifications
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
if (NotificationAutoTypeId >= 16) {
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
logprint(LOG_ALERT, "Notification: AutoTypeID limit exceeded: "~NotificationAutoTypeId);
return nil;
}
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
NotificationAutoTypeId += 1;
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
_typeid = NotificationAutoTypeId;
}
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
var new_class = {
parents: [Notification],
NotificationType: _type,
Ident: _ident,
IsDistinct: 1, #1: MP bridge only latest notification
FromIncomingBridge: 0,
Callsign: nil,
TypeId: _typeid, # used in MP bridged
};
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
return new_class;
},
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
setType: func(_type) {
if (!isscalar(_type)) {
logprint(DEV_ALERT, "Notification.new: _type must be a scalar!");
return nil;
}
me.NotificationType = _type;
return me;
},
setIdent: func(_ident) {
if (!isscalar(_ident)) {
logprint(DEV_ALERT, "Notification.new: _ident is not scalar but ", typeof(_ident));
return nil;
}
me.Ident = _ident;
return me;
},
GetBridgeMessageNotificationTypeKey: func {
return me.NotificationType~"."~me.Ident;
},
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
};
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
#---------------------------------------------------------------------------
# Recipient - base class for receiving notifications.
#
# You have to implement the Receive method
# The Receive method must return a sensible ReceiptStatus_* code
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
var Recipient =
{
new: func(_ident)
{
if (_ident == nil or _ident == "")
{
_ident = id(new_class);
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
logprint(LOG_WARN, "Emesary Error: Ident required when creating a recipient, defaulting to ", _ident);
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
}
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
__emesaryUniqueId += 1;
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
var new_class = {
parents: [Recipient],
Ident: _ident,
RecipientActive: 1,
UniqueId: __emesaryUniqueId,
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
};
return new_class;
},
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
Receive: func(notification)
{
logprint(DEV_ALERT, "Emesary Error: Receive function not implemented in recipient ", me.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
},
setReceive: func(f)
{
if (isfunc(f)) { me.Receive = f; }
else { logprint(DEV_ALERT, "Recipient.addReceive: argument must be a function!"); }
return me;
},
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
};
#
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# Instantiate a Global Transmitter, this is a convenience and a known starting point.
# Generally most classes will use this transmitters, however other transmitters
# can be created and merely use the global transmitter to discover each other.
Added Emesary and AN/SPN-46 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. 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.
2016-04-01 22:13:35 +00:00
var GlobalTransmitter = Transmitter.new("GlobalTransmitter");
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
#
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
# Base method of transferring all numeric based values.
# Using the same techinque as base64 - except this is base248 because we can use a much wider range of characters.
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
#
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
var BinaryAsciiTransfer =
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
#excluded chars 32 (<space>), 33 (!), 35 (#), 36($), 126 (~), 127 (<del>)
alphabet :
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
chr(1)~chr(2)~chr(3)~chr(4)~chr(5)~chr(6)~chr(7)~chr(8)
~chr(9)~chr(10)~chr(11)~chr(12)~chr(13)~chr(14)~chr(15)~chr(16)~chr(17)~chr(18)~chr(19)
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
~chr(20)~chr(21)~chr(22)~chr(23)~chr(24)~chr(25)~chr(26)~chr(27)~chr(28)~chr(29)
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
~chr(30)~chr(31)~chr(34)
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
~"%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}"
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
~chr(128)~chr(129)
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
~chr(130)~chr(131)~chr(132)~chr(133)~chr(134)~chr(135)~chr(136)~chr(137)~chr(138)~chr(139)
~chr(140)~chr(141)~chr(142)~chr(143)~chr(144)~chr(145)~chr(146)~chr(147)~chr(148)~chr(149)
~chr(150)~chr(151)~chr(152)~chr(153)~chr(154)~chr(155)~chr(156)~chr(157)~chr(158)~chr(159)
~chr(160)~chr(161)~chr(162)~chr(163)~chr(164)~chr(165)~chr(166)~chr(167)~chr(168)~chr(169)
~chr(170)~chr(171)~chr(172)~chr(173)~chr(174)~chr(175)~chr(176)~chr(177)~chr(178)~chr(179)
~chr(180)~chr(181)~chr(182)~chr(183)~chr(184)~chr(185)~chr(186)~chr(187)~chr(188)~chr(189)
~chr(190)~chr(191)~chr(192)~chr(193)~chr(194)~chr(195)~chr(196)~chr(197)~chr(198)~chr(199)
~chr(200)~chr(201)~chr(202)~chr(203)~chr(204)~chr(205)~chr(206)~chr(207)~chr(208)~chr(209)
~chr(210)~chr(211)~chr(212)~chr(213)~chr(214)~chr(215)~chr(216)~chr(217)~chr(218)~chr(219)
~chr(220)~chr(221)~chr(222)~chr(223)~chr(224)~chr(225)~chr(226)~chr(227)~chr(228)~chr(229)
~chr(230)~chr(231)~chr(232)~chr(233)~chr(234)~chr(235)~chr(236)~chr(237)~chr(238)~chr(239)
~chr(240)~chr(241)~chr(242)~chr(243)~chr(244)~chr(245)~chr(246)~chr(247)~chr(248)~chr(249)
~chr(250)~chr(251)~chr(252)~chr(253)~chr(254)~chr(255),
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
# base248: powers of 2 (i.e. po2(x) = f(248 ^ x);
# 0 based list so the first item is really[1]; i.e. 124 which is 248/2 as po2 is the magnitude excluding sign
po2: [1, 124, 30752, 7626496, 1891371008, 469060009984, 116326882476032, 28849066854055936],
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
_base: 248,
spaces: " ",
empty_encoding: chr(1)~chr(1)~chr(1)~chr(1)~chr(1)~chr(1)~chr(1)~chr(1)~chr(1)~chr(1)~chr(1),
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
encodeNumeric : func(_num,length,factor)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
var num = int(_num / factor);
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
var irange = int(BinaryAsciiTransfer.po2[length]);
if (num < -irange) num = -irange;
else if (num > irange) num = irange;
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
num = int(num + irange);
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
if (num == 0)
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
return substr(BinaryAsciiTransfer.empty_encoding,0,length);
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
var arr="";
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
while (num > 0 and length > 0) {
var num0 = num;
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
num = int(num / BinaryAsciiTransfer._base);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
rem = num0-(num*BinaryAsciiTransfer._base);
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
arr =substr(BinaryAsciiTransfer.alphabet, rem,1) ~ arr;
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
length -= 1;
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
}
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
if (length>0)
arr = substr(BinaryAsciiTransfer.spaces,0,length)~arr;
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
return arr;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
},
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
retval : {value:0, pos:0},
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
decodeNumeric : func(str, length, factor, pos)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
var irange = int(BinaryAsciiTransfer.po2[length]);
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
var power = length-1;
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
BinaryAsciiTransfer.retval.value = 0;
BinaryAsciiTransfer.retval.pos = pos;
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
while (length > 0 and power > 0) {
var c = substr(str,BinaryAsciiTransfer.retval.pos,1);
if (c != " ") break;
power = power -1;
length = length-1;
BinaryAsciiTransfer.retval.pos = BinaryAsciiTransfer.retval.pos + 1;
}
while (length >= 0 and power >= 0) {
var c = substr(str,BinaryAsciiTransfer.retval.pos,1);
# spaces are used as padding so ignore them.
if (c != " ") {
var cc = find(c,BinaryAsciiTransfer.alphabet);
if (cc < 0)
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
print("Emesary: BinaryAsciiTransfer.decodeNumeric: Bad encoding ");
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
return BinaryAsciiTransfer.retval;
}
BinaryAsciiTransfer.retval.value += int(cc * math.exp(math.ln(BinaryAsciiTransfer._base) * power));
power = power - 1;
}
length = length-1;
BinaryAsciiTransfer.retval.pos = BinaryAsciiTransfer.retval.pos + 1;
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
}
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
BinaryAsciiTransfer.retval.value -= irange;
BinaryAsciiTransfer.retval.value = BinaryAsciiTransfer.retval.value * factor;
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
return BinaryAsciiTransfer.retval;
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
},
encodeInt : func(num,length){
return me.encodeNumeric(num, length, 1.0);
},
decodeInt : func(str, length, pos){
return me.decodeNumeric(str, length, 1.0, pos);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
}
};
New encoding scheme for transfer over bridge that is slightly more efficient in most cases.
2016-04-16 13:13:33 +00:00
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
var TransferString =
{
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
MaxLength:16,
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
#
# just to pack a valid range and keep the lower and very upper control codes for seperators
# that way we don't need to do anything special to encode the string.
getalphanumericchar : func(v)
{
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
if (find(v,BinaryAsciiTransfer.alphabet) > 0)#"-./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_abcdefghijklmnopqrstuvwxyz") > 0)
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
return v;
return nil;
},
encode : func(v)
{
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
if (v==nil)
return "0";
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
var l = size(v);
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
if (l > TransferString.MaxLength)
l = TransferString.MaxLength;
var rv = "";
var actual_len = 0;
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
for(var ii = 0; ii < l; ii = ii + 1)
{
ev = TransferString.getalphanumericchar(substr(v,ii,1));
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
if (ev != nil) {
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
rv = rv ~ ev;
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
actual_len = actual_len + 1;
}
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
}
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
rv = BinaryAsciiTransfer.encodeNumeric(l,1,1.0) ~ rv;
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
return rv;
},
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
decode : func(v,pos)
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
var dv = BinaryAsciiTransfer.decodeNumeric(v,1,1.0,pos);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
var length = dv.value;
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
if (length == 0){
dv.value = "";
Emesary changes to better support GeoEventNotifications. A GeoEventNotification can be used to notify all other MP craft (that are connected to the bridge) of AI objects or ballistic items that are present on the local player's machine. For example tankers, dropped payloads, missiles, carriers. Changes - Fix transfer string encoding for bridge. If the string contained untransmittable characters the length was wrong. Change to use the valid characters from BinaryTransfer. - Fix bug transferring negative numbers. - Add method to notification to provide the type key to be used to decide if a non distinct message should be added to the queue; rather than relying on the simple type.ident. This allows multiple notifications of the same type to be non distinct but also be transmitted - Allow the maximum size of the mp string to be defined per bridge; rather than a system wide value. This allows the bridges to have their size tuned to match expected requirements; for example a bridge that is transmitting GeoEventNotification may need a lot more space than a bridge that is transmitting property sync notifications. - Improve error message when out of space (due to the maximum string length) - add trace option to bridges to aid debugging of transmitted values. This will produce verbose output. - Add UniqueIndex to GeoEventNotification; to allow for multiple non-distinct notifications to be transmitted concurrently. This overrides the GetBridgeMessageNotificationTypeKey to include the UniqueIndex
2017-11-18 00:51:08 +00:00
return dv;
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
}
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
var rv = substr(v,dv.pos,length);
dv.pos = dv.pos + length;
dv.value = rv;
return dv;
Emesary mp support Add support for transfer string Change Type to NotificationType as Type can be confusing
2016-04-12 21:25:11 +00:00
}
};
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
#
# encode an int into a specified number of characters.
var TransferInt =
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
encode : func(v, length)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
return BinaryAsciiTransfer.encodeNumeric(v,length, 1.0);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
},
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
decode : func(v, length, pos)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
return BinaryAsciiTransfer.decodeNumeric(v,length, 1.0, pos);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
}
};
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
var TransferFixedDouble =
{
encode : func(v, length, factor)
{
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
return BinaryAsciiTransfer.encodeNumeric(v, length, factor);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
},
decode : func(v, length, factor, pos)
{
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
return BinaryAsciiTransfer.decodeNumeric(v, length, factor, pos);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
}
};
var TransferNorm =
{
powers: [1,10.0, 100.0, 1000.0, 10000.0, 100000.0, 1000000.0, 10000000.0, 100000000.0, 1000000000.0, 10000000000.0, 100000000000.0],
encode : func(v, length)
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
return BinaryAsciiTransfer.encodeNumeric(int(v * BinaryAsciiTransfer.po2[length]),length, 1.0);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
},
decode : func(v, length, pos)
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
dv = BinaryAsciiTransfer.decodeNumeric(v, length, 1.0, pos);
dv.value = (dv.value/BinaryAsciiTransfer.po2[length]);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
return dv;
}
};
var TransferByte =
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
encode : func(v)
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
return BinaryAsciiTransfer.encodeNumeric(v,1, 1.0);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
},
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
decode : func(v, pos)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
return BinaryAsciiTransfer.decodeNumeric(v, 1, 1.0, pos);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
}
};
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
var TransferCoord =
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
# LatLon scaling;
# 1 degree = 110574 meters;
# requires 4 bytes for 1 meter resolution.
# permits 0.1 meter resolution.
LatLonLength: 4,
LatLonFactor: 0.000001,
AltLength: 3,
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
encode : func(v)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
return BinaryAsciiTransfer.encodeNumeric(v.lat(), TransferCoord.LatLonLength, TransferCoord.LatLonFactor)
~ BinaryAsciiTransfer.encodeNumeric(v.lon(), TransferCoord.LatLonLength, TransferCoord.LatLonFactor)
~ emesary.TransferInt.encode(v.alt(), TransferCoord.AltLength);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
},
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
decode : func(v,pos)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary fixes - Transfer encoding rewritten to handle negative numbers properly and fix scaling. - Change the "no receive method" to be just a warning as it is unwise rather than being wrong. Emesary MP bridge fixes from Nikolai OutgoingBridge: - When transmitting queue, make sure transmitted messages cannot remain in the queue when not completely emptied, and thus be sent again, and eventually fill up the queue. - Also allow smaller messages to sent even though there was not room for a larger message (the removal of the 'break' command). - To prevent coding the same message again with the 'break' removed, store an already coded string that was rejected due to too little room inside the message so when there is room for it, it was coded only once. - Stop recalculating MessageExpiryTime when there is no room for a notification. If it has asked to expire after expire time, let it expire. IncomingBridge: - Make sure listeners on emesary[x] properties are removed when a mp aircraft is invalid, otherwise a hidden bridge will sit in background and process same notifications a new bridge is already processing. - Change order of setting IncomingMessageIndex to ease debugging in reciever. - Since a bridge class can handle multiple emesary properties on same aircraft, use a vector per aircraft to store the bridge instances in, to make sure Remove can be called on all instances listening to same aircraft.
2020-07-25 12:11:07 +00:00
var dv = BinaryAsciiTransfer.decodeNumeric(v, TransferCoord.LatLonLength, TransferCoord.LatLonFactor, pos);
var lat = (dv.value);
dv = BinaryAsciiTransfer.decodeNumeric(v, TransferCoord.LatLonLength, TransferCoord.LatLonFactor, dv.pos);
var lon = (dv.value);
dv = emesary.TransferInt.decode(v, TransferCoord.AltLength, dv.pos);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
var alt =dv.value;
dv.value = geo.Coord.new().set_latlon(lat, lon).set_alt(alt);
return dv;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
}
};
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
# genericEmesaryGlobalTransmitterTransmit allowes to use the emesary.GlobalTransmitter via fgcommand
# which in turn allows using it in XML bindings, e.g.
# <binding>
# <command>emesary-transmit</command>
# <type>cockpit-switch</type>
# <ident>eicas-page-select</ident>
# <page>hydraulic</page>
# </binding>
#
var genericEmesaryGlobalTransmitterTransmit = func(node)
{
var transmitter = emesary.GlobalTransmitter;
var t = node.getNode("transmitter",1).getValue();
if (t != nil) {
transmitter = emesary.getTransmitter(t);
if (transmitter == nil) {
logprint(LOG_WARN, "Invalid transmitter "~t);
return;
}
}
var type = node.getNode("type").getValue();
if (type == nil) {
logprint(LOG_WARN, "emesary-transmit requires a type");
return;
}
var ident = node.getNode("ident").getValue();
if (ident == nil) {
logprint(LOG_WARN, "emesary-transmit requires an ident");
return;
}
var typeid = node.getNode("typeid",1).getValue() or 0;
if (typeid == 0) {
typeid = TypeIdUnspecified;
logprint(LOG_WARN, "emesary-transmit using generic typeid ", typeid);
}
var message = emesary.Notification.new(type, ident, typeid);
node.removeChild("type");
node.removeChild("id");
node.removeChild("typeid");
# add remaining nodes to the message hash
var children = node.getValues();
if (children != nil) {
foreach (var key; keys(children)) {
message[key] = children[key];
}
}
transmitter.NotifyAll(message);
};
Bugfix (temporary) for emesary nasal runtime error.
2020-08-31 18:39:22 +00:00
# Temporary bugfix -- FIXME
# removecommand("emesary-transmit"); #in case of reload
emesary.nas add comments, type checks; fix typos; add debug/emesary.deb.nas add fgcommand to use the global transmitter
2020-06-29 08:49:18 +00:00
addcommand("emesary-transmit", genericEmesaryGlobalTransmitterTransmit);
Emesary multiplayer bridge rework. 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.
2017-07-23 14:04:46 +00:00
#setprop("/sim/startup/terminal-ansi-colors",0);
#for(i=-1;i<=1;i+=0.1)
#print ("i ",i, " --> ", (TransferNorm.decode(TransferNorm.encode(i,2), 2,0)).value);
#debug.dump(TransferNorm.decode(TransferNorm.encode(-1,2), 2,0));
#debug.dump(TransferNorm.decode(TransferNorm.encode(0,2), 2,0));
Emesary : rework transfer encoding This better supports -ve numbers by using -range/2 to range/2 instead of prepending a '-' to the start of the encoded value for -ve numbers.
2020-06-05 10:46:54 +00:00
#debug.dump(TransferNorm.decode(TransferNorm.encode(1,2), 2,0));
Copy permalink