This suppose the understanding of the script commands of VBS3.
vsTaskerPlugin
VBS allows a third party to communicate with the internal engine from a DLL using a scripting mechanism called ASI.
Unfortunately, the DLL is called at a low rate and the script processing takes quite a lot of time. Because both the ASI and the IG are inside the same thread, the impact on the IG frame rate is noticeable. Also, because the DLL is called at a low frequency, syncing the vsTASKER simulation engine with proper position of the VBS entities is not very efficient, even with extrapolation (VBS speeds are not what we do expect).
The vsTaskerPlugin gathers all vsTASKER entities in a local list and tries to maintain a consistency with the VBS engine. When necessary, it updates vsTASKER with messages sent through the LAN to vbs-proxy component.
The communication with VBS core is done using the only provided function:
typedefint (WINAPI * ExecuteCommandType)(constchar *command, char *result, int resultLength);
which processes the command and returns a result. This processing is CPU intensive and slows down the frame rate.
Using vsTASKER scenario jointly with IA in VBS can become problematic when numerous entities are engaged because of the low rate syncing of entities. vsTASKER ends up with a situation which does not reflect in time the VBS situation, with reaction times which are not acceptable. It is better to switch OFF the VBS AI and force the position of entities.
The plugin must be compiled prior to be loaded by VBS.
Make sure that you have set the environment variable: BSIM_DIR to point to Bohemia directory (below VBS)
Open the solution in /Runtime/VBS-3/Plugin (vc100 or vc140) and generate the DLL in x64 bits. It should be stored in $(BISIM_DIR)/VBS3/Plugins64
vbs-proxy
This component must be attached to the Scenario player and setup according to the vsTaskerPlugin static variable:
#defineIN_PORT 9930 // vsTASKER -> VBS
#defineOUT_PORT 9931 // VBS -> vsTASKER
#defineCLIENT_IP"127.0.0.1"// Where to access vsTASKER