-
Notifications
You must be signed in to change notification settings - Fork 10
Data structure overview
Here you can find the description of basic building blocks of datafiles.
All files are saved as XML (.cat
/.gst
/.ros
), or as a zip archive containing XML files (.catz
/.gstz
/.rosz
/.bsr
/.bsi
).
Datafiles are essentially either Catalogues or Rosters, both using similar but separate schemas.
- Rosters (
.ros
/.rosz
) define the actual list of selections, grouped into forces, and are the final product of using BattleScribe. - Catalogues (
.cat
/.catz
) are datafiles containing very detailed templates from which one can later create and validate rosters.- There is a very special type of catalogue that acts as a "root" - it's called the game system (
.gst
/.gstz
). Game systems are datafiles that definegameSystemId
which is referenced in every other catalogue belonging to the system. This allows BattleScribe to detect what game systems are defined in the data, and show only catalogues that are associated with it.
- There is a very special type of catalogue that acts as a "root" - it's called the game system (
There are also two additional file types that support file distribution:
- Indexes (
index.xml
/index.bsi
) are a kind of a protocol/manifest whose URL acts as an identifier of an internet data source for BattleScribe. They are lightweight index files that list files and versions (and these files' URLs), and based on this info, BattleScribe decides whether a file has an updated version for download. - Repository distributions (
.bsr
) are zip archives containg whole data package:- an
index.xml
file defining contents of the archive, and possibly additional repository URLs to subscribe to; - catalogues and gamesystems.
- an
The structure is a tree as follows:
Catalogues are the complete datafile structure, containing all building blocks required for BattleScribe to create a roster. Game system catalogues are the root of the logical file structure, and the root of the file is a catalogue structure.
Children:
- Cost Types
- Profile Types
- Category Entries
- Force Entries
- Shared Selection Entries (SSE)
- Shared Selection Entry Groups (SSEG)
- Shared Profiles (SP)
- Shared Rules (SR)
- Root Selection Entries (SE) contain special Root
SE
s and Root Info Links - Root Rules
Properties:
Category entries are tag-like entities. They can be a target of condition (e.g. count all Big
units where Big is a category these units have). A SE
may define a primary category, under which that selection will be available in roster.
Children:
- Profiles
- Rules
- [InfoLink][]s
- Constraints
- Modifiers
Properties:
Characteristic defines a value for a given characteristic type. This value is always textual, although for certain modifiers it can be parsed by BattleScribe as a numeric, just for the duration of modification.
No children.
Characteristic type defines a name for a single field of profile type, later referenced by an actual characteristic to identify which field's value it represents.
Cost types are an extension of the old points-only system. They abstract away points and any other cost system for your game. Cost types define a countable resource that should be summed up and/or limited in rosters.
Force entries define the structure of the roster and are a representation of a detachment, battalion or strike force. All selections within must originate from a single catalogue.
Profile types define a name for a list of characteristic types, which is then selected as a type for a profile. You can think of a profile type as a column set, where each column is a characteristic type. Multiple profiles with the same profile type will be displayed together, creating a table.
Profiles are a named list of characteristics. They are used both in catalogues and rosters.
Rule is the only multi-line textual entity in all of BattleScribe data structure (you may enter line breaks in other places, but only this one is guaranteed to preserve them). It also has a displayable name.
This is the most core, ubiquitous construct, along with SEG. These two are absolutely fundamental, and define the actual selection tree presented to the user. These entities are displayed during roster creation/editing, and represent units, models, upgrades and other equipment/abilities that require similar semantics.
SEG
groups together SE
s that should be constrained together, or just to visually group some selections in Roster Edit view.
Following are elements of rosters.
Basics
-
Unique Id
short UUID, actually can be any unique text, internally used to distinguish, identify and reference entities. Almost every entity has it. -
Name
a common, visual, textual name of the entity, non-unique, displayed in the GUI (visual interface) of both Roster and Data editor.
Reference:
-
Book
is a textual field containing name of book or similar publication where the entity originates from. -
Page
is a textual field describing the part of the publication to look for this entity in.
Revision
-
Revision Number
is a numeric, integral value. This value is used in [data index][], and if it's higher, the file will be updated.
Entry:
-
Hidden?
if this field is checked, the entity will not be visible to the user, and any already selected entries will cause error showing up in error list in Roster Editor. You can change the value of this field through a modifier which is the primary use case of this property.
Author Details:
Name
Contact
Website