# MFABD2: a MaaFramework assistant that plays Brown Dust 2 dailies for you

> MFABD2 is a Python automation assistant built on MaaFramework that drives Brown Dust 2 through an emulator or a real Android device, claiming to run close to fifty minutes of daily, weekly and event tasks unattended. It suits a player who wants the repetitive half of a gacha game's daily loop automated, and it is a tool that runs against a live game client, so its maintenance burden lives in the game's own updates.

**sunyink/MFABD2** — 《棕色尘埃2 (Brown Dust 2)》MaaFramework (MFA)框架自动化脚本。自动领取日常，拒绝给游戏打工！ 

- Repository: https://github.com/sunyink/MFABD2
- Stars: 641 · Forks: 43
- Language: Python
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/sunyink-mfabd2

## A MaaFramework task graph aimed at one game

MFABD2 is built on MaaFramework, a framework for writing device automation tasks as a data-driven pipeline, and this project is a full flow assistant for one specific title, Brown Dust 2. The README frames the value proposition in a blunt way, freeing the fifteen minutes of daily chores and running close to fifty minutes of daily, weekly and event tasks unattended.

The scope of automation is listed by category, and it is broad for a daily-task bot. On opening, it launches and updates the game and applies the front configuration. Combat farming covers the hunting ground, the holy stone cave, the roguelike tower, PVP and seasonal events across the normal, challenge, beast and field variants. There is a free draw section covering the daily free pull, the discount tier and keeping the multi-pool pity. Resources and rewards cover full-map collection, pet dispatch, restaurant settlement and one-click claiming of task, event, pass and mail rewards. Weekly idle tasks cover the doomsday book, automatic fishing and cabin likes. Two extras are called out separately: merchant arbitrage, which identifies the highest price, cooks dishes and bulk trades a customisable item list, and fishing takeover, which detects the right moment to reel and loops on its own.

The architecture is the MaaFramework one, and the repository layout makes that visible. There is an agent/ directory for the custom actions, deps/ for dependencies, release/ for packaging, runtimes/ for the runtime images, and the resource bundle and framework version are both pinned in requirements.txt rather than left to the installer.

The audience is a player, not a developer, in the sense that the shipped artefact is a UI you download and run. The audience for the code is someone who wants to extend the task set.

## Version channels, and the downgrade trap

The project publishes on two channels, and the README explains the difference with some care. The stable channel uses a pure numeric version number and is described as the choice for players who want stability, and the documentation says it usually arrives only after a hundred or more commits and several rounds of patch verification. The beta channel uses a version number containing Beta, iterates frequently against what is actually happening in the game and with its assets, with update granularity measured in days or even hours, and the project actively invites bug reports through issues on that channel.

The version numbers themselves are the giveaway. The releases listed are v4.6.0, and two v4.5.1 build tags with a date and a commit hash, such as v4.5.1-ci.261018.c1ed0289, which is a continuous integration build rather than a curated release. That naming scheme tells you the beta channel is a moving target by construction.

The downgrade note is the part worth reading twice, because it is a data-loss trap. Switching update channels does not downgrade automatically. For the desktop build, the beta and internal test patch numbers are one and two respectively above the same stable baseline, so a lower target version simply will not receive a push, and the advice is to back up the configuration and saves, then manually download the full package for the target channel and extract it into a new directory. For the Android APK, the criterion is the install number the system uses to judge application age, not the display version or the channel. A package with a smaller install number cannot be installed over the top of a newer one, so a downgrade requires uninstalling first, and uninstalling clears the application data, which means backing up the configuration and saves first. The project also points at docs/android.md for the full update notes.

Desktop updates are handled inside the UI, with downloads provided by a third party mirror service, while the Android APK currently uses the GitHub update source.

## Three ways to run it: emulator, phone and PC client

The deployment options differ enough to be worth separating, because each has a different set of prerequisites.

The Windows path is the traditional one. The quick start says to download the platform package, extract it, set MuMu to 1920 by 1080, switch the game to Simplified Chinese, then launch the UI. The recommended emulator is MuMu 12, which needs a Google environment configured, and the display must be set to the tablet mode 1920 by 1080 with a DPI around 270 or 280. The UI is MFAA, the Avalonia-based MaaFramework client, and its top tab bar creates new tabs for multiple instances. The project has a save slot feature, so multi-instance runs need a save slot number filled in.

The Android path is the simplest. You download MFABD2-<version>-android-arm64.apk from the releases page, install it directly with no extraction and no emulator, and you need Android 9 or newer on a 64-bit ARM phone, with authorisation through Shizuku, the tool that grants system operation rights to apps, or through root. The game language must be Simplified Chinese. The install and run details are in docs/android.md.

The Mac path is the fiddliest. The documentation says the configuration is somewhat complex and points at the M9A documentation site, noting that the software deployment part is shared with the same framework, and that a one-click environment repair script is provided in the root directory. On Apple Silicon the recommendation is to control the iOS version through PlayCover directly with no Android emulator, but there is a hard requirement: the hguandl fork of PlayCover must be used, because the mainline release has no MaaTools and cannot connect. PlayCover support is contributed and maintained by a named community member.

A fourth path is in public beta. The PC client guide covers controlling the Win32 Windows version of the game directly with no emulator, and it is in the beta channel with the work driven by a named contributor, with available tasks depending on the selected version.

## The in-game configuration the bot expects

Before the automation can run, the game has to be configured in specific ways, and the documentation is unusually explicit about it. The current version supports automatic configuration, but the game language has to be switched to Simplified Chinese and the resolution has to be correct first, after which the setup can be completed during a run.

If automatic configuration fails, the manual settings are given as a table of category, setting and value. For operation, the method of selecting operations is set to tap the ground. For image, the resolution is FHD and the game start screen is the main menu. For notification, the yellow dot is set to not use.

The rendering note is a hardware judgement. When image quality looks wrong, check the rendering method, because new machines usually perform better with Vulkan and older machines are advised to use DirectX. Skill animations can be turned off to improve running speed.

The third step is character skills and equipment. Skill positions and equipment dismantle options are set in a way that is stored locally in the emulator and does not affect other instances, so it is configured once. The upgrade target level and the gold spending limit are to be set manually according to personal preference. There is a specific note about equipment: keep at least one SR or UR plus-nine item for refining.

There is also a section on task reset. Map state recognition, automatic generation of skill teleport arrays and the great majority of interruption scenarios are handled by an automatic reset, and the recommendation is to end the game on the story main map or on the teleport array.

## Reading requirements.txt as the maintenance contract

The dependency list at the top of requirements.txt is short and mostly reflects the resource and image work the assistant does:

```bash
json-with-comments
requests>=2.25.0
pytz
loguru
numpy<2
Pillow>=9.0.0
```

The numpy upper bound is a compatibility pin rather than a preference, and the presence of Pillow and json-with-comments tells you the project parses JSON resources with comments and processes images locally.

Below the dependency list sit the version pins, each commented in the file, and they are the clearest statement of how the project is maintained. A resource bundle version can be specified with MFAA_TAG, and the comment says the CI reads that line to download the resources. A MaaFramework core version override uses MFA_CORE_TAG, blank meaning no override and the core shipped with MFAA is used instead, and filling it in is described as an emergency mode that pulls that core version after MFAA is installed and syncs the pip, Android and resource checks.

The comment on that override documents a concrete bug. The current override sits at 5.14.3, and the reasoning is that the 5.12.3 core shipped with MFAA has a defect where the agent channel deadlocks, because the server replies to each controller event one by one and the client does not receive them, so the live view buffer fills after about two minutes of idle time. The upstream issue 1505 fixed it in 5.14.1, and the line is cleared so that the version follows the resource tag again.

A third pin, ANDROID_AGENT_CORE_TAG, selects the release tag of the Android agent core, and its comment is strict: when explicitly chosen, the framework version must be exactly the same as the desktop one, and the Python version must match the MaaFramework app builder. The project chooses 5.14.3 for the desktop, aligning with the Android side.

The maintenance point list file at the repository root and the CLAUDE.md file suggest a project that keeps an explicit register of what needs attention across versions.

## Where MFABD2 is the wrong tool

The first limitation is the one every automation tool for a live game has, and this project is explicit about it. The tasks are implemented against a specific client version, and the game's own updates change what the bot sees. The beta channel description says it iterates at day or even hour granularity against what is happening in the game and with its assets, and the PC client guide says the available tasks depend on the selected version. That is a permanent maintenance obligation, and it is the project's cost, not the user's.

The second case is the player who wants the game to look untouched. The assistant configures the client, changes settings, and drives a full session of combat, drawing and trading. Any service that does that risks tripping anti-cheat measures or violating the publisher's terms, and no script can promise otherwise. A project like this exists precisely because players accept that risk, and an evaluation that ignores it is not honest.

The third case is hardware. The Windows path needs a specific emulator at a specific resolution and DPI, the Android path needs Android 9 on ARM64 with Shizuku or root, and the Mac path needs a non-mainline PlayCover fork. Anyone without one of those three environments cannot run it, and the setup is not trivial in any of them.

The alternative worth comparing is doing the dailies by hand, which is what most players do. The comparison is roughly fifteen minutes of manual play against close to fifty minutes of unattended execution, so the case for the tool is time rather than capability, and the tool is only worth the setup cost if you would otherwise play every day. A second alternative is a generic scripting approach, where you drive the emulator with your own ADB scripts, which gives you full control over what the client does and avoids a third party's interpretation of the game's screens, and which costs you the maintained task set and all the version pinning work described above.

## Conclusion

MFABD2 fits a player of Brown Dust 2 who treats the daily and weekly grind as a chore and has the hardware to run an emulator, a rooted or Shizuku-enabled phone, or a Mac with PlayCover, and who is comfortable with a tool that drives the live client. It is the wrong choice for a player who wants the game to look and behave as if played by hand, for anyone whose device cannot run the required environment, and for a team that needs a supported contract rather than a single maintainer's automation scripts. Before installing, pick the release channel deliberately, because switching from the beta channel back to stable requires the manual download described in the release notes, and read the version pinning block in requirements.txt, since the resource bundle tag, the MaaFramework core tag and the Android agent core tag are each pinned separately and must agree.

## FAQ

### What does the MFABD2 automation assistant actually automate?

It covers daily startup and game updates, combat farming in the hunting ground, holy stone cave, roguelike tower, PVP and seasonal events, free gacha draws, resource and reward collection across maps, pets, restaurant, tasks, events, pass and mail, weekly tasks, merchant arbitrage and automatic fishing, in a run described as close to fifty minutes of unattended play.

### What are the system requirements to run MFABD2?

On Windows you need the MuMu 12 emulator set to tablet mode 1920 by 1080 with a DPI around 270 or 280, or the beta PC client. On Android you need Android 9 or later on an ARM64 phone authorised through Shizuku or root. On Apple Silicon Mac the documentation recommends the hguandl fork of PlayCover, since the mainline version has no MaaTools.

### How do I downgrade MFABD2 from the beta channel to the stable channel?

Switching channels does not downgrade automatically. On desktop the beta and internal test patch numbers sit above the same stable baseline so no update is pushed, and you need to back up configuration and saves then extract the target channel package into a new directory. On Android the install number decides, so a downgrade needs an uninstall that clears app data, which is why backing up first matters.

### Which versions does the MFABD2 project pin?

Three separate tags in requirements.txt: MFAA_TAG for the resource bundle, MFA_CORE_TAG for the MaaFramework core version, and ANDROID_AGENT_CORE_TAG for the Android agent core. The comments state that when the Android core is pinned explicitly, the framework version must match the desktop exactly and the Python version must match the MaaFramework app builder.

### What licence is MFABD2 released under?

The repository records a custom licence that GitHub cannot classify, and the README badge refers to MIT and Apache-2.0, with LICENSE, LICENSE-MIT and LICENSE-APACHE files in the repository root. A separate TRADEMARKS.md covers icons, original assets and project identity without changing the open source licence.

## Sources

- [Issues](https://github.com/sunyink/MFABD2/issues)
- [README](https://github.com/sunyink/MFABD2/blob/main/README.md)
- [Releases](https://github.com/sunyink/MFABD2/releases)
- [sunyink/MFABD2 on GitHub](https://github.com/sunyink/MFABD2)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sunyink-mfabd2