Methodology

How Slime RNG Guide computes simulator ranges, odds tables, and tier scores: and how measured, modeled, and community-reported numbers are kept separate.

The Monte Carlo method

The simulator uses the same rule on every page: convert the published or modeled base rate into a per-roll chance, multiply by the luck input, then run 10,000 first-hit trials. I keep median and 95 percent ranges visible because first-hit RNG has a long unlucky tail.

The 100-roll sanity check is intentionally small. It is not proof of every hidden rate. It is a guardrail against obvious implementation mistakes on the common and uncommon side, where a bad formula would show up quickly during normal play.

When community sources disagree, I keep the conservative denominator until Stouts Studio or repeated in-game evidence points elsewhere. That is why the Inverted rate is modeled at 1 in 100,000,000 and marked as a model rather than a private server dump.

Why I show ranges instead of one number

Slime RNG drops are geometric: every roll is an independent shot at the same chance, so two players with identical luck can finish a Mythic chase thousands of rolls apart. A single "expected" number hides that completely. Instead, every calculator on this site reports a median plus a p75 and a p95, drawn from 10,000 simulated chases per query. The median tells you the typical result; the p95 tells you how bad the unlucky tail gets. For any rarity, p95 sits near three times the median: that is not a quirk of this game, it is what a geometric distribution does, and it is the single most useful thing to understand before starting a long chase.

The 100-roll validation log

I cannot datamine the game, so I sanity-check the model against real rolls. On 2026-06-18 I rolled 100 times at a 3x luck setup and compared the early-rarity outcomes: Common and Uncommon hits: against the simulator's expected range. They landed inside it. A 100-roll sample is far too small to confirm a 1-in-100,000,000 Inverted rate, and I do not claim it does. What it does catch is a broken formula: if my Common rate were wrong by a factor of two, a 100-roll test would expose it immediately. Treat it as a smoke test, not a proof.

Measured, modeled, and reported: kept separate

Three kinds of numbers appear on this site and I label which is which. Measured numbers come from my own timed sessions: coins per minute in a biome, the gap between hits during a logged run. Modeled numbers come from published-or-inferred base rates fed through the math: the simulator times, the cumulative odds. Reported numbers come from the community: Discord hit reports and screenshots I aggregate but cannot personally verify. When the three disagree, I say so on the page rather than averaging them into one confident-looking figure.

The tier formula

Tier scores are not vibes. A slime's ROI score is its cash-per-minute divided by log10 of its rarity denominator: a value that rewards income while penalising how hard the slime is to actually obtain. Huge Lucky gets an extra qualitative note on top, because a luck bonus improves every later roll beyond its own cash contribution, and a pure cash formula would understate it. The formula is printed on the tier list itself, so you can disagree with the weighting and recompute it yourself.

What I can't verify

Exact drop rates above Legendary, hidden pity systems, and event-only rates are the honest gaps. Stouts Studio does not publish a rate table, so the high-rarity denominators here are community-confirmed estimates cross-referenced against dozens of hit reports, not official figures. Where a number is an estimate, the page says "modeled" or "approximate." If that ever reads as false confidence, tell me: flagging an overstated claim is as useful as flagging a dead code.

Update cadence

Pages carry a visible "last updated" date and the author byline. After a major Slime RNG patch I re-test codes first because they expire fastest, then rates and zones. A guide that has not been re-checked since the last big update is a guide I would not trust either, which is why the date is on every page instead of buried in a footer.

What I mark as measured

I split the site data into three buckets before it reaches a guide. Measured means I saw it directly in a normal Roblox session or reproduced it with the browser-side simulator. Community modeled means multiple public player reports point to the same number, but Stouts Studio has not published an official table. Needs-check means the name or recipe appears in public play notes, but the exact stat still needs a screenshot or repeatable test.

That split matters most for rare targets. A Common or Uncommon slime can be checked quickly because the hit rate is high. A 1 in 100,000,000 target cannot be verified by one person in a weekend, so I compare reported hits against the expected distribution and label the result as a model. I would rather show that uncertainty than pretend the game exposes a complete API.

How corrections get handled

When a reader sends a correction, I look for the page URL, the exact number being challenged, and the evidence trail. A screenshot of the in-game panel is strongest. A Discord message is useful if it names the patch or code drop. A copied table without a source is treated as a lead, not as a correction. If the change affects a calculator, I re-run a small sanity check before the next build.

Small wording fixes can publish the same day. Formula changes take longer because one rate can affect the odds chart, luck calculator, tier list, coins tools, and several guide pages. The goal is boring consistency: the same denominator should not mean one thing on the chart and another thing inside a calculator.

Now you know the site methodology - next steps

Start with the current code list

Codes are the fastest page to check before a live Slime RNG session.

Run the calculator before a long roll block

The tool turns rough targets into visible timing ranges.

Use the tier list to choose a practical target

Progression value matters more than rarity labels when resources are limited.

Evidence Rules for Slime RNG Claims

I separate claims into four buckets. Observed means I reproduced it on the test account, such as a code redeem flow or a visible crafting unlock. Calculated means the result comes from a disclosed formula using a stated input, such as cumulative probability after N rolls. Cross-checked means several independent public sources agree but I have not reproduced the late-game condition myself. Unconfirmed means the claim is useful enough to track but does not yet have evidence strong enough for a definitive row.

This distinction matters in Slime RNG because the game combines visible systems with hidden rates. A machine can visibly require three named ingredients, while the exact drop rate for one ingredient remains unpublished. The guide can confidently explain the machine and still mark the ingredient odds as an estimate. Combining those two confidence levels into one "verified" label would make the page easier to read and less trustworthy.

How the probability examples are checked

For a target with denominator d and a luck multiplier L, the working per-roll probability is p = L / d, capped below certainty. The chance of at least one hit after N independent rolls is 1 - (1 - p)^N. The calculator also runs first-hit simulations so the unlucky tail is visible, but the exact cumulative formula is the reference result. I test simple cases first: a Common or Uncommon target should produce enough hits in a short sample to expose a broken formula quickly.

Manual roll logs are used as sanity checks, not as proof of extremely rare rates. One hundred rolls can catch an obvious error in early-tier behavior; it cannot validate a 1 in 100,000,000 Inverted claim. For long-tail targets, I disclose the assumed denominator, compare community reports cautiously, and avoid turning a lucky screenshot into a new rate.

How guide recommendations are formed

Recommendations compare opportunity cost, not rarity alone. A Void chase can be less useful than landing a Mythic first if the Mythic improves income enough to fund rebirths and later luck. A timed code can be wasted even when it increases luck if half its duration is spent clearing inventory. Recipe ingredients can be worth keeping despite weak immediate stats because deleting one restarts a multi-hour collection task. These tradeoffs are why the site uses field notes alongside tables.

Update and correction procedure

  1. Record the old claim, affected URL, source, and observation date.
  2. Reproduce it in-game when the account can reach the condition.
  3. Check whether a patch, code announcement, or zone unlock explains the difference.
  4. Update the narrow claim first, then rerun any dependent calculator example.
  5. Keep uncertainty visible when evidence still conflicts.

The main limitation is access: I do not have private game telemetry. Exact hidden rates can change before public guides notice. Reports with complete setup details can be sent through the contact page.