Palworld breeding guides copy each other. A number gets published once, gets repeated, and after a while everyone quotes it and nobody can say where it came from. This page explains how we try not to do that, and lists the figures we deleted from this site once we went looking for their source and could not find one.
Where our data comes from
Palworld's dedicated server is a free, anonymous download, and it ships the gameplay data tables because the server is the authority on game logic. We extract those tables ourselves and generate every page from them. Nothing on this site is transcribed from another Palworld site by hand — which is what makes the errors below fixable at all, because each figure traces back to a named property in a named asset.
Concretely, the breeding pages are generated from DT_PalMonsterParameter (289 species with their CombiRank and flags), DT_PalCombiUnique (the override table), BP_PalGameSetting (the Combi_* tuning values) and DA_BreedingItemEffectData (what each cake does).
The three things we say about any fact
| Label | What it means |
|---|---|
| Extracted | Read directly out of a game asset. We name the property so you can check it. Example: the four counts in Combi_PassiveInheritNum. |
| Derived | Computed by us from extracted values, using a rule we state. Example: every parent pair that produces a given species. |
| Not in the data | Commonly published, but we could not find a source in any asset we extracted. We say so and do not print the number. |
What the breeding engine's accuracy figure actually covers
We cross-check our breeding resolver against an independently datamined outcome table on every build. The current result is 41,617 of 41,617 rows reproduced, or 100.000%. If it ever drops below 100%, the build fails.
That figure is worth stating precisely rather than rounding up into a slogan. The table holds 44,851 rows in total. We compare 41,617 of them and skip 3,234 — every one of them a row involving a species we deliberately do not ship because the game marks it unreleased. So the honest claim is "we match the best available reference wherever it and we describe the same pairing" — not "we have verified the game itself".
The 2 gender-dependent rows used to be skipped, and are not any more. Our resolver returns every outcome a pair has, each with the gender assignment it belongs to, so a gendered row is matched on parents, genders and child together rather than dropped from the score. A row a resolver cannot express is a row its accuracy figure should not have been quoting around.
We also treat agreement as a floor rather than proof. A shared assumption between two datamining efforts would agree with itself, which is exactly how the bug below survived a 100% score for as long as it did.
Three figures we removed from this site
These were all here, and all of them are still on most other Palworld sites.
1. "Potentials inherit 30% from each parent, 40% random"
Removed. The game stores Combi_TalentInheritNum = 1, 2, 3 — a roll over how many Potentials transfer. The 30/30/40 model instead describes a per-stat lottery over three possible sources. Those are different shapes of mechanic, not competing estimates of one, so we deleted the model rather than re-tuning its constants. We also deleted the 2.7% figure (0.3 × 0.3 × 0.3) that one of our guides derived from it.
2. "Passives inherit at 40 / 30 / 20 / 10%"
Removed. The counts are real — Combi_PassiveInheritNum = 1, 2, 3, 4 — but that array is stored as a bare list with no weights beside it, and no other asset we extracted carries a passive-inheritance distribution. Our calculator now treats the four counts as equally likely, says so on screen, and shows a range so you can see how much the unknown weighting could matter.
3. "Mutation is 1%, or 3% with an Extravagant Vegetable Cake"
Half removed. The cake's contribution is extractable: MutationRateBonusPercent = 2, so it adds 2 percentage points. The base rate is not. Combi_MutationRate and five Combi_Mutation* coefficients exist as property names in the shipped server binary, but none carries a serialized value in the Blueprint defaults. A bonus on an unknown base is not a rate, so we publish the bonus and decline to complete the sum.
A bug this approach caught
The rank formula picks the species whose CombiRank sits closest to the parents' average. Which species are eligible is the whole game: unique-combo children are excluded, and so are species flagged IgnoreCombi. We were applying the first exclusion and not the second, giving a candidate pool of 186 instead of 184.
It survived a 100% validation score because the two species it leaked are ones the reference table barely covers. What settled it was not the score but the reference table's own shape: every IgnoreCombi species in it appears as a parent in hundreds of rows and as a rank-formula child in none. Today the pool is 184 of 289 — 103 unique-combo children and 2 more excluded by that flag.
Things we still do not know
- How the inherited counts are weighted, for either passives or Potentials. Both arrays ship without weights.
- The base mutation rate. Property names exist; values do not.
- Whether a passive a parent already carries can be inherited when that passive is flagged to the mutation pool rather than the ordinary pool. The pool flags govern which passives get rolled onto a new Pal, which is a different mechanism from parent-to-child inheritance. We say this explicitly instead of guessing, because it changes whether Babysitter is worth chasing.
- Per-species egg hatch durations. The game stores a hatch divisor per rarity band and a global multiplier, not a per-species time, so any site listing exact minutes per Pal is computing from assumptions it does not state.
If we are wrong
Then it is a bug and we want to know. Every figure here names the asset and property it came from specifically so it can be checked against the game rather than against us.