This post will explore the timeline and cause of the recent NP bug of Romulus=Quirinus and Summer Kiara in the NA version. First, we will follow how this type of stacking Super Effective NP evolved in the Japanese version of the game. With this necessary context, we can then look into how the bug came to be in NA.

TL;DR: A mismatch between the game data and the game code led to Romulus and Summer Kiara checking for traits on themselves instead of on enemies for their Noble Phantasms' Super Effective damage conditions. The NA version updated the game code but didn't update the game data accordingly.

JP server

Romulus=Quirinus was first released in JP on 16th April 2020 with a new stacking Super Effective NP that checked for how many traits existed on enemies. As seen in the following video, Romulus was working as intended after his release in JP:

There were many parameters in his NP but the parameter of concern here is Target. On release, the Target parameter of Romulus's NP was set to 0. As far as we know, the Target parameter was unused in the game code1 at this point in time and 0 was just a dummy placeholder value2. Before version 2.26.0 (JP), when the game calculated the damage for stacking SE NP, it would always check for the existence of the trait(s) on enemies.

After Romulus, 2 other stacking SE NPs were released. The first one was Miyamoto Musashi's upgraded NP (9th August 2020) and the second one was Summer Kiara's NP (17th August 2020). Both of them also check for the existence of the trait(s) on enemies like Romulus's NP so no change was needed in the game code. Both of them used 0 as the dummy value for the Target parameter.

On 20th January 2021, Taira no Kagekiyo (Avenger) was released and she also used the stacking Super Effective NP. However, instead of checking for existence of the Vengeance trait on enemies, Taira's NP looks for the existence of the trait/buff on herself. Thus, a new app version, 2.26.0 (JP), was also released to deal with this new condition.

To delineate whether the stacking SE NP checks on self or enemies for the existence of the trait(s), DW made use of the hitherto unused Target parameter. It was decided that Target=0 would mean checking on self and Target=1 would mean checking on enemies.

As noted above, Romulus, Musashi and Summer Kiara all check for traits' existence on enemies. However, they all had Target=0 as originally released. Therefore, together with the 2.26.0 update, all of their Target values were changed to 1 in accordance with the change in the game code.

NA Server

Back at NA server, Romulus=Quirinus was released in the same manner as they did in JP, on 30th March 2022. The Target value was set to 0 and his NP was working as intended as seen in the video below:

Thus, we could confirm that Romulus=Quirinus was released together with the original stacking SE NP game code that only checked for the existence of the trait on enemies. Romulus=Quirinus was released with the game code that didn't use the Target parameter (pre-Taira game code).

Between Romulus=Quirinus's release and July 13th, it was noticed that Romulus's NP was dealing lesser than expected damage. There were a couple isolated posts that noticed this change, but no action was ever taken since the wider community was oblivious to this change. Further notice was raised when Summer Kiara also suffered from the same bug.

Given that Romulus=Quirinus's NP was working correctly on release, something must have changed to cause it to break. Since Atlas Academy tracks every game data change, we know that Romulus's NP had maintained Target=0 from release to the bugfix on July 13th. Since the game data didn't change but the damage was different, the only possible culprit would be the game code.

Following the various Romulus=Quirinus gameplay videos, we could narrow down the window when the game code was changed, leading to lower than expected NP damage:

We can see that Romulus's NP stopped working as expected between the Fate/Requiem event and the Summer 4 rerun event. Between those two events, Aniplex released version 2.31.0 (NA) on May 23rd. Version 2.31.0 introduced new exciting features such as Servant coins, Grailing to lv120, Append skills.

In the JP server, servant coins, grailing to lv120 and append skills were introduced after Taira's release. Therefore, it is safe to assume that together with the new headline features, version 2.31.0 of the NA region also merged the new stacking SE NP code that was introduced with Taira no Kagekiyo.

As noted above in the JP version, when the Taira no Kagekiyo update hit, Romulus's NP's Target=0 was required to be changed to Target=1. Lasengle overlooked this change in NA however, and Romulus=Quirinus's NP still had Target=0 despite NA now using post-Taira game code which took the Target parameter into account.

As a result, Romulus=Quirinus was checking for Roman buffs on himself instead of enemies after the append skill update on NA.

Summer Kiara was released with pre-Taira data Target=0 as well, so she also suffered from the same bug as Romulus. Interestingly, Musashi's NP upgrade was released with Target=1 so her new NP worked as intended right from the start in NA.

On July 13th, Lasengle deployed a hotfix, updating the game data and changing Romulus and Summer Kiara's NPs' Target to 1. As of today, Romulus=Quirinus and Summer Kiara behave exactly like JP server.

I sincerely thank the people over at the Discord who have crunched the numbers to understand this issue, everyone who have reported and amplified it, and the video creators so I could create this thread with publicly accessible evidence.

Thank you for reading,

1: Note that while the stacking SE NP didn't use Target at the time, other NP types did make use of the parameter.

2: Why would DW add an unused Target parameter? For other Super Effective NPs, Target is used to determine the trait that would trigger the SE damage. When DW was coding for this NP SE stack function, we guess that they already had Musashi's upgraded NP in mind. Since Musashi's upgraded NP targets 2 traits: [109 - Alter Ego] and [115 - Moon Cancer], TargetList was used and Target became unused.

Couldn't DW have removed Target instead of having it with a dummy value? Due to how the parameters are parsed, there would be less code change with a dummy value than not having a Target value.