Serverside panic on `graph.get_relative_up(position).unwrap()`

[patowen]

If I launch Hypermine on the master branch with block_reach set to 2, I get the following panic:

2026-03-04T01:39:06.557360Z  INFO found config at $HOME/.config/hypermine/client.toml
2026-03-04T01:39:06.557490Z  INFO using save file $HOME/.local/share/hypermine/default.save
2026-03-04T01:39:06.569751Z  INFO spawning character id=f1644f405148e95c name=gyrola
2026-03-04T01:39:06.569772Z  INFO connected locally id=1v1

thread '<unnamed>' (17977) panicked at common/src/character_controller/mod.rs:37:45:
called `Option::unwrap()` on a `None` value
stack backtrace:
2026-03-04T01:39:06.584560Z  INFO Guessed window scale factor: 1
2026-03-04T01:39:06.813072Z  INFO Vulkan instance layers: ["VK_LAYER_VALVE_steam_fossilize_64", "VK_LAYER_VALVE_steam_overlay_64", "VK_LAYER_VALVE_steam_fossilize_32", "VK_LAYER_VALVE_steam_overlay_32", "VK_LAYER_MESA_device_select", "VK_LAYER_NV_optimus", "VK_LAYER_MESA_overlay", "VK_LAYER_INTEL_nullhw"]
2026-03-04T01:39:06.860890Z  INFO selected device name="NVIDIA GeForce RTX 3060"
   0: __rustc::rust_begin_unwind
             at /rustc/254b59607d4417e9dffbc307138ae5c86280fe4c/library/std/src/panicking.rs:689:5
   1: core::panicking::panic_fmt
             at /rustc/254b59607d4417e9dffbc307138ae5c86280fe4c/library/core/src/panicking.rs:80:14
   2: core::panicking::panic
             at /rustc/254b59607d4417e9dffbc307138ae5c86280fe4c/library/core/src/panicking.rs:150:5
   3: core::option::unwrap_failed
             at /rustc/254b59607d4417e9dffbc307138ae5c86280fe4c/library/core/src/option.rs:2175:5
   4: core::option::Option<T>::unwrap
             at /home/patrick/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:1016:21
   5: common::character_controller::run_character_step
             at ./common/src/character_controller/mod.rs:37:45
   6: server::sim::Sim::step
             at ./server/src/sim.rs:546:13
   7: server::Server::on_step
             at ./server/src/lib.rs:185:40
   8: server::Server::run::{{closure}}
             at ./server/src/lib.rs:140:44
   9: <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tracing-0.1.44/src/instrument.rs:321:15
  10: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /home/patrick/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/future.rs:133:9
  11: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /home/patrick/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/future.rs:133:9
  12: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}::{{closure}}::{{closure}}
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:753:70
  13: tokio::task::coop::with_budget
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/task/coop/mod.rs:167:5
  14: tokio::task::coop::budget
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/task/coop/mod.rs:133:5
  15: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}::{{closure}}
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:753:25
  16: tokio::runtime::scheduler::current_thread::Context::enter
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:442:19
  17: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:752:44
  18: tokio::runtime::scheduler::current_thread::CoreGuard::enter::{{closure}}
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:840:68
  19: tokio::runtime::context::scoped::Scoped<T>::set
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/context/scoped.rs:40:9
  20: tokio::runtime::context::set_scheduler::{{closure}}
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/context.rs:176:38
  21: std::thread::local::LocalKey<T>::try_with
             at /home/patrick/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:513:12
  22: std::thread::local::LocalKey<T>::with
             at /home/patrick/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:477:20
  23: tokio::runtime::context::set_scheduler
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/context.rs:176:17
  24: tokio::runtime::scheduler::current_thread::CoreGuard::enter
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:840:27
  25: tokio::runtime::scheduler::current_thread::CoreGuard::block_on
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:740:24
  26: tokio::runtime::scheduler::current_thread::CurrentThread::block_on::{{closure}}
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:200:33
  27: tokio::runtime::context::runtime::enter_runtime
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/context/runtime.rs:65:16
  28: tokio::runtime::scheduler::current_thread::CurrentThread::block_on
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/scheduler/current_thread/mod.rs:188:9
  29: tokio::runtime::runtime::Runtime::block_on_inner
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/runtime.rs:368:52
  30: tokio::runtime::runtime::Runtime::block_on
             at /home/patrick/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/runtime.rs:340:18
  31: client::main::{{closure}}
             at ./client/src/main.rs:59:25
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2026-03-04T01:39:08.125104Z  INFO exiting due to closed window

The game is still playable, with just the client active, not the server, so I cannot, for instance, break or place any blocks.

[patowen]

There are some things I want to experiment with in Hypermine, but I'm definitely close to the point where I would like to take a pass through the codebase and correct the logic errors that have built up over time despite my best efforts to write bug-free code.

My plan is to do this while improving documentation for new readers of the code. My hope is that the code can be readable enough that logic errors like this resulting in panics become obvious.

[patowen]

However, I think I know the root cause: When a character is spawned, it is spawned at MIsometry::translation_along(&(na::Vector3::y() * 1.4)), which results in a Position that is associated with the origin node but happens to be outside that node. The logic of nearby_nodes falsely assumes that the Position passed in has its local vector inside the dodeca, causing it to exit early and return no nodes when that assumption fails.

This is a bug in multiple places:

• The nearby_nodes function's contract demands that every node in range of the passed in location in space is returned. The accidental precondition created on start is invalid and would make the function very brittle if we depended on that precondition.
• We also make the assumption that if you call nearby_nodes with a particular NodeId passed in start, then that NodeId will be returned. This assumption is false if local is too far from the origin, and nearby_node behaves exactly as it is documented to behave.

The quick and dirty fix for this would be, in server.sim, right before calling character_controller::run_character_step, to call self.graph.ensure_node_state(position.node);, although this will still result in the (non-fatal) server-side error "Collision checking returned OutOfBounds" due to the nearby_nodes bug.

I'm a little hesitant to just patch up bugs without a larger underlying purpose, though. Rust has a reputation of making it easier than other programming languages to write bug-free code, so I'd like to try to ensure that where possible. More tests could help with that, but tests seem like a band-aid solution.

[Ralith]

I don't follow your last paragraph at all. We should fix bugs, and we should have tests to help detect bugs, which we can then fix.

[patowen]

I think I wrote my previous comment when I was tired. Fixing bugs as we discover them makes sense, and so does writing tests. I think I was starting to get concerned about the number of bugs suggesting that the code has gotten too complex and needed some kind of major refactoring to actually squash these kind of bugs for real.

However, this problem can be attacked from multiple angles, so squashing bugs as we find them makes sense in retrospect. My last paragraph was really just expressing a feeling of frustration.