1. Treat the current Details screen as the numeric source
Open the exact Wish and capture its Details panel. Record game version, server, verification date and time, banner name, Wish type, target tier, guarantee text, current counter, carryover rule, selected target, and any featured-guarantee or path state. Official web notices often summarize a mechanic but direct players back to Details for the full current rule.
2. Preserve the official web evidence separately
Use these HoYoverse publications as versioned context:
- current Character Event notice;
- Character Event Wish-2 mechanics;
- Capturing Radiance Q&A;
- Version 5.0 update details;
- Chronicled Wish rules and FAQ.
Store the URL, publication date, later edit date when shown, and the exact claim you used. Do not cite the home page, a user post on the same platform, or a screenshot detached from its banner/version as equivalent evidence.
3. Identify the counter family
HoYoverse states that Character Event Wish and Character Event Wish-2 share their guarantee count and that this count is independent of other Wish types. The same publication says the shared count carries to future periods. This supports combining history within that family only. Weapon, Standard, Chronicled, and other current or future types require their own Details and must not be merged because their names all contain “Wish.”
4. Reconstruct the current count
Count eligible wishes since the last result that resets the guarantee counter under the applicable current rule. Preserve the history pages or export used. If history is incomplete, label the counter uncertain rather than treating the oldest visible record as a known reset. A count equal to or above the entered hard ceiling is a diagnostic: reconcile the family and reset event instead of applying modulo.
5. Copy the hard guarantee, do not infer it from a name
Enter the current ceiling exactly as disclosed in Details. HoYoverse's public Character Event Wish-2 examples and Chronicled Wish FAQ demonstrate that ceilings and carryover exist, but the calculator does not transfer one publication's number to every banner. A future Wish type, limited event, or rule revision can differ even if the UI uses familiar rarity terms.
6. Represent selected-target state explicitly
The guarantee for “a top-rarity result” and the guarantee for “this selected item” are different conditions. Enter the maximum number of target-tier results still required under the exact current state. Use one only when the next qualifying result is guaranteed to be the selected target. Otherwise record why a larger number is supported: featured guarantee, path progress, designated item, or another current Details rule.
7. Read Capturing Radiance as a conditional disclosure
HoYoverse's February 2025 update to the Capturing Radiance Q&A gives a base trigger probability and says the consolidated promotional-character probability applies when winning a 5-star character in the Event Wish. It also describes a guaranteed trigger based on a sequence of promotional-character outcomes. This is not a complete probability that the next wish is a 5-star, and it is not a stateless replacement for the selected target input. Preserve the conditional denominator and relevant history.
8. Version Epitomized Path state
Version 5.0 reduced the maximum Fate Points required for Epitomized Path from two to one. Earlier official articles accurately describe the older two-point system but are no longer sufficient for a current plan. Record the charted target, current Fate Points, reset/expiry rule, and current Details wording. Do not let a generic “weapon banner” selector import a historical maximum.
9. Keep counter carryover and path expiry separate
HoYoverse's Chronicled Wish FAQ says its wish guarantee count carries within that Wish type while Fate Points do not carry into the next period. This is a useful model-design lesson: a counter and a target-selection state can have different lifetimes. The log needs separate fields for each, and a saved plan should state which values survive the event boundary.
10. Do not publish an unverified soft-pity curve
The former LootCalc pages used fixed soft-pity starts and an implied probability ramp derived from community datasets, then described the outputs as official. The official web sources cited here do not publish a complete per-wish rarity schedule. Without a current primary schedule, LootCalc does not calculate a next-pull chance, cumulative chance, expected pull count, or percentile. A hard ceiling remains useful without pretending the intervening distribution is known.
11. Audit the guarantee-ceiling formula
Let H be the current hard ceiling, c the current count, and t the maximum target-tier results still required. The conservative number of additional wishes is(H − c) + (t − 1) × H. The first term respects current progress; later terms represent complete worst-case cycles. An early result ends the old scenario and starts a new record with its actual reset state.
12. Bound in-game resources without forecasting income
Record wish items already owned, Primogems already owned and allocated, and the current exchange cost per wish. The planner spends compatible wish items first and applies Primogems only to the remainder. It never assumes future events, commissions, exploration, subscription rewards, shop purchases, or a six-week version income. Report a shortfall plainly; do not turn it into purchase or “skip/pull” advice.
13. Keep a state-change log
verified_on,server,game_version,wish_type,banner_name,target,details_capture,counter_family,current_count,hard_ceiling,max_target_tier_results,featured_or_path_state,owned_wish_items,owned_primogems,primogems_per_wish,planned_wishes,actual_wishes,result_obtained,new_counter,new_target_state,share_url,notes YYYY-MM-DD,server,exact version,type,name,target,path or URL,family,0,0,1,state,0,0,0,0,0,result,0,state,URL,record real observations only
This is an empty schema. It is not a collected pull dataset, proof of a probability curve, or evidence that LootCalc accessed an account. Do not insert illustrative rows into a file presented as gameplay observations.
14. Preserve corrections and source edits
HoYoverse can edit an existing Q&A, as happened with the later Capturing Radiance clarification. Record both the original publication and the date you verified the current text. When a rule changes, preserve the old plan as historical and create a new one. Never rewrite an old observation so that it appears to have used a rule that did not yet exist.
Use the planner
Enter the current values in the Genshin Wish Guarantee & Resource Planner, then save the URL beside the Details capture and state-change log.