Fields of Mistria characters
Use this character roster when you need a name, birthday, role, affiliation, or relationship state without opening a string of separate pages. Birthday and role questions can stay on this page until a source-level detail is genuinely needed. Characters remains bound to the v1.0.2 capture.
Steam 1.0 release ·Characters data boundary
Start this characters check with the displayed count, then keep the chosen field and internal record provenance together when the answer affects a longer route.
Characters lookup
35 records shown · v1.0.2
Community reference images · not an official source
35 records shown · Name A–Z
No records match this lookup.
A useful character search starts with the clue the player actually remembers. Enter a full or partial name for a direct match, or choose occupation, affiliation, marital state, or species when the question concerns a group rather than one resident. The counter shows how many of the 35 captured records remain after every active control is applied, so a narrow result can be distinguished from an empty source field. Birthday text and roles stay beside the character name because those facts answer different planning questions: a birthday helps with the calendar, while an occupation or affiliation helps locate the right social context. The roster does not convert those fields into gift preferences, heart requirements, daily schedules, or romance eligibility. Those claims need a page that captured them explicitly. When two names or roles look similar, compare the stable record id and recheck the displayed fields and version boundary instead of assuming that one profile supplies the missing facts for another. This keeps a quick resident lookup useful without turning a bounded roster into a complete relationship simulator.
What this lookup covers
The roster exposes the fields that the captured pages actually share: birthday text, occupation, affiliation, marital state, species, gender, captured community record, and revision id. A missing value is shown as “Not captured”; it is not inferred from a different character or from a guide. Search checks every exposed field, while the field and value controls narrow the same 35-record boundary. Adeline is included as a real record and links to her captured page, making the lookup useful for a specific villager question. The structure also keeps identity fields separate from relationship assumptions, so an empty marital or affiliation value cannot be mistaken for a confirmed negative. The count is a boundary for this revision, so a future addition can be recognized as a new record rather than silently folded into an old result. This keeps a villager comparison reproducible when names, roles, or relationship fields change. This section keeps the 35 characters records inside the v1.0.2 capture separate from later research.
The shared fields reveal both the strength and the limit of this character dataset. Names, birthday strings, occupations, affiliations, marital labels, species, gender, captured community records, and revision markers can be compared because they were retained as separate values. Blank cells remain blank through the interface and are labeled as not captured; they do not mean that a character has no job, no affiliation, or no relationship status. Search covers the visible record values, while filtering asks a more exact question about one selected field. That distinction matters when a common word appears in a source note but is not the value of the field being compared. The page also keeps community character identities apart from Steam achievements and official update announcements. A version announcement can describe a relationship-system change, but it does not rewrite every roster row. Use the town route for system and place connections, the updates route for dated release changes, and this page for the character fields present in the sealed community capture. Together they form a traceable route without merging unlike sources.
Version boundary
Start with the name field for a direct lookup, then switch the filter field to occupation, affiliation, or marital state when you are comparing residents. The page keeps the v1.0.2 boundary visible so later patch changes can be added without silently rewriting an older profile. Community stable record ids open in a separate tab and remain separate from the official store and announcement sources used elsewhere in the almanac. For a daily decision, pair a character result with the town and achievements routes; this roster answers who a resident is, not what a future event guarantees. For a focused comparison, keep one filter active at a time and note the displayed count before opening a source. That makes it easier to tell whether a result changed because of the query or because the captured record set was revised. Use the characters result as a documented next step, then revisit the linked source if a later version changes the field.
Every character result belongs to the displayed v1.0.2 capture boundary. That label identifies the revision context used by this almanac; it is not a promise that a resident profile will never change after the capture date. A later source revision can add a schedule, correct a role, or change wording, which is why the page keeps record ids, revision ids, and outgoing internal record provenance visible. For a decision that depends on an exact current behavior, recheck the displayed fields and version boundary and compare its revision with the boundary shown here. Local search and sorting never modify the captured values, and the site does not store a private relationship state for these roster rows. The safe workflow is simple: find the resident, read the fields that are actually present, note any uncaptured value, and follow the source when the missing detail would affect a gift, event, route, or romance decision. If an official patch changed the underlying system, check the dated update timeline as a second source rather than treating an older community row as proof of the new rule. A roster result is therefore a starting point for a social plan, not the plan itself. Keep calendar, preference, and event questions attached to their own evidence so one convenient identity page does not accumulate unsupported behavior claims.