vsTASKER 7 User Manual
×
Menu
Index

Options

 
Options
1

Moving Entities

1. Moving Entities
When this option is checked, vsTASKER (GUI) will automatically update the position of the entities during runtime, by reading the shared-memory segment.
Export component must be attached to each entity.
Uncheck this option if the shared-memory is not used or if the GUI is not used either and to improve the simulation speed in case of numerous entities and high refresh rate.
By default, the Export component refresh rate is 1hz, which is quite low even with thousand entities.
2

Runtime Model

2. Runtime Model
When checked, the Models (Components and Data-Models) are updating the public data (exported using //&&) whenever the Inspector window is opened during runtime.
If unchecked, the data is not updated from SIM to GUI and only the value changes from GUI to SIM are received.
 
3

Entity Handle

3. Entity Handle
Not used for now
 
4

Catalogs

4. Catalogs
Select here which kind of catalog reference to use:
  • Single: unique catalog for entities, allowing several scenarios to share the same list and definitions. This is the default.
  • Multiple: each scenario hold their own catalog of entities. This used to be the default for versions older than 5.1.
It is not advisable to change from Multiple to Single. It is better and simpler to have one unique catalog per database as catalog is preferably used for runtime entities. The only reason why each scenario shall have their own catalog is to restrict the runtime entity creation to a predefined set of entities that are unique for the current scenario.
5

Terrains

5. Terrains
Select here if the terrain definition (including all layers and editor3D) is shared between all scenarios (in this case, it belongs to the database only and each scenario has a link to the database terrain data) or if any scenario must have its own terrain definition (in this case, the database has only a link to the current selected scenario terrain data).
  • Single: unique terrain hold by the database. All scenarios will use the same terrain data definition. Memory efficient as the terrain will not be duplicated. The default mode.
  • Multiple: each scenario hold their own terrain data definition. Must be used only if each scenario has different terrain layers.
When only one terrain is used for several scenarios, use Single Terrain mode as it does save a lot of memory, mostly when the terrain is memory consuming.
6

Welcome Page

6. Welcome Page
Put here the URL (local, starting with file:// or remote using http://) of any HTML pages or website you want, associated with the current database (or not).
By default, points to a blank page.
 
7

Enable Tracing

7. Enable Tracing
When checked, vsTASKER GUI will display in magenta the active objects of the selected (focused) entity. This is the default but might be a little time consuming for release simulation engines that request maximum performances. When unchecked, the shared-memory is not used.
 
8

Fast Processing

8. Fast Processing
When checked, the incoming (shared-memory) tracing pile is processed continuously (by the GUI) until emptied. This insures that the actual tracing status is in synch with the Simulation Engine but the risk is a lower GUI reactivity in case of faster than real-time mode.
 
9

Watchers

9. Watchers
When checked, all the Watcher objects (in Logics) are working, meaning that the Simulation Engine will update the shared-memory for tracing in the GUI when the Logic (containing the Watchers) is opened during runtime. This is the default and might be a little CPU consuming.
 
10

Sequence Log

10. Sequence Log
Not available yet
 
11

Events Log

11. Events Log
Not available yet