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

476 lines
21 KiB
Text
Raw Normal View History

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
#---------------------------------------------------------------------------
#
# Title : EMESARY multiplayer bridge
#
# File Type : Implementation File
#
# Description : Bridges selected emesary notifications over MP
# : 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
#
# Author : Richard Harrison (richard@zaretto.com)
#
# Creation Date : 04 April 2016
#
# Version : 4.8
#
# Copyright <20> 2016 Richard Harrison Released under GPL V2
#
#---------------------------------------------------------------------------*/
# Example of connecting an incoming and outgoing bridge (should reside inside an aircraft nasal file)
#
# var routedNotifications = [notifications.TacticalNotification.new(nil)];
# var incomingBridge = emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
# var outgoingBridge = emesary_mp_bridge.OutgoingMPBridge.new("F-15mp",routedNotifications);
#------------------------------------------------------------------
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
#
Emesary: refactor incoming bridge connection logic This is mainly to allow unit testing.
2018-10-31 09:05:34 +00:00
# NOTES:
# * Aircraft do not need to have both an incoming and outgoing bridge, but it is usual.
#
# * Only the notifications specified will be routed via the bridge.
#
# * Once routed a message will by default not be re-rerouted again by the outgoing bridge.
#
# * Transmit frequency and message lifetime may need to be tuned.
#
# * IsDistinct messages must be absolute and self contained as a later message will
# supercede any earlier ones in the outgoing queue (possibly prior to receipt)
#
# * Use the message type and ident to identify distinct messages
#
# * The outgoing 'port' is a multiplay/emesary/bridge index, however any available string property
# can be used by specifying it in the construction of the incoming or outgoing bridge.
# NOTE: This should not often be changed as it different versions of FG or model will
# have to use the same properties to be able to communicate
#
# * multiplay/emesary/bridge-type is used to identify the bridge that is in use. This is to
# protect against bridges being used for different purposes by different models.
#
# * The bridge-type property should contain an ID that identifies the purpose
# and thereore the message set that the bridge will be using.
#
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
# - ! is used as a seperator between the elements that are used to send the
# notification (typeid, sequence, notification)
# - There is an extra ! at the start of the message that is used to indicate protocol version.
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
# - ; is used to seperate serialzied elemnts of the notification
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
# General Notes
#----------------------------------------------------------------------
# Outgoing messages are sent in a scheduled manner, usually once per
# second, and each message has a lifetime (to allow for propogation to
# all clients over UDP). Clients will ignore messages that they have
# already received (based on the sequence id).
# The incoming bridge will usually be created part of the aircraft
# model file; it is important to understand that each AI/MP model will
# have an incoming bridge as each element in /ai/models needs its own
# bridge to keep up with the incoming sequence id. This scheme may not
# work properly as it relies on the model being loaded which may only
# happen when visible so it may be necessary to track AI models in a
# seperate instantiatable incoming bridge manager.
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
#
# The outgoing bridge would usually be created within the aircraft loading Nasal.
Emesary: tidy up default MP prooperty index and add droptanks to GeoEvent
2016-04-25 18:40:57 +00:00
var EmesaryMPBridgeDefaultPropertyIndex=19;
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
var OutgoingMPBridge =
{
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
SeperatorChar : "!",
MessageEndChar : "~",
StartMessageIndex : 11,
DefaultMessageLifetimeSeconds : 10,
MPStringMaxLen: 128,
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
new: func(_ident, _notifications_to_bridge=nil, _mpidx=19, _root="", _transmitter=nil, _propertybase="emesary/bridge")
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
if (_transmitter == nil)
_transmitter = emesary.GlobalTransmitter;
Emesary: tidy up default MP prooperty index and add droptanks to GeoEvent
2016-04-25 18:40:57 +00:00
print("OutgoingMPBridge created for "~_ident," mp=",_mpidx);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
var new_class = emesary.Recipient.new("OutgoingMPBridge "~_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
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
if(_notifications_to_bridge == nil)
new_class.NotificationsToBridge = [];
else
new_class.NotificationsToBridge = _notifications_to_bridge;
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_class.NotificationsToBridge_Lookup = {};
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 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
foreach(var n ; new_class.NotificationsToBridge)
{
Emesary: add new method and tidy up diagnostics.
2018-07-27 22:33:38 +00:00
print(" ",_ident," outwards bridge[",n,"] notifications of type --> ",n.NotificationType, " Id ",n.TypeId);
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
n.MessageIndex = OutgoingMPBridge.StartMessageIndex;
new_class.NotificationsToBridge_Lookup[n.TypeId] = n;
}
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.MPout = "";
new_class.MPidx = _mpidx;
new_class.MessageLifeTime = 10; # seconds
new_class.OutgoingList = [];
new_class.Transmitter = _transmitter;
new_class.TransmitRequired=0;
new_class.Transmitter.Register(new_class);
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
new_class.MpVariable = _root~"sim/multiplay/"~_propertybase~"["~new_class.MPidx~"]";
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.TransmitterActive = 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
new_class.TransmitFrequencySeconds = 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
new_class.trace = 0;
Emesary: ensure that MPStringMaxLen initialized to default value in OutgoingBridge constructor
2017-11-19 12:49:15 +00:00
new_class.MPStringMaxLen = OutgoingMPBridge.MPStringMaxLen;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.TransmitTimer =
maketimer(6, func
{
if(new_class.TransmitterActive)
new_class.Transmit();
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.TransmitTimer.restart(new_class.TransmitFrequencySeconds);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
});
new_class.Delete = func
{
if (me.Transmitter != nil) {
me.Transmitter.DeRegister(me);
me.Transmitter = nil;
}
};
new_class.AddMessage = func(m)
{
append(me.NotificationsToBridge, m);
};
#-------------------------------------------
# Receive override:
new_class.Receive = func(notification)
{
if (notification.FromIncomingBridge)
return emesary.Transmitter.ReceiptStatus_NotProcessed;
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
#print("Receive ",notification.NotificationType," ",notification.Ident);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
for (var idx = 0; idx < size(me.NotificationsToBridge); idx += 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
if(me.NotificationsToBridge[idx].NotificationType == notification.NotificationType)
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
me.NotificationsToBridge[idx].MessageIndex += 1;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
notification.MessageExpiryTime = systime()+me.MessageLifeTime;
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
notification.Expired = 0;
notification.BridgeMessageId = me.NotificationsToBridge[idx].MessageIndex;
notification.BridgeMessageNotificationTypeId = me.NotificationsToBridge[idx].TypeId;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
#
# The message key is a composite of the type and ident to allow for multiple senders
# of the same message type.
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
#print("Received ",notification.BridgeMessageNotificationTypeKey," expire=",notification.MessageExpiryTime);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
me.AddToOutgoing(notification);
return emesary.Transmitter.ReceiptStatus_Pending;
}
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
new_class.AddToOutgoing = func(notification)
{
if (notification.IsDistinct)
{
for (var idx = 0; idx < size(me.OutgoingList); idx += 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 (me.trace)
print("Compare [",idx,"] qId=",me.OutgoingList[idx].GetBridgeMessageNotificationTypeKey() ," noti --> ",notification.GetBridgeMessageNotificationTypeKey());
if(me.OutgoingList[idx].GetBridgeMessageNotificationTypeKey() == notification.GetBridgeMessageNotificationTypeKey())
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
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 (me.trace)
print(" --> Update ",me.OutgoingList[idx].GetBridgeMessageNotificationTypeKey() ," noti --> ",notification.GetBridgeMessageNotificationTypeKey());
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
me.OutgoingList[idx]= notification;
me.TransmitterActive = size(me.OutgoingList);
return;
}
}
}
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
else
if (me.trace)
print("Not distinct, adding always");
if (me.trace)
print(" --> Added ",notification.GetBridgeMessageNotificationTypeKey());
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
append(me.OutgoingList, notification);
me.TransmitterActive = size(me.OutgoingList);
};
new_class.Transmit = func
{
var outgoing = "";
var cur_time=systime();
for (var idx = 0; idx < size(me.OutgoingList); idx += 1)
{
var sect = "";
var notification = me.OutgoingList[idx];
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 (!notification.Expired and notification.MessageExpiryTime > cur_time)
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
var encval="";
var first_time = 1;
var eidx = 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
notification.Expired = 0;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
foreach(var p ; notification.bridgeProperties())
{
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 nv = p.getValue();
encval = encval ~ nv;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
eidx += 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
# !idx!typ!encv~
sect = sprintf("%s%s%s%s%s%s%s",
OutgoingMPBridge.SeperatorChar, emesary.BinaryAsciiTransfer.encodeInt(notification.BridgeMessageId,4),
OutgoingMPBridge.SeperatorChar, emesary.BinaryAsciiTransfer.encodeInt(notification.BridgeMessageNotificationTypeId,1),
OutgoingMPBridge.SeperatorChar, encval, OutgoingMPBridge.MessageEndChar);
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 (size(outgoing) + size(sect) < me.MPStringMaxLen)
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
{
outgoing = outgoing~sect;
}
else
{
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
print("Emesary: ERROR [",me.Ident,"] out of space for ",notification.NotificationType, " transmitted count=",idx, " queue size ",size(me.OutgoingList));
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
notification.MessageExpiryTime = systime()+me.MessageLifeTime;
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
break;
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
}
}
else
{
notification.Expired = 1;
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
}
}
me.TransmitterActive = size(me.OutgoingList);
setprop(me.MpVariable,outgoing);
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
# print("Set ",me.MpVariable," size(",size(outgoing));
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
#loopback test:
# incomingBridge.ProcessIncoming(outgoing);
#
# Now remove any expired messages from the outgoing queue.
# The only real way of doing this is via the pop() function
# so we have to delete the expired items from the list by rebuilding
# the list from the start with non-expired items, and then
# all of the items past the end (of the rebuilt list) can be popped
# (pop removes the last element from a vector)
var outSize = size(me.OutgoingList)-1;
var out_idx = 0;
for (var idx = 0; idx <= outSize; idx += 1)
{
#print("Q1 [",idx,"] ",me.OutgoingList[idx].MessageExpiryTime-cur_time," Expired=",me.OutgoingList[idx].Expired);
if(!me.OutgoingList[idx].Expired)
{
#print("move ",idx, " => ",out_idx);
var mmove = me.OutgoingList[idx];
me.OutgoingList[out_idx] = me.OutgoingList[idx];
out_idx += 1;
}
}
var to_del = (outSize+1) - out_idx;
#print("--> out idx",out_idx, " to delete ",to_del);
while(to_del > 0)
{
#print("--> pop ");
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
pop(me.OutgoingList);
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
to_del = to_del - 1;
}
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +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
new_class.TransmitTimer.restart(new_class.TransmitFrequencySeconds);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
return new_class;
},
};
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 Multiplayer bridge
2016-04-09 19:39:57 +00:00
#
#
# one of these for each model instantiated in the model XML - it will
# route messages to
var IncomingMPBridge =
{
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
trace : 0,
new: func(_ident, _notifications_to_bridge=nil, _mpidx=19, _transmitter=nil, _propertybase="emesary/bridge")
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
if (_transmitter == nil)
_transmitter = emesary.GlobalTransmitter;
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
print("IncomingMPBridge created for "~_ident," mp=",_mpidx, " using Transmitter ",_transmitter.Ident, " with property base sim/multiplayer/"~_propertybase);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
var new_class = emesary.Transmitter.new("IncominggMPBridge "~_ident);
if(_notifications_to_bridge == nil)
new_class.NotificationsToBridge = [];
else
new_class.NotificationsToBridge = _notifications_to_bridge;
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_class.NotificationsToBridge_Lookup = {};
foreach(var n ; new_class.NotificationsToBridge)
{
print(" Incoming bridge notification type --> ",n.NotificationType);
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +00:00
n.IncomingMessageIndex = OutgoingMPBridge.StartMessageIndex;
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_class.NotificationsToBridge_Lookup[n.TypeId] = n;
}
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.MPout = "";
new_class.MPidx = _mpidx;
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
new_class.MPpropertyBase = _propertybase;
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_class.MessageLifeTime = OutgoingMPBridge.DefaultMessageLifetimeSeconds; # seconds
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.OutgoingList = [];
new_class.Transmitter = _transmitter;
new_class.MpVariable = "";
new_class.Connect = func(_root)
{
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
me.MpVariable = _root~"sim/multiplay/"~new_class.MPpropertyBase~"["~new_class.MPidx~"]";
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
me.CallsignPath = _root~"callsign";
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
me.PropertyRoot = _root;
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
setlistener(me.MpVariable, func(v)
{
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
#print("incoming ",getprop(me.CallsignPath)," -->",me.PropertyRoot," v=",v.getValue());
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
me.ProcessIncoming(v.getValue());
});
};
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
new_class.setprop = func(property, value){
if (IncomingMPBridge.trace == 2)
print("setprop ",new_class.PropertyRoot~property," = ",value);
setprop(new_class.PropertyRoot~property,value);
};
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
new_class.GetCallsign = func
{
return getprop(me.CallsignPath);
};
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
new_class.AddMessage = func(m)
{
append(me.NotificationsToBridge, m);
};
new_class.Remove = func
{
print("Emesary IncomingMPBridge Remove() ",me.Ident);
me.Transmitter.DeRegister(me);
};
#-------------------------------------------
# Receive override:
new_class.ProcessIncoming = func(encoded_val)
{
if (encoded_val == "")
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;
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 encoded_notifications = split(OutgoingMPBridge.MessageEndChar, encoded_val);
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
for (var idx = 0; idx < size(encoded_notifications); idx += 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
if (encoded_notifications[idx] == "")
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
continue ;
# get the message parts
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 encoded_notification = split(OutgoingMPBridge.SeperatorChar, encoded_notifications[idx]);
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
if (size(encoded_notification) < 4)
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
print("Error: emesary.IncomingBridge.ProcessIncoming bad msg ",encoded_notifications[idx]);
else {
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 msg_idx = emesary.BinaryAsciiTransfer.decodeInt(encoded_notification[1],4,0).value;
var msg_type_id = emesary.BinaryAsciiTransfer.decodeInt(encoded_notification[2],1,0).value;
var bridged_notification = new_class.NotificationsToBridge_Lookup[msg_type_id];
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 (bridged_notification == nil) {
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
print("Error: emesary.IncomingBridge.ProcessIncoming invalid type_id ",msg_type_id);
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
} else {
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
bridged_notification.FromIncomingBridge = 1;
bridged_notification.Callsign = me.GetCallsign();
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +00:00
if(IncomingMPBridge.trace>1)
print("ProcessIncoming callsign=",bridged_notification.Callsign," ",me.PropertyRoot, " msg_type=",msg_type_id," idx=",msg_idx, " bridge_idx=",bridged_notification.IncomingMessageIndex);
if (msg_idx > bridged_notification.IncomingMessageIndex) {
if(IncomingMPBridge.trace==1)
print("ProcessIncoming callsign=",bridged_notification.Callsign," ",me.PropertyRoot, " msg_type=",msg_type_id," idx=",msg_idx, " bridge_idx=",bridged_notification.IncomingMessageIndex);
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
var msg_body = encoded_notification[3];
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
if (IncomingMPBridge.trace > 2)
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
print("received idx=",msg_idx," ",msg_type_id,":",bridged_notification.NotificationType);
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
# populate fields
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 bridgedProperties = bridged_notification.bridgeProperties();
var msglen = size(msg_body);
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
if (IncomingMPBridge.trace > 2)
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
print("Process ",msg_body," len=",msglen, " BPsize = ",size(bridgedProperties));
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 pos = 0;
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +00:00
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
for (var bpi = 0; bpi < size(bridgedProperties); bpi += 1) {
if (pos < msglen) {
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +00:00
if (IncomingMPBridge.trace > 2)
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
print("dec: pos ",pos);
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +00:00
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
var bp = bridgedProperties[bpi];
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
dv = bp.setValue(msg_body, me, pos);
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +00:00
if (IncomingMPBridge.trace > 2)
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
print(" --> next pos ",pos);
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +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 (dv.pos == pos or dv.pos > msglen)
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
break;
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +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
pos = dv.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
} else {
print("Error: emesary.IncomingBridge.ProcessIncoming: [",bridged_notification.NotificationType,"] supplementary encoded value at position ",bpi);
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
break;
}
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
}
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
# maybe extend the bridge to allow certain notifications to only be routed to a specific player;
# i.e.
# (notification.Callsign == nil or notification.Callsign == getprop("/sim/multiplay/callsign"))
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
if (bridged_notification.Ident == "none")
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
bridged_notification.Ident = "mp-bridge";
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
me.Transmitter.NotifyAll(bridged_notification);
Emesary MP bridge: fix lost messages on MP bridge. When more than one message type being transmitted on the bridge only one of the types would be reliably received. Bug caused because the message index is per notification type (on MP bridge outgoing) but was being treated as per incoming bridge (rather than notification).
2020-03-24 11:02:13 +00:00
bridged_notification.IncomingMessageIndex = msg_idx;
Fix so that the callsign is a method as most of the MP properties probably won't be fully populated when the incoming bridge is created.
2016-04-16 13:14:16 +00:00
}
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
}
}
}
}
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
foreach (var n; new_class.NotificationsToBridge) {
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
print("IncomingBridge: ",n.NotificationType);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
}
return new_class;
Emesary: refactor incoming bridge connection logic This is mainly to allow unit testing.
2018-10-31 09:05:34 +00:00
},
connectIncomingBridge : func(path, notification_list, mpidx, transmitter, _propertybase){
var incomingBridge = emesary_mp_bridge.IncomingMPBridge.new(path, notification_list, mpidx, transmitter, _propertybase);
incomingBridge.Connect(path~"/");
me.incomingBridgeList[path] = incomingBridge;
return incomingBridge;
},
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
#
# Each multiplayer object will have its own incoming bridge. This is necessary to allow message ID
# tracking (as the bridge knows which messages have been already processed)
# Whenever a client connects over MP a new bridge is instantiated
Emesary: modify bridge to use new MP properties; or to allow the property base for all bridges within a model to use. By separating out the bridges this could be used in the future to transmit Emesary properties at a different rate. It is one of the future possible methods to improve MP communications and dual/multi controls
2017-12-28 00:25:01 +00:00
startMPBridge : func(notification_list, mpidx=19, transmitter=nil, _propertybase="emesary/bridge")
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
{
Emesary: refactor incoming bridge connection logic This is mainly to allow unit testing.
2018-10-31 09:05:34 +00:00
me.incomingBridgeList = {};
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
#
# Create bridge whenever a client connects
#
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
setlistener("/ai/models/model-added", func(v)
{
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
# Model added will be eg: /ai[0]/models[0]/multiplayer[0]
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
var path = v.getValue();
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
# Ensure we only handle multiplayer elements
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
if (find("/multiplayer",path) > 0)
{
var callsign = getprop(path~"/callsign");
Emesary MP Bridge; optimisation Encode the indexes and use add constants to remove hardcoded values
2016-04-17 09:32:19 +00:00
print("Creating Emesary MPBridge for ",path);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
if (callsign == "" or callsign == nil)
callsign = path;
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: refactor incoming bridge connection logic This is mainly to allow unit testing.
2018-10-31 09:05:34 +00:00
me.connectIncomingBridge(path, notification_list, mpidx, transmitter, _propertybase);
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +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
#
# when a client disconnects remove the associated bridge.
#
Added Emesary Multiplayer bridge
2016-04-09 19:39:57 +00:00
setlistener("/ai/models/model-removed", func(v){
var path = v.getValue();
Emesary: refactor incoming bridge connection logic This is mainly to allow unit testing.
2018-10-31 09:05:34 +00:00
var bridge = me.incomingBridgeList[path];
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 (bridge != nil)
{
Emesary MP Bridge; optimisation Encode the indexes and use add constants to remove hardcoded values
2016-04-17 09:32:19 +00:00
# print("Bridge removed for ",v.getValue());
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
bridge.Remove();
Emesary: refactor incoming bridge connection logic This is mainly to allow unit testing.
2018-10-31 09:05:34 +00:00
me.incomingBridgeList[path]=nil;
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 Multiplayer bridge
2016-04-09 19:39:57 +00:00
},
};
Copy permalink