Forem: graysonwerner100-commits

Why every CS2-to-CSGO rank converter gives you a different answer (and how I picked one)

graysonwerner100-commits — Sun, 10 May 2026 16:59:16 +0000

I built a small tool called cs2rankconverter.com — punch in your CS2 Premier rating, get the equivalent CSGO rank. It exists because Valve replaced the familiar Silver-to-Global rank system with a 1,000–35,000 number scale and never bothered to publish a mapping. Players who quit during CSGO and came back during CS2 have no clue what their new number means.

Should be simple right? Take Premier's rating, look up the matching CSGO rank, return it. Two days of work, ship it, done.

Except every existing converter I checked gave a different answer.

Dexerto says 18,000 is "DMG-LEM range." Esportstales says 18,000 is mid-LEM. Scope.gg's 2.5M-player analysis maps it to high LE. Leetify's data implies upper-LEM. None of them are wrong. They're all using legitimate methods that produce different results from the same underlying reality.

This is a fun little case study in why "convert X to Y" problems get harder the moment you actually look at the data. If you're building anything that maps between two scales — game ranks, school grades to GPAs, Likert survey scales, anything where two systems measure roughly the same thing differently — the same trap applies.

The two methods, and why they disagree

There are exactly two principled ways to map CS2 Premier ratings to CSGO ranks. They produce different answers. Most converters quietly pick one without telling you.

Method 1: Bracket-matching

Premier has 7 color brackets (Gray, Light Blue, Dark Blue, Purple, Pink, Red, Yellow). CSGO had 18 ranks. Divide them up proportionally. Gray covers Silver I through Silver Elite Master (6 ranks). Light Blue covers all four Gold Novas. And so on.

const COLOR_TO_RANKS = {
  gray:      ['S1', 'S2', 'S3', 'S4', 'SE', 'SEM'],   // 6 ranks
  lightBlue: ['GN1', 'GN2', 'GN3', 'GNM'],            // 4 ranks
  darkBlue:  ['MG1', 'MG2', 'MGE'],                   // 3 ranks
  purple:    ['DMG', 'LE', 'LEM'],                    // 3 ranks
  pink:      ['SMFC'],                                // 1 rank
  red:       ['SMFC', 'GE'],                          // overlap
  yellow:    ['GE'],                                  // 1 rank
};

function bracketMatch(rating) {
  const color = colorFromRating(rating);
  const ranks = COLOR_TO_RANKS[color];
  const colorMin = COLOR_RANGES[color].min;
  const colorMax = COLOR_RANGES[color].max;
  const positionInColor = (rating - colorMin) / (colorMax - colorMin);
  const rankIndex = Math.floor(positionInColor * ranks.length);
  return ranks[Math.min(rankIndex, ranks.length - 1)];
}

Clean. Easy to explain. Easy to remember.

The problem: it assumes the two scales' brackets correspond to equivalent population slices. They don't. CSGO's Silver tier (6 ranks) historically held about 32% of the playerbase. CS2's Gray bracket holds about 10% in 2026. By bracket-matching, a player at rating 3,000 (which is "mid-Gray, top half of Silver tier" in bracket terms) is actually in the bottom ~5% of CS2 — way worse than the average Silver in CSGO ever was.

Method 2: Percentile-matching

Take the player's percentile in Premier. Find the CSGO rank that historically held that same percentile. Return that rank.

// Pre-computed from CSGO 2017-2019 distribution data
const CSGO_RANK_PERCENTILES = {
  S1:   { lower: 0.000, upper: 0.045 },
  S2:   { lower: 0.045, upper: 0.087 },
  S3:   { lower: 0.087, upper: 0.146 },
  S4:   { lower: 0.146, upper: 0.222 },
  SE:   { lower: 0.222, upper: 0.305 },
  SEM:  { lower: 0.305, upper: 0.391 },
  GN1:  { lower: 0.391, upper: 0.481 },
  GN2:  { lower: 0.481, upper: 0.560 },
  GN3:  { lower: 0.560, upper: 0.637 },
  GNM:  { lower: 0.637, upper: 0.710 },
  MG1:  { lower: 0.710, upper: 0.781 },
  MG2:  { lower: 0.781, upper: 0.844 },
  MGE:  { lower: 0.844, upper: 0.893 },
  DMG:  { lower: 0.893, upper: 0.931 },
  LE:   { lower: 0.931, upper: 0.961 },
  LEM:  { lower: 0.961, upper: 0.982 },
  SMFC: { lower: 0.982, upper: 0.995 },
  GE:   { lower: 0.995, upper: 1.000 },
};

function percentileMatch(rating, distribution) {
  const percentile = percentileForRating(rating, distribution);
  for (const [rank, range] of Object.entries(CSGO_RANK_PERCENTILES)) {
    if (percentile >= range.lower && percentile < range.upper) {
      return rank;
    }
  }
  return 'GE';
}

This is more honest about how good a player actually is relative to peers. If you're at the 95th percentile in Premier, you map to the 95th percentile in CSGO, which was around LE/LEM.

The problem: it produces narrower bands that "feel weird." A rating of 18,500 maps to LEM under percentile-matching, but to mid-LEM-to-Supreme under bracket-matching. Players coming back from a 4-year break expect the bracket-matching answer because that's how their brain still organizes ranks visually.

Why the answers differ in practice

Run both methods on a few sample ratings and you get this:

Rating	Bracket method	Percentile method	Difference
3,000	Silver III	Silver I	2 ranks
6,000	Gold Nova II	Silver Elite Master	1 rank
9,000	Gold Nova Master	Gold Nova III	1 rank
12,000	Master Guardian Elite	Master Guardian I	2 ranks
15,000	Distinguished MG	Master Guardian Elite	1 rank
18,000	Legendary Eagle Master	Legendary Eagle	1 rank
22,000	Supreme MFC	Legendary Eagle Master	2 ranks

The two methods produce systematically different results because Premier's distribution is more compressed than CSGO's was. CS2's rating system is closer to FACEIT's Elo scale, which spreads players across a numeric continuum. CSGO's 18 ranks were skewed toward the middle (most players were Gold Nova or low MG).

Neither method is "wrong." They answer slightly different questions:

Bracket-matching answers: "Which CSGO rank icon would Premier's color tier correspond to?"
Percentile-matching answers: "Which CSGO rank held the same fraction of players as my current Premier rating?"

For most players the second question is the more useful one — "am I above average, top 10%, top 1%?" — but the first question matches their visual mental model.

What I actually shipped

A 60/40 weighted blend of percentile-matching and bracket-matching, because:

Pure percentile-matching produces results that contradict every existing community converter, which makes users distrust the tool ("but Dexerto said I was DMG?")
Pure bracket-matching produces results that don't reflect actual current skill distributions
The blended approach lands within 1 rank of every major community source for ~85% of ratings

function convertRating(rating) {
  const bracketRank = bracketMatch(rating);
  const percentileRank = percentileMatch(rating, CURRENT_PREMIER_DISTRIBUTION);

  // If they agree, return that
  if (bracketRank === percentileRank) return bracketRank;

  // Otherwise weight 60% percentile (more honest), 40% bracket (more familiar)
  const bracketIdx = RANK_ORDER.indexOf(bracketRank);
  const percentileIdx = RANK_ORDER.indexOf(percentileRank);
  const blendedIdx = Math.round(percentileIdx * 0.6 + bracketIdx * 0.4);
  return RANK_ORDER[blendedIdx];
}

I document this honestly in the tool's About page. There's no "official" mapping; Valve never published one. Anyone claiming their converter is canonical is selling something.

Distributions drift, so the answer drifts

Here's the part that actually keeps me up: the underlying CS2 distribution isn't static. Sample data from Leetify shows this:

January 2024 average rating: ~8,000
September 2024 average: ~9,000
January 2026 average: ~11,000

The bar moved 3,000 points in two years. A rating of 11,000 in 2024 was solidly above-average; in 2026 it's literally the average. Any converter that hard-codes percentile cutoffs based on 2024 data will tell users they're better than they are by 2026.

The fix is to refresh distribution data periodically:

// Re-aggregate distribution from a 30-day rolling window
async function refreshDistribution() {
  const samples = await fetchRecentLeaderboardSamples({ 
    minDate: thirtyDaysAgo() 
  });
  const histogram = bucketize(samples, { bucketSize: 1000 });
  const cdf = computeCDF(histogram);
  await db.set('premier_distribution', cdf);
}

I update mine quarterly. That's enough to track Elo inflation without constantly shifting answers under returning users. If you build any converter where one side of the mapping has time-varying statistics, you need a refresh strategy or your tool gets quietly wrong.

Why "Valve should just publish the mapping" doesn't work

You'd think the cleanest solution is for Valve to release official numbers. They won't, and probably shouldn't. Here's why:

The systems measure different things. CSGO's per-map ranks are now per-map in CS2 Competitive. Premier is a unified global rating. There isn't a single mapping; the right answer depends on which CSGO rank context you're asking about (Inferno-only? Average across all maps? Highest map?).
Publishing it would lock in inflation. If Valve says "20,000 = Global Elite," players above 20k start expecting GE-tier behavior from teammates. Premier ratings continuing to drift would break that contract within months.
Marketing. The whole reason CS2 abandoned named ranks was to escape the Silver-to-Global meme economy. An official mapping resurrects it.

So community-derived approximations are the only game in town. They'll always be approximations. That's fine — most users want a ballpark, not exactness.

Lessons that generalize

If you're building any cross-scale converter, the lessons here apply:

Identify which method you're using and document it. Bracket vs. percentile is the same dichotomy as nominal vs. ordinal scales in stats. Most "converters" are bracket-matchers without realizing it.
Distributions drift. Anything pegged to "what the average user looks like" needs a refresh schedule. Hardcoded percentile cutoffs go stale.
Users expect bracket-matching, even when percentile-matching is more correct. Their mental model is the dominant scale's named buckets, not the underlying skill distribution. A pure-correctness answer will feel "wrong" to them.
Consensus across converters tells you when you're broken. I sanity-check my output against three other community sources. If I disagree with all of them by 2+ ranks, something's wrong on my end (usually stale distribution data).
Be honest in the UI about uncertainty. I show a confidence band, not a single rank, when the rating is near a bracket boundary. Eg. rating 4,950 returns "Silver Elite Master / Gold Nova I" — because honestly, both are defensible.

If you want to play with the live tool, cs2rankconverter.com does this conversion in one click. The math behind it is roughly what's described above; the data refreshes quarterly. Feel free to plug in numbers and tell me where it disagrees with your gut — those edges are where the next iteration usually comes from.

If you've shipped a similar two-scale converter and ran into different gotchas, I'd love to hear about it in the comments. Especially curious about converters between systems where one side has a long-tail distribution and the other has a normal-ish one — that's a research question I haven't fully solved.

What 123 million simulated CS2 case openings taught me about modeling RNG

graysonwerner100-commits — Sat, 09 May 2026 20:21:54 +0000

I run case-sim.com, a free CS2 case opening simulator. As of this week the global counter ticked past 123 million openings. That's a weirdly humbling number — it's also enough rolls that any subtle bug in my probability code would have been screaming at me for years.

I want to share what I actually learned building this thing, because most "how to model case openings" tutorials I've seen are wrong in at least one quiet, important way. If you're building anything with weighted RNG — loot tables, gacha, slot mechanics, A/B traffic splitting — some of this will probably save you a bug.

This is going to be code-heavy. Sorry/not sorry.

The drop rate model (and the off-by-one I shipped for two weeks)

Valve disclosed CS2's case tiers back in 2017 and they haven't changed:

Tier	Color	Drop chance
Mil-Spec	Blue	79.92%
Restricted	Purple	15.98%
Classified	Pink	3.20%
Covert	Red	0.64%
Knife/Glove	Gold	0.26%

Add those up: exactly 100%. That's not a coincidence — that's an invariant you should be enforcing in tests, not assuming.

The naive implementation is simple:

const TIER_WEIGHTS = {
  milSpec:    0.7992,
  restricted: 0.1598,
  classified: 0.0320,
  covert:     0.0064,
  rare:       0.0026, // knife/glove
};

function rollTier() {
  const r = Math.random();
  let cumulative = 0;
  for (const [tier, weight] of Object.entries(TIER_WEIGHTS)) {
    cumulative += weight;
    if (r < cumulative) return tier;
  }
  return 'milSpec'; // floating-point fallback
}

That fallback at the bottom is not me being paranoid. 0.7992 + 0.1598 + 0.0320 + 0.0064 + 0.0026 should equal 1.0, but in JavaScript:

0.7992 + 0.1598 + 0.0320 + 0.0064 + 0.0026
// 0.9999999999999999

If Math.random() returns 0.99999999... and your cumulative caps out at 0.9999999999999999, you fall off the end. With 123M rolls that bug fires roughly... a lot. So you either return a fallback or you switch to integer weights:

const TIER_WEIGHTS_INT = {
  milSpec:    7992,
  restricted: 1598,
  classified:  320,
  covert:       64,
  rare:         26,
}; // sums to exactly 10000

function rollTier() {
  const r = Math.floor(Math.random() * 10000);
  let cumulative = 0;
  for (const [tier, weight] of Object.entries(TIER_WEIGHTS_INT)) {
    cumulative += weight;
    if (r < cumulative) return tier;
  }
}

I shipped the float version. It worked. But the integer version is just better and I switched.

Within a tier, items are uniform. So once rollTier() returns 'covert', you just pick uniformly from the covert items in that case. Don't overthink it.

The 10% StatTrak roll

StatTrak is a separate roll after the item is picked, not a sixth tier:

function open(caseDef) {
  const tier = rollTier();
  const item = pickUniform(caseDef.items[tier]);
  const isStatTrak = Math.random() < 0.10;
  return { item, isStatTrak };
}

I see a lot of clones get this wrong — they roll StatTrak as part of the tier weights and the math drifts. It's conditional, not categorical.

Float values: where most tutorials die

Each skin has a wear value from 0.0 (Factory New) to 1.0 (Battle-Scarred). The wear conditions:

Wear	Float range
Factory New	0.00 – 0.07
Minimal Wear	0.07 – 0.15
Field-Tested	0.15 – 0.38
Well-Worn	0.38 – 0.45
Battle-Scarred	0.45 – 1.00

Here's the gotcha that wrecks most sims: float ranges aren't 0 to 1 for every skin. Each skin has a min_float and max_float clamped by the workshop creator. The AK-47 Vulcan has min=0.0, max=0.9. The AWP Asiimov has min=0.18, max=0.55 — meaning it cannot drop Factory New, ever. If your sim rolls AWP Asiimov FN, your sim is wrong.

Correct version:

function rollFloat(skin) {
  const raw = Math.random();
  return raw * (skin.maxFloat - skin.minFloat) + skin.minFloat;
}

function wearFromFloat(f) {
  if (f < 0.07) return 'Factory New';
  if (f < 0.15) return 'Minimal Wear';
  if (f < 0.38) return 'Field-Tested';
  if (f < 0.45) return 'Well-Worn';
  return 'Battle-Scarred';
}

The skin-specific min/max is the entire reason float-capped skins (like a 0.00-something AK-47 Fire Serpent) trade for absurd money. They're rarer than the wear distribution alone suggests because the underlying float distribution is also clamped on the high end.

The spin animation bias trap

This is the one I want every developer building a loot reveal UI to internalize, because I've seen it shipped in production at sites that should know better.

You've seen the CS2 case opening animation: items scroll horizontally, decelerate, and stop on the result. The wrong way to build that:

// ❌ WRONG: roll position, derive result
function openCase() {
  const trackLength = items.length * itemWidth;
  const stopPosition = Math.random() * trackLength;
  animateTo(stopPosition);
  return getItemAt(stopPosition); // result depends on visual layout
}

Why it's wrong: the items on the track aren't uniformly distributed by tier. Most slots are common items, very few slots are knives. If you roll a uniform position over the track, your effective drop rate is just whatever fraction of the visible track is occupied by each tier — not Valve's 79.92/15.98/3.20/0.64/0.26.

The right way:

// ✅ RIGHT: roll result, then animate to it
function openCase(caseDef) {
  const result = rollResult(caseDef);             // 1. determine outcome
  const targetIndex = placeResultOnTrack(result); // 2. position it
  const targetPx = targetIndex * itemWidth + jitter();
  animateTo(targetPx, { duration: 5000, easing: 'ease-out' });
  return result;                                  // 3. show what we already decided
}

The track is just visual theater. The result is decided first. The animation lands on it.

This sounds obvious but if you grep enough open-source case opener clones on GitHub you'll find the wrong pattern in real code. It feels right because it looks random. It just isn't the right random.

Pattern indices and the Doppler problem

Each item also rolls a pattern index from 0 to 999. For most skins this affects the visual layout but not the value. For some skins — Case Hardened (blue gems), Crimson Web (full webs), Fade (100% fades), and especially Dopplers — pattern is everything.

Dopplers are nasty because the same skin name maps to different "phases" depending on pattern:

// Phase mapping for one Doppler variant (illustrative — exact ranges vary by knife)
const DOPPLER_PHASES = {
  ruby:        [418],
  sapphire:    [419],
  blackPearl:  [420],
  phase1:      [415],
  phase2:      [416],
  phase3:      [417],
  phase4:      [421],
};

function dopplerPhase(item, patternIndex) {
  for (const [phase, indices] of Object.entries(item.phases)) {
    if (indices.includes(patternIndex)) return phase;
  }
  return null;
}

Phase distribution isn't uniform — Ruby/Sapphire/Black Pearl are ~5% combined, the rest split among phases 1-4. If you implement Dopplers as a single skin with a uniform pattern roll, your sim will show Ruby Karambits at like 0.1% rate and people will (correctly) call you out.

I model each Doppler variant as essentially seven distinct items at the right relative weights. It's annoying but it's the only way to get realistic pulls. You can see the full case list at case-sim.com/cases if you want to compare.

What scale actually breaks

123M rolls means a lot of things you wouldn't think about start to matter:

Database writes. I do not write a row per opening. That would be insane. Aggregate counters per case, per item, per day. The "global unbox feed" people see is a sliding window of recent rolls held in memory and trimmed aggressively. If you're building anything in this space, design your schema around aggregates from day one.

Rare-item flexing. When someone pulls a Dragon Lore (1 in 3,906 in a Souvenir Cobblestone package), they take a screenshot. They post it. The screenshot shows your URL. This is great for you — but it also means your knife/glove pull endpoint gets traffic spikes. Cache pulled-item OG images and pre-render the share cards.

Float floors. I had a bug where extremely low floats (below 0.001) would render as scientific notation in the UI: 1.234e-4 instead of 0.000123. Looked like garbage on share cards. Always format floats explicitly:

const formatFloat = (f) => f.toFixed(6).replace(/0+$/, '').replace(/\.$/, '');

Trust. Once you publish drop rates, people will run their own statistical tests. Someone DM'd me a chi-square goodness-of-fit on 50,000 of their personal openings. It checked out (thank god). Have your random source be auditable — prefer crypto.getRandomValues() over Math.random() if you can, even though for sim purposes Math.random is mathematically fine.

function secureRandom() {
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return arr[0] / 0xFFFFFFFF;
}

A few things I'd do differently

If I rebuilt today:

Integer weights from day one. Every probability lives as parts-per-10000 or parts-per-1000000. Floating point in probability code is just asking for it.
Decouple the item pool from the case definition. I had cases hard-referencing item objects. When Valve added new wear ranges or float caps, I had to touch every case. Now the case is just a list of item IDs + tier weights, and the item registry is the source of truth.
Test the invariant. Every case definition has a unit test that asserts tier weights sum to exactly 10000. Cheap to write, catches stupid copy-paste mistakes when adding new cases.

test.each(allCaseDefs)('case %s tier weights sum to 10000', (caseDef) => {
  const total = Object.values(caseDef.tiers).reduce((a, b) => a + b, 0);
  expect(total).toBe(10000);
});

That test has caught me twice.

Wrap

If you're modeling weighted-random anything — loot, gacha, traffic splitting, even A/B variants — the lessons from running 123M case openings of Counter-Strike 2's official cases are basically:

Use integer weights, not floats. Probability sums need to be exact, not "close enough."
Roll the result first, then animate to it. Visual position should never derive the outcome.
Per-skin float ranges matter more than tier weights for determining real-world rarity.
Conditional rolls (StatTrak, Doppler phase) are not extra tiers. Don't shoehorn them in.
Test that your weights sum to your invariant. Every time. In CI.

If you want to see how this all pans out in practice — opening real cases with real Valve odds, no money, no signup — that's literally what I built case-sim for. Otherwise, take the code patterns and go build your own thing. The world has room for more weighted RNG done right.

Hit me up in the comments if you've shipped something similar and ran into different gotchas. Always curious what other people hit.