Standalone

The standalone installer allows you to run the app without having to do anything in R.

Installation from R

1. Install R and RStudio.

2. Optionally install lighttpd (see “Other system utilities” below)

3. From RStudio:

   install.packages("ovscout2", repos = c("https://openvolley.r-universe.dev",
                                          "https://cloud.r-project.org"))

   or

   install.packages("remotes") ## only needed once
   remotes::install_github("openvolley/ovscout2")

Other system utilities

Two other system utilities are recommended but not required. Note that the standalone Windows bundle already includes these utilities — no further action is needed in that case.

1. pandoc is required for generating match reports from scouted files. Install following https://github.com/jgm/pandoc/blob/master/INSTALL.md. If not present, the report generation menu item won’t be shown. If you are starting the app from RStudio, you do not need to install pandoc because RStudio comes bundled with its own copy.

2. lighttpd is a lightweight web server that is used to play the match video (when using a local video file). Install (from within R, on Windows only) using ovscout2::ov_install_lighttpd() or manually from http://lighttpd.dtech.hu/ (for Windows) or via your package manager for other operating systems (see https://redmine.lighttpd.net/projects/lighttpd/wiki/GetLighttpd). If lighttpd is not installed, the app falls back to servr but this is a little slower and less responsive than lighttpd.

Startup — standalone

Run the ov_scouter.bat (Windows) or ov_scouter (Linux/Mac) script. It will prompt you for a season directory, dvw file, and video file. The season directory and dvw file are optional (a new match file will be created if no dvw is provided) but the video is required for click-scouting.

Options controlling the app behaviour and scouting preferences can be changed via the “Preferences” button in the app. You can switch from click-mode scouting to type-mode or vice-versa from within the app — see Switching scout modes below.

Startup — from R

In each session you first need to load the ovscout2 package:

library(ovscout2)

Then start the app. You can start it with no arguments:

ov_scouter()

… and it will prompt you (as for the standalone version) for a season directory, dvw file, and video file. The season directory and dvw file are optional (a new match file will be created if no dvw is provided) but the video is required.

You can optionally provide those arguments explicitly. To start a new match for a certain video file, using teams from already-scouted matches in your season directory, you could do:

ov_scouter(video_file = "/path/to/video.mp4", season_dir = "/path/to/season_dir")

If you have already partially-scouted a match and saved that file, you can re-start scouting:

ov_scouter("/path/to/saved_file.ovs")

(In this case you do not need to provide the video file path, because that is saved within the .ovs file.)

Click-scouting conventions

There are a few ways in which you can tailor the click-scouting to your requirements. These can set via the ov_scouting_options() function or the “Click-scouting conventions” pane in the preferences. They include:

• end_convention determines whether you are treating the end coordinate of an attack or serve as the actual end location (i.e. where the ball contacted the floor or out of bounds area), or the intended end location. The actual might differ from the intended if there is a block touch or the ball hit the net. If “actual”, and a block touch is recorded, then the end location of the attack will not be used for the dig location (the dig location will be missing).

• nblockers and default_nblockers. If nblockers is TRUE then the data entry will include a section to enter the number of blockers on each attack. This is recommended and set to TRUE by default. The default_nblockers value can be used to set the number of blockers that will be pre-selected on each attack. Having a default value might speed up the data entry process very slightly but it is not recommended because it’s easy to forget to update it on each attack and then your data will include default-valued entries that you can’t easily distinguish from genuine ones that you actually entered.

• transition_sets. If FALSE, then sets in transition are not scouted. After entering an attack end location (and play continues) the next click will be for the counterattack start location, with no set scouted in between.

• attacks_by allows attacks to be recorded by combination code (“X5”, “V5”, etc) or just by tempo (high, medium, quick)

• set_quality. If FALSE (which is the default), set actions are not graded, although set errors and over-sets (a set that goes over the net) are marked as such. If set_quality is TRUE, the data entry will include a section where each set can be graded as “excellent”, “good”, “OK”, or “poor”.

• setter_calls. The “setter call” is where the setter instructs their middle to run. For example, a setter call of “K2” means that the middle hitter ran behind the setter (as if to hit a quick ball behind). The setter call is entered even if the setter actually set someone else. You can set this to “none” (no setter calls), “reception” (setter calls on reception-phase attacks only), or “both” (setter calls will be recorded on both reception-phase and transition-phase attacks). Setter calls are not recorded on poor reception/dig or overpasses.

  Note that if you are not scouting transition sets, you can’t record setter calls in transition because the setter call code is attached to the setting action. If transition_sets is FALSE and setter_calls is “both”, it will be treated as “reception”.

Type-scouting conventions

There are many fewer convention settings for type-scouting, because those conventions are largely controllled directly by the scout and what they are entering when they type. The only setting here is whether the scout is using zones or cones to record attack directions. See the Switching between zones and cones section below.

Shortcuts

Keyboard shortcuts can be viewed by clicking the “ Keyboard” button.

Shortcuts can be changed from the shortcuts pane (click the shortcut in question and type the new shortcut key to use). Changes to shortcuts made within the app cannot currently be saved, but users starting from R can specify shortcuts via the click_shortcuts, type_shortcuts, and playstable_shortcuts parameters.

Key remapping

In type-scouting mode it is possible to remap keys (so that when you press a particular key, it is treated as if it were a different key). This remapping is commmonly done by scouts so that their keyboard input can be faster and more efficient.

The only key remapped by default is the “;” key, which is remapped to “a”. Key remappings can only be changed when starting from R (see the key_remapping parameter). It is not currently possible to change the key remappings when using the standalone startup.

Click-scouting

The click-scouting process is a guided one. Each contact is marked by clicking on the video at the time and point of contact, with the point of contact being the point on the floor directly below the ball as it is being played. This will often be between the player’s feet as they dig or set the ball, or below them if they are jumping to spike.

• unpause the video. The number of the serving player and their serve type (float/jump/etc) will be shown below the video panel. You can change the serve type before the serve, if you can see that it is wrong

Type-scouting

An introduction to type-scouting is beyond the scope of this manual. You can find some information online or through (paid) courses and books. If you are not already familiar with type-scouting, it is strongly recommended that you use the click-scouting mode instead. It is designed to allow high-quality match information to be recorded but with a vastly easier learning curve.

For type-scout users, be aware that there are some non-standard scouting codes that can be used in ovscout2 that might save you a few keystrokes:

• starting lineups can be entered with L codes such as L 4,7s,8,10,1,3,17 (you can use spaces instead of commas if you prefer). The first six numbers give the players starting in positions 1–6, with “s” being used to designate the setter. The 7th (and 8th) numbers after the L are optional and are the libero(s). Use aL for the visiting team lineup

• at the end of the rally, the point can be assigned by entering p or *p (if the home team won the rally) or ap (visiting team). Or you can use the shortcut keys, which by default are Ctrl-ArrowUp to assign the point to whichever team is at the top of the court diagram, and Ctrl-ArrowDown for the other team

• attack combinations can be entered without the player number. For example, if the home team made an X5 attack kill to position/cone 3 you can enter X53# without the player’s jersey number (use aX5... for the visiting team). ovscout2 will automatically infer the player number. For an X5 attack this is the front-row outside hitter, except in P1-reception when the opposite is expected to hit from position 4. Note some limitations on this process:

  • it can’t assign a player number to second-ball attacks (P2 by default) or overpass attacks (PR);

  • it uses the attack start zone and setter position (team rotation) to infer the player number;

  • it assumes that the team is playing with standard player role patterns and a setter-outside-middle rotation (i.e. the close outside hitter is in position 2 when the setter is in 1).

  If the team plays with some other patterns, or if these assumptions don’t hold for a particular attack, provide the player number in the scout code as usual

• setter calls in reception need only be Kx — the set action will be assigned to the on-court setter of the receiving team. Setter calls in transition, if you wish to include them, will need the team identifier as well (i.e. *Kx or aKx)

• you can signal the end of the set by entering **set

Zones and cones in detail

Scouted match files allow locations of court to be recorded in several different ways with differing levels of accuracy:

• zones are a 3 x 3 grid of squares on each side of the court (so one zone is a 3m x 3m square on an indoor court) and numbered 1–9
• each zone can be divided into four subzones A–D (each subzone is a 1.5m x 1.5m square on an indoor court)
• coordinates lie on a 100 x 101 grid that covers the entire court plus a margin around the outside of it, giving locations with a resolution of about 10cm.

Zones and subzones apply to all skills. Attack end locations have an extra option of cones, which are numbered 1–7 (1–8 for middle attacks) and give the direction of the attack. Attack end locations/directions can be stored as cones or zones but not both in the same file. It is a common (but not universal) convention when scouting with cones that the cone gives the intended direction of attack, not the actual direction (the two might differ if the ball deflected off the block or the net).

In conventional scouting software, zones and subzones can be entered through the typed-in scout codes, but coordinates must be entered by clicking on a court diagram. In ovscout2 in click mode, all locations are recorded as coordinates (from the clicks that you make on the video or court diagram) and are converted internally to zones and subzones. When you export a click-scouted match to dvw, you have the option of converting attack end locations to cone directions, which will be generated from the attack end coordinates.

If you are type-scouting, you must choose between zones or cones for your attack end location/directions. It is not advisable to switch between them while scouting a match, because the existing zone end data will not be converted to cones (or vice-versa, if you are going the other way) and you will end up with inconsistent information in your match file. It is not possible to losslessly convert from zones to cones: zones don’t map uniquely to cones (and vice-versa). Coordinates can be converted to zones or cones, but be aware that your scouting conventions will matter for interpreting the end result. If you have click-scouted attacks with the end point being the actual end point of the attack (i.e. the dig location) then a cone can be assigned but it will be the actual direction of attack, not necessarily the intended direction. If you are click-scouting with intended attack end points then attacks with a block touch won’t have an end point recorded (and no cone will be assigned to those attacks when exporting to dvw with cones, nor a zone when exporting to dvw with zones).

If you have set your type-scouting preference to cones and you start the app with a partially-scouted file that uses zones, the app will start in zone mode to be consistent with the already-entered data.