Fields of Mistria town rank

49 records shown · Name A–Z

No records match this lookup.

The town lookup connects named places, public systems, player tasks, and versioned source records without turning them into a live quest tracker. Search a location, repair phrase, request, renown term, or source name, then use type, category, source, or version fields to isolate the relevant family. A place row can identify where a subject belongs in the captured data but does not provide a complete opening schedule or coordinate. A system relation can connect town repair, requests, skills, or collection work without proving every prerequisite and timing rule. Version labels distinguish a current system note from an older announcement, while the Updates route remains the source for official chronology. The result count reflects the active controls and does not represent unfinished quests in the player’s save. Use the lookup to find the documented checkpoint, read the exact fields shown, and open the source when a route depends on a schedule, dependency, reward, or state that the compact row did not capture.

Town records can include names, types, categories, player-task phrases, source text, location relationships, version ids, tags, page identities, revisions, and explicit links to neighboring systems. The page preserves those values separately so a relation is not mistaken for a requirement and a version phrase is not mistaken for the current state of every record. Broad search helps recover a task from remembered wording; the field filter confirms whether that wording belongs to type, category, source, or another displayed value. The relationship panel shows connections present in the sealed records, not a generated quest graph. Character pages provide resident identities, skills provides progression-oriented records, and updates provides dated official changes. None of those routes should fill a missing town field automatically. If a place lacks hours, a repair lacks dependencies, or a request lacks timing, follow the source and keep the compact result limited to the evidence it actually contains.

The town surface uses the displayed v1.0.2 capture context and keeps version ids attached to records that expose them. This is important because Early Access notes, the full 1.0 release, and the current patch can describe different states of repair, renown, relationships, or public systems. The official timeline establishes when a change was announced, while the structured town record shows which fields were captured from its community source. A later revision should add new evidence without erasing the older boundary. For a current route, find the place or task, check its source and version fields, and verify any missing dependency or schedule at the linked page. The almanac does not read quest progress, synchronize a calendar, or mark town repairs complete. Search and sorting are local reading controls. Keeping them separate from save state makes the page useful for orientation while preventing an old announcement or partial relation from being presented as a guaranteed current quest rule. When a plan spans several days, retain the record’s version and source beside the task name. That context is more dependable than a detached note after a patch changes the surrounding system. Add the record type as well when the same phrase can describe both a place and a public system.