These demos need
VR-FORCES 3.10 (minimum) from Mäk Technologies.
This demo shows a tight integration of vsTASKER & VR-FORCES by allowing vsTASKER to behave like a doctrine editor on top of VR-FORCES that is then used like a simple CGF & GIS display.
Open Global window in Environment::Classes::Global.
Select Definitions pane. Here, you will see all the VR-FORCES header files needed in vsTASKER to access the VR-FORCES API.
In Declarations pane, you will see a function prototype to let vsTASKER being informed of any entity added in VR-FORCES scenario (manually or from start).
Methods Pane develops the function.
Open Scenario window in Environment::Classes::Scenario
Select Declarations pane. Here, you see the main VR-FORCES main node (object): CtCgf. This object (pointer) will be used in vsTASKER to access the VR-FORCES environment as it would be from a normal C++ user-module (doing class extension). The three DtVrfObject are just there for the purpose of the demo. Not mandatory.
In Initialization pane, you will see in the case INIT part that cgf pointer is set from udata(). udata() is attached data to the INIT event sent by a C++ user-module that makes the link between VR-FORCES world and vsTASKER world (in terms of start-up and runtime master-slave issues). This user-module can be found in Runtime/VrForces/vrfapp.cxx.
This module is compiled with vsTASKER generated files so, user can start adding some specific code in it (as long as this code is generic enough. Specific code must be put into vsTASKER, at Global, Scenario or Entity level).
Cgf->vrfObjectManager() registers the vsTASKER add entity callback function.
Anytime VR-FORCES will add a new entity, vsTASKER will be notified.
Open Entity window in Environment::Classes::Entity
In the Declarations pane, you find a DtVrfObject pointer to the VR-FORCES object. Every entity has their pointer to their VR-FORCES counterpart.
Entity class also holds several task objects to be used in Logics.
Open now Scenario property window (double-click background of Scn scenario map) and select Reaction::Events pane. See how addEnt event is processed. Here, according to received DIS data, the proper Entity Catalog is used to create scenario entity.
Expand Entities::Catalog. vrfTank and vrfTruck have different behavior (select them and Logics). These behaviors trigger different logics defined in Logics.
Open now, for i.e. the logic “circulate” and see how gotoBeta Action has been defined (Implementation pane) based VR-FORCES use of predefined Tasks.
If MAK_VRFDIR and MAK_VRLDIR environment variables are correctly set, you can compile the scenario (tested with vrforces 3.10 & vrlink 3.10)
Start the simulation. You can monitor for each selected entity, their behavior (click on the entity and select Logics section on top of the Map). The Behavior in magenta is the running one. You can stop it and activate another one. You can also stop the simulation, change the connection, save and start again (no need to recompile).
You need to unzip in VR-FORCES scenarios directory the vsTaskerScn one provided in Runtime/VrForces/vsTaskerScn.zip. You have there the three scenarios that can be loaded from VR-FORCES (assuming the Mäk-Land terrain is available).
Anytime you do a change (move/create/delete entities on VR-FORCES), you can update the vsTASKER scenario using Menu options: Import::Scenarios::VR-FORCES.
In the three examples provided here, vsTASKER is holding the Logics and sequences basic tasks using the VR-FORCES API and library.
If you open any of the Logics, you will find intensive use of Entity methods: ent()->methods() and these methods have been defined in Sources::Entity. These methods contain direct calls to VR-Forces API (see Definitions and Methods panes).
1) Open the database vrf_mission
2) Compile the generated code.
3) Launch the generated VR-FORCES Simulation Engine.
4) Start VR-FORCES GUI
5) Load the requested scenario (helicopter is the recommended)
6) Load the Stealth (if any)
7) Start VR-FORCES exercise and monitor the Stealth, the VR-FORCES scenario Map and the vsTASKER logic.
