BARAS: A Rust-Based Combat Parser for SWTOR Endgame

What BARAS Solves and Who It Serves

BARAS, short for Battle Analysis and Raid Assessment System, addresses a specific pain point for Star Wars: The Old Republic players who do endgame content: operations and raids. In these modes, knowing your damage output, healing, and threat is critical, but the game itself provides no built-in combat log parser. BARAS fills that gap by reading combat logs and presenting them in a fast, modern interface. The target audience is the raiding community, from progression groups to parse-chasers. It is not a general-purpose tool; it is narrowly scoped to SWTOR's combat log format and the encounter definitions that matter for endgame bosses. The README positions it as the 'ultimate companion' for endgame, which is promotional language, but the project's structure confirms a serious focus on raid encounters, including a validation tool that replays logs against boss definitions.

Architecture: Rust Core, Tauri Shell, Dioxus Frontend

The project is written in Rust and uses a split architecture. There is a separate crate called `baras-parse-worker` that handles the heavy lifting of parsing combat logs. This worker is built as a sidecar binary that the main Tauri application invokes. The frontend is built with Dioxus, a Rust-based UI framework, and the whole thing is packaged as a Tauri v2 application. This means the UI is rendered in a webview, but the parsing logic runs natively. The separation is deliberate: the parse-worker can be built and validated independently, and the Tauri app stays lightweight. The README shows a manual build process where you must copy the worker binary to a specific directory with a target triple suffix, which suggests the sidecar is loaded at runtime based on the platform. This architecture is a good fit for performance, because Rust's concurrency and memory safety apply to the parsing hot path, while the UI remains responsive. However, it also means there are two build stages, and the sidecar must match the target triple exactly or the app will not find it.

Getting It Running: Installation and Build Commands

For end users, the README points to the official website for the installation guide, so the exact release install steps are not in the repository. For developers, building from source is documented. The prerequisites are the Rust stable toolchain, the `wasm32-unknown-unknown` target, the Dioxus CLI, the Tauri CLI, and optionally `just` for convenience. On Linux, you need a list of system packages including `libwebkit2gtk-4.1-dev`, `libjavascriptcoregtk-4.1-dev`, `libappindicator3-dev`, `librsvg2-dev`, `patchelf`, `libxdo-dev`, and `libasound2-dev`. The recommended development command is `just dev`, which builds the parse-worker sidecar and starts the Tauri dev server with hot-reload on `localhost:1420`. For a release build, `just bundle` produces platform-specific artifacts: AppImage and `.deb` on Linux, NSIS installer on Windows, and `.dmg` on macOS. Notably, there is no cross-platform compilation; you must build on each OS. The manual steps are explicit: build the worker with `cargo build --release -p baras-parse-worker`, copy it to `app/src/target/release/baras-parse-worker-<TARGET_TRIPLE>`, then run `cd app && cargo tauri build`. The README warns that the compiled application is unsigned, which may trigger OS warnings but does not stop it from running. That is a real hurdle for less technical users.

Configuration and Encounter Definitions

Configuration is stored in platform-specific directories: `%APPDATA%\baras\` on Windows, and `~/.config/baras/` on Linux and macOS. The primary file is `config.toml`, which saves global settings and overlay profiles. The `encounters` directory holds timer definitions for bosses. Adding a file in the same format will load it into the app, which means the app is extensible without recompiling. Similarly, the `effects` directory holds definitions for effects. This is a key mechanism: the parser does not hardcode boss timers or effect logic; it reads them from TOML files. That is a double-edged sword. On the positive side, the community can add new encounters as they are released. On the negative side, if the definitions are incomplete or outdated, the parser may misreport timers or miss effects. The `baras-validate` CLI tool is a safeguard: it replays combat logs against encounter definitions, for example `cargo run --bin baras-validate -- --boss revan --log test-log-files/operations/hm_tos_revan.txt`. This is a concrete way to test definitions before relying on them in a raid. However, the README does not document the format of the encounter or effect files, so extending them requires reverse-engineering or asking the community.

Platform Support and Its Caveats

The platform support table is refreshingly honest. Windows 10/11 is marked as native. Linux is native for both X11 and Wayland, which is rare for a Tauri app. macOS is marked as native but experimental. That experimental label is important: if you are on a Mac, expect rough edges. The README does not specify what is experimental, but the lack of a stable release for macOS suggests it is not the primary target. The build instructions also reveal a limitation: there is no cross-platform compilation. You must build on the target OS, which is standard for Tauri but still a constraint. The unsigned binary note applies to all platforms, but on macOS, Gatekeeper may be more aggressive, potentially requiring right-click open or terminal commands to run. The README does not mention that, but it is a known friction point for unsigned macOS apps. For Linux users, the dependency list is long, and `libappindicator3-dev` is often deprecated in favor of `libayatana-appindicator`, but the README lists the former, so you should follow that exactly or the build may fail.

Validation Tooling: A Concrete Quality Check

One of the most distinctive features is the `baras-validate` CLI. It replays combat logs against encounter definitions, which is a form of regression testing for the parser. The README gives an example with `--boss revan` and a log file. This suggests that the project has a test-log-files directory with sample logs for operations like 'hm_tos_revan' (hard mode TOS, Revan). This is a genuine advantage over many parsers that rely on manual testing. It means that when a new patch changes combat log format, the maintainers can run the validator to see what breaks. For users, it also means you can verify that your local encounter definitions are correct before a raid. However, the validator is a developer tool, not a user-facing feature. The README does not explain how to interpret the output, and the encounter definitions are not documented. So if you are not a developer, you may never use it. Still, its existence signals a mature development process, which is a positive signal for adoption.

Limitations and When BARAS Is the Wrong Tool

BARAS is not for everyone. If you are a casual player who does not do operations, you do not need a combat parser. If you are on macOS and expect a polished experience, the experimental label is a warning. The lack of a cross-platform build means you cannot just download a Linux binary; you must build it yourself or use the provided release artifacts, which are not linked in the README. The unsigned binaries are a security concern for some users, though the MIT license and open-source nature mitigate that if you build from source. Another limitation is that the README does not describe the UI features in detail. There is no mention of overlays, damage meters, or log export options beyond the config directory. The config.toml saves overlay profiles, so overlays exist, but you have to infer that. If you need a parser with extensive customization, such as custom graph layouts or advanced filtering, BARAS may not have it yet. Finally, the project is fan-made and not affiliated with EA or Broadsword, so it could break if the game changes its log format. The validator helps, but it is a reactive tool, not a preventive one.

Alternatives and the Difference in Approach

The most well-known alternative for SWTOR combat parsing is StarParse, a Java-based application. StarParse has been around for years and is widely used in the raiding community. Its approach is different: it runs on the Java Virtual Machine, which gives it cross-platform support but also a heavier runtime and slower startup compared to a native Rust binary. StarParse typically requires manual setup of a combat log directory and often relies on a separate overlay program. BARAS, in contrast, is native, which should mean lower memory usage and faster parsing, and it integrates the overlay into the Tauri app. The README does not mention StarParse, but the difference in architecture is clear from the repository: Rust and Tauri versus Java and Swing or JavaFX. If you value performance and a modern UI, BARAS is the forward-looking choice. If you value a long track record and community plugins, StarParse is safer. There is also the official SWTOR combat log parser, but it is not a real-time tool. BARAS claims to be 'fast and modern', and the Rust implementation supports that claim, but the evidence is in the code, not in benchmarks. The README does not provide performance numbers, so you should verify with your own logs.

Editorial conclusion

BARAS is for SWTOR players who raid or run operations and want a fast, cross-platform combat parser with a modern interface. If you are on Windows 10/11 or Linux with X11 or Wayland, it is a viable choice. Avoid it if you need official support or a stable macOS experience, as macOS is experimental. Before adopting, verify that the encounter definitions match your raid content and that you are comfortable with the unsigned binaries and manual sidecar setup. Join the Discord for help, and check the website for the latest installation guide. If you prefer a battle-tested parser with a longer history, consider StarParse, which is a mature alternative but lacks BARAS's Rust performance and cross-platform reach.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes