Versioning System
Relevant source files
The following files were used as context for generating this wiki page:
The Versioning System in Chapter Master encompasses the methodologies and tools used to track software iterations and automate environment setup for development. It relies on structured metadata defined in JSON configuration files and PowerShell automation scripts to ensure consistency across different development environments.
Sources: datafiles/main/version.json, run_gobo.ps1:1-10
Component Overview
The system is divided into metadata tracking and automation tooling. The metadata defines the current state of the software, while the automation scripts handle the retrieval and installation of specific binary versions required for the project's build and formatting pipeline.
Version Metadata Structure
The core versioning information is stored in a centralized JSON file. This file serves as the single source of truth for the application's current versioning state.
| Field | Description |
|---|---|
version | The semantic or numerical representation of the current build. |
Sources: datafiles/main/version.json
Automation and Tooling Versioning
The project utilizes PowerShell scripts to manage external tool versions. The run_gobo.ps1 script demonstrates a versioning and auto-update mechanism for the GML Formatter. It queries the GitHub API to identify and download the latest release of required binaries, ensuring the development environment remains up to date.
The following flowchart illustrates the auto-update logic used for external tools:
The script uses a specific repository EttyKitty/Gobo to fetch the gobo.exe formatter.
Sources: run_gobo.ps1:12-42
Data Schema Versioning
While software versioning is tracked globally, data structures (such as Chapters) maintain internal identification systems to ensure compatibility across different iterations of the game's data files.
Chapter and Data Identification
Each chapter data file uses an id field. This ID acts as a version-persistent identifier that allows the engine to link specific configurations, specialized roles, and livery data to the correct entity regardless of file name changes.
| Component | Identifier Type | Usage |
|---|---|---|
| Chapter | id (Integer) | Unique reference for chapter templates (e.g., 37 for Consecrators). |
| Origin | origin (Integer) | Type versioning: 1-Founding, 2-Successor, 3-Other, 4-Custom. |
| Livery | is_changed (Boolean) | Flag to track if the livery data version has been modified. |
Sources: datafiles/main/chapters/37.json:4-6, datafiles/main/chapters/36.json:208
Dependency Mapping
The versioning system also tracks lineage dependencies through the founding ID field. This creates a relationship map between different versions of chapters (Founding vs Successor).
This hierarchy ensures that successor chapters inherit or reference properties based on the version of the founding chapter they are linked to.
Sources: datafiles/main/chapters/36.json:6, datafiles/main/chapters/35.json:6
Build and Formatter Integration
The system integrates versioning with the build process by tracking success and error rates during automated tasks. The PowerShell implementation tracks the elapsed time and counts errors encountered during the processing of files, providing a technical summary of the build/format state.
Sources: run_gobo.ps1:48-89
Summary
The Versioning System in Chapter Master is a hybrid approach combining static metadata in version.json with dynamic tool management via run_gobo.ps1. By maintaining unique integer IDs for data entities and utilizing GitHub API integration for external dependencies, the project ensures environment stability and data integrity across development cycles.