Pal Calc forces desired passives into children, which sometimes adds unnecessary complexity

[ayellowlizard]

(very badly drawn red circles but you can probably see the problem here)

A Ryu-F with Vampiric (not a part of the final product) is used, despite a Ryu-F with Demon God also being available.

The Demon God Ryu can be substituted into the Vampiric Ryu, which would save time (since Demon God is one of the desired passives)

[tylercamp]

Interesting, nice catch, I presume Pal Calc would’ve considered both options and (for some reason) considered this to be more optimal than what you expected

I’ll need to properly debug/investigate when I have time

[tylercamp]

(EDIT: Comment about why the above result happens, doesn't address the original comment/suggestion - click to expand)

---

Looking at the raw data in the debugger, I see that:

• The estimate for the suggested, 1-step path takes ~04:10:00
• The top part of the displayed path has an actual estimate of 04:00:00, but it gets an extra 50 minutes because of the "specific gender" requirement

This explains why the selected path is chosen over the expected one, it just has a shorter base estimation.

BUT there's more to it than that - the gender requirement would've had a much larger impact if the simpler approach was used. Gender probabilities for this pal are 50/50, and would double the time estimate of the required-gender step. The simpler, 1-step path would become 08:20:00 instead of 04:10:00

This graph looks weird at first, but it's actually more efficient because the part which gets a specific gender has fewer overall requirements. It minimizes the impact of requiring a specific gender by doing part of the "breeding selection" in an earlier step

So this is behaving as intended and is, counterintuitively, the optimal path

---

The behavior shown here is working as intended but it does expose another potential optimization method. While Pal Calc does apply the required-gender effort calc when building a new child, it doesn't take that into account when deciding which pals to keep + discard.

(This whole process could potentially generate billions/trillions of intermediate pals, the only way to make this manageable is to throw out suboptimal pals before adding anything to the next step. This is why there aren't any other tools that can solve for full passive trees - pruning is needed to make it work, and making a good pruning system is very hard to do right)

I'll try including self-breeding-effort as a discriminator (pals are grouped by discriminator properties and duplicates are removed within these groups), and as part of the actual "optimal pal" pruning process

---

Re: placing in discriminator - my testing suggests this check is either unnecessary or rarely useful. On average this increases breeding pairs by ~10x (in one case going from 50.9m total checked to 1.6b total checked) and in my limited testing I didn't find any cases where the result was any better

If placing in a discriminator isn't useful, then adding it to the sorting process wouldn't be useful either, but I tried it anyway and the only effect was a preference for longer breeding paths (though they'd have the same final time estimate)

Overall this is interesting to note, but apparently not something we need to account for in the breeding solver

[tylercamp]

I'll leave this open in case you have any other questions/comments

[ayellowlizard]

I'm a little confused. Wouldn't this be better as there are two options to choose from? (versus the one offered by the other solution) One can skip a part and the other is what's already pathed out in the tree. Sorry if that's a stupid question haha.

[tylercamp]

(EDIT: I went into the full probability calc involved, which may be useful, but I missed OP's larger point, click this to expand and see those details anyway)

---

The issue is the chance of getting exactly two passives, those being the ones we want, and being the correct gender

All of that in a single step is very unlikely so it gets a high effort estimation and ends up being sub-optimal

Typing from bed atm but can type out the exact probabilities tomorrow

---

One big piece impacting probabilities is that we want exactly 2 passives, and the parents having 2 vs 3 to pick from makes a big difference. If there’s 3 available then we need to roll exactly 2 inherited. (30% chance IIRC). If there’s only 2 available then we could roll for 2, 3, or 4 passives, and those would all work since there’s only 2 to pick from anyway (60% chance)

So the decision to add in an extra passive there becomes much bigger than expected, and then the gender requirement multiplies the overall estimate for that step

---

(I'm also a bit confused by your above picture, not sure what "Breedject" means? Anyway..)

In your comment you suggest that, when producing a Blazamut Ryu with [Impatient, Demon God], the suggested single-step path will be optimal. It's important to note that Pal Calc determines an "optimal" path based on probabilities and time estimates, not on the number of steps. A 5-step path taking 3 hours will be more optimal than a 1-step path taking 5 hours.

(tl;dr in next comment)

Your Suggested Path

To make this Blazamut Ryu using [Demon God] + [Impatient, Heated Body], we require:

• Zero random passives - 40% chance
• Exactly 2 direct passives, - 30% chance
• The 2 direct passives, out of 3 available parent passives, are correct - 33% chance
  • There are 3 possible ways to choose 2 passives - [Demon God, Impatient, [Demon God, Heated Body], [Impatient, Heated Body]
  • We only want one of those three possible results, i.e. 1 in 3 chance

The estimate for this single step becomes 0.4 * 0.3 * 0.33 = ~0.04, or 4% total chance for this result, or 1 in 25 chance with 25 attempts on average. At 10 minutes per attempt, that gives a 04:10:00 estimate for this single step.

Solved Path

For the first part of the solved path with [Vampiric] + [Impatient, Heated Body] -> [Impatient], we require:

• Zero random passives - 40% chance
• Exactly 1 direct passive - 40% chance
• The 1 direct passive, out of 3 available parent passives, is correct - 33% chance

The estimate for this first part is then 0.4 * 0.4 * 0.33 = ~0.053, or 5.3% total chance for this result, or 1 in 19 chance with 19 attempts on average. At 10 minutes per attempt, that gives a 03:10:00 estimate for this part.

The next part, involving [Impatient] + [Demon God] -> [Impatient, Demon God], requires:

• Zero random passives - 40% chance
• At least 2 direct passives - 60% chance
  • With only 2 parent passives to pick from, we can roll 2, 3, or 4 directly-inherited passives and we'd still end up with just the two parent passives
  • We couldn't do this with the suggested path since there was an irrelevant passive that could've been included
• The only available passives are all desired, so there's no additional probability of selecting the "right" passives

The estimate for this second part is then 0.4 * 0.6 = 0.24, or 24% total chance for this result, or 1 in 5 chance with 5 attempts on average. At 10 minutes per attempt, that gives a 00:50:00 estimate for this part.

The 2nd part depends on the first part, so we need to add these together. 03:10:00 + 00:50:00 = 04:00:00 for the solved path.

The probabilities for the suggested path involve ~04:10:00. The solved path takes 04:00:00 instead. Even though the solved path involves more steps, it is more efficient.

(Pal Calc shows an estimate of 04:50:00 for the solved path, rather than the 04:00:00 I calculated here. This is because the next step, using this pal, requires to pals of opposite genders, which further modifies the effort. The probabilities I calculated are just the "base probability" of getting a Blazamut Ryu with any gender with [Impatient, Demon God]

Use in Later Steps

The Blazamut Ryu with [Impatient, Demon God] is then bred with the other to produce the final result. We'll try this with your suggestion and Pal Calc's solved path to see how the final result is affected.

Since both pals in the final step are "wildcard", i.e. they don't have a definite gender, Pal Calc needs to force one of the pals to have "the opposite gender" of the other. Pal Calc will consider setting each parent to the opposite gender of the other, and take the faster pairing, if any. If there isn't a particular "optimal" way to assign genders, Pal Calc will pick one randomly.

This doesn't affect the time estimate for the final step, which just requires that appropriate parents are available, but it affects the total estimate of the overall path. Therefore I'll just explain how both approaches are affected by the gender probability calc.

Required Gender - Your Suggested Path

As calculated above, the suggested path requires ~04:10:00 to produce in general, without imposing a specific gender. The other parent, with [Serenity, Musclehead], has the same estimate of 04:10:00.

Since both of these pals are bred in a single step and have the same time estimate, Pal Calc will assign just one of them with opposite gender. Since the graph shows this top part of the graph having a specific gender, we'll include it on this pal.

Blazamut Ryu has a 50/50 chance of male/female pairing. Therefore, to get a specific gender is a 50% chance, and will require twice as many breeding attempts. The suggested path takes 04:10:00 for a pal with any gender, and this required gender constraint brings it up to 08:20:00.

If the suggested path was used, getting an opposite-gender Blazamut Ryu would take 08:20:00.

Required Gender - Solved Path

The same 50/50 probability for a specific gender is required here. However, this is being applied on the 2nd half of this part which, as calculated before, has a base estimate of 0:50:00. A specific-gender requirement doubles this, bringing it to 01:40:00. Combined with the prior step, requiring 03:10:00, brings us to 04:50:00.

The solved path provided by Pal Calc takes just 04:50:00 instead.

[tylercamp]

(EDIT: tl;dr of the above semi-relevant comment - click to expand)

^ Comprehensive wall of text, highlighting the important bits:

In your comment you suggest that, when producing a Blazamut Ryu with [Impatient, Demon God], the suggested single-step path will be optimal. It's important to note that Pal Calc determines an "optimal" path based on probabilities and time estimates, not on the number of steps. A 5-step path taking 3 hours will be more optimal than a 1-step path taking 5 hours.

The probabilities for the suggested path involve ~04:10:00. The solved path takes 04:00:00 instead. Even though the solved path involves more steps, it takes slightly less time and is therefore more efficient.

Since both pals in the final step are "wildcard", i.e. they don't have a definite gender, Pal Calc needs to force one of the pals to have "the opposite gender" of the other.

If the suggested path was used, getting an opposite-gender Blazamut Ryu would take 08:20:00.

The solved path provided by Pal Calc takes just 04:50:00 instead with the opposite-gender requirement.

And to emphasize again:

Pal Calc determines an "optimal" path based on probabilities and time estimates, not on the number of steps. A 5-step path taking 3 hours will be more optimal than a 1-step path taking 5 hours.

The described result seems inefficient because it involves more steps. But the suggested path of directly breeding [Impatient, Heated Body] + [Demon God] -> [Impatient, Demon God] is, in fact, slower than what Pal Calc suggests because of the underlying probabilities involved.

[tylercamp]

Another way of looking at this is that it's worth the extra time to "breed out" the irrelevant passive to just get a pal which only has the desired passives...

OH - your point is that this could be done by breeding with the Demon God pal, and there'd be a chance of getting a pal which just has both in the interim...

[tylercamp]

I missed that since I'm explaining Pal Calc's approach and am (of course) biased towards how it reasons about things

So this relates to an intentional quirk of Pal Calc - if a parent has a passive we want, it will only consider children which inherit that passive. This means it never considers the case where Demon God is used in that "breeding out the passive" step, even though it could be used instead with a small chance of having a passive we want. If the parents have [Desired A, Desired B], Pal Calc will never consider a case where the child only gets [Desired A] but not [Desired B].

It is potentially more efficient to update with your suggested breeding path, but I'm actually conflicted about this, and am currently thinking "no". There are a few reasons:

1. More complicated graph display - The new "lucky" case of inheriting both passives makes the rendered graph a lot more complex. The Impatient step would need to split into a graph where it happens to get Demon God too
2. Confusing intent - A reader who sees a parent with Demon God might expect that they should pass it down at that step, even though they should take a pal which just has Impatient on its own if available
3. In this case, this confusion would lead to a lot more effort in producing the child pal, since they might try to include the "specific gender" in the same step
4. Reliability - Though it looks weird, by ignoring "lucky" cases Pal Calc is only producing reliable paths

--

(Continuing to reason about this, but am slowly convincing myself that this should be supported...)

[tylercamp]

(Leaving these notes partly for myself)

Right now I'm focusing on how to accurately update time estimates for this change. Been revisiting this with ChatGPT and properly making estimates seems very complicated.

It's not just a matter of adding an optional path of D + IH -> DI, since that path would only be relevant if we got it before the D + IH -> I result. We could only use D + IH -> DI to accurately reduce the estimate if the D + IH step continues even after the intended D + IH -> I result. We're likely to hit the -> I result first, which would make the -> DI result entirely irrelevant.

This also doesn't account for the fact that the ->DI is part of an "opposite gender" constraint.

(Similarly, I've found that the existing "doubled estimate" part of the "opposite gender" constraint may be inaccurate and a proper estimation would require an iterative solution like markov chains. The "opposite gender" constraint is a much simpler process than the topic here, but would still require a lot of calculations to estimate, which doesn't bode well for this)

---

If we did "just" use the D + IH -> DI to reduce the overall -> DI estimate, I'm not sure how that "reduction" would actually apply. I guess it's the probability of the main D + I -> DI result or the probability of the D + IH -> DI result? Using that directly would be 0.04 + 0.24, giving a 1 in 3.6 (40m) estimate chance vs the original 1 in 4.16 (50m) estimate...

I guess that's intuitively + roughly reasonable, since the -> DI result is only slightly less likely than the -> I result? (4% vs 5.3%)

Still debating whether it's appropriate to try to compensate for this in the estimates at all...

[tylercamp]

After a bunch more consideration, I settled on leaving the estimates unchanged, swapping input pals if there are others available, and adding an "optional passive" indicator to any child pals. Properly handling this could improve breeding estimates, but would be massively more complex.

However, I've decided to not make any changes at all for this case. The half-baked approach I settled on wouldn't improve any estimates, and I believe it would make the breeding graphs more confusing to read.

I think it would be better to things as-is since it best conveys the intended steps of the breeding graph, and if the user sees something like this then they can swap out the input pals when they're breeding.

@ayellowlizard I'm going to mark this as wontfix, but I'll leave the issue open for visibility, and will add the documentation tag so that a note about this is added somewhere eventually

[ayellowlizard]

Got it! I have to admit, I didn't understand most of what you just said, but thank you for considering it anyways lol :)

[tylercamp]

Hmm... still thinking about this, it might make sense to include unnecessary but desired passives as optional for the child

The child would be treated as having "random" passives, i.e. those "optional but desired" passives wouldn't be targeted for passing down to children, but this might allow for faster paths where one parent's optional passives have overlap with the other parents' passives. This would improve the estimate for the parent with optional passives without hurting the estimate for breeding results from that parent

(Just a note-to-self)