Editorial Standards
LootCalc is the organizational author and publisher of this site. This page explains how sources, formulas, calculator changes, and corrections are handled; it does not claim a named expert or independent reviewer where none is shown.
What We Publish
Calculators
Interactive tools for expected value, bad-luck protection, drop odds, route timing, and currency planning.
Guides
Practical explanations that document assumptions, formulas, and limitations behind the calculators.
Reference Pages
Game hubs and methodology pages that help readers find the right tool and understand how results should be interpreted.
Public source examples
These are examples currently cited by specific calculator pages. A link here does not make it a source for every game or formula: each page must identify the exact claim it supports, its verification date, and whether the claim enters the calculation.
Review And Update Process
Each sourced rule carries a verification date. That date records the last check; it is not a promise of continuous monitoring or a fixed refresh schedule. A newer patch or a reader report requires the affected rule and formula to be checked again.
Formula changes are checked against simple examples before publication. For probability pages, we prefer transparent math over unsupported claims: readers should be able to see what the calculator assumes and where the numbers come from.
We do not present anonymous personal credentials as a substitute for clear sourcing. If a page relies on community observations or incomplete public data, it should say so directly.
Ownership And Review Matrix
Drop-rate calculators
Pages such as Barrows, relics, loot tables, and boss spawns are checked against the published drop table or the closest public source we can cite. When a calculator uses a sample observation log instead of a confirmed rate, the page should call that out as a sample, not as an official probability.
Economy and EV pages
EV and GPH pages separate stable formulas from volatile prices. The formula can remain valid while item values move, so calculators expose user-editable costs, run times, and value assumptions instead of pretending a single price snapshot is permanent.
Planning tools
Budget, route, and timeline tools are reviewed for input clarity first. A user should understand which fields are required, which fields are estimates, and which outputs are long-run averages rather than promises about a single run.
Policy and trust pages
Legal, privacy, contact, author, and methodology pages give readers a correction path, applicable disclaimers, and the source policy behind the calculators.
What A Review Checks Before Publication
A calculator update starts with the user-facing question: what decision is the page helping a player make? If the page only repeats a public drop rate without adding a worked example, an adjustable assumption, or a clear caveat, it is not ready to be published as a separate page. A useful page should let the reader inspect or change the inputs and reproduce the output.
We then check the math path. Simple independent drops should use the complement rule; mutually exclusive reward tables should not double-count outcomes; time-efficiency pages must subtract costs before converting to hourly value; and any bad-luck protection model must document where the guarantee or ramp starts. If a mechanic is unknown, the page should offer an override rather than claiming certainty.
Finally, we check whether the page gives readers enough context to challenge the result. Strong pages include a last-updated date, a source note, a link to methodology, and a route for corrections. For material changes, the update should be visible in the page copy or changelog so returning users know why the output changed.
Corrections, Versioning, And Retesting
We treat corrections as part of the publishing process, not as a separate support queue. A reported formula error is checked first because it can change every output on a page. A source disagreement is checked next: we compare the report against official notes, public wiki revisions, API documentation, or the data table already cited by the page.
When an update changes a calculator result, the page should explain the practical effect in plain language. If a patch changes a drop table, readers need to know which inputs, model boundary, or outputs changed. If the update only clarifies wording or fixes a display bug, the page can say that too.
Retesting is most important after live-service patches. Seasonal reward tables, rotating vendors, item values, pity rules, and route times can all drift after publication. A page stays useful when the fixed math, editable inputs, and dated source notes make that drift visible instead of hiding it behind a single unsupported recommendation.
Corrections
Corrections, source updates, and calculator bug reports can be sent through the contact page. Include the affected URL, the source you are comparing against, and a short description of the issue.
Contact LootCalc