# Auto_Simulated_Universe: a screen-reading bot for a Honkai Star Rail game mode > A Python automation suite that plays the Simulated Universe roguelike mode by reading the screen with OpenCV and clicking with PyAutoGUI, distributed as a PyInstaller GUI and as scripts you run yourself. **CHNZYX/Auto_Simulated_Universe** — 崩坏：星穹铁道 模拟宇宙自动化 （Honkai Star Rail - Auto Simulated Universe） - Repository: https://github.com/CHNZYX/Auto_Simulated_Universe - Stars: 3,796 · Forks: 215 - Language: Python - License: AGPL-3.0 - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/chnzyx-auto-simulated-universe ## Two game modes, two entry scripts, one shared library The repository is split by game mode rather than by layer. `diver.py` runs the differential universe, which the README says is the mode this branch focuses on, and `simul.py` runs the ordinary Simulated Universe. A third script, `align_angle.py`, exists on its own because calibration is a separate concern. Both entry points share the directories you would expect: `abyss/` for the mode-specific logic, `actions/` for the primitive layer that moves a character, opens a menu or waits out an animation, and `utils/` for helpers. `gui.py` is the graphical front end, `notif.py` is a Windows notification helper that also ships as `notif.exe` in a packaged build, and `imgs/` holds the image assets the matcher works against. There is also `start.mp3`, which tells you something about how the project feels about long unattended runs. The README points at a separate documentation repository for the full guide, a question and answer page, and a page on running under multiple Windows user accounts in the background. That last one exists because the automation needs the game window to stay exactly where it was put, so a second desktop session is the workaround for wanting to use the machine at the same time. ## Installing with conda, or double clicking a batch file The README recommends conda and asks for it to be run from `cmd` rather than PowerShell, because the virtual environment switch is said to fail in PowerShell: ```bash conda create -n asu python=3.12 -y conda activate asu pip install -r requirements.txt ``` The alternative is `install_requirements.bat`, a double clickable batch file in the repository root that installs the same dependencies, and the README marks it as the route not to take. The dependency list is where the design becomes legible. `opencv_python` does the image recognition, `PyAutoGUI` moves the mouse and presses keys, `pyscreeze==0.1.28` is a second screen region finder used alongside OpenCV, `onnxruntime-directml` provides a DirectML inference backend on Windows, `shapely` and `pyclipper` do polygon work, and `numpy` is pinned to 1.26.4, which is the kind of pin that tells you the project has to work on a specific set of versions rather than whatever is current. `flet==0.23.2` and `flet_core==0.23.2` are the desktop GUI framework, pinned in the same way. So the pipeline is Windows and GPU directed in intent, even though DirectML is only one of several installable extras. A machine without a DirectML capable GPU is expected to fall back to CPU, which is what the `--cpu` flag is for. `pyinstaller` in the list is how the downloadable GUI builds are produced, and `pyuac` explains why the packaged executable asks for elevation. ## Six settings in info.yml and one rename you must not skip Configuration lives in a single YAML file. The repository ships `info_example.yml` and `info_example_old.yml`, and the README's instruction is to rename the first one to `info.yml` and edit that. Nothing generates it for you, so a first run without the rename produces a missing file rather than a set of defaults. The settings that matter are these: ```yaml config: difficulty: 5 speed_mode: 0 cpu_mode: 0 save: 4 timezone: Default max_run: 34 ``` `difficulty` runs 1 to 5 and falls back to 4 when the world has no difficulty 5. `save` sets how many of the first four in-game save slots are written automatically. `max_run` is the run count. `timezone` exists because the game resets its blessings on a schedule tied to real time, so an automation that crosses that boundary can find its state changed underneath it. The one setting that needs game knowledge to fill in is `team`, which picks a team archetype from five options the README names in Chinese, covering pursuit, damage over time, ultimate, break and shield counter. Pick the one that matches the characters you have, since both the route and the skill timing follow from that choice. There is also a `skill` list naming the characters whose techniques should be opened in the boss room, in order. One constraint is repeated in both the command line and the GUI sections of the README: carry at least one ranged character, and put it in slot one. ## Calibration is the part that has to work on your machine Because the bot navigates by rotating the camera, it needs to know how far one unit of camera rotation moves the view. That value is the calibration, it is machine specific, and the README warns that changing mouse DPI invalidates it. Calibration is done by teleporting the character to a fixed in-game location, Herta's office, and running the calibration script: ```bash python align_angle.py ``` The character turns in place until the sequence finishes, and the script measures how far the view actually moved against how far it was asked to move. Run it once per display setup. The reason calibration depends on the display is stated plainly in the command line section: only 1080p or higher resolutions are supported, in windowed or full screen, with HDR off, the interface language set to Simplified Chinese, and nothing occluding the game window. The GUI section adds a cloud version of the game that has to be opened as a desktop web application, which is an odd constraint to document but an honest one. The same restriction drives the request not to move the game window once a run or a calibration has started. Everything downstream, pathing included, assumes a fixed pixel origin, which is also why a rotation that is calibrated slightly wrong sends the character into a wall and, in the README's phrasing, gets lost. ## Running the scripts with flags for speed, debugging and run count The command line entry points take flags rather than prompting, which is what makes the project scriptable: ```bash python diver.py <--debug> <--speed> <--cpu> --nums= ``` `--speed` turns on the speedrun mode, `--debug` keeps the bot from exiting to the summary screen after it gets lost, `--cpu` forces recognition onto the CPU, and `nums` sets how many runs to complete, which must be a positive integer. The ordinary mode script carries more: ```bash python simul.py --bonus= --debug= --speed= --find= --nums= ``` Those take values rather than bare flags: `bonus` in 0 or 1 for immersion rewards, `debug` in 0, 1 or 2, `find` in 0 or 1 where 0 records a route and 1 runs one. The `find` flag is the interesting one, because it implies a route can be recorded once and replayed, which is the sensible way to handle a mode where the map layout is fixed and only the fights vary. A separate option covers whether to use the top left consumable item before elite and boss fights. Stopping is documented as a hard requirement rather than a convenience, since a stuck bot holding the mouse is the failure mode users hit first. The F8 key and a stop button in the GUI both stop a run, and a checkbox controls whether the command line window stays visible while the GUI is open. ## Notifications, weekly counters and a licence that fits the risk The notification helper is packaged as `notif.exe` and posts a Windows toast each time a run completes. If you run the automation in a secondary Windows user account, the arrangement the README describes is to run the GUI in the child account and `notif.exe` in the main one, so the notification arrives on the desktop you are actually looking at. The counter resets weekly, and `logs/notif.txt` holds the count on its first line if you want to edit it by hand. `pystray` and `winotify` in the dependency list are what put the icon in the system tray. The licence is AGPL-3.0, a heavy choice for a game automation tool and an interesting one: it guarantees that anyone running a modified build as a service has to publish their changes. What deserves more attention is the disclaimer, which quotes the publisher's fair play statement directly: third party tools, scripts and accelerators that damage game fairness are prohibited, and violations can lead to deducted gains, a frozen account or a permanent ban. The project's own disclaimer says it interacts only through the existing user interface, modifies no game files or code, and is not intended to provide an unfair advantage. That is the standard framing for this category of tool and it is worth reading against the quoted policy rather than accepting on its own. The most recent release, v8.044 from 2026-05-27, describes itself as a package built from recently merged pull requests with uncertain reliability, which is an unusually candid release note. The last push was on 2026-08-14. ## Conclusion The engineering in this repository is ordinary and competent: screen capture, template matching, a camera rotation heuristic that has to be calibrated per machine, and a queue of actions. What sits on top of it is not an engineering problem, because the publisher's own fair play statement bans scripts, so that risk belongs to the person running it rather than to the code. If you are studying the approach, the parts worth reading are `abyss/` for the route logic, `align_angle.py` for the calibration heuristic, and `info.yml` for the settings that change behaviour. If you want to run it, the first requirement is not Python, it is a physical display of at least 1920 by 1080 with the game in Simplified Chinese. ## FAQ ### How do I install Auto_Simulated_Universe's dependencies? The README recommends conda, run from cmd rather than PowerShell: create a Python 3.12 environment named asu, activate it, and run `pip install -r requirements.txt`. There is also `install_requirements.bat` in the repository root, which the README marks as the option not to take. ### What display settings does the HSR automation require? The README states that only 1080p or higher physical resolutions are supported, in windowed or full screen, with HDR off, the interface language set to Simplified Chinese, and nothing covering the game window. The cloud version has to be opened as a desktop web application, set to full screen, with the network and latency display turned off. ### Why does the bot get lost, and what does calibration fix? Camera rotation that is too large or too small makes the pathing wrong. Calibration measures how far the view actually turns against how far the script asks for, done by teleporting the character to Herta's office and running `python align_angle.py` until the rotation sequence ends. Changing mouse DPI invalidates the calibration, so it has to be redone. ## Sources - [CHNZYX/Auto_Simulated_Universe on GitHub](https://github.com/CHNZYX/Auto_Simulated_Universe) - [Issues](https://github.com/CHNZYX/Auto_Simulated_Universe/issues) - [License: AGPL-3.0](https://github.com/CHNZYX/Auto_Simulated_Universe/blob/main/LICENSE) - [README](https://github.com/CHNZYX/Auto_Simulated_Universe/blob/main/README.md) - [Releases](https://github.com/CHNZYX/Auto_Simulated_Universe/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chnzyx-auto-simulated-universe