Turn a target Pal into an ordered breeding tree that shows parents, intermediate Pals, retained traits, and required checkpoints.
Read a combined tree instead of isolated recipes
A multistep target is rarely just a straight chain. One branch may move the desired species forward while another consolidates passive carriers, and both branches can feed a later pairing. The Tree view keeps those dependencies connected, numbers every breeding stage, and shows which child becomes a parent later so you can see why each intermediate exists.
Rounds view presents the same route as scheduled waves. Independent stages can appear in the same round, while a stage that consumes an earlier offspring waits for that dependency. This is scheduling guidance, not a claim that eggs hatch at identical speeds or that every branch will succeed on its first attempt.
- Confirm the route inputs
Check the named roster copies, renewable species, target, and selected passive carriers before treating the tree as an in-game checklist.
- Follow stage dependencies
Breed stages whose parents are available, record the required child and retained traits, then unlock downstream stages that consume that offspring.
- Save the successful hatch
Record a useful intermediate in the active plan so later recalculation starts from actual progress rather than repeating completed ancestry.
Choose the route view that answers your question
Quickest path is the cleanest way to ask how the roster can reach a species in the fewest sequential generations found by the bounded search. Start to target is appropriate when one owned Pal must be represented in the ancestry. A passive-aware Full custom plan can produce a wider combined tree because it has to unite exact carriers as well as reach the target species. Changing modes changes the constraint, not merely the drawing style.
The route header separates breeding operations from scheduled rounds and lists missing bridge species and sex checkpoints. A bridge is a species connection, not a secret source of desired passives. A sex checkpoint means a later pairing depends on a compatible parent sex; the tool identifies the requirement but cannot predict which sex will hatch.
Worked example: replace an unavailable branch
Imagine a five-stage tree uses one selected trait carrier on the left branch and renewable species on the right. When you discover that carrier is unavailable, choose “I do not have this” on that route input. The planner excludes it for the current plan, searches the legal graph again, and either displays another route or reports the exact blocked result.
- Try another route cycles through verified alternatives when the bounded search returns more than one path.
- Restoring removed inputs returns the route-specific exclusions without changing the saved roster itself.
- A truncation notice means the shown route is legal but the search did not compare every possible alternative before pruning.
Path planning cannot remove breeding randomness
A tree is deterministic about recipe structure, but actual breeding remains probabilistic. The route can say which passive should be retained at a checkpoint and warn about possible or guaranteed baggage on a carrier. It cannot guarantee that the desired set appears, calculate an exact egg count, or remove unwanted random passives from the game’s inheritance system.
The scheduler also does not model incubator capacity, cake production, world settings, travel, capture time, or manual sorting. Use Rounds to understand dependencies and potential concurrency, then adapt the workload to your base. If a game update changes breeding outcomes after the pinned data pack, verify the combination in your current version.