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):
randomModifieris 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
|Damage formula term||Buff Action||Default Value||Lower Bound||Upper Bound|
|NP gain formula term||Buff Action||Default Value||Lower Bound||Upper Bound|
|Crit stars formula term||Buff Action||Default Value||Lower Bound||Upper Bound|
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.
atkModrefers to the
atkbuff action which contains
downAtkminusTypes. Charisma buff has buff type
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
maxRateis a property of the buff item. This value can be found in the DB or API. If there are multiple buffs, the max
maxRateis used. Different buffs of the same buff action usually have the same
cardModwith 10 level 10 Merlin's Hero Creation applied and no buster damage down:
cardMod-> buff action
num= 1000 + 500 * 10 = 6000 (
baseParam= 1000 and there are 10 Hero Creation, each has
limitis normal but
num> 0 so lower bound is not applied
baseValue= 6000 - 0 = 6000
limitis normal and
maxRateso upper bound is applied ->
cardModvalue is 5000 or 500%.
powerModis 1000%. As seen in the formula mapping,
powerModconsists of 4 buff actions and each of them has their own limits. However, most of the common
powerModbuffs fall into buff action
damagewhich has an upper limit of 1000%.
Buffs which have the same non-zero buff group are unstackable. For example:
enemyServerMods 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:
reducedhpis the provisional damage counter:
reducedhpis updated every hit
reducedhpstarts at 0
start reducedhp= usually previous hit's
end reducedhp(see the Lancelot NP case for a different case)
hpis the target's HP value used for comparision with
hpis updated between cards
OKis whether the hit has overkill effect:
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.
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.
tested: whether all of the variables values are verified in the actual game
1st attack: outright kills the taunt servant, deals more than 50% hp or deals less than 50% hp of damage
2nd attack: kills the taunt servant or doesn't happen
3rd attack: happens or doesn't happen
hp: the hp value
checkDeadTurn: 3 boolean flags of the taunt servant
narrowDownHate: 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
getTargetBase: returns the first "eligible" servant of the input list
In all scenarios, even after the taunt servant is killed with or without guts,
narrowDownHate returns the taunt servant,
. 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
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:
reducedhpis greater than
hp. Therefore, the game thinks the taunt servant is already dead and doesn't record
deadTurnwhen the enemy kills the taunt servant.
deadTurnfrom being recorded on the 2nd attack,
Falseon the 3rd attack.
getTargetBasebehave 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:
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.
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
crit star modon 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