Astrionyx – Wuthering Waves Gacha Analysis Tool & Details

After quitting Genshin Impact, Honkai: Star Rail, and Zenless Zone Zero, I recently became obsessed with Wuthering Waves ~~(yes, the game behind the meme “xxx only needs to xxx, while xxx has a lot more to think about”)~~. When talking about these gacha games, the evil loot box is an essential part; where there are pulls, there will always be wins and losses on characters and weapons, spawning a bunch of third-party mini-programs like “xxx Helper” or “xxx Workshop,” one of whose key features is gacha history analysis.

The story began when a friend wanted to see my Star Rail pull records, but upon opening the mini-program I used before, all previously saved histories were gone. I tried downloading the cloud version of Star Rail to re-import the gacha link and recover the data, but after half a day of tinkering, the mini-program kept reporting an invalid gacha URL, and the historical records were never retrieved. I couldn’t get over it, so I decided to build my own gacha log analysis tool, keeping the data in my own hands—hence this gacha analysis tool was born.

Astrionyx is a Next.js-based web app that supports analyzing different banner histories, allows manual import or data updates, and can also import data via API.

It can be deployed on Vercel as well as on your own server, supporting both MySQL and Vercel Postgres. Currently, overseas traffic is resolved to Vercel and uses Vercel Postgres, while domestic traffic is resolved to my own server using my own MySQL database—super convenient.

During development, I ran into quite a few interesting problems. If you’re planning to write a similar app yourself, I hope this helps.

Data Import & Update

Data Import

Like most games, Wuthering Waves provides no official API to export gacha data. Its history is shown by generating a temporary link when the user clicks the “Gacha History” button, opening it in an in-game browser. We can capture this link (starting with https://aki-gm-resources.aki-game.com/aki/gacha/index.html) via packet sniffing or log files.

The page POSTs to the API https://gmserver-api.aki-game2.com/gacha/record/query to fetch each banner’s pull history. The request contains key info like player ID (playerId), server ID (serverId), banner ID (cardPoolId), all extractable from URL parameters:

CodeBlock Loading...

The banner type parameter cardPoolType ranges [1, 7], mapping as follows:

CodeBlock Loading...

Create a backend API that forwards to the official API to get each banner’s history.

Data Update

In games like Wuthering Waves, pulls come in “10-pull” batches.

As shown, a “10-pull” can yield two identical items—two records with exactly the same attributes including pull time—so the JSON looks like:

CodeBlock Loading...

This makes it impossible to tell which records have already been imported when updating, hurting stat accuracy. We need an ID that can distinguish two identical items even at the same timestamp.

We can build a unique ID from banner type ID + timestamp + draw index, where draw index counts from 1 for pulls at the same timestamp. Thus, the two identical weapons get uniqueIds 01174845445601 and 01174845445605.

CodeBlock Loading...

Even if imported data overlaps with existing records, new pulls can still be identified and the database updated correctly.

Probability Calculation

The stats overview page uses the ECharts library to render a pull-probability line chart as a component background, showing the gacha system’s probability distribution. Chart data is computed by two main functions:

Theoretical Probability

According to Bilibili uploader “A Balanced Tree”’s Brief Analysis of WuWa Gacha, WuWa rates follow this model, where $i$ is the pull count:

P_5[i] = \begin{cases} 0.008 & (i < 66) \ 0.008 + 0.04 \cdot (i - 65) & (66 \leq i < 71) \ 0.208 + 0.08 \cdot (i - 70) & (71 \leq i < 76) \ 0.608 + 0.1 \cdot (i - 75) & (76 \leq i < 79) \ 1 & (i = 79) \end{cases}

Build a theoretical probability function calculateTheoreticalProbability:

CodeBlock Loading...

Actual Probability

Since the tool is mainly for personal use, sample sizes are small; some pull counts may have no data. Direct frequency estimation causes wild swings—0% or 100% extremes.

To avoid this, we apply Bayesian smoothing:

P_{\text{posterior}} = \frac{k_i + S \cdot P_{\text{prior}}}{n_i + S}

Where:

$k_i$ : 5-star count at pull $i$ , $n_i$ : total pulls at position $i$ , $P_{\text{prior}}$ : theoretical probability, $S$ : smoothing factor

Behavior:

When $n_i$ is small, $P_{\text{posterior}}$ leans toward theoretical $P_{\text{prior}}$ When $n_i$ is large, $P_{\text{posterior}}$ leans toward observed frequency $\frac{k_i}{n_i}$

Smoothed result:

Implementation:

CodeBlock Loading...

Auto Deployment

As mentioned, Astrionyx is deployed on both Vercel and my own server. Every time I push, I used to have to SSH in, pull, and build—super tedious. The theme author once wrote a workflow that auto-builds and deploys the theme to a remote server; I adapted it for Astrionyx.

But GitHub-to-server network quality is awful, transferring the build artifact took 20 min+ on average. Luckily, Cloudflare R2 offers 10 GB free storage and zero egress fees, and download speeds inside China are decent, so it can act as a “transfer station.”

The main workflow now uploads/downloads with 5 retries (single downloads can still fail due to network hiccups; 5 retries solve most cases).

CodeBlock Loading...

With this workflow, every push to main automatically builds and deploys Astrionyx. Using R2 as a transfer station cuts deployment time from 20 min to under 4 min—saving lives.

That's all🎉.

Astrionyx is a Next.js-based web app that supports analyzing different banner histories, allows manual import or data updates, and can also import data via API.

During development, I ran into quite a few interesting problems. If you’re planning to write a similar app yourself, I hope this helps.

Data Import & Update

Data Import

const url = new URL(sanitizedInput);
const params = new URLSearchParams(url.hash.substring(url.hash.indexOf('?') + 1)); 

const playerId = params.get('player_id') || '';
const cardPoolId = params.get('resources_id') || ''; 
const cardPoolType = params.get('gacha_type') || '';
const serverId = params.get('svr_id') || '';
const languageCode = params.get('lang') || '';
const recordId = params.get('record_id') || '';

CodeBlock Loading...

The banner type parameter cardPoolType ranges [1, 7], mapping as follows:

export const POOL_TYPES = [
  { type: 1, name: "Character Event Convene" },
  { type: 2, name: "Weapon Event Convene" },
  { type: 3, name: "Character Permanent Convene" },
  { type: 4, name: "Weapon Permanent Convene" },
  { type: 5, name: "Beginner Convene" },
  { type: 6, name: "Beginner Choice Convene" },
  { type: 7, name: "Gratitude Targeted Convene" },
];

CodeBlock Loading...

Create a backend API that forwards to the official API to get each banner’s history.

Data Update

In games like Wuthering Waves, pulls come in “10-pull” batches.

As shown, a “10-pull” can yield two identical items—two records with exactly the same attributes including pull time—so the JSON looks like:

JSON

{
    "code": 0,
    "message": "success",
    "data": [
        {
            "cardPoolType": "Character Precision Tuning",
            "resourceId": 21050043,
            "qualityLevel": 3,
            "resourceType": "Weapon",
            "name": "Pioneer’s Matrix·Probe",
            "count": 1,
            "time": "2025-05-29 01:47:36"
        },
        ...
        {
            "cardPoolType": "Character Precision Tuning",
            "resourceId": 21050043,
            "qualityLevel": 3,
            "resourceType": "Weapon",
            "name": "Pioneer’s Matrix·Probe",
            "count": 1,
            "time": "2025-05-29 01:47:36"
        },
        ...
    ]
}

CodeBlock Loading...

This makes it impossible to tell which records have already been imported when updating, hurting stat accuracy. We need an ID that can distinguish two identical items even at the same timestamp.

function generateUniqueId(poolType: string | number, timestamp: number, drawNumber: number): string {
  const poolTypeStr = poolType.toString().padStart(2, '0');
  const drawNumberStr = drawNumber.toString().padStart(2, '0');
  return `${poolTypeStr}${timestamp}${drawNumberStr}`;
}

const uniqueId = generateUniqueId(timestampInSeconds, requestPoolType, drawNumber);

CodeBlock Loading...

Even if imported data overlaps with existing records, new pulls can still be identified and the database updated correctly.

Probability Calculation

Theoretical Probability

According to Bilibili uploader “A Balanced Tree”’s Brief Analysis of WuWa Gacha, WuWa rates follow this model, where $i$ is the pull count:

P_5[i] = \begin{cases} 0.008 & (i < 66) \ 0.008 + 0.04 \cdot (i - 65) & (66 \leq i < 71) \ 0.208 + 0.08 \cdot (i - 70) & (71 \leq i < 76) \ 0.608 + 0.1 \cdot (i - 75) & (76 \leq i < 79) \ 1 & (i = 79) \end{cases}

Build a theoretical probability function calculateTheoreticalProbability:

export const calculateTheoreticalProbability = (): [number, number][] => {
  const baseRate = 0.008; // base 0.8%
  const hardPity = 79; // hard pity at 79
  const data: [number, number][] = [];
  const rateIncrease = [
    ...Array(65).fill(0), // pulls 1-65 no increase
    ...Array(5).fill(0.04), // 66-70 +4% each
    ...Array(5).fill(0.08), // 71-75 +8% each
    ...Array(3).fill(0.10) // 76-78 +10% each
  ];
  
  let currentProbability = baseRate;
  for (let i = 1; i <= hardPity; i++) {
    if (i === hardPity) {
      currentProbability = 1; // 79th pull guaranteed
    } else if (i > 65) {
      currentProbability = i === 66
        ? baseRate + rateIncrease[i - 1]
        : currentProbability + rateIncrease[i - 1];
    }
    data.push([i, currentProbability]);
  }
  return data;
};

CodeBlock Loading...

Actual Probability

Since the tool is mainly for personal use, sample sizes are small; some pull counts may have no data. Direct frequency estimation causes wild swings—0% or 100% extremes.

To avoid this, we apply Bayesian smoothing:

P_{\text{posterior}} = \frac{k_i + S \cdot P_{\text{prior}}}{n_i + S}

Where:

$k_i$ : 5-star count at pull $i$ , $n_i$ : total pulls at position $i$ , $P_{\text{prior}}$ : theoretical probability, $S$ : smoothing factor

Behavior:

When $n_i$ is small, $P_{\text{posterior}}$ leans toward theoretical $P_{\text{prior}}$ When $n_i$ is large, $P_{\text{posterior}}$ leans toward observed frequency $\frac{k_i}{n_i}$

Smoothed result:

Implementation:

export const calculateActualProbability = (
  gachaItems: GachaItem[] | undefined,
  theoreticalProbabilityData: [number, number][]
): [number, number][] | null => {
  // data processing logic
  
  const S = 20;
  const probabilityData: [number, number][] = new Array(79);
  
  for (let i = 0; i < 79; i++) {
    const n_i = pullCounts[i];
    const k_i = rarityFiveCounts[i];
    
    if (n_i === 0) {
      // no data at this pull count, use theoretical
      probabilityData[i] = [i + 1, theoreticalProbabilityData[i][1]];
    } else {
      const prior_prob_i = theoreticalProbabilityData[i][1];
      const smoothed_probability = (k_i + S * prior_prob_i) / (n_i + S);
      probabilityData[i] = [i + 1, smoothed_probability];
    }
  }
  
  return probabilityData;
};

CodeBlock Loading...

Auto Deployment

The main workflow now uploads/downloads with 5 retries (single downloads can still fail due to network hiccups; 5 retries solve most cases).

YAML

# .github/workflows/deploy.yml

name: Build & Deploy

on:
  push:
    branches:
      - main
    paths-ignore:
      - '**.md'
      - 'docs/**'
  repository_dispatch:
    types: [trigger-workflow]

permissions: write-all
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

env:
  PNPM_VERSION: 9.x.x
  NODE_VERSION: 20.x
  KEEP_DEPLOYMENTS: 1
  RELEASE_FILE: release.zip

jobs:
  build_and_deploy:
    name: Build & Deploy
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 1
          lfs: true

      - name: Setup PNPM
        uses: pnpm/action-setup@v3
        with:
          version: ${{ env.PNPM_VERSION }}
          run_install: false

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'pnpm'

      - name: Install deps
        run: pnpm install --frozen-lockfile

      - name: Build
        run: |
          if [ -f "./ci-release-build.sh" ]; then
            sh ./ci-release-build.sh
          else
            echo "Build script missing, using default"
            pnpm build
          fi

      - name: Create release archive
        run: |
          mkdir -p release_dir
          if [ -f "./assets/release.zip" ]; then
            mv assets/release.zip release_dir/${{ env.RELEASE_FILE }}
          else
            echo "assets/release.zip missing, check build output"
            exit 1
          fi

      - name: Install rclone
        run: |
          curl -O https://downloads.rclone.org/rclone-current-linux-amd64.zip 
          unzip rclone-current-linux-amd64.zip
          cd rclone-*-linux-amd64
          sudo cp rclone /usr/local/bin/
          sudo chown root:root /usr/local/bin/rclone
          sudo chmod 755 /usr/local/bin/rclone
          rclone version

      - name: Configure rclone
        run: |
          mkdir -p ~/.config/rclone
          cat > ~/.config/rclone/rclone.conf << EOF
          [r2]
          type = s3
          provider = Cloudflare
          access_key_id = ${{ secrets.R2_ACCESS_KEY_ID }}
          secret_access_key = ${{ secrets.R2_SECRET_ACCESS_KEY }}
          endpoint = ${{ secrets.R2_ENDPOINT_URL }}
          region = auto
          acl = private
          bucket_acl = private
          no_check_bucket = true
          force_path_style = true
          EOF

      - name: Upload to R2
        id: upload_to_r2
        run: |
          echo "Uploading to R2"
          max_retries=5
          retry_count=0
          upload_success=false
          
          while [ $retry_count -lt $max_retries ] && [ "$upload_success" = "false" ]; do
            echo "Upload ${retry_count}/${max_retries} to R2"
            if rclone copy release_dir/${{ env.RELEASE_FILE }} r2:${{ secrets.R2_BUCKET }} --retries 3 --retries-sleep 10s --progress --s3-upload-cutoff=64M --s3-chunk-size=8M --s3-disable-checksum; then
              upload_success=true
              echo "Upload succeeded"
            else
              echo "Upload failed, retrying"
              retry_count=$((retry_count + 1))
              if [ $retry_count -lt $max_retries ]; then
                echo "Waiting 5 s"
                sleep 5
              fi
            fi
          done
          
          if [ "$upload_success" = "false" ]; then
            echo "Max retries reached"
            exit 1
          fi
          
          DOWNLOAD_URL="${{ secrets.R2_PUBLIC_URL }}/${{ env.RELEASE_FILE }}"
          echo "DOWNLOAD_URL=$DOWNLOAD_URL" >> $GITHUB_ENV
          echo "Download URL: $DOWNLOAD_URL"

      - name: Download from R2 and deploy
        uses: appleboy/ssh-action@v1.0.3
        with:
          command_timeout: 10m
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          password: ${{ secrets.PASSWORD }}
          key: ${{ secrets.KEY }}
          port: ${{ secrets.PORT }}
          script: |
            set -e
            source $HOME/.bashrc
            
            mkdir -p /tmp/astrionyx
            cd /tmp/astrionyx
            rm -f release.zip
            
            max_retries=5
            retry_count=0
            download_success=false
            
            echo ${{ env.DOWNLOAD_URL }}

            while [ $retry_count -lt $max_retries ] && [ "$download_success" = "false" ]; do
              echo "Download (${retry_count}/${max_retries})"
              if timeout 60s wget -q --show-progress --progress=bar:force:noscroll --no-check-certificate -O release.zip "${{ env.DOWNLOAD_URL }}"; then
                if [ -s release.zip ]; then
                  download_success=true
                else
                  echo "Downloaded file empty, retrying"
                fi
              else
                echo "Download failed, retrying"
              fi
              
              retry_count=$((retry_count + 1))
              if [ $retry_count -lt $max_retries ] && [ "$download_success" = "false" ]; then
                echo "Waiting 5 s"
                sleep 5
                rm -f release.zip
              fi
            done
            
            if [ "$download_success" = "false" ]; then
              echo "Max retries reached"
              exit 1
            fi
            
            basedir=$HOME/astrionyx
            workdir=$basedir/${{ github.run_number }}
            mkdir -p $workdir
            mkdir -p $basedir/.cache
            
            mv /tmp/astrionyx/release.zip $workdir/release.zip
            cd $workdir
            unzip -q $workdir/release.zip
            rm -f $workdir/release.zip
            
            rm -rf $workdir/standalone/.env
            ln -s $HOME/astrionyx/.env $workdir/standalone/.env
            export NEXT_SHARP_PATH=$(npm root -g)/sharp
            
            cp $workdir/standalone/ecosystem.config.js $basedir/ecosystem.config.js
            
            rm -f $basedir/server.mjs
            ln -s $workdir/standalone/server.mjs $basedir/server.mjs
            
            mkdir -p $workdir/standalone/.next
            rm -rf $workdir/standalone/.next/cache
            ln -sf $basedir/.cache $workdir/standalone/.next/cache
            
            cd $basedir

            # remember to change to your available port 👇
            export PORT=8523
            pm2 reload server.mjs --update-env || pm2 start server.mjs --name astrionyx --interpreter node --interpreter-args="--enable-source-maps"
            pm2 save
            
            echo "${{ github.run_number }}" > $basedir/current_deployment
            
            echo "Cleaning old deployments, keeping ${{ env.KEEP_DEPLOYMENTS }} latest"
            current_run=${{ github.run_number }}
            ls -d $basedir/[0-9]* 2>/dev/null | grep -v "$basedir/$current_run" | sort -rn | awk -v keep=${{ env.KEEP_DEPLOYMENTS }} 'NR>keep' | while read dir; do
              echo "Removing old version: $dir"
              rm -rf "$dir"
            done
            
            rm -rf /tmp/astrionyx 2>/dev/null || true
            echo "Deployment complete"

      - name: Post-deploy script
        if: success()
        run: |
          if [ -n "${{ secrets.AFTER_DEPLOY_SCRIPT }}" ]; then
            echo "Running post-deploy script"
            ${{ secrets.AFTER_DEPLOY_SCRIPT }}
          fi

      - name: Clean R2
        if: always()
        run: |
          echo "Cleaning temp files in R2"
          rclone delete r2:${{ secrets.R2_BUCKET }}/${{ env.RELEASE_FILE }}

CodeBlock Loading...

# ci-release-build.sh

#!env bash
set -e
CWD=$(pwd)

npm run build
cd .next
pwd
rm -rf cache
cp -r ../public ./standalone

cd ./standalone
echo ';process.title = "Astrionyx"' >>server.js
mv server.js server.mjs
mv ../static/ ./.next/static

cp $CWD/ecosystem.standalone.config.cjs ./ecosystem.config.js

cd ..

mkdir -p $CWD/assets
rm -rf $CWD/assets/release.zip
zip --symlinks -r $CWD/assets/release.zip ./*

CodeBlock Loading...

With this workflow, every push to main automatically builds and deploys Astrionyx. Using R2 as a transfer station cuts deployment time from 20 min to under 4 min—saving lives.

That's all🎉.