This bug lookup keeps the complete 94-record boundary in one readable field guide. Its strongest use is a quick field check that keeps an uncertain spawn detail visibly uncertain. Bugs remains bound to the v1.0.2 capture.
Current · v1.0.294 structured records94 record images
Start this bugs check with the displayed count, then keep the chosen field and internal record provenance together when the answer affects a longer route.
Captured family · 94
Bugs lookup
94 records shown · v1.0.2
◇Community reference images · not an official source
The bug lookup turns a 94-record list into a smaller set of captured clues. Search by name when the target is known, or filter season, location, time, sell value, rarity, or museum status when the player remembers only part of the encounter. The result count reflects the current search and selected field value together. Sorting can place names or numeric values in a stable order, but it never converts rarity into encounter odds or combines several fields into a hidden score. Time and location deserve special care because the public records do not use one perfectly uniform format. A numeric-looking location stays as captured rather than being renamed, and an empty time cell remains not captured. Museum membership and sell value answer separate questions: one explains collection purpose, while the other records a captured economic field. Use them together only after confirming the season and location clues that actually belong to the same row. The internal record provenance is the correct next step whenever abbreviated data would change the route a player plans.
Bugs
What this lookup covers
The visible fields come directly from the bug records: season, location, time, sell value, rarity, museum flag, museum set, source text, tags, page update marker, and revision id. Some location values are numeric in the source capture; they remain numeric rather than being reinterpreted as a place name. Search and filters consume the rendered record fields, and sorting by sell value uses only numeric values that are present. The route does not invent weather or spawn schedules. It also leaves collection flags next to the source text, which helps distinguish an item relevant to the museum from an item that is simply valuable to sell. The page treats a museum flag, a captured value, and a time string as different kinds of evidence. Combining them in one row is convenient, but it does not make one field explain another or turn an observed rarity label into an official encounter rate. This section keeps the 94 bugs records inside the v1.0.2 capture separate from later research.
Rows can include a bug name, season, location, time string, captured sell value, rarity, museum flag or set, source text, tags, page update marker, page id, and revision id. The interface exposes those fields without treating the richest row as a template for every other species. Missing weather, frequency, or schedule information is not inferred from a neighboring entry. Search is intentionally broad enough to find a clue in the visible record, while the field selector is exact enough to test whether that clue is stored as season, location, time, or another category. This distinction helps when community wording contains the same term in a note and in a structured field. The bug family connects to the museum alongside fish, forageables, and artifacts, yet each route remains independent because their spawn and collection fields are not interchangeable. The page provides a documented shortlist, not a universal calendar, and the absence of a value should narrow the claim made from the row.
Version control
Version boundary
Search for a species name, filter by season or museum status, and use the displayed structured fields for the page-level context. A “Not captured” cell marks the edge of the public boundary and keeps the page honest when a field is missing. The record set is tied to v1.0.2, while the Updates route keeps official release chronology separate from community field coverage. If you are deciding what to carry home, compare value only after checking the season and location cells; the page does not claim that every captured bug can appear at every time. Search and filter are most helpful when the player remembers one clue, such as a season or museum set. Once a candidate appears, open its source if the question depends on a numeric time, a location code, or a field that is marked as not captured. Use the bugs result as a documented next step, then revisit the linked source if a later version changes the field.
The visible version marker binds this bug collection to the v1.0.2 capture used for the current almanac. It does not claim that global records, community pages, or the game itself will remain unchanged. A later patch or source revision can add encounter details, correct a value, or change a collection relationship. The page keeps stable ids and internal record provenance so that future information can be compared rather than silently substituted. For a practical check, select the season or museum field, read the time and location exactly as captured, and recheck the displayed fields and version boundary if either field looks abbreviated or missing. Official release announcements belong on the updates timeline; they can explain when a system changed but do not automatically populate the row-level bug table. Local controls alter only visibility and order. They do not save a collection state, calculate spawn chances, or write back to the source. That boundary keeps the lookup fast while preserving a clear route to the evidence behind each entry. When a personal collection note depends on a narrow time window, copy the source wording and revision alongside the name. This makes a later discrepancy easier to diagnose than a bare checklist mark. Preserve the season as well, since an isolated time string does not identify the full captured encounter context.
