Pack Development

How the GSPack repository works. This page is for pack makers and contributors. Players don't need it.

The repository holds everything except the mod jars: configs, the quest book, KubeJS scripts and assets, and the tools that generate them. The pack itself is published on CurseForge.

Repository layout

Path	Contents
config/	All mod configs, including the generated quest book (config/ftbquests/quests)
kubejs/	KubeJS scripts and assets, including the quest book textures (kubejs/assets/gspack)
tools/	Scripts that generate the quest book, textures and menu, and sync with a local instance
tools/content/	The quest book source: one script per chapter
modlists/	A snapshot of all mods per pack version (<version>.json)
MODS.md	Generated list of every mod and version
CHANGELOG.md	What changed per version (quests, KubeJS, tools), written by hand
MOD-CHANGELOG.md	Mod changes per pack version, generated

Tools

All tools are PowerShell scripts. Run them from the repository root:

Script	What it does
tools/build-quests.ps1	Builds the quest book from tools/content/
tools/sync-to-instance.ps1	Installs the quest book and KubeJS and the Mystical Customization crops from the repo into an instance (-WhatIf to preview)
tools/sync-from-instance.ps1	Copies config/ and kubejs/ from your instance into the repo and refreshes MODS.md
tools/track-mods.ps1	Saves a mod snapshot for a version and updates MOD-CHANGELOG.md
tools/make-item-textures.ps1	Generates the endgame item textures
tools/make-menu-textures.ps1	Generates the main menu textures
tools/make-menu-layout.ps1	Generates the FancyMenu title screen layout
tools/make-ore-loot.ps1	Writes the ore loot tables that make other mods' ores drop AllTheOres materials (re-run after adding ore mods)
tools/convert-world.ps1	Converts a world to the unified materials while the server is stopped (-DryRun, -Interactive, -Pick); the GSPack Server Installer ships it as Convert World

Editing quests

The quest files are generated. Don't edit config/ftbquests/quests by hand, and don't save quest edits made in-game: they're overwritten on the next build. Edit the chapter scripts in tools/content/ instead, then rebuild:

powershell -ExecutionPolicy Bypass -File tools\build-quests.ps1

This writes config/ftbquests/quests (FTB Quests 26.1 JSON5 format) and the chapter banners and labels in kubejs/assets/gspack/textures/quests.

To check that every item, entity, structure, biome and dimension ID in the quests exists, pass a list of IDs dumped from the mod jars (one namespace:id per line):

powershell -ExecutionPolicy Bypass -File tools\build-quests.ps1 -ItemList ids.txt

Content files

File	Contents
00_tables.ps1	Chapter groups and reward tables
01_welcome.ps1 … 22_utilities.ps1	One file per chapter
99_decor.ps1	Chapter colours and section labels for the banners

Quest syntax

Chapter '<key>' '<title>' '<icon item>' '<group>' '<subtitle>' [-hidelines] [-showlines]

Q '<key>' '<title>' '<tasks>' '<dependencies>' '<rewards>' -desc '<text>' [-sub '<subtitle>'] [-opt] [-icon '<item>'] [-size 1.5] [-shape 'hexagon'] [-pos 'x,y']

• Tasks (separated by ;): ns:item*N, check, dim:<id>, biome:<id>, kill:<entity>*N, struct:<id or #tag>, adv:<advancement>, levels:N, look:<block>, stage:<name>[@<icon>][|<title>] (a KubeJS player stage, FTB Quests type gamestage), tag:<item tag>*N@<icon>[|<title>] (N items of any mod's version of a material; the build writes the KubeJS stage script gspack_quest_tags.js). Item tasks for a unified material become tag tasks automatically, and an item can carry data components: ns:item[component.field=value]
• Dependencies (separated by ,): a quest key in the same chapter, or chapter/key for a quest in another chapter
• Rewards (separated by ;): xp:N, lvl:N, table:<name> (random roll), choice:<name> (player picks), ns:item*count
• Description: | starts a new line, {@pagebreak} starts a new page, and & colour codes work (&6 gold, &e yellow, &r reset, …)
• Reward tables: Table '<key>' '<title>' @('spec@weight', ...)

Example:

Q 'iron' 'Iron Age' 'minecraft:iron_ingot*16' 'furnace' 'xp:50;table:common' -desc (
    "Iron is the backbone of almost every mod in the pack.||" +
    "Tip: The worldgen mods add huge caves.")

Quest IDs are derived from the chapter and quest keys, so rebuilding keeps player progress as long as you don't rename keys. The layout is automatic: the column is the dependency depth, and the row is the nearest free slot to the average row of the parents. If every quest of a chapter has -pos, the chapter keeps those positions instead (used for the GSPack Progression and Trophy Checklist chapters). Dependency lines are hidden in every chapter, because the automatic layout makes them cross; -showlines turns them on for a hand-placed chapter.

Tip: a build rewrites every chapter. Chapters that were saved by the game (after sync-from-instance) can hold settings the build script doesn't write, such as hide_tooltip on reward tables. After a build, keep only the chapters you changed and restore the rest with git checkout -- <file>.

Syncing with an instance

The sync scripts and track-mods.ps1 use the GSPack Dev Build instance (D:\CurseForge\Instances\GSPack Dev Build) by default. Pass -Instance <path> for another one.

# Install the quest book and KubeJS from this repo into the instance
powershell -ExecutionPolicy Bypass -File tools\sync-to-instance.ps1

# Copy config/ and kubejs/ from the instance into this repo and refresh MODS.md
powershell -ExecutionPolicy Bypass -File tools\sync-from-instance.ps1

After installing, run /ftbquests reload in-game and press F3 + T to reload textures. Restart the game if KubeJS startup scripts changed.

Releasing a new version

1. Update the mods in your instance and sync: tools\sync-from-instance.ps1.
2. Track the mod changes:

   powershell -ExecutionPolicy Bypass -File tools\track-mods.ps1 -Version 0.4

   This saves modlists/0.4.json and adds what was added, removed and updated to MOD-CHANGELOG.md.
3. Rebuild the quest book if you changed tools/content/.
4. Add a section for the version to CHANGELOG.md: new and changed quest chapters, KubeJS and tool changes.
5. Export the pack and upload it to CurseForge.
6. Update the Mod List page of this wiki from the new modlists/<version>.json.

Server owners then rebuild their server with GSPackServerInstaller, which picks up the new version from CurseForge.