-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breeding passives on a specific step doesn't take into account future passives #95
Comments
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 |
Looking at the raw data in the debugger, I see that:
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 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 |
I'll leave this open in case you have any other questions/comments |
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 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)(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 (tl;dr in next comment) Your Suggested PathTo make this Blazamut Ryu using
Solved PathFor the first part of the solved path with
The estimate for this first part is then The next part, involving
The estimate for this second part is then
(Pal Calc shows an estimate of Use in Later StepsThe Blazamut Ryu with 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 PathAs calculated above, the suggested path requires ~ 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
Required Gender - Solved PathThe 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
|
^ Comprehensive wall of text, highlighting the important bits:
And to emphasize again:
The described result seems inefficient because it involves more steps. But the suggested path of directly breeding |
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... |
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 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:
-- (Continuing to reason about this, but am slowly convincing myself that this should be supported...) |
(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)
The text was updated successfully, but these errors were encountered: