Getting Started with LootCalc

1. Start with the decision, not the game name

A calculator is useful only when its output changes a decision. The main LootCalc tool shapes are:

• Probability scenarios: estimate one-or-more success probability over repeated eligible attempts.
• Guarantee or pity ledgers: track a published counter, boundary, or user-entered progression rule.
• Resource budgets: compare current resources, visible costs, planned actions, and a shortfall.
• Batch accounting: subtract all direct costs from a measured batch return and normalize by maps or time.
• Progress planners: apply current progress and user-entered thresholds without predicting loot.

Browse the games directory and read the first paragraph of a tool before entering data. If you need a market history, build ranking, account scan, or route recommendation and the page does not say it performs that task, its output should not be stretched to answer it.

2. Separate sourced rules from scenario inputs

Every number should have one of three roles:

1. Sourced mechanic: a public rule linked beside the calculation and checked on a stated date.
2. Observed value: a dated price, time, cost, or outcome from a defined measurement window.
3. What-if assumption: a value chosen to explore a scenario, labeled so it cannot be mistaken for a game fact.

Do not turn a forum repetition into a confirmed mechanic. Do not mix a current price with a route time measured under a different setup. If a public source does not establish a changing value, the honest design is an editable input rather than a hidden default. The site-wide rule is documented on the Methodology page.

3. Record the full measurement boundary

A “two-minute run” is ambiguous unless it says where timing begins and ends. For a repeatable farming cycle, include travel, combat, loading, looting, banking or inventory management, reset, and return to a comparable start. Record costs from the same window. For a batch, keep the map count, gross return, direct costs, and elapsed time together instead of mixing best-case speed with average returns.

A compact evidence note can contain:

version_or_patch,source_url_or_capture,measured_at_utc,attempt_definition,input_values,time_boundary,cost_boundary,notes

4. Check the model before reading the result

A fixed independent probability uses different math from a hard guarantee or a chance that changes after failures. For a constant per-attempt chance p, the probability of at least one success in n comparable attempts is 1 - (1 - p)^n. That formula is not valid when eligibility changes, attempts are correlated, or a published state machine modifies the rate.

Expected value is also a long-run arithmetic average, not a promise for the next attempt. A value calculator must state what rewards are included, subtract direct costs before calling a result profit, and measure time before converting a per-run number to a per-hour number.

5. Use hypothetical examples as examples

Suppose a made-up reward is worth 1,000 value units and has an assumed 1% independent chance. Its expected contribution is 1,000 × 0.01 = 10 units per attempt. Over 50 attempts, the probability of seeing at least one is 1 - 0.99^50 ≈ 39.5%. These numbers teach the formula; they do not describe any named item or game.

If each complete attempt takes 120 seconds and costs 3 units, the model can show 30 attempts per hour and a hypothetical net contribution of (10 - 3) × 30 = 210 units per hour. Real analysis requires all other relevant rewards and costs to use the same boundary.

6. Read diagnostics as stop signs

Current tools reject negative values, impossible orderings, non-integer counters, and published boundaries they cannot extend. A diagnostic at a guarantee cap does not mean the calculator should wrap the input into a new cycle. It means eligibility, excluded attempt types, the current game rule, or the recorded count needs review.

7. Preserve provenance when sharing

A copied scenario URL is useful because another person can inspect the same fields. It is not evidence by itself. Include the source date or observation note, avoid personal information in labels, and verify that a copied link restores the intended values. After a patch or new measurement window, create a new scenario instead of silently overwriting the old context.

8. See three different evidence boundaries

• Apex Pack Probability Calculator: EA's disclosed minimum rate is a lower-bound estimate, while the 500 eligible-pack rule becomes a diagnostic boundary. See the linked EA disclosure.
• OSRS Barrows Calculator: the public equipment formula is sourced, while current values and full-route timing stay user-entered. See the Barrows mechanics reference.
• Minecraft Loot Table Calculator: a narrow weighted-pool mode follows documented weights and rolls; conditions, functions, and nested tables require the exact file or a direct derived probability. See the Microsoft creator documentation.

9. A pre-result checklist

• The tool answers the decision you actually have.
• Every mechanic is sourced, observed, or explicitly hypothetical.
• Version, eligibility, item, activity, and target definitions match the source.
• Prices, costs, and time use one dated measurement boundary.
• The result is interpreted as probability, expectation, budget, or progress—not as a guarantee it does not provide.
• A contradictory live-game result is documented and reported rather than normalized away.