Bug Tracking for Train and Transport Sims

Train and transport sims model networks: tracks, signals, blocks, schedules, and the physics of vehicles moving through them. Their bugs are network-dependent and emergent. Two trains deadlock at a junction under a signal configuration that is fine everywhere else, a schedule sends a vehicle the long way for reasons buried in pathfinding cost, or a long consist behaves wrong on a gradient because of how coupling forces accumulate. None of this reproduces without the network, because the bug is a property of the layout. This post covers what breaks in routing, signals, and train physics, and how to capture the network state that makes these reproducible.

Signals, blocks, and deadlock

The classic transport sim bug is the deadlock: two or more trains each holding a block the other needs, frozen forever. Signaling is what is supposed to prevent this, and deadlocks happen when the signal placement, the block boundaries, and the reservation logic interact in a way that lets a cycle of dependencies form. These are exquisitely sensitive to the exact layout, because moving one signal a tile changes the block structure and can create or cure a deadlock that exists nowhere else on the map.

Reproducing a deadlock means capturing the relevant slice of the network: the track graph around the junction, the signal types and positions, the current block reservations, and which train holds and wants what. A report that two trains are stuck is unactionable. A report carrying the local topology and the reservation state lets you see the dependency cycle directly, and watch whether the bug is in reservation, in signal logic, or in the player's design, without rebuilding their junction from a screenshot.

Routing and schedule conflicts

Beyond signals, transport sims route vehicles along schedules through a path the game chooses by cost. Bugs here look like a vehicle taking an absurd route, ignoring a closer depot, or oscillating between two destinations. The cause is usually in pathfinding cost or penalty accumulation: a penalty that should discourage a path is undercounted, or a cached route went stale when the player edited the network. The vehicle is following the rules, but the rules computed a wrong answer for this specific graph.

These need the schedule and the routing context to debug. The vehicle's full schedule, its current order, the path the game computed, and the costs or penalties along it let you see why the pathfinder preferred the wrong route. A report that a train is going the wrong way tells you nothing about whether the schedule is misconfigured, the penalty math is off, or a cache is stale. The captured routing decision turns an apparent AI tantrum into a specific cost calculation you can inspect and correct.

Train physics and consist behavior

Many transport sims model some physics: acceleration, braking, the weight of a consist, and the forces between coupled cars on gradients and curves. Bugs here include a long train that cannot start on a slope it should handle, coupling forces that snap or oscillate, a consist that derails on a curve at a speed it should take, or braking that overshoots a station. These depend on the specific train composition and the specific track geometry, so a generic test train on flat track will never show them.

Capturing physics bugs means recording the consist and the geometry together. The locomotives and cars with their weights and power, the current speed and acceleration, the gradient and curve radius at the failure point, and the coupling forces if you model them give you the inputs to the physics that misbehaved. A report that a train derailed is a story. A report that carries the consist, the speed, and the track profile is a physics problem with defined inputs, which you can feed back into the simulation and watch fail the same way.

Grouping network bugs across layouts

Every player builds a different network, so the same signaling or routing bug appears in countless different junctions and schedules. Triaging by the surface symptom treats one reservation bug as a hundred separate stuck-train reports. Grouping by the underlying fault, the specific reservation case or the specific pathfinding penalty, collapses those divergent layouts into one issue, and the topology and routing data in the grouped reports exposes the shared structural trigger that all the different junctions have in common.

Counts keep the priorities sensible. A deadlock that any common junction pattern can trigger affects far more players than one that needs an exotic layout, and a routing penalty bug that quietly costs everyone efficiency matters more than a rare cosmetic glitch. Occurrence counts on grouped issues show how many networks each fault actually reaches, so you fix the signaling and routing problems players keep building into rather than the single bizarre layout that produced the most detailed forum post.

Setting it up with Bugnet

Bugnet lets a transport sim capture the network state behind its bugs. The in-game report button snapshots the relevant slice when a player flags a deadlock or a misrouted vehicle: the local track graph, the signal types and positions, the current block reservations, the vehicle schedules and computed paths with their costs, and the consist and physics state, all as custom fields and attributes. Instead of a note that two trains are stuck, you receive the topology and reservations to load the network and see the dependency cycle.

When the simulation throws while resolving a path or a reservation, crash reporting captures the stack trace with the same network context. Occurrence grouping folds reports sharing a fault into one counted issue, so the deadlock common junctions trigger rises above the exotic one. You filter by network size, vehicle type, or any custom field, prioritize by count, ship the fix, and confirm the routing or signaling fault stops recurring, all from one dashboard rather than rebuilding junctions from screenshots.

Test against real networks and watch the trend

Teams that ship transport sims keep a library of real player networks and reference layouts and run them every release, because the signaling and routing bugs that matter only emerge in dense, organically grown networks, not in a tidy test track. Make sure your report capture includes the network snapshot and reservation state even in release builds, and test the loop by loading a captured deadlock and confirming the dependency cycle reproduces. A signaling change you have not tested against real junctions will surprise you in the wild.

Watch the grouped occurrence list around any change to pathfinding, signaling, or physics, because each is a chance to break layouts that only exist in player networks you cannot easily generate. A cluster of deadlock reports after a signaling patch is your earliest warning that the reservation logic regressed. A transport sim that captures the topology, the schedules, and the physics state, and groups by fault, turns its own network complexity from an unreproducible mess into a layout you can load, inspect, and fix.

Transport sim bugs are properties of the network. Capture the topology, reservations, schedules, and physics state, and group by fault so you can load the exact layout that deadlocked.