Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.



...

Table of Contents
maxLevel

...

4
minLevel2

WaterCoach Display configuration

...

Section


Column
width45%

Schema definition

The structure of the XML-schema for the WaterCoach Display configuration is as shown on the right. To connect multiple applications for a combined training in WaterCoach the multipleSystems element (see below) has to be configured in the waterCoachDisplay before config (see on the right). An XML-schema for the waterCoachDisplay and multipleSystems is shown below.


 

Explanation

The waterCoachDisplay XML schema is divided into two parts. The multipleSystems element and the config element. The keys for both elements are explained below.

multipleSystems

  • Multiple applications can be connected with each other in WaterCoach by enabling the multipleSystems attribute.
  • When enabled, you need to is possible to specify a path and file name for the systemTimeFile. This is a NetCDF file containing the in-training time in milliseconds since 1 Jan 1977, that will be written by the leader and read by the follower(s).  There is no difference in the configuration between the leader and follower applications, which is which is determined by the user at start-up (see User Guide).

See for more details on multiple systems below.

config

The keys in the XML-schema are explained in the figure on the right. Some of the keys are explained in more detail here.

  • Scenarios/scripts that can be played with the WaterCoach must be part of a scenario/script database. The key scenarioScriptDatabasePath contains the (absolute or relative) path to the scenario/script database.
  • Historical scenarios/scripts may be familiar to players of the game. Therefore it is possible to hide the year of the scenario/script in the WaterCoach by setting the flag hideYear to true. Note that for the WaterCoach a copy of the operational system should be used since some changes in the FEWS configuration are required; see below. A better option for misleading players is to overrule the date/time of the historical scenario by explicitly setting the in-game time in the script configuration.
  • Events in a script can be associated with a file that is executed during the game. For example, a pdf-file can be associated with an event to simulate an incoming e-mail or an mp3-file to simulate telephone calls. Using the key fileAssociation , programs can be specified with which files with indicated extensions must be processed. Default file associations are used if nothing is specified here.
  • In the section timeControl , the presence of buttons for time control during the game can be configured, namely a pause/play button, a next button for jumping to the next scheduled event in the script, fast Forward/Backward buttons for speeding up/down time, and a set button for adjusting the time manually.
  • Section  experienceLevel  contains configuration of experience levels in the game. With the key  levels , the actual experience levels are defined, separated by semi-colons, e.g. "Beginner;Intermediate;Expert". In the script configuration, events can be defined for each of these experience levels. The flag  adjustLevel  indicates that the experience level can be adjusted during the game.
  • The key fewsLogEventCodes accepts a list (separated by semi-colons) of event codes from FEWS that have to be logged in the WaterCoach log, e.g. "Info;ManualForecast.started".
  • Anchor
    visualization
    visualization
  • The WaterCoach can be played combined with the so-called "procedure game", developed for the Dutch Water Service (Waterdienst). In such a combined setting, the hostname and the port number for connecting to the combined game must be specified in serverHostName and serverPort , respectively. Furthermore, forecasts must be published to a file in so-called PI-format. This can be accomplished by setting the key writePiOutput to true (defaults to false).
  • Anchor
    visualization
    visualization
    showVisualizeScriptButton  is deprecated.
  • The option copyLocalDataStore has been added to aid the script configurator. If you are working on the script for one scenario, you can turn of the copying of the localDataStore at the start-up of the WaterCoach by temporarily setting this keyword to false. Note: this option has no effect in an application that is configured as participant.
  • Some default values can be entered (useful when developing a game): defaultUserName, defaultScenario and defaultScript.
  • log4jConfigPath and logPath are deprecated.
  • The keyword scriptLogPath  can be set to overrule the default locations of the watercoach log file. In this file, all actions within the WaterCoach display are logged, and thus can be used for after action review or feedback.
  • Keyword displayConfirm  controls the presence of "Are you sure?" confirmation buttons.
  • Keyword clientConfigExportURL defines whereto the clientConfig.xml is exported to. This can be used when the WaterCoach is used in Participant mode. The Master application can export the clientConfig.xml to this location. This file can be used by the Participant applications(s) to connect to the Master localDataStore.
  • The keyword participant is deprecated. See below on how to activate participant mode.

Meta-application, or combining multiple Scenario Script Databases (SSD)

You can combine multiple SSD for a single WaterCoach application, see for more information Scenario and Script database (SSD)#SSDfolderstructurefordifferent(older)versionsofaDelft-FEWSapplication(akaWaterCoachmeta-application)


Column


...