QuestVariables.h header

QString ew::app::branching::questName(const ew::core::branching::Quest &quest, const ew::core::project::Project &project)

What a quest is called: the name of the codex entity it is, or a marker when that entity is gone.

One resolver, so the quest list, the effects wording, the variable inspector and the validator cannot disagree about what an author called something.

std::map< ew::core::foundation::VariableId, QuestVariableInfo > ew::app::branching::questVariableInfo(const ew::core::project::Project &project)

Every quest state variable in project, by id.

Built once and handed to the surfaces that need it, rather than each of them reaching into the quest registry with its own idea of how to word things. The effects editor offers the states as a picker instead of a free-text box – which is the whole of "set quest Q entry 2 to complete rather than set q_2 to 3" – and the variable inspector uses the same label, so the row an author reads after the effect runs says the same words the effect did.

QString ew::app::branching::questVariableLabel(const ew::core::project::Project &project, ew::core::foundation::VariableId variableId)

How a variable should be shown when it belongs to a quest – "Rescue the Cartographer: Find the ledger" – or empty when it does not.

The whole point of 2.12: an inspector row reading questRescueTheCarto2 = "complete" tells an author nothing they wrote, and a generated name is not a thing anybody chose.

std::vector< ew::core::branching::Variable > ew::app::branching::syncQuestVariables(const ew::core::branching::Quest &quest, const QString &name, const std::vector< ew::core::branching::Variable > &variables)

variables with quest's state variables created, renamed and re-seeded to match it.

A quest's state is story state, exactly like gold or hasKey: it changes as the reader plays, it must be inspectable mid-playthrough, it must export, and conditions must be able to test it. Giving each quest and entry a Text variable means all four already work rather than each being rebuilt in quest-shaped form – and it is why a condition can read ledgerFound = "complete".

Existing variables are updated in place, never replaced. The id is what every effect and condition in the project points at; handing out a new one would silently orphan all of them while looking, in the editor, like a rename.

The initial value is the quest's or entry's FIRST state, which is where an author said it starts. A quest whose states have been rewritten so the old initial no longer exists is re-seeded to the new first state, because a variable starting at a state its quest does not have is a condition that can never be true.

std::vector< ew::core::branching::Variable > ew::app::branching::withoutQuestVariables(const ew::core::branching::Quest &quest, const std::vector< ew::core::branching::Variable > &variables)

variables with every variable belonging to quest removed.

Deleting a quest must take its variables with it. Leaving them behind would fill the inspector with rows nothing writes to and nothing explains – the exact residue that makes a variable list stop being read.