Bug Reporting for Games With Mounts and Pets

Mounts and pets make a world feel alive and make your bug tracker feel busy. A companion is a second entity that must follow, path around obstacles, react to the player, and appear or vanish on command through summon and dismount logic. Each of those is a system that can fail independently: a pet that falls behind and never catches up, a mount that teleports across the map, a companion that clips into geometry, a summon that produces two of the same pet or none at all. The reports are vivid and the causes are buried in companion state. This post covers capturing that state, pathing, and lifecycle so the bugs become reproducible.

A companion is an entity with its own life cycle

A mount or pet is not a visual effect, it is a full entity with state: it exists or it does not, it is following or stationed or commanded, it has a pathing target and a position, and it has a relationship to the player who owns it. That state has a lifecycle, summoned into the world, active and following, dismissed or stored, and possibly persisted across zones or saves. Bugs appear wherever that lifecycle has a gap: a summon that does not clean up the previous instance, a dismiss that leaves the entity half-removed, a zone transition that loses the companion entirely.

Because the companion acts semi-autonomously, its behavior is driven by its own internal state rather than direct player input, which is exactly what makes its bugs hard to reproduce. The player did not tell the pet to walk off a cliff; the pet's follow logic and pathing did, in response to a situation that has since passed. To debug a lost or misbehaving companion you need a snapshot of its state at the moment, its follow mode, its target, its position relative to the player, and where it was in its lifecycle. The visible symptom is downstream of that state.

Capture the companion state and ownership

Log the companion's core state when a report fires: its existence and lifecycle stage, its current behavior mode such as following, stationed, or commanded, its position and the owner's position, and the distance and any leash or teleport-to-owner thresholds. Capture ownership and identity too, especially in multiplayer, where companions can be misattributed, duplicated, or left orphaned when an owner disconnects. A great many pet bugs are really identity bugs, the wrong owner, two instances of one pet, or a companion that outlived the system that should have despawned it, and only the state snapshot reveals which.

Summon and dismount events are the most failure-prone moments, so log them explicitly with their full context: what triggered the summon, whether a previous instance existed, where the companion spawned, and what the dismount did to the entity and any state it carried. The duplicate-pet bug is almost always a summon that did not check for or clean up an existing instance. The vanished-pet bug is often a dismount or zone transition that removed the entity but failed to restore it. Logging these lifecycle events with their before-and-after state makes both immediately diagnosable instead of mysterious.

Pathing and following

The behavior most players complain about is pathing, so capture the companion's pathing state: its current navigation target, the path it computed, its progress along that path, and the navmesh status at its position. A pet that falls behind and never catches up is usually a pathing failure, the target moved off the navmesh, the path could not be computed, or the follow distance logic stopped requesting new paths. Logging the navmesh validity at the companion's position and the last successful path tells you whether the navigation system failed or the follow logic stopped asking it for help.

Teleport-to-owner logic is the safety net that hides and reveals pathing bugs. Most companion systems teleport the pet to the player when it falls too far behind or gets stuck, which masks pathing failures, until the teleport itself misfires and the pet appears inside a wall, on the wrong floor, or across a chasm. Logging when and why the teleport fired, and the position it chose, exposes both the underlying pathing failure that triggered it and any bug in the teleport placement. The combination of pathing state and teleport events covers nearly the entire surface of follow-related complaints.

Common mount and pet failure modes

The recurring bugs cluster into a few families. Pathing failures: pets falling behind, getting stuck on geometry, or refusing to cross gaps. Teleport misfires: companions snapping into walls or onto the wrong surface. Lifecycle bugs: duplicate summons, vanished pets after zone changes, and companions orphaned by owner disconnects. Transition bugs specific to mounts: mounting that fails to parent the player correctly so they desync from the mount, and dismounting that drops the player into geometry or at the wrong position. Each shows a clear pattern in the state, pathing, and lifecycle logs.

Mounts add the wrinkle that the player is attached to a moving entity, so the mount's physics and the player's controller must stay in sync. A mount that the player is riding can teleport, clip, or desync, dragging the player into a broken state or leaving them behind while the mount moves on. Network sync makes this worse: in multiplayer the mount's position must agree across clients, and a desync produces a player riding a mount that other players see elsewhere. Capturing the mount and player relative state, and in multiplayer the synced positions, is what makes these attachment and sync bugs debuggable.

Setting it up with Bugnet

Bugnet's in-game report button lets a player flag a companion problem the moment it happens, when their pet is stuck on a ledge or their mount has teleported into a wall. The SDK attaches the companion context you capture: its lifecycle stage and behavior mode, its position relative to the player, its pathing target and navmesh status, and the recent summon, dismount, and teleport events. The report arrives in your dashboard with the companion's state already recorded, so you can see whether pathing failed, a teleport misfired, or a lifecycle event left the entity orphaned, instead of guessing from a player describing a confused pet.

Companion bugs often tie to specific places or specific actions, a ledge pets cannot path past, a zone boundary that loses them, a summon that duplicates. Bugnet groups these into one issue with an occurrence count, and with the location, companion type, or event type as a custom field you filter straight to the pattern. Seeing that hundreds of lost-pet reports all share one zone transition points directly at that transition's despawn-and-restore logic, while a cluster of duplicates points at the summon check, turning a scatter of vivid anecdotes into a prioritized, targeted fix list.

Testing companions and their transitions

Build a test bench that exercises the companion lifecycle and pathing in headless scenarios: summon while one already exists, dismiss and resummon, cross every zone boundary, follow the player through narrow geometry and across gaps, and force the teleport safety net to fire. Assert invariants: never more than one instance per owner, the companion never ends up inside geometry after a teleport, ownership stays correct through disconnects, and a dismissed companion fully despawns. Run it deterministically in CI so a regression in the summon check or the navmesh integration trips the build before players meet it.

Turn real reports into fixtures by replaying their captured companion and pathing state and asserting the companion now behaves. Add runtime safeguards too: validate teleport destinations against the navmesh before placing the pet, deduplicate summons against any existing instance, and persist companion state robustly across zone transitions and saves. For mounts, verify the player parenting and, in multiplayer, the position sync each frame. The combination of lifecycle tests, real-report fixtures, and these safeguards keeps companions feeling reliable and alive rather than a steady source of stuck, lost, and duplicated friends.

A misbehaving pet acts on its own state, not your input. Capture its lifecycle, pathing, and teleport events and the lost or teleporting companion becomes reproducible.