Quests

Minecraft 1.21.1Fabric + NeoForgeTenet 0.2.0

A questQuestOne objective with a title, an icon, a position on the canvas, and the tasks that complete it. The unit a player sees and ticks off. is one file, and this page is the fields it can carry. Three groups: how it introduces itself, where it sits on the canvasCanvasThe pannable, zoomable surface quests are drawn on. A quest's x/y are its position on it, in canvas pixels., and what it does — dependencies, progression, visibility and gates. The taskTaskOne thing a quest asks for — items, a kill count, a dimension reached. A quest has several; all of them must be done unless minRequired says otherwise.See also Rewards and rewardRewardWhat a quest gives on completion: items, experience, a command, or a loot crate. Separate from tasks, and evaluated only once.See also Tasks it holds have pages of their own.

{
  "id": "punch_a_tree",
  "title": "Punch a Tree",
  "subtitle": "Eight logs, and it counts them itself",
  "description": ["Everything worth having starts with a tree."],
  "icon": { "item": "minecraft:oak_log" },
  "x": 0,
  "y": 0,
  "tasks": [
    { "type": "tenet:item", "item": "minecraft:oak_log", "count": 8 }
  ],
  "rewards": [
    { "type": "tenet:item", "item": "minecraft:wooden_axe" }
  ]
}

Identity#

Chapters have ids, titles, subtitles and icons too, and the same rules apply to them. A chapter's subtitle is the one line under its name, drawn as the second line of its sidebar row's hover, and it is translated with chapter.<id>.subtitle — see Languages. A chapter group has an id, a title, a description and an icon, and no subtitle: a group is a heading over chapters, and a second line of prose above them belongs to the chapter it is about.

Tags#

Quests, chapters, chapter groups, tasks and rewards each carry an optional tags list: words the object answers to in lookups by tag. A lookup of #village — in a command, in a script, or in an open_quest click — resolves to the first object of the asked kind carrying that tag, in declaration order. Dependency edges keep their id-or-alias charset (a # there is refused), so tags name one thing to open or check rather than gating anything.

Each tag is lowercase letters, digits and underscores (^[a-z0-9_]{1,64}$), the same rule an id follows; anything else is an error. Quests, chapters, tasks and rewards edit tags as a comma list in the editor; a group's tags are file-only, like its aliases. There is no quest-book text search over tags yet: they are stored, validated, resolved for #tag lookups, and search integration is future work. FTB Quests calls this tags, present on every object — its one use in the reference pack is ["village"] on a quest.

Icons#

An icon is one of four arms, named by its key:

{ "item": "minecraft:oak_log", "count": 1 }
{ "texture": "my_pack:textures/gui/emblem.png" }
{ "sprite": "occultism:block/chalk_glyph/0" }
{ "entity": "minecraft:creeper" }

An item is drawn as the item, with its count and data components. A texture is a file's path — textures/ and .png included — drawn stretched into the icon's box; a path nothing holds draws the missing texture. A sprite is an atlas region id, drawn from the atlas into the icon's box; a region nothing holds draws the missing mark. An entity is drawn as its spawn egg where one exists; an entity with no egg draws the missing mark naming it. The item arm is the shape every file written before the union uses, so old files read unchanged. Naming two arms warns, naming the winner and the ignored arms; only the winner draws.

Texture and sprite icons are drawn on quest nodes (and the links that mirror them), the quest card, task and reward rows, sidebar rows, the book's header, and toasts. The in-game picture picker sets any arm: its Item tab picks items, File picks pack textures with thumbnails, Sprite takes an atlas id with a live preview of exactly what the node will draw, and Entity searches mobs. Setting one arm clears the others.

Writing a description#

A description is an array of strings, one per paragraph, and each is read as markdown when a player opens the quest:

• **bold**, *italic* (or _italic_), and `code`.
• [text](https://example.com) for a link — underlined, and it opens in the browser when clicked. Only http and https open; anything else is refused with a word in the status bar.
• A line starting with #..###### is a heading, and one starting with - , * or + is a bullet. Headings come in four sizes: # is twice the body text, then ## at 1.75×, ### at 1.5× and #### at 1.25×. ##### and ###### use the smallest of those, because the card's font has one size and the body's is its floor.
• A backslash escapes the punctuation that would otherwise be markup -- a backslash, *, _, a backtick, a bracket, a parenthesis, #, - or + -- so \* is a literal star and \a stays \a.

A line break is a line break: markdown here does not join lines into flowing paragraphs, because these files are written a line per paragraph and joining them would re-wrap prose an author had already wrapped. The file keeps the raw markdown — the editor shows it as written, and only the reader's card renders it.

FTB text codes#

A description converted from FTB Quests keeps its text tokens, and the reader's card reads them — the converter passes pack text through verbatim, and the tokens are a render-time reading:

• & and § colour and style codes (&a green, &l bold, &o italic, &n underline, &r reset), &#RRGGBB hex, and &z rainbow. Struck-through (&m) arrives underlined and obfuscated (&k) arrives plain: the seam has no run for either, and those are the closest survivals.
• {@pagebreak} starts a new paragraph run — the card scrolls rather than paging, so a boundary is a break and not a pager.
• {image:path width:N height:N align:center} draws the picture inline in the prose, fitted to the column and centred unless told otherwise. Files stretch to fill, like chapter pictures; the same .png-means-file rule applies, and a file the pack does not ship draws nothing rather than breaking the card.
• {open_url:...} opens through the same http/https-only rule a markdown link uses, and {substitute:key} resolves against the locale overlay.
• A whole paragraph that is a raw JSON text component reads its clickable runs: open_url opens through the same http/https-only rule, and FTB's change_page — whose value FTB's own reader treats as a quest to open rather than a book page — opens that quest by id or alias. Any other click action reads as words with nowhere to press, and docs: addresses read the same way: there is no guide shelf here. Colours and emphasis inherit down the component the way vanilla reads them.
• \& is a literal ampersand — which is also the rule for Tenet-native packs: & starts a colour code, FTB-style, so R&B reads as R and a literal one is written \&.

Titles, subtitles, chapter titles and element words read the words without the ink: those surfaces draw one ink, so &aChapter 2 reads as Chapter 2 in white. Descriptions wear the colours, because the card draws run by run. The quest card's header and the canvas labels wear them too — a title there draws its runs, truncated like plain text, because colours are widthless and styles are dropped where widths are measured. Everywhere else a title is one ink: sidebar rows, toasts, captions and the HUD read the stripped words, and never the raw codes.

A chapter's and a group's description are parsed and shown to nobody: neither reaches the reader's card -- a chapter's does not cross to the client at all, and the chapter panel shows only a paragraph count -- so the reading above is a quest's description. The editor always shows text that a reader would not yet see, which is the point of the hideTextUntilComplete flag below.

The node on the canvas#

A shape of none draws no panel at all: the node is its icon, and the whole square is clickable. Every other outline is hit-tested by its own pixels, so a click lands on exactly what is drawn.

A quest's coordinates are its own; a chapterChapterA row of related quests on the canvas, with its own icon and its own progression rules. Belongs to exactly one chapter group. is never positioned. Its frameFrameA chapter's bounding rectangle on the canvas, computed from the quests inside it plus padding. Never authored — the book works it out. on the canvas is computed from the quests inside it plus padding, so moving a quest moves the frame with it.

Dependencies#

dependsOn is a list of quest ids — or their aliases — that must be satisfied before this one is open. They may live in other files, and a reference that resolves to nothing is an error rather than a quiet lock. A chapterChapterA row of related quests on the canvas, with its own icon and its own progression rules. Belongs to exactly one chapter group. whose progressionMode is linear supplies the chain itself, so its quests need no dependsOn at all.

minRequired replaces the count, not the bar: the mode still decides what each one must reach, so one_started with minRequired: 2 means "any two of these, started".

Optional quests#

A quest with "optional": true is marked a side quest — a branch the player may do, drawn with its dependency lines. The flag is a marker, not a gate: an optional quest gates the quests that depend on it exactly like any other quest (that is FTB Quests' optional, whose only other effect is excusing the quest from chapter completion). minRequired counts every dependency, and the card's "2 of 3 met" counts the same denominator the engine enforces.

Early progress#

A quest with "flexibleProgress": true lets its tasks be worked on before its dependencies are met; completion still waits for them. A quest that says nothing follows its chapter's defaultFlexibleProgress — either true makes the quest flexible, and there is no opt-out, so a migration tool writes the resolved value onto each quest and leaves the chapter default off.

What that means in play: progress on a flexible quest accumulates while its gate is shut — the card shows the real counts, and the dependency lines show what is missing — and an already-maxed quest completes on the first tick after its gate opens. A submit or a kill that maxes the last task does not finish the gate's other quests in the same call; the next tick does that, once per team rather than once per node.

While the gate is shut the quest still draws gated — padlock, dimmed node, REQUIRES x of y — although its state stays measurable rather than locked. An UNLOCKED reading is what made whole flexible chapters look open; FTB shows such quests locked, and the padlock is what tells a player measuring from a player who may claim.

Do not confuse this with the chapter's progressionMode: that one chains a chapter's quest list in order (flexible there means "order means nothing", linear means the list is the road), and this one is about whether dependency edges block task progress. Two different axes.

A chapter's own dependencies#

A chapter can wait on other chapters, the same way a quest waits on quests. Until its rule is met, every quest inside it is locked — it cannot be started, finished or claimed, whatever its own dependsOn says — and by default the chapter is listed, dimmed, with what it is waiting for on hover.

{
  "id": "the_deep",
  "title": "The Deep",
  "dependsOn": ["first_steps"],
  "prerequisiteMode": "all_completed",
  "completesWhen": ["the_festival"],
  "hideUntilDependenciesComplete": true
}

Note the pair of similar names, because they are the ones an author mixes up: hideUntilDependenciesComplete withholds this chapter's row until its own gate is met, while defaultHideUntilDependencies* decide what its quests do about their own dependencies. The editor labels them "Hide until open" and "Hide quests until done" for that reason.

A chapter with nothing to show is also left out of a reader's book on its own: if every quest in it is hidden — by these defaults, by the flags below, or because the chapter holds no quests — the sidebar row goes with them, and returns the moment one quest is visible. That is what makes a chapter of fifty unrevealed quests behave like a chapter that has not started yet rather than a door into an empty canvas. An author in edit mode sees it either way.

A chapter's state is locked → open → started → completed:

• locked — its dependsOn rule is unmet.
• open — the rule is met, and nothing inside it is done.
• started — any quest in it has progress or is finished.
• completed — every quest in completesWhen is done.

A chapter with no completesWhen therefore never reports completed, which is a real state: a chapter only ever waited on as "started" needs no completion to declare. A chapter that another chapter waits on as completed must declare one, and the loader reports the pair that does not — that combination is a chapter that can never be opened.

The two graphs are checked separately: a quest cycle is refused, and so is a chapter cycle, including the one that is easy to miss — chapter A waits on chapter B, and B is finished by a quest inside A. Both are reported with the chain, because a loop like that is otherwise a chapter that simply never opens.

Hiding is only how a gated chapter is presented. The gate itself is enforced by the server whatever hideUntilDependenciesComplete says, so a command or a script cannot complete a quest in a chapter that is not open.

Drawing the lines#

The chapter's dependencyStyle sets how its lines look; dependencyLines overrides one dependency's line, axis by axis. Only the axes a line names are overridden — the rest fall back to the chapter, then to the built-ins (chamfered, a chevron at the target, solid, thin).

Older files that write the single arrows axis (none, one, both, many) are still read: none is a blunt end, one a chevron at the target, both one at each end, and many a stream at its old 24-pixel spacing. The editor writes the three current axes, and a chapter's default may set all of them — only anchors and split handles are per-line.

For a whole chapter:

{
  "dependencyStyle": { "form": "curved", "arrowHead": "triangle", "arrowPlace": "stream", "dash": "solid" }
}

Progression and repeats#

A repeatable quest's cooldown runs from the moment its last unclaimed reward is claimed, not from the completion: the round ends when its payout is fully collected, and the count moves then too. A repeatable with nothing to collect — no rewards, or everything automatic — resets at completion instead, because no claim will ever arrive to end it.

The chapter's own progressionMode decides whether the chapter is walked one quest at a time or unlocked as it becomes available:

• flexible — every quest whose prerequisites are met is open. The default.
• linear — the order of the chapter's quests list is the progression: each unlocks when the one above it completes.

A quest in a linear chapter that also declares dependsOn must satisfy both its own edges and the quest above it. That is a real combination — a linear spine with one quest that also needs something from another chapter — so nothing warns about it.

Visibility#

Nine flags, each hiding one different thing. All of them are presentation: a hidden quest still loads, still counts for progress, and is always shown to the editor.

Recipe viewers#

A recipe viewer with Tenet's pages shows the questline beside the recipes: EMI renders full quest pages, JEI and REI share a fallback over the same item lookup, and where more than one viewer is installed the first in that order wins outright — the others register nothing. All three are soft dependencies: a client without any of them loses nothing.

Traffic goes both ways. Pressing a quest in the viewer opens the book on that quest — a press for a quest the tree no longer holds opens nothing rather than an empty card. Pressing a task or reward row in the book opens the viewer's recipes for what the row names, tags included where the viewer supports them; with no viewer installed the press is inert. Which quests a viewer may list is the disableRecipeMod flag above: a hidden quest never reaches the viewer, because the server resolves it onto the wire and the client holds no file record to second-guess.

Announcements#

disableToast quiets a completion. It lives on the quest, on every task, and on every reward — FTB Quests' disable_toast on every quest object — and either silence wins over the auto-claim ladder: a quest that asked for no toast gets none, whatever its auto says.

Held payouts#

/tenet rewards block holds a team's payouts, and a held reward stays outstanding until it is released. Two flags exempt a payout from the hold — FTB Quests' ignore_reward_blocking on both quest objects:

Either flag wins: a held team still pays a quest that asked to be exempt, and a held quest still pays the one reward on it that asked. See Rewards.

Stages#

requiresStage is a namespaced id the player must have for the quest to be open to them:

{ "requiresStage": "my_pack:inducted" }

It is the one gate here that is per player rather than per team: a quest gated on a stage is open to a player who has it and locked to one who does not, even in the same party. Stages are granted by stage rewards and removed by them, read by stage tasks, and manipulated from scripts — see KubeJS scripting.

requiresStageTeam: true reads the gate from the team's stages instead: one member's induction opens the quest for everybody. The team half is granted by a stage reward with teamStage: true, asked about by a stage task with teamStage: true, and handed out by hand with /tenet stage add-team. FTB Quests calls the flag team_stage.

A stage is the gate for one player, and it is the wrong tool for "this chapter follows that one": repeating it on every quest in the chapter is worse than one dependsOn on the chapter, which is checked and cannot be missed on a quest somebody adds later. Reach for a stage when the gate really is per player — "this is the tutorial, and only the person who did it may see this" — and for a chapter gate use the chapter's own fields above.

What a quest inherits#

These live on the chapter manifest and apply to its quests unless a quest overrides them:

A chapter's palette reaches everything that belongs to it — the canvas, the quest cards and their buttons and fields, the picker and rename cards, and the tooltips describing them — while the book's own chrome (sidebar, header, menus, tools panel, notices) keeps the player's theme. themePatch is how a chapter sets "raised surfaces at #24242E, radius 4" without shipping a whole theme file.