VASSAL Reference Manual
Home > Concepts
Concepts
A brief overwiew of some of the main concepts you need to know to get started creating a VASSAL module.
Module
All the pieces that make up a Vassal implementation of a game are collected together into a single file called a Module, which typically have a .vmod
suffix.
Physically, a Module is a ZIP archive containing the different files that go together to make up the Module.
You can inspect the files that make up a Module by opening it with any utility that can open ZIP Archives.
Note
|
Some tools may require you to rename the module file from .vmod to .zip before you can open it. Just rename it back to .vmod when you have finished.
|
A Module contains various files and folders:
-
The buildfile.xml is an XML file that links all the parts of your module together and includes all the definitions of the different Components and Pieces that make up your module.
The buildfile is normally maintained for you by the VASSAL Module Editor, but you can manually edit and update the buildfile if you know what you are doing. Make a backup first!!! -
The moduledata file holds the summary information about your module that is displayed in the Module Manager.
-
The images folder holds all the image files used in your module.
-
HTML files shown in Chart Windows.
-
Pre-defined Setup files used to start games.
Extension
Components and Pieces
A VASSAL Module is made up of two fundamentally different types of elements that are defined and manipulated in two different ways.
Components | Pieces |
|
---|---|---|
Mobility |
Fixed elements making up the structure of the module. |
Mobile element that can move about on Map components. |
Duplication |
Only one of each Component exists in a game. |
There can be multiple instances of each Piece in a game. |
Activation |
Activated by Hotkeys, ignore Key Commands. |
Activated by Key Commands, ignore Hotkeys. |
Toolbar Buttons |
Many Components can be activated by buttons that reside on the main Vassal toolbar. |
Pieces are never associated with a Toolbar button. |
Flexibility |
Limited to in-built configuration and flexibility provided by core VASSAL. |
Highly configurable and extensible by module designer. |
Components
VASSAL Components consist of the structural pieces that are used to implement a game. Some key Components used in nearly every module are:
-
Maps that combine one or more boards into a playing surface that Pieces can be placed on.
-
Boards that implement an individual map or part of map
-
Zones identify individual subsections of a Board.
-
Charts allow the display of reference materials.
-
Game Piece Palettes where Pieces can be defined.
-
Dice Buttons to roll and report on Die rolls.
Pieces
Pieces are used to implement the individual units, counters and other display pieces that make up a game.
Pieces are constructed from more than 40 different 'trait’s, each of which adds or modififies the behaviour of a piece. The number, order and configuration of the different traits within a piece control how it looks and acts in a VASSAL game.
Some important traits used in many pieces are:
-
Basic Piece defines the base image and name of a Piece.
-
Layers add additional layers of images to a Piece than can be shown or hidden.
-
Markers and Dynamic Properties add values to a Piece that can change over time and can be referenced in other Traits, Pieces and Components.
-
Triggers allow sequences of actions to be generated.
-
Prototypes allow a group of the same traits to be applied to different Pieces that share similar actions.
-
Send To Location and Move Fixed Distance allow pieces to be moved on Command.
-
Global Key Commands allow Key Commands to be sent to other pieces.
See the Game Piece for full details of all available traits.
Stacking and Game Piece Layers
By default, Pieces that are placed in the same Location in a Map will form a group called a Stack.
Stacks
A Stack is a set of Pieces in the same location and Game Piece Layer.
Pieces in a Stack are slightly offset from each other to give a visual cue that there are multiple pieces tacked together in that location.
Clicking on a Stack selects all Pieces in the Stack and the whole Stack can be moved as one unit. Double-clicking on a Stack expands it with a greated visual offset to show more of the counters in the Stack. Individual counters in the Stack can be selected and acted on.
The size of the visual offset for expanded and unexpanded Stacks is configurable in the Stacking Options Component of a Map.
At-Start Stacks
At-Start Stacks are a special kind of Stack that are defined as part of a Map. The Pieces on the Map are defined as part of the Map, not in a Game Piece Palette like ordinary Pieces.
Whenever a new game is started that uses that Map, a new Stack of those pieces is automatically created. Once the Pieces in an At-Start Stack have been moved away, the At-Start Stack no longer exists.
Decks
Decks are a special version of an At-Start Stack that have an independent existence, regardless of whether they contain any Pieces or not.
Decks act like a Deck of card, to hold and potentially hide the identity of Pieces (in the case of a face-down Deck.)
Hotkeys and Key Commands
Hotkeys and Key Commands represent a Keystroke that Vassal components and Piece traits 'listen' out for and perform actions when they see one that they are interested in. They allow one VASSAL Component or Piece to activate a completely different Component or Piece.
Hotkeys and Key Commands can be defined as an actual Keystroke that can be pressed on a keyboard, or can be defined as a 'virtual' Named Keystroke. Named Keystrokes can only be generated by VASSAL Components and Piece traits. See the Keystroke Commands, Named Commands, Key Commands and Hotkeys page for more information.
Hotkeys and Key Commands look very similar when you define them, but they have two different uses.
Hotkeys
Hotkeys are recognized by VASSAL Components and are completely ignored by Pieces.
Whenever a Hotkey is generated, it is sent to ALL VASSAL Components in no particular order.
-
By the user pressing a key or key combination while a VASSAL Map or Chart component has the focus (Not if the Chat Windows is currenly in focus).
-
By the Action Button Component, which can initiate a sequence of Hotkeys.
-
By the Global Hotkey Piece trait.
Key Commands
Key Commands are completely ignored by VASSAL Components.
Whenever Key Commands are generated, they are always sent to a specific set of Pieces. The Key Commands are sent to every trait within the selected set of pieces, that can then react to them if they are configured to do so.
-
By right-clicking on a Piece and selecting a Menu Command. The Key Command associated with tha Menu Command will be sent to the piece that is being right-clicked.
-
By activating a Trigger Action trait that can issue a sequence of Key Commands to the Piece that contains it.
-
By activating any Global Key Command Component or Piece trait to send a Key Command to a specific group of Pieces selected by the conditions specified in the Global Key Command.
Global Key Commands
Global Key Commands (commonly referred to as GKC’s) are a group of very commonly used components that select a group of pieces and send a Key Command to all the selected pieces. From Vassal version 3.7, any GKC can also be used to set Dynamic Properties in the selected pieces.
There are 5 different kinds of GKCs:
-
Counter GKCs are a piece trait that can be included in any Piece definition. They are initiated by a Menu Command or Key Command on the piece and can affect any piece in the current game.
-
Module GKCs are defined in the top level Module component and are initiated by an associated Toolbar button and can affect any piece in the current game.
-
Map GKCs are defined in a Map and are initiated by an associated Toolbar button and can affect any piece on the Map they are defined on.
-
Deck GKCs are defined in a Deck and are initiated by a right-click menu item on the Deck, and can affect any piece in the Deck.
-
Startup GKCs are defined in the top level Module component and are initiated when a new game is started or loaded and can affect any piece in the current game.
Many of the features of GKC’s are shared between the different types and detailed usage of GKCs is detailed here.
Values in VASSAL
Al values used in VASSAL are stored as strings of characters. A number like 42 is actually stored as "42". True and False values are stored as "true" and "false".
When needed, Vassal will convert to and from numbers and true/false values, for example when adding numbers, or checking of a condition is true. You generally do not need to worry about this, but it is good to understand what is happening under the hood.
In general all Components and Piece Traits that use numbers, require whole numbers (Integers).
Decimal numbers (e.g. 1.5) can be used and stored if you are experienced enough to know the limitations.
Properties
Properties are named values provided by VASSAL, by Components and by Pieces that can be referenced and used in other Components and Pieces.
The values of Properties can change over time and represent the current state of the different Pieces and Components in the current game and of VASSAL itself.
See the Properties Page for a comprehensive list of the Properties available in VASSAL.
Many of the properties have values that are controlled by VASSAL, but the following two types are Properties defined by the Module Designer.
Global Properties
Global Properties are user-defined properties that can have their value changed by user actions during Play. Global Properties can be created at the Module level, the Map level or the Zone Level and follow the visibility rules outlined in the previous section.
Global Properties can have their value changed by
-
Change Property Toolbar Button Component
Piece Properties
Piece Properties are user defined properties that exist within a specific Piece and can have their value changed by user actions during play.
-
A Marker defines a read-only Property that can’t be changed.
-
A Dynamic Property defines a Property that can have its value updated.
-
A Calculated Property defines a Property whose value is defined by a BeanShell Expression and is freshly re-calculated whenever its value is needed.
Dynamic Properties can have their value changed by
-
A Change value command defined in the Dynamic Property.
-
A Set Piece Property trait.
-
A Set Attachment Property trait.
Property Visiblility
-
Module level properties
-
Map level properties
-
Zone level properties
-
Piece properties
The Properties Page lists which level each Property is defined at.
When a Property value is needed, VASSAL starts searching at the level appropriate to the Component or Piece that needs the valie and searches upwards to find a value for the Property. If a Property of the same name exists on more than one level, then only the lowest level will be seen.
Module level components (such as Dice Buttons or Global Key Commands defined at the Module level) can only 'see' Module level properties.
Map level components (such as the Map Report Formats or the Line of Sight thread) can only 'see' the Map level properties defined on their own Map, plus Module level properties.
There are no Zone level components.
Pieces can only 'see' the Zone level properties in their current Zone, the Map level properties on their current Map and all Module level properties.
These visibility rules can be overridden using the GetProperty BeanShell functions.
Uniquely Identifying Pieces
In more advanced modules, there is a need to be able to identify particular pieces to perform automated operations on them.
Module designers can classify groups of pieces using Markers, applied via Prototypes. Pieces can also be identified by their BasicName property, but this will not be unique if multiple pieces have been created from the same definition.
Vassal provides the following properties available on Game Pieces to assist with identifying pieces in advanced modules:
Property | Description |
---|---|
PieceId |
The PieceId property uniquely defines the definition that created this piece. All pieces created from the same definition (Piece Definition in a Game Piece Palette, At-Start Stack or Deck, or a Piece Definition in a Place Marker or Replace trait) will have the same PieceId value. |
PieceUID |
The PieceUID property uniquely defines a piece. Each piece in a particular game is guaranteed to have a unique PieceUID and this is carried forward in Save games UNTIL the next time the game is manually refreshed by the Game Refresher, when a new PieceUID will be allocated. It will nearly always be better to use the UniqueID property rather than PieceUID. |
UniqueID |
The UniqueID property uniquely defines a piece. Each piece in a particular game is guaranteed to have a unique UniqueID and this is carried forward in Save games AND is maintained when a Game is refreshed via the Game Refresher. The UniqueID of a piece takes and keeps the value of the PieceUID that is first assigned to the piece. |
ParentID |
The ParentID property only exists in pieces that have been created with the Replace trait and contains the UniqueID of the Game Piece that created piece. |
CloneID |
The CloneID only exists in pieces that have been duplicated with the Clone trait and contains the UniqueID of the Game Piece that initial piece that performed the first Clone (which also has CloneID set). If a new version of a Cloned piece is pulled from a Piece Paletter and Cloned, it and the new clones will have a different CloneID from any earlier clones. |
Expressions
Old-Style Expressions
BeanShell Expressions
Property Match Expressions
Passing values to pieces
The Set Piece Property trait allows one piece to set a specific Dynamic Property in a selection of other pieces.
The Place Marker and Replace With Other traits and all varieties of Global Key Commands also have the ability to set the value of mulitple Dynamic Properties in the pieces they affect as well as perform their main purpose.
Values can also be shared between pieces by storing them in Global Properties that are accessible to all the pieces involved.
See the Passing values to pieces page for details on how to use these features.