Choose the tool that matches the decision before entering numbers. A permanent upgrade budget, a move recipe, a type matchup and a single-stat comparison need different inputs. Keeping those tasks separate makes each answer easier to inspect. The hub connects them while preserving the limits of the underlying data, including random upgrades, triggered effects and mechanics that have not been extracted.
Pick a tool by the decision you need to make
Use the build planner when the question concerns a League partner, a proposed move set and the static contributions of held items, Vitamins and Lab levels. It keeps structured selections together and makes a plan easier to share. Use the Lab budget calculator when the question is how much permanent progression costs from owned levels to target levels. Those costs are summed from the extracted upgrade schedule, which is a different calculation from combat output.
For move development, the fusion recipe tool answers which extracted combinations qualify and what prerequisites apply. For an attack-versus-defender question, the type matchup tool applies the validated runtime mapping. These dedicated tools reduce the chance of putting a correct number into the wrong formula. A recipe requirement does not become a damage modifier, and a public type-chart value should not be substituted for the game’s effective multiplier without its mapping step.
Start with source data that answers the right question
The reference tools let you inspect 126 held items, 26 Vitamins and 151 public Pokémon records. The item database connects effects with extracted shop prices and copy limits. The Vitamin estimator exposes the per-stack field, addition or multiplier kind, capacity rules and relevant stat boundaries. The Pokédex directory provides identity, public species stats and labeled raw evolution fields. These datasets describe different layers of the game and should not be merged into a single assumed combat formula.
Before calculating, identify where each input came from. A measured runtime hit value, a public move-power field and a percentage in an item description are not interchangeable baselines. The sandbox accepts your own value precisely because it cannot infer the omitted context. Naming the baseline and keeping a record of its source makes a comparison reproducible, even when the answer is only a relative illustration rather than a prediction of what the next enemy will receive.
How the extracted source groups combine
The runtime stat rules name 6 source groups: vitamins, items, temporary, passive, buffs, allies. Positive multiplier bonuses add within each group before the group factors multiply together. In the sandbox, enter the total positive percentage for each group rather than entering an already multiplied final stat. Flat additions are combined with the baseline before those groups are applied. This order is an extracted rule, not a convention borrowed from another game’s calculator.
A practical implication is that another positive bonus inside a heavily increased group does not produce the same relative change as adding that percentage to an untouched group. The displayed formula makes that difference visible without claiming that every source is equally obtainable. Temporary effects, buffs and allies remain user-entered assumptions here. Their fields let you explore a known scenario; they do not prove that a specific effect exists, is active, or has a particular value for the build you are using.
Penalties and flat additions need separate treatment
The extracted rules multiply reducing modifiers rather than adding them to the positive-bonus pool. If multiple penalties apply, enter their combined product in the penalty field. Do not turn a reduction into a negative positive-bonus input and assume the result preserves the source treatment. The sandbox keeps that factor separate so the formula remains inspectable and the meaning of each control is clear. It is a compact arithmetic tool rather than a general editor for every conditional modifier.
Flat additions also need a consistent baseline. Enter only additions that have not already been included in the baseline value. Otherwise the result counts the same amount twice. For a non-damage stat, keep the same-type and effectiveness fields neutral. For a damage-related illustration, use a baseline appropriate to the particular hit or component being studied. This discipline matters more than displaying many decimal places: an accurately evaluated expression can still answer the wrong question if its inputs overlap.
Same-type bonuses and effectiveness are different terms
The extracted ordinary same-type attack bonus is ×1.25. Adaptability uses ×1.5625 for the relevant player case, while allied attacks use the ordinary handling. The relationship being checked is between the attacking Pokémon and the attack type. It is not a team threshold that activates after collecting a certain number of same-type moves. The public research-frame requirements describe cosmetic avatar frames and do not supply evidence of a combat synergy threshold.
Effectiveness concerns the move type against the defender instead. The runtime maps the public matrix to its own values before combining defender types, then bounds the product between ×0.4 and ×1.8. The sandbox accepts that effective multiplier within the extracted range; it does not remap a raw value for you. Obtain the appropriate result from the type tool and keep it separate from the same-type selector to avoid treating related-sounding mechanics as a single bonus.
A reference hit value is not damage per second
Damage per second requires a time model as well as a damage model. A useful simulation would need the relevant attack cadence, chosen upgrades, projectile behavior, target coverage, triggered effects and other runtime conditions. The public move dataset cannot supply all of that merely by exposing power or accuracy. Even a correct static damage component does not establish how often the component lands or how many enemies it affects in an actual run.
Move-scaling extraction is marked partial. Its available baseline excludes randomly chosen upgrade stats and upgrade rarity. Ultimate data is also partial, with static fields available but cast behavior not simulated. These limitations are reasons to name the output carefully, not reasons to hide the useful arithmetic. The sandbox therefore reports a combined reference value and its expression. It never labels the result as expected DPS, a guaranteed hit, a win rate or a complete simulation score.
Apply boundaries only in the tool that owns the stat
The multiplier sandbox shows the expression before stat-specific caps and rounding. Different stats have different limits, so applying a universal cap to an arbitrary user baseline would be misleading. The Vitamin tool applies the relevant extracted boundary for its selected stat, while the planner applies supported boundaries to its own runtime-stat reference. Use those tools when a cap is central to the question, and use the sandbox when the goal is to inspect how the source groups interact.
This also affects comparisons near a boundary. A larger raw expression can produce the same usable result after a cap, while a small difference can disappear during rounding. Conversely, a capped isolated component does not explain every interaction in the complete build. Record which stage of the calculation you are comparing and whether the number is raw or constrained. A screenshot without that context can make different, internally consistent tools appear to disagree when they are actually answering different questions.
Connect calculations to progression and evidence
A numerically attractive plan still needs an attainable route. The League unlock checklist connects partners to extracted requirements, while the Stardust reference helps relate permanent upgrade goals to documented rewards. These resources keep feasibility visible alongside arithmetic. They do not imply that a reward is already earned or that a partner is unlocked on your account, because this website does not inspect your game save.
For comparative advice, consult the tier methodology and distinguish editorial reasoning from eligible community samples. A popularity percentage is not a damage multiplier, and a community rating is not a controlled performance measurement. The tools support a decision by exposing assumptions and source rules; they do not convert sparse social signals into guaranteed combat results. Use a calculation to test a specific claim, such as whether a proposed source-group change affects a reference stat, rather than treating one output as a complete ranking.
Share the calculation with its assumptions intact
Copy link stores the entered values with the current game build. That lets another player reproduce the expression rather than guessing which bonuses were included. The browser also retains the current state locally when storage is available. Unsupported formats, non-finite numbers, out-of-range fields and mismatched build identifiers are rejected instead of being silently coerced into plausible-looking results. Reset restores a neutral baseline, and clipboard failure exposes a selectable link for manual copying.
When comparing results after a patch, preserve the older link as evidence of the previous assumptions and start a new current-build calculation. The source methodology documents the snapshot and extraction boundaries. If an observed result differs from the sandbox, first check input overlap, missing conditional effects, stat boundaries and whether the same game build is being compared. Only then does the remaining discrepancy identify a useful extraction or implementation question.
Frequently asked questions
Can I paste public move power here and call the output DPS?
No. The sandbox multiplies the supplied reference value but does not determine attack timing, hit behavior or upgrade rolls. Public move power is not a complete runtime damage baseline.
Why is a temporary or ally bonus manually entered?
The fields expose the extracted group structure for a scenario you specify. They do not infer dynamic effects from a partner or loadout. Keep a neutral value unless you have evidence for the particular bonus being modeled.