SamandClaude Fable 5
6b980b9efb
- a player build ships beside the dev one — dev chords and probe surfaces go dark, and a gate enforces what a player can still reach, by medium not by module - the binary carries its own shaders and its shipped UI, finds the WoW folder by itself, and keeps its local state in one benilla-config folder - the glue screens get a capture shutter, and the engine stops depending on the protocol crate Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
31 lines
1.4 KiB
Rust
31 lines
1.4 KiB
Rust
//! `cargo run -p benilla-formats --example where` — **where does benilla think the install is?**
|
|
//!
|
|
//! The resolver's own answer, printed (decision 1175). Two callers, and both are the reason this
|
|
//! is a program rather than a comment:
|
|
//!
|
|
//! - `scripts/gates.sh`, to decide whether the enforcer gate can run. It used to hand-roll half
|
|
//! the rule (`[ -n "$WOW_DATA" ] || [ -d WoW/Data ]`), which is exactly the duplication 1175
|
|
//! exists to end — a gate that disagrees with the client about where the install is will skip
|
|
//! on a machine where the client would have run, or run on one where it cannot.
|
|
//! - a human whose client came up with no world. "It looked in these four places and none of them
|
|
//! existed" is actionable; "the terrain just doesn't appear" is not.
|
|
//!
|
|
//! Exits **0** when an install was found and **1** when none was, so a shell can branch on it.
|
|
|
|
fn main() -> std::process::ExitCode {
|
|
match benilla_formats::wow_data() {
|
|
Some(data) => {
|
|
println!("{}", data.display());
|
|
std::process::ExitCode::SUCCESS
|
|
}
|
|
None => {
|
|
eprintln!("no WoW install found. Looked in, in order:");
|
|
for c in benilla_formats::candidates() {
|
|
eprintln!(" {}", c.display());
|
|
}
|
|
eprintln!("Set $WOW_DATA, or put a WoW folder beside the binary.");
|
|
std::process::ExitCode::FAILURE
|
|
}
|
|
}
|
|
}
|