Skip to content

atlasacademy/fgo-docs

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

45 Commits

deeper

deeper

 
 

images

images

 
 

.gitignore

.gitignore

 
 

README.md

README.md

 
 

_config.yml

_config.yml

 
 

Repository files navigation

Miscellaneous information on FGO gameplay

Discord server invite

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.

Range of randomModifier in the damage formula

An integer in the range [900, 1100):

  • 900: inclusive lower bound (0.9 randomModifier is possible)
  • 1100: exclusive upper bound (1.1 randomModifier is not possible)

C# method reference.

Arash and Chen Gong NP OC effect randomModifier

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.

Maximum value of total powerMod

1000%.

Lower and upper bounds of buffs

  • Some common factors in the damage formula
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
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
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.

    • The mapping of damage formula terms to buff actions can be found here.
    • The mapping of buff actions to positive and negative buff types can be found here.
    • For example: 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
  • Explanation of the variables:
    • Buff action variables can be found here:
      • 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.
    • For example: we are trying to calculate cardMod with 10 level 10 Merlin's Hero Creation applied and no buster damage down:
      • cardMod -> buff action commandAtk -> plusTypes buff type upCommandall
        • baseParam: 1000
        • baseValue: 0
        • limit: normal
        • maxRate: 5000
      • num = 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 applied
      • num = num - baseValue = 6000 - 0 = 6000
      • limit is normal and num > maxRate so upper bound is applied -> num = 5000
      • The final cardMod value is 5000 or 500%.

Notes:

  • It's not quite correct to say the max value of 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%.
  • The interaction can get pretty messy so when in doubt, follow the formula step by step. I purposefully used "Default Value" in the table above instead of "baseParam" or "baseValue".
  • There are also some floors in the damage formula that might affect the effective buff value.

Unstackable buffs

Buffs which have the same non-zero buff group are unstackable. For example:

enemyServerMod in the NP gain formula

The NP gain formula.

The 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.

How MISS and GUARD are determined

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:

  • num3 = status effect chance
  • random roll = random integer in range [0, 1000)
  • num2 = target's resistance + random roll
  • if num2 > num3: buff fails
    • if num2 > 1000 (100%): it displays GUARD, otherwise MISS

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:

  • Charm effect:
    • Example 1:
      • num3 = 600
      • random roll = 876
      • num2 = 876 + 175 = 1051
      • 1051 > 600 -> buff fails
        • 1051 > 1000 -> displays GUARD
    • Example 2:
      • num3 = 600
      • random roll = 598
      • num2 = 598 + 175 = 773
      • 773 > 600 -> buff fails
        • 773 < 1000 -> displays MISS
  • DEF down effect:
    • Example 1:
      • num3 = 1000
      • random roll = 928
      • num2 = 928 + 175 = 1103
      • 1103 > 1000 -> buff fails
        • 1103 > 1000 -> displays GUARD
    • Example 2:
      • num3 = 1000
      • random roll = 761
      • num2 = 761 + 175 = 936
      • 936 < 1000 -> buff procs

How enemy's Critical Miss is determined

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.

How the special summoning effects work

Reddit post about gold orbs, rainbow orbs and silver to gold conversions.

How hit damage is distributed

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

How the Overkill bug happens

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 hit
      • reducedhp starts at 0
      • start 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 cards
    • OK is whether the hit has overkill effect:
      • end reducedhp < hp -> Normal
      • end reducedhp >= hp -> OK

  • Scathach 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.

  • Lancelot NP:

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.

  • MHXA BAQE:

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 Trigger skill on Death) or a gutsFunction (Trigger skill on Guts 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 and gutsFunction also reset the reducedHp for all enemies (i.e., In a wave where an AOE attack that kills one enemy with deadFunction/gutsFunction, the reducedHp for the other enemy/eneemies is also reset; subsequent face cards that attack a surviving enemy start at 0 reducedHp It is likely that there are functions apart from deadFunction and gutsFunction which can reset the reducedHp Regardless of deadFunction and gutsFunction, guts proc itself (createResurrection) also resets reducedHp on the associated enemy

Enemy behavior after killing taunt servant

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.

  • Table columns:
    • Scenario number: 1-6
    • 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
    • Internal game variables and functions during the 3rd attack:
      • hp: the hp value
      • isAlive, isGuts, 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 [1].
      • 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, [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).

Pre 2.0 update behavior

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:

  • Because the first attack deals more than 50% starting hp of damage, on the 2nd attack, 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.
  • As the overkill bug prevents 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.

What affects whether a card procs critical hit

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:

    • Each skill will advance the rng by a different amount depending on the number of effects it has and how many units it affects. For example, a basic charisma is going to advance rng following the amount of units on the field. However, skadi battery or a command seal only advances the rng by 1. The amount of rng change may come in relevant given the chosen command cards.

  • 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] and [201-300]. Your position in these bracket is based on things like your stargen and card multiplier(like quick buff). If you are in the first bracket, each hit will generate up to one star, thus advance the rng by 1. If you are in the second bracket, each hit will always make 1 star and then have a chance of making a second one. However, this will still advance rng by 2. The same principle holds true for the third bracket.

        • Different things can change your stargen bracket. Alongside stargen and card multiplier, overkill and critical increase stargen by 30% and 20% respectively. All factors affecting stargen can be found in the complete formula. The amount of crits prior to the card does not play a direct role, they only matter if the critical(s) push the card to the next stargen bracket through the aforementioned 20% or by overkill shenanigans. Lastly, the class of the enemy can also slightly alter the stargen based on their server rate. The exact value for each specific enemy can be found under 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.

Lists of Mystic Code skills that have 500% chance in JP but 100% in NA

UPDATE: All MC skills' chances were fixed on 2021-03-12

  • Mystic Code: Chaldea
    • 2: Instant Enhancement
    • 3: Emergency Evade
  • Mystic Code: Chaldea Combat Uniform
    • 1: Buff All Allies
    • 2: Gandr
  • Mystic Code: Atlas Institute Uniform
    • 1: Dust of Osiris
    • 2: Rain of Isis
  • Anniversary Blonde
    • 1: Mana Burst
    • 3: Knight's Oath
  • Royal Brand
    • 1: Reaction Reinforcement
    • 2: Iron Devotion
    • 3: Inescapable
  • Brilliant Summer
    • 1: Rumble Party
    • 2: Deadly Trident
  • Memories of the Lunar Sea
    • 1: Spiritron Boost
    • 2: Stepping Stone to Ultimate Victory
  • Memories of the Far Side of the Moon
    • 1: Spiritron Boost (All)
    • 2: Stepping Stone To Survival

About

Miscellaneous information about FGO gameplay

Resources

Readme
Activity
Custom properties

Stars

16 stars

Watchers

8 watching

Forks

4 forks
Report repository

Releases

No releases published

Packages

No packages published

Contributors 5