Copyright VirtualSim 2004-2020 - All rights reserved
Messages
The way vsTASKER handles CIGI is by encapsulating a message into an Packet object (which can also be seen as a class) with all latitude for any usage.
The thing to remember is that any CIGI Packet defined in the GUI will generate a class with the same name (or like) and only one instance.
In the above definition of Packets (Air, Sea, Land...), we have separate class definitions which all are using the CigiEntityCtrlV3_3 class of the CCL library (in fact, they are all using the CigiEntity Data Model which used the CigiEntityCtrlV3_3 class):
Each Packet is running at a given frequency to ensure update of the IG. The more update, the better the output but the more load of the network. When many entities are in stake, it is advisable to manage wisely the update rate.
As each Packet class generates one instance, it can be easily accessed from any place in the code.
For example, the Air Packet above will be accessed this way:
cigi.Air->...
If the user has added the method: update() in the Packet definition, the method will be accessible from the code:
cigi.Air->update();
Some Packet need to handle several entities. This is the way above (Air, Sea...) Packets are doing. They have a list of CigiEntity objects to handle and they perform the update when necessarily.
CigiViewDefV3 message, can be called on event (or from the code) and issue only one message. For such Packet associated with only one message, the message parameters can be mapped with local variables for user to setup:
Of course, it would make no sense to allow a static data interface for a Packet with multiple instances inside. Reason why such Packets uses an array of Data Models attached to each entity with their own specific data interface.
