0.9.4
What's Changed
add: sourcing guides for every required item, with shared fragments and contract metadata
- Where to Find now has a written guide for all 95 required items — it had one. Each page
explains the activity, the steps, and links the community walkthrough it came from. - Guide sections fold away: every
##heading is a collapsible expander, open by default, so a
long step list can be collapsed while reading. - Guides can show pictures —
renders a map slide or screenshot, disk-cached like the
reward thumbs, so it works offline after the first load. - Each page shows which contract yields the item and who hands it out, when that is known.
Bought or mined items show neither row instead of blank labels.
Markdown renderer
MarkdownDocumentgains block-levelimages and{{include: key}}fragment splicing.
Both are total like the rest of the parser: malformed input stays plain text. An image between two
numbered steps deliberately does not restart the numbering.MarkdownViewerfolds each##section into a stock themedExpander(WPF-UI ships
DefaultExpanderStyle, so no hand-rolled disclosure control) and resolves images through
ThumbnailLoader— the same disk-cached path the reward and inventory thumbs use.- Fixes a latent crash:
Font()returns null when the resource is missing, and WPF throws on a null
FontFamily, so an unresolvedMonoFontFamilytook the whole guide page down.
Shared fragments
- Text several guides share lives once in
docs/sourcing/_shared/and is pulled in with a
{{include: key}}line. 14 fragments now back 95 guides; the Onyx mechanic sits in one file rather
than nine, and the two source links in one rather than twenty-three. - Fragments are keyed by front matter
name, layered bundled/%AppData%like the guides, and can
never become guides because the guide scan is top-directory only. Expansion is one level deep, so
fragments cannot reference each other into a loop. - The reload signature covers the fragment folders, so editing a shared block refreshes every guide
that includes it.
Guide metadata
- Optional
contract:andfaction:front matter render as labelled rows at the top of
How to obtain, each hidden on its own.contractholds the candidate mission name; where two
names are in circulation both are given rather than one being picked. - Data tests reject unknown front matter keys and blank optional values — a typo would otherwise
render nothing, silently, on one page.
Authoring workflow
- New
sourcing-guideskill captures how these are written: validate the name against the catalog,
fan out to every sibling item one source feeds, ask only about genuine ambiguities, and never
invent a game fact. It also records why the API, the wiki, Spectrum and the community trackers
cannot supply this, so the research is not repeated. - Two rules worth keeping: never name a shop or quote a price (both are live data that go stale
immediately — defer to the shop finder and SCMDB), and keep every list item on one physical line,
since the parser trims lines and a wrapped item silently resets ordered numbering.
Fixes a stale user-facing string that told users to correct notes in sourcing-notes.json, a file
that no longer exists.
update: rename the sidebar's Catalog item to Contracts
- The first sidebar item now reads Contracts instead of Catalog, matching the heading of the
page it opens ("Wikelo Contracts") — clicking "Catalog" and landing on "Contracts" was a small but
needless stumble.
Naming, not behaviour: Nav_Catalog is referenced only by the sidebar item in MainWindow.xaml, so
this is one string per language. CatalogPage / CatalogViewModel / the resource key keep their
names — internally "catalog" is still accurate, it is the cached data set, and renaming them would be
churn with no reader benefit.
Every other sidebar label already agreed with its page: Favorites, Where to Find and Settings match
word for word, and AboutPage reuses Nav_About as its own heading so the two cannot drift. Catalog
was the only real mismatch. Inventory / "My Inventory" is left alone — a possessive page heading over
a short nav label is the same pattern this change lands on.
fix: inventory quantity field showed only a single digit
- The quantity box on the Inventory page cut the number off after one digit, so a stock of 10000 was
unreadable and unverifiable while typing. It now shows five digits comfortably, with room for six.
The box was sized 110px, which looked generous but is not how a NumberBox divides its width: the
inline spin buttons take their desired size first and the text area receives only the remainder.
Buttons plus padding came to roughly 95px, leaving ~14px for the text — exactly one digit. Widened to
150px, sized from the real requirement (scrip is traded in the tens of thousands, so five digits is
the floor) rather than from how the control looks.
The reasoning is recorded in a comment next to the value, because the number reads like arbitrary
padding and the obvious "tidy-up" is to shrink it back.