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

532 lines
20 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 : 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
# 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
#
#---------------------------------------------------------------------------*/
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.
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
ReceiptStatus_Abort : 2, # Fatal error, stop processing any further recipieints of this message. Implicitly failed.
ReceiptStatus_Finished : 3, # Definitive completion - do not send message to any further recipieints
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
new: func(_ident)
{
var new_class = { parents: [Transmitter]};
new_class.Recipients = [];
new_class.Ident = _ident;
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
new_class.Timestamp = nil;
new_class.MaxMilliseconds = 1;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
__emesaryUniqueId += 1;
new_class.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: 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){
if (max_ms){
if (me.Timestamp == nil)
me.Timestamp = maketimestamp();
me.MaxMilliseconds = max_ms;
#print("Set overrun detection ",me.Ident, " to ", me.MaxMilliseconds);
} else {
# me.Timestamp = nil;
me.MaxMilliseconds = 0;
#print("Disable overrun detection ",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
# Add a recipient to receive notifications from this transmitter
Register: func (recipient)
{
append(me.Recipients, recipient);
},
Emesary: add new method and tidy up diagnostics.
2018-07-27 22:33:38 +00:00
DeleteAllRecipients: func
{
me.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
# 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.
NotifyAll: func(message)
{
Emesary: add new method and tidy up diagnostics.
2018-07-27 22:33:38 +00:00
if (message == nil){
print("Emesary: bad notification nil");
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);
}
print("Recipient ",recipient.Ident, " has been removed from transmitter (", me.Ident, ") because of the above error");
me.DeRegister(recipient);
return Transmitter.ReceiptStatus_Abort;#need to break the foreach due to having modified what its iterating over.
}
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
{
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
{
return Transmitter.ReceiptStatus_OK;
}
}
}
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.MaxMilliseconds and me.TimeTaken > me.MaxMilliseconds ){
printf("Overrun: %s ['%s'] %1.2fms max (%d)",me.Ident,message.NotificationType, me.TimeTaken,me.MaxMilliseconds);
# print("Overrun: ",me.Ident, "['",message.NotificationType,"']", " ", me.TimeTaken,"ms (max ",me.MaxMilliseconds," ms)");
foreach (var recipient; me.Recipients) {
if (recipient.TimeTaken)
printf(" -- Recipient %25s %7.2f ms",recipient.Ident, recipient.TimeTaken);
}
}
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;
}
};
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
#
#
# Base class for Notifications. By convention a Notification has a type and a value.
# SubClasses can add extra properties or methods.
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
# Properties:
# Ident : Generic message identity. Can be an ident, or for simple messages a value that needs transmitting.
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
# NotificationType : Notification Type
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
# 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
# The IsDistinct is important for any messages that are bridged over MP as
# only the most recently sent distinct message will be transmitted over MP
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
{
var new_class = { parents: [Notification]};
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.Ident = _ident;
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
new_class.NotificationType = _type;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.IsDistinct = 1;
new_class.FromIncomingBridge = 0;
new_class.Callsign = nil;
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
new_class.GetBridgeMessageNotificationTypeKey = func {
return me.NotificationType~"."~me.Ident;
};
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 (_typeid == 0)
{
_typeid = NotificationAutoTypeId;
NotificationAutoTypeId = NotificationAutoTypeId + 1;
}
new_class.TypeId = _typeid;
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;
},
};
# Inherit or implement class with the same signatures to receive messages.
var Recipient =
{
new: func(_ident)
{
var new_class = { parents: [Recipient]};
if (_ident == nil or _ident == "")
{
_ident = id(new_class);
Remove debug and tidy up messages
2016-05-16 20:06:48 +00:00
print("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
}
Recipient.construct(_ident, new_class);
},
construct: func(_ident, new_class)
{
new_class.Ident = _ident;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.RecipientActive = 1;
__emesaryUniqueId += 1;
new_class.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
new_class.Receive = func(notification)
{
# warning if required function not
print("Emesary Error: Receive function not implemented in recipient ",me.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
#
# 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
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.
#
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 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
alphabet : 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)~chr(20)~chr(21)~chr(22)~chr(23)~chr(24)~chr(25)
~chr(26)~chr(27)~chr(28)~chr(29)~chr(30)~chr(31)~chr(34)
~"%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}"
~chr(128)~chr(129)~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
#print(BinaryAsciiTransfer.po2[1]);
var irange = int(BinaryAsciiTransfer.po2[length] / factor);
var scale = int(irange / factor);
#print("EC ",irange, " sc=",scale);
var num = int(_num / factor);
if (num < -scale) num = -scale;
else if (num > scale) num = scale;
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 : 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 irange = int(BinaryAsciiTransfer.po2[length]/factor);
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 : 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), 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 : 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, pos, 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
}
};
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 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
# 28 bits = 268435456 (268 435 456)
# to transfer lat lon (360 degree range) 268435456/360=745654
# we could use different factors for lat lon due to the differing range, however
# this will be fine.
# 1 degree = 110574 meters;
encode : func(v)
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.lat()+90)*745654,5, 1.0)
~ BinaryAsciiTransfer.encodeNumeric((v.lon()+180)*745654,5, 1.0)
~ TransferNumeric.encode(v.alt(), 3, 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
var dv = BinaryAsciiTransfer.decodeNumeric(v,5, 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 lat = (dv.value / 745654)-90;
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,5, 1.0 ,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 lon = (dv.value / 745654)-180;
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 = TransferNumeric.decode(v, 3, 1.0 ,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 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