Below is a collection of small posts about FGO mechanics. Most are originally discussed in the Atlas Academy discord server. Some more techy information such as the damage formula can be found in the deeper folder.
An integer in the range [900, 1100):
randomModifier
is possible)randomModifier
is not possible)Because Arash and Chen Gong NP OC effect is an extra deal damage function, they use a different randomModifier
, independent from the main damage function's randomModifier
.
1000%.
Damage formula term | Buff Action | Default Value | Lower Bound | Upper Bound |
---|---|---|---|---|
atkMod | atk | 100% | 0 | 500% |
defMod | defence | 100% | 0 | N/A |
cardMod | commandAtk | 100% | 0 | 500% |
cardMod | commandDef | 100% | N/A | 500% |
powerMod | damage | 0% | N/A | 1000% |
critDamageMod | criticalDamage | 0% | N/A | 500% |
npDamageMod | npdamage | 0% | N/A | 500% |
specialDefMod | specialdefence | 0% | -100% | 500% |
NP gain formula term | Buff Action | Default Value | Lower Bound | Upper Bound |
---|---|---|---|---|
cardMod | commandNpAtk | 100% | 0 | 500% |
cardMod | commandNpDef | 100% | N/A | 500% |
npChargeRateMod | dropNp | 100% | 0 | 500% |
Crit stars formula term | Buff Action | Default Value | Lower Bound | Upper Bound |
---|---|---|---|---|
cardMod | commandStarAtk | 100% | 0 | 500% |
cardMod | commandStarDef | 100% | N/A | 500% |
starDropMod | criticalPoint | 100% | 0 | 500% |
enemyStarDropMod | criticalPoint | 100% | 0 | 500% |
Here's how the buff values are collected and summed up in the game code:
Each term in the damage formula corresponds to one or many buff actions. Buff actions are like buff categories containing positive and negative buff types.
atkMod
refers to the atk
buff action which contains upAtk
plusTypes and downAtk
minusTypes. Charisma buff has buff type upAtk
.Buff actions values are calculated using the following formula:
num = buffAction.baseParam + (total plusTypes buffs values) - (total minusTypes buff values)
if buffAction.limit in (normal, lower):
if num < 0:
num = 0
num = num - buffAction.baseValue;
if buffAction.limit in (normal, upper):
if maxRate < num:
num = maxRate
return num
baseParam
baseValue
limit
maxRate
is a property of the buff item. This value can be found in the DB or API. If there are multiple buffs, the max maxRate
is used. Different buffs of the same buff action usually have the same maxRate
value.cardMod
with 10 level 10 Merlin's Hero Creation applied and no buster damage down:
cardMod
-> buff action commandAtk
-> plusTypes
buff type upCommandall
baseParam
: 1000baseValue
: 0limit
: normalmaxRate
: 5000num
= 1000 + 500 * 10 = 6000 (baseParam
= 1000 and there are 10 Hero Creation, each has Value
of 500)limit
is normal but num
> 0 so lower bound is not appliednum
= num
- baseValue
= 6000 - 0 = 6000limit
is normal and num
> maxRate
so upper bound is applied -> num
= 5000cardMod
value is 5000 or 500%.Notes:
powerMod
is 1000%. As seen in the formula mapping, powerMod
consists of 4 buff actions and each of them has their own limits. However, most of the common powerMod
buffs fall into buff action damage
which has an upper limit of 1000%.Buffs which have the same non-zero buff group are unstackable. For example:
The enemyServerMod
s in the attacking and defending formulas refer to two different variables in the enemy data: tdRate
for attacking NP gain and tdAttackRate
for defending NP gain. They are usually the same but there's no code requirement for them to be identical.
The status effect proc check is still as described in Kyte's post. MISS and GUARD are only for display. Here's how they are determined:
As a result of this, a failed 100% chance status effect can only display GUARD.
For example, with Shuten's first skill (60% chance Charm, 100% chance DEF down) against shadow Medusa in the X-E FQ with 17.5% resistance:
The critical miss sign appears if the enemy has a crit chance down debuff and would have crit without the debuff assuming the rng roll is the same.
Reddit post about gold orbs, rainbow orbs and silver to gold conversions.
The following formula applies to all hits' damage except for the last one:
Hit damage = Card damage × Hit Percentage / Sum of hits percentage (Note that /
is integer division)
The last hit's damage is calculated by subtracting the previous hits' damage from the card damage.
Therefore, the last hit's damage can be different from a prior hit's even with the same hit percentage. For example, Musashi's Buser card has [33, 67]
damage distribution. With her first skill active, the damage distribution array becomes [33, 33, 67, 67]
. With card damage of 15,228, the hits damage are [2512, 2512, 5101, 5103]
:
>>> 15228 * 33 // 200 # Hit 1; "//" is integer division
2512
>>> 15228 * 33 // 200 # Hit 2; 33+33+67+67=200
2512
>>> 15228 * 67 // 200 # Hit 3
5101
>>> 15228 - 2512 - 2512 - 5101 # Hit 4
5103
What is the Overkill bug?
In various circumstances, face cards (not NPs) can get 1.5x NP gain similar to the overkilling effect, despite the card not killing the enemy.
To determine which hit should have the overkill effect, the game keeps track of provisional damage between hits and compares it with the target's HP value. The target's HP is updated between cards while the provisional damage counter is not reset between cards. This leads to double counting of damage dealt and "overkilling" when the target is still alive.
Here are some examples of how the game determines when the overkill effect applies and the overkill bug in action.
Explanations of the tables' columns:
reducedhp
is the provisional damage counter:
reducedhp
is updated every hitreducedhp
starts at 0start reducedhp
+ damage
= end reducedhp
start reducedhp
= usually previous hit's end reducedhp
(see the Lancelot NP case for a different case)hp
is the target's HP value used for comparision with reducedhp
:
hp
is updated between cardsOK
is whether the hit has overkill effect:
end reducedhp
< hp
-> Normalend reducedhp
>= hp
-> OKScathach BQAE:
Scathach's quick card and first hit of the arts card experience overkill effect before she kills the target. Because the hp
value is updated after the first card (14409 to 7300) while reducedhp
is carried over from the first card, the overkill bug happens.
reducedhp
is properly reset for Lancelot's NP card so the bug doesn't happen here. NP gain value is also shown in the table.
A video of the bug in action: https://www.bilibili.com/video/av34113229 @ 1:42. MHXA Arts card 2nd hit has the overkill bug.
reducedhp
is also reset when a deadFunction
( Trigger skill on Death) or a gutsFunction
( Trigger skill on Guts) activates. For example, as seen in this video of the behaviour in Valentine's 2023 (NA) CQ, the observed charge gain on Romulus-Quirinus's Arts card is 54.15% with the card dealing 0 overkill hits on Artemis; however the expected charge gain should be 72.19% with the card dealing 2 overkill hits on Artemis:
Enemy HP | reducedhp before arts card |
Damage dealt | reducedhp after arts card |
Overkill (reducedhp > enemy HP) |
|
---|---|---|---|---|---|
Expected | 84543 |
68435 |
67922 |
136357 |
true |
Observed | 84543 |
0 (reset) |
67922 |
67922 |
false |
i.e. The reducedhp
should have been 68435
before the first hit of the arts card; this would have made the reducedhp
after the arts card (136357
) greater than the enemy HP (84543
). This is what the first row in the above table shows. However, as we see in the second row, the reducedhp
was reset by the time the arts card hit; meaning that the actual reducedhp
after the arts card was merely 67922
(which is not greater than the enemy HP). Thus, no OK hits are observed on this card.
Note
deadFunction
andgutsFunction
also reset thereducedHp
for all enemies (i.e., In a wave where an AOE attack that kills one enemy withdeadFunction
/gutsFunction
, thereducedHp
for the other enemy/eneemies is also reset; subsequent face cards that attack a surviving enemy start at 0reducedHp
It is likely that there are functions apart fromdeadFunction
andgutsFunction
which can reset thereducedHp
Regardless ofdeadFunction
andgutsFunction
, guts proc itself (createResurrection
) also resets reducedHp on the associated enemy
With the 2.0 update*, DW fixed this enemy behavior to be mostly consistent. Enemy will stop attacking after killing the taunt servant except for the following case:
If an enemy kills the taunt servant in the first attack action and the taunt servant has guts, the second attack action will not happen but the third attack action will.
You can see this scenario in this gif. Lalter attacked and killed Spartacus with guts. Tesla didn't attack and Siegfried attacked instead.
Note: With the 2.0 update, I'm quite sure the behavior is the same even with enemy NP attack or attack with on-hit effects (e.g. Hokusai 3rd skill).
You can see in the following image the reasons for the enemy behavior.
1-6
tested
: whether all of the variables values are verified in the actual game1st attack
: outright kills the taunt servant, deals more than 50% hp or deals less than 50% hp of damage2nd attack
: kills the taunt servant or doesn't happen3rd attack
: happens or doesn't happenhp
: the hp valueisAlive
, isGuts
, checkDeadTurn
: 3 boolean flags of the taunt servantnarrowDownHate
: returns the list of player servants with taunt. For example, the input of the function is [1, 2, 3]
and the first servant has taunt, the output is [1]
.getTargetBase
: returns the first "eligible" servant of the input listIn all scenarios, even after the taunt servant is killed with or without guts, narrowDownHate
returns the taunt servant, [1]
. In scenarios 1, 2, 4-6, getTargetBase
still considers 1
to be "dead" so it returns no eligible servant, -1
, and there's no attack.
In scenario 3, the flag isAlive
is switched to True
in the 3rd attack as the guts servant hp
value is updated. getTargetBase
found an eligible servant and the 3rd attack happens (For the 2nd attack, isAlive
is still False
).
The table below details the enemy behavior before the 2.0 update. The cells that changed with the 2.0 update are highlighted.
Generally, if the enemy deals more than 50% starting hp of damage and kills in the 2nd attack, there will be a 3rd attack.
Note: This doesn't apply to enemy NP attack or attack with on-hit effects (e.g. Hokusai 3rd skill).
The above conditions sound familiar? Yes, the overkill bug rears its head again. Because of the overkill bug, checkDeadTurn
is set to False
and wreaks havoc on the downstream functions:
reducedhp
is greater than hp
. Therefore, the game thinks the taunt servant is already dead and doesn't record deadTurn
when the enemy kills the taunt servant.deadTurn
from being recorded on the 2nd attack, checkDeadTurn
returns False
on the 3rd attack.narrowDownHate
and getTargetBase
behave differently with and without guts but essentially there will be a 3rd attack.Note: I don't track the game code closely enough to know for sure that this behavior changes with the 2.0 update but the NA game code is definitely different between version 1.35.1 and 2.1.0. There's still this pre-2.0 video that I haven't been able to explain.
Skills with random chance like imperial privilege can have different outcomes if you savescum and use additional skills beforehand. In the same vein, critical hits can also be tampered with, and anything that affects skills will also affect critical proc rng. However, unlike skills, critical hits only enter the scene after the player selects their cards and starts their turn. Nevertheless, the player still has options to change whether cards crit or not.
Let us consider King Hassan, whose deck is described below:
Card | Hits |
---|---|
Arts (A) | 3 |
Buster (B) | 1 |
Quick (Q) | 5 |
Extra (E) | 6 |
Let's assume we have a hand of his 5 cards (A-B-B-B-Q), and each card has a non-zero and non-100% chance to crit.
Example scenario: B-B-Q chain and we are interested in whether the third card crits or not. Different inputs from the player can change whether it crits or not. These inputs will "advance" or "change" the rng. If the card has a 50% change to crit, a dice with 100 faces is rolled and it will crit if the number is above 50. This exact dice will always land with the same number — this is why you can't savescum while not using any skills and get a different result. When you push the rng by "1", you're going to the next dice which will give a completely dice roll. Despite getting a different dice roll, it's still possible to not crit or get the desired outcome, you're just getting another chance at it.
Skills, CS:
The maximum amount of stars that CAN be generated:
A common misconception is that it is the hit count up to the current card that changes whether it crits. For example, doing B-A-Q instead of B-B-Q would be 4 hits as opposed to 2 hits, thus leading to a different crit outcome. This generalization is true in most scenarios, but it is possible to get different crit result with the same hitcount or the same crit result with different hitcount.
Another misconception is that it is the amount of stars that has been generated that plays a determining factor. Once again that is true in most scenarios, but both these generalizations are a byproduct of the following:
What the hitcount actually does is affect how many stars can be generated. The stars that a card produces is the sum of the stars produced by each hit inside. This is why a card with a higher hitcount will typically generate more stars. Every time that a hit calculates the amount of stars, the rng will advance.
The rng will advance by a different amount depending on your stargen bracket. These brackets are [1-100]
[101-200]
[201-300]
crit star mod
on the Atlas DB.Certain command codes can also play a role. The command cards which increases the card stargen may change the rng. Using King Hassan arts card, if the card stargen is at 90%, the stargen would push the rng three times. With a command code that gives 20% stargen, it would change the card's bracket thus push the rng 6 times. However, if the stargen started at 60%, the bracket would remain the same thus would not change the rng.
Other command codes can also play a role. For example, the Da Vinci command code. In the B-B-Q chain, if either of the first cards contain this cc. It will push the rng by 1 and thus the quick card may differ.
This description was focused for one of the cards to crit. However, most random events in battle use the same aforementioned dice. For example, the damage on the cards and the AI of the enemy is also different based on that dice. The only exception is guts calculation. Whether a servant comes back to life using guts is calculated using a separate dice so advancing the main dice counter won't affect whether Necromancy CE procs guts and vice versa.
UPDATE: All MC skills' chances were fixed on 2021-03-12