Astrionyx - A Wuthering Waves Gacha Analysis Tool and the Details Behind It

After quitting Genshin Impact, Honkai: Star Rail, and Zenless Zone Zero, I recently got hooked on Wuthering Waves (yes, that "xxx only needs to do xxx, while xxx has a great many things to consider" game). When it comes to this kind of anime-style game, the dreaded gacha is an unavoidable part of the experience. And where there's gacha, there's always the question of whether you win or lose the 50/50 on a character or weapon — which in turn gave rise to a whole crop of third-party mini-apps, the likes of "Assistant" and "Workshop" apps. One of their key features is gacha analysis.

It all started when a friend wanted to check my Honkai: Star Rail gacha records, only to open the mini-app he'd been using and find that all the records he'd saved were gone. He tried downloading Honkai: Star Rail Cloud to re-import the gacha link and restore the data, but after hours of tinkering the mini-app kept reporting an invalid gacha URL, and he never did get the history back. I couldn't stop thinking about it afterward, so I decided to build my own gacha record analysis tool and keep the data in my own hands. That's how this gacha analysis tool came to be.

Astrionyx is a Next.js-based web app, Astrionyx is currently a Next.js frontend with a Go backend. It supports analyzing records from different types of banners, and lets you manually import or update data as well as import via API. Besides Wuthering Waves, it also supports Genshin Impact, Honkai: Star Rail, Zenless Zone Zero, Arknights: Endfield, Neverness to Everness, and other games. The frontend can be dropped straight onto Vercel or EdgeOne Pages for hosting, while the backend is deployed to your own server with Docker — deployment is very, very convenient.

While building Astrionyx, I ran into quite a few interesting problems. If you're thinking of writing an app like this yourself, I hope this helps.

Importing and Updating Data

Importing Data

Like the vast majority of games, Wuthering Waves doesn't offer an official API for exporting gacha data. Here's how it displays gacha history: when you tap the "Gacha History" button, the game generates a temporary link and opens it in the in-game browser to show your gacha history. We can grab this link — the one starting with aki-gm-resources.aki-game.com/aki/gacha/index.html — by capturing network traffic or from the log file.

That page sends a POST request to the API gmserver-api.aki-game2.com/gacha/record/query to fetch the pull history for each banner. The request contains key details — the player ID (playerId), server ID (serverId), and banner ID (gachaId), all of which can be extracted from the parameters in the URL:

TypeScript

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

const playerId = params.get("player_id") || "";
const gachaId = params.get("resources_id") || "";
const gachaType = params.get("gacha_type") || "";
const serverId = params.get("svr_id") || "";
const languageCode = params.get("lang") || "";
const recordId = params.get("record_id") || "";

Here, the banner type parameter cardPoolType takes the value [1, 13], mapped as follows:

TypeScript

// 2026.06.09： 添加 10,11 号联动唤取卡池
// 2026.07.21： 添加 12,13 号忆旅唤取卡池
// 牛魔的怎么越来越多卡池了😅

export const POOL_TYPES = [
  { type: 1, name: "角色活动唤取" },
  { type: 2, name: "武器活动唤取" },
  { type: 3, name: "角色常驻唤取" },
  { type: 4, name: "武器常驻唤取" },
  { type: 5, name: "新手唤取" },
  { type: 6, name: "新手自选唤取" },
  { type: 7, name: "感恩定向唤取" },
  { type: 8, name: "角色新旅唤取" },
  { type: 9, name: "武器新旅唤取" },
  { type: 10, name: "角色联动唤取" },
  { type: 11, name: "武器联动唤取" },
  { type: 12, name: "角色忆旅唤取" },
  { type: 13, name: "武器忆旅唤取" },
];

Build a backend API that forwards the request to the official API to fetch each banner's gacha history.

Updating Data

In Wuthering Waves and similar games, gacha pulls can be done as ten-pulls.

As the image shows, a ten-pull can yield two of the same item — that is, two records with completely identical attributes, including the pull timestamp (in a ten-pull, all items are generated at the same instant). The result fetched via JSON looks like this:

JSON

{
    "code": 0,
    "message": "success",
    "data": [
        {
            "cardPoolType": "角色精准调谐",
            "resourceId": 21050043,
            "qualityLevel": 3,
            "resourceType": "武器",
            "name": "远行者矩阵·探幽",
            "count": 1,
            "time": "2025-05-29 01:47:36"
        },
        ...
        {
            "cardPoolType": "角色精准调谐",
            "resourceId": 21050043,
            "qualityLevel": 3,
            "resourceType": "武器",
            "name": "远行者矩阵·探幽",
            "count": 1,
            "time": "2025-05-29 01:47:36"
        },
        ...
    ]
}

This means that when we later update our gacha records, we can't tell which records have already been imported, and that skews the accuracy of our statistics. So we need an ID that can distinguish two identical items even when they share the same timestamp.

We can use timestamp + banner type ID + pull index to define this unique ID. The pull index means: counting from 1, which pull this is at the same timestamp. So the two identical weapons above can be assigned unique IDs of 1748454456000100001 and 1748454456000100005.

func GenerateUniqueID(timestamp int, gachaType string, drawNumber int) (int64, error) {
	gachaTypeID, err := strconv.Atoi(strings.TrimSpace(gachaType))
	if err != nil {
		return 0, err
	}

	return int64(timestamp)*1_000_000_000 +
		int64(gachaTypeID%10_000)*100_000 +
		int64(drawNumber%100), nil
}

That way, even if imported data overlaps with existing data, we can still correctly identify newly added gacha records and update the database.

Calculating Probability Data

In the page's stats overview, I used the ECharts library to render a line chart of gacha probability analysis as the component's background, to show the probability distribution of the gacha system. The line chart's data is computed by two main functions:

Theoretical Probability Calculation

According to A Quick Look at Wuthering Waves' Gacha System by Bilibili creator Yike Pinghengshu, Wuthering Waves' gacha probability follows the model below, where $i$ is the number of pulls:

$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}$

From this we build a theoretical probability function calculateTheoreticalProbability:

TypeScript

export const calculateTheoreticalProbability = (): [number, number][] => {
  const baseRate = 0.008; // 基础概率0.8%
  const hardPity = 79; // 保底79抽
  const data: [number, number][] = [];
  const rateIncrease = [
    ...Array(65).fill(0), // 1-65抽概率不增加
    ...Array(5).fill(0.04), // 66-70抽每次+4%
    ...Array(5).fill(0.08), // 71-75抽每次+8%
    ...Array(3).fill(0.10) // 76-78抽每次+10%
  ];
  
  let currentProbability = baseRate;
  for (let i = 1; i <= hardPity; i++) {
    if (i === hardPity) {
      currentProbability = 1; // 第79抽必出
    } else if (i > 65) {
      currentProbability = i === 66
        ? baseRate + rateIncrease[i - 1]
        : currentProbability + rateIncrease[i - 1];
    }
    data.push([i, currentProbability]);
  }
  return data;
};

Empirical Probability Calculation

Since the tool is mainly for personal use, the gacha data sample is small, and some pull positions may have no data at all. Estimating directly by frequency would make the probability curve swing wildly, producing extreme values like 0% or 100%.

To avoid this, we can introduce Bayesian smoothing for a better result.

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

Where:

$k_i$ : the number of 5-stars observed at the $i$ th pull position, $n_i$ : the total number of pulls at the $i$ th pull position, $P_{\text{prior}}$ : the theoretical probability, $S$ : the smoothing factor

It behaves as follows:

If $n_i$ is small (i.e., when there isn't much data), $P_{\text{posterior}}$ will be closer to the theoretical probability $P_{\text{prior}}$

If $n_i$ is large (i.e., when the data volume is large), $P_{\text{posterior}}$ will be closer to the empirical frequency $\frac{k_i}{n_i}$

The improved result looks like this:

Here's the implementation code:

TypeScript

export const calculateActualProbability = (
  gachaItems: GachaItem[] | undefined,
  theoreticalProbabilityData: [number, number][],
): [number, number][] | null => {
  const maxPity = theoreticalProbabilityData.length;
  const totalSamples = pullCounts.reduce((sum, count) => sum + count, 0);
  const equivalentSamples = Math.max(
    10,
    Math.min(120, 50 + (1000 - totalSamples) / 10),
  );
  const probabilityData: [number, number][] = new Array(maxPity);

  for (let i = 0; i < maxPity; i++) {
    const sampleCount = pullCounts[i];
    const hitCount = rarityFiveCounts[i];

    if (sampleCount === 0) {
      probabilityData[i] = [i + 1, theoreticalProbabilityData[i][1]];
    } else {
      const priorProbability = theoreticalProbabilityData[i][1];
      const priorSamples =
        i >= maxPity * 0.8 ? equivalentSamples * 1.5 : equivalentSamples;
      const smoothedProbability =
        (hitCount + priorSamples * priorProbability) /
        (sampleCount + priorSamples);
      probabilityData[i] = [i + 1, smoothedProbability];
    }
  }

  return probabilityData;
};

Automatic Deployment

The project currently uses a workflow plus Alibaba Cloud Container Registry to automate deployment.

The following automatic deployment method is outdated and kept only as a record:

As mentioned earlier, Astrionyx is deployed both on Vercel and on my own server, so every time I made a change and pushed it to the repo, I had to pull and build on the server — a real pain. The author of this theme had written a workflow that automatically builds the theme and deploys it to a remote server, so I adapted it slightly and used it for Astrionyx.

Repository · innei-dev

yohaku-deploy-action

Shell

But in practice I found that the network connection between GitHub and the server was very poor, so transferring the built package to the server took a long time every time (20 min+ on average). As luck would have it, Cloudflare's R2 object storage offers10 GB of free storage per month and no download fees, and its download speeds within the mainland are decent too, so it could serve as a "relay station" to solve this problem.

The main workflow with object storage looks like this. Both uploads and downloads are set to retry 5 times (a single download can still fail due to network fluctuations, but in practice 5 retries resolve the vast majority of problems).

YAML

# .github/workflows/deploy.yml

name: 构建与部署

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: 构建与部署
    runs-on: ubuntu-latest

    steps:
      - name: 检出代码
        uses: actions/checkout@v4
        with:
          fetch-depth: 1
          lfs: true

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

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

      - name: 安装依赖
        run: pnpm install --frozen-lockfile

      - name: 构建项目
        run: |
          if [ -f "./ci-release-build.sh" ]; then
            sh ./ci-release-build.sh
          else
            echo "构建脚本不存在，使用默认构建命令"
            pnpm build
          fi

      - name: 创建发布归档
        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 不存在，检查构建脚本输出"
            exit 1
          fi

      - name: 安装 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: 配置 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: 上传到 R2 存储
        id: upload_to_r2
        run: |
          echo "开始上传到 R2"
          max_retries=5
          retry_count=0
          upload_success=false
          
          while [ $retry_count -lt $max_retries ] && [ "$upload_success" = "false" ]; do
            echo "上传 ${retry_count}/${max_retries} 到 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 "上传成功"
            else
              echo "上传失败，准备重试"
              retry_count=$((retry_count + 1))
              if [ $retry_count -lt $max_retries ]; then
                echo "等待 5 秒后重试"
                sleep 5
              fi
            fi
          done
          
          if [ "$upload_success" = "false" ]; then
            echo "已达到最大重试次数"
            exit 1
          fi
          
          DOWNLOAD_URL="${{ secrets.R2_PUBLIC_URL }}/${{ env.RELEASE_FILE }}"
          echo "DOWNLOAD_URL=$DOWNLOAD_URL" >> $GITHUB_ENV
          echo "下载URL: $DOWNLOAD_URL"

      - name: 从 R2 下载并部署
        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 "下载 (${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 "下载的文件为空，准备重试"
                fi
              else
                echo "下载失败，准备重试"
              fi
              
              retry_count=$((retry_count + 1))
              if [ $retry_count -lt $max_retries ] && [ "$download_success" = "false" ]; then
                echo "等待5秒后重试"
                sleep 5
                rm -f release.zip
              fi
            done
            
            if [ "$download_success" = "false" ]; then
              echo "已达到最大重试次数"
              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

            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 "清理旧部署，保留 ${{ env.KEEP_DEPLOYMENTS }} 个最新版本"
            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 "删除旧版本: $dir"
              rm -rf "$dir"
            done
            
            rm -rf /tmp/astrionyx 2>/dev/null || true
            echo "部署完成"

      - name: 运行部署后脚本
        if: success()
        run: |
          if [ -n "${{ secrets.AFTER_DEPLOY_SCRIPT }}" ]; then
            echo "执行部署后脚本"
            ${{ secrets.AFTER_DEPLOY_SCRIPT }}
          fi

      - name: 删除 R2 中的文件
        if: always()
        run: |
          echo "清理 R2 存储中的临时文件"
          rclone delete r2:${{ secrets.R2_BUCKET }}/${{ env.RELEASE_FILE }}

Shell

# ci-release-build.sh

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

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

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 ./*

With this workflow, every time I push code to the main branch, Astrionyx automatically builds and deploys to the server. And using R2 object storage as a relay station dramatically cuts deployment time (the whole workflow went from 20 min to under 4 min) — a real life-saver.

That's all🎉.