(Very rough and poor) Japanese translation via deepL:

deepLからの拙い和訳：

1. プライマリースキルデータテーブルの最初の4バイトの意味は、Effectsプロセスバイト（バイト0x0cである）によって異なる。

バイト0x00は、物理的なステータスを使用する多くのEPの場合、0から255までの精度ボーナスです。他のケースでは次のようになります。
* ターゲットの種族/性別バイトの値に基づいてターゲットを除外する。
* ターゲットの種族/性別のバイトの値に基づいてターゲットを含む。
* デバフや複数のデバフを与える際の基本的なインフリクト率とする。
* スタッツにバフをかける際の100％の基本ダメージ率を指定します。
* 0～255の固定ダメージです。
* 隠れた10番目のアイテムスロットに装備するアイテムです。
* ヒットレートは75%です。
* 設定されたり解除されたりする戦場の効果の一部です。
* 何もない状態、つまり無駄な状態。

0x01バイトは、多くの場合、あるEPのパワー定数またはベースパワーである。これは、それ自体がスキルのパワーを決定する値であり、EPに応じてスキルを強化するいくつかのステータスのパワーもある程度決定されます。ほとんどの場合、これは基本的なダメージで、テストしたかどうかは覚えていませんが、ヒーリングには全く影響しないと思います。

他のケースでは次のようになります。
* デバフ付与の成長率、これは
* ステートブーストによって付与されるバフの基本量。
* 固定ダメージの全体または一部の量
* EPで回復するWPやJPの量。
* セットされたり、セットされなかったりする戦場の効果の一部。
* 全く何もない、要するに無駄。

バイト0x02は、多くの場合、与えられたEPのパワー成長値またはパワーマルチプライヤーである。これは、EPが与えるダメージやヒーリングに直接影響するほか、特定のステータスが結果にどれだけ影響するかを決定します。値が高いほど、ステータスが高ければダメージやヒーリングの上限が高くなることを意味します。

他のケースでは次のようになります。
* ビットフィールドとして与えられるデバフを決定する2バイトの値の上位バイト。
* バイト 0x01 と合わせて、ユーザーの意志に基づいてブーストされるステータスの追加量。
* ターゲットの最大HPのうち、回復される割合 - この量は、キャスターの最大HPに乗じて4で割ったものである。
* 固定ダメージの一部
* 回復するLPの量。
* セットされたり、セットされなかったりする戦場の効果の一部。
* 全く何もない、要するに無駄なもの。

バイト0x03は、通常、ターゲットに与えられるステータス効果である。これは次のいずれかになる。
* 2バイトの値の下半分がビットフィールドとして与えられます（私はこれを「ビットワイズ・ステータス・エフェクト」と呼んでいます）。
* または、有用または有害な数多くの雑多な効果のいずれかとして、私はこれらを「拡張ステータス効果」と呼んでいます。

拡張ステータス・エフェクトは、ビットワイズ・ステータス・エフェクトと同じ効果を重複して持ちますが、ビットワイズ・ステータス・エフェクトは積み重ねることができず、後者は積み重ねることができます。また、Extendedリストにのみ存在するステータスエフェクトもあります。Extendedリストも1バイトで、0から0x39までの値が含まれているようです。これらの中には、他のExtendedステータス・エフェクトと重複しているものや、様々なEPエフェクトと重複しているものがあります。多くは様々なことを行うようにハードコードされており、ステータスのデバフや特定のスキルをカウンターやインタラプトとして発動するように設定するなど、Extendedステータスエフェクトでしかできないこともあります。

ビットワイズの全ステータス効果をキャンセルするには、拡張ステータス効果リストを使用する以外に方法はなく、もちろんこれらの効果の中にはバグもあります。最も悪いのは拡張ステータス効果0x16で、これは明らかにキャラクターのすべてのステータス効果のバイトを0にします...Stasis Rune、Overdrive、Revolution9、そして他にもV-Maxのクールダウン効果のようにすべてのステータスにデバフをかけるものも含まれます。

なぜスタッツデバフがEPではなくエクステンドのステータス効果で行われるのか理解できません。計算式をプログラムした人の計画性のなさや先見性のなさの結果だと思います。

また、特定のタイプの混乱がどのようにして引き起こされるのかもわからない。テストの結果、ビット単位のステータス効果データブロックには3つの異なるビットがあり、最大5つの自由なステータス効果ビットがあるにもかかわらず、ビット単位のステータス効果の与え方は、スキルスロットやおそらく使用するEPによって異なるようです。

拡張ステータス効果のデータブロックには、ストーン以外にも対象を自動的に殺す方法が少なくとも5種類あります。そのうちの1つが、ザラクティスが「クーデター」と呼んでいたもので、ターゲットの現在のHPが最大HPに比べて低いほど成功率が高くなるインスタントKOです。まったく同じことをするのに、なぜこんなにたくさんの方法があるのかは、オリジナルのプログラマー以外、誰にもわかりません。私がテストしたところ、クレジットのドロップ、アイテムのドロップ、モンスターの吸収、メックプログラムのダウンロードができないものがある以外は、すべてまったく同じであると判断したようです。さらに、プライマリースキルデータテーブルのバイト0x11のビット0x40が、すべてのドロップ、吸収、ダウンロードを防ぐようになっているようで、これはさらに複雑です。

多くの不明瞭なExtendedステータス効果は、特定のEPにハードコードされている他の効果と似ています。例えば、「ライトソード・エクステンド」というステータス効果は、「アルカイザー・チェンジ」というEPやスキルスロット（キャラクターのスプライトを変更し、隠しスロットに「レイソード」を装備する）と類似しており、「ミスティック・チェンジ・エクステンド」というステータス効果も「アルカイザー・チェンジ」というEPやスキルスロットと類似しています。

多くのエフェクトは、特定のEPや特定のスキルスロットにハードコードされています。これらのスキルスロットには、すべて同一またはほぼ同一のダミーデータが使用されています。

重複するエフェクトを削除し、ハードコードされたエフェクトをExtended Status EffectやEPに移動させれば、実行ファイルのサイズやRAMの容量を大幅に削減でき、コードベースの複雑さも大幅に減少するでしょう。これが実現しなかった理由について、私は次のように考えています。
* 事前にあまり計画されていなかった、あるいは進行中にスケッチさえしていなかった。
* 整理整頓がほとんどされていなかった。
* 計画を始める前に誰かがコード化していた。
* 複数の人が同じ作業をしていたが、コミュニケーションがほとんどなかった。
* 誰かがプロジェクトの後半にやってきて、他の人の仕事を終わらせる前に終わらせてしまった。

2. 様々なカウンター、インターラプト、ブロックを扱うデータテーブル、バイト、ビットフラグがいくつか分かれています。それらの中には、明らかに同じことをしているものもありますし、場合によっては、フラグやバイトがすべて設定されているにもかかわらず、同じことをしているすべてのスキルで、いくつかのフラグが設定されていなければならないこともあります。

また、プライマリースキルデータテーブルの中には、他のものと混ざっていることもあります。
* バイト0x09、ブロッキングバイト。バイト0x09、ブロッキング・バイト。シールド・ブロッキング・バイトは正常です。
* Byte 0x0A, the menu visibility byte. なぜかこのバイトの効果の一部はターゲティングバイトと重複しており、アイテム破壊に関連することをしています。

これらのバイトは文字通り非常に多く、私自身もすべてを把握しきれませんし、すべてをテストするには8時間労働で数ヶ月かかるでしょう。

これは典型的なデータの重複であり、スウェイバック、KOスロー、ドラゴンターンのユニークカウンターのような複雑なカウンターの多くがほとんど機能しないか、まったく機能しない理由でもあります。データの重複が修正されてリマスター版にアップデートされるか、誰かがサガフロを分解・逆コンパイルするまでは、これらの効果をどのように実装すればいいのか、誰にもわからないでしょう。

このフラグの中には、複数の「接触」フラグが含まれており、一次技能データの特殊属性バイト0x05に接触フラグが含まれています。

3. 3.ターゲティングバイトとAoE（Area of Effect）バイトは、より複雑な効果を実現するために互いに依存している場合があります。

効果範囲には、形と大きさの2つの部分があります。

AoEの形をバイトの上位ニブルに、AoEの大きさを下位ニブルにするというまともな方法ではなく、特定のビットの集まりにマッピングされた異なる効果の迷路になっています。結果を得るためには、256ビットの組み合わせをすべて手作業でテストしなければなりませんでしたが、その中には確信が持てないものも多く、すべてをテストし終えることはできませんでした。

AoEバイトに隣接していることに少なくとも感謝しているターゲティングバイトは、さらに悪い。これは、ターゲティングとスキル選択に関する様々な効果の集まりです。これらの効果の中には、ターゲティングバイトの下位ニブルにのみ存在するものもあれば、バイトの上位ニブルで変化するものもあります。また、AoEバイトに作用する効果があるかどうかもわからないので、少なくとも5つの基本的なAoE形状を、ターゲティングバイトの256の値すべて、つまり約1100の組み合わせでテストする必要があります。

ターゲティングバイトの1ビットはシールドブロックに関係しているかもしれませんが、よくわかりませんが、誰かがそう言っていました。シールドブロッキングをテストするのは悪夢のようです。

このことを知ったとき、私は数週間の絶望の後、サガフロの改造をやめてしまいました。

ターゲティングバイトにはパターンがなく、レンジ値とビットフラグを組み合わせているようですが、もちろんビットフラグはまともに配置されていません。実際にはビットフラグか、あるいはレンジチェックの組み合わせに違いないのですが、パターンが意味をなさないので、正直なところ私にはわかりません。

サガフロのように、バグだらけで、誰にも理解できないコードを使っているのではないでしょうか。日本のハッカーが理解しているとはとても思えませんし、もし理解していたとしても、発見した内容を共有しないことで有名なので、恐らく絶対に修正できないでしょう。文字通り、このクソゲーをリバースエンジニアリングするよりも、サガフロをクローンする方が簡単だし、それなら自分でゲームを作った方が、少なくともその努力でお金を稼げる可能性がある。

サガフロの計算式の部分を実装した人は、絶対に苦しむべきだし、それどころかネット上で馬鹿にされても仕方がない。

4. アニメーションやモンスターのパーツに関連すると思われる不明な部分が大量にあります。これは、モンスターの形態を、特定のスキルやスキル範囲に合わせてハードコードするという、重複した作業を行っているため、これらのビットやバイトが無駄になっているのだと思います。

5. 約1/3～1/2のEffects Processes（EP、もっと簡単に言うと数式）は存在しないほうがいい。それらは
* 他のEPのエフェクトを、どこかにビットフラグを立てたり、プライマリスキルデータの最初の4バイトを有効活用するなどして、マイナーチェンジして重複させたもの。
* 他のEPの効果を、データをほとんど変更することなく、他のEPに簡単に含めることができるような方法で重複させる。
* 文字通り、何もしません。
* バグがあります。
* キャラクターのステータスビットを設定したり、特定のカウンターや割り込みをトリガーしたりするようにハードコードされていて、パラメータとして1～2バイトで簡単にできるようになっている......そして、それらは通常、最初の4バイトやプライマリスキルデータの未使用バイトの一部または全部を実際には何のためにも使わない。言い換えれば、データで簡単にできることをハードコーディングすることでコーディングスペースを無駄にしており、全体的にスペースと複雑さが少なくなっています。
* 物理的スキルと魔法的スキルが別々になっていますが、これはビットフラグとして設定されるべきであり、それらを強化するスタッツもビットフラグとして設定されるべきです。
* 他の場所ではハードコードされていない方法で行われている、あらゆる種類の効果や計算式がハードコードされています。
* ハードコードされたステータス効果による他のEPとの重複、場合によってはどこかにフラグを立てるだけで済むようなステータス効果のイミュニティのバイパスもあります。
* 性別と種族のバイトの特定の値に基づいて、追加のダメージを与えたり、抵抗を回避したりします-もちろん、ハードコードされています。

5. 文字通り、全く使われていないバイトが1つあり、Final Strikeの場合は1つの転記ミスを除いてゼロで埋め尽くされています。

6. コンボデータの半分だけが実際にプライマリースキルデータテーブルに存在します。それは少なくともビットフィールドとしてフォーマットされています。残りの半分は、私の記憶が正しければ、特定のコンボプロパティを持つすべてのスキルの1エントリあたり2バイトのリストです。

言い換えれば、コンボデータの残りの半分は、「有効」の後にスキル名が続くASCII文字セットの文字列を手動で変換し、検索アルゴリズムを実装する前に、コンボデータをフォーマットする上で最も最適な方法でフォーマットされています。1995年から1998年にかけて、平均的なSquareのコーダーが仕事中にどれだけのアルコールを摂取したのか、あるいはこの地域（おそらく彼らの地下室）で秘密のドラッグラボが稼動していて、その煙を不幸なコーダーの地下オフィスに流していたのか、本当に気になるところだ。

もしかしたら、誰かが若い頃に実験的なことをしていて、仕事の合間にアートチームの尻から酸を落としたり、コカインを吸ったりしていたのかもしれない。

もし私がこのようなことを書いていたら、公式コードやスキルデータに含まれる他のすべての重大な誤りを無視して、このことだけで私は解雇されていただろう。

7. なぜか使用弾薬のバイトに「ドロップ、吸収、ダウンロードを無効にする」フラグが入っていて、スキルごとの使用弾薬が0〜63の範囲に制限されています。また、「全弾使用」と思われる未使用のフラグもあります...当然ながら、このフラグはシュートオールの味方版でも敵版でも使用されていません。

8. セカンダリスキルデータテーブルとリンクスキルデータテーブルには、不明なビットや無駄なバイトがいくつか含まれていますが、正直なところ、これは私が経験した他のことに比べて、コメントに値しないほど軽い違反です。

そのうちのいくつかはアニメーションだと思いますが、残念ながら呪文のアニメーションの効果は、JP使用フラグや各呪文学校のスキルの範囲に結びついていると思われます。

9. スウェイバック、コウ・スロー、ドラゴンターンの条件付き武術カウンターは、独自の小さなテーブルがありますが、もしかしたら、一般的なカウンターの計算式やEPのパラメータとして使用できたかもしれません。また、カウンターのトリガーの計算式やEP自体も、各スキルのプライマリーデータのテーブルエントリーのパラメータになります。そうすれば、より柔軟に対応でき、他の条件付きカウンターにも同様の効果を持たせることができます。

English backup for when the pastebin goes down:

1. The meaning of the first four bytes of the primary skills data table varies depending on the Effects process byte (which is byte 0x0c).

Byte 0x00 is in the case of many EPs that use physical stats an accuracy bonus, from 0 to 255. In other cases it can:
* Exclude a target based on the value of the targets species/gender byte.
* Include a target based on the value of the targets species/gender byte.
* Be the base inflict rate for dealing a debuff or several debuffs.
* Be the base inflict rate out of 100 for buffing stats.
* Be fixed damage from 0 to 255.
* Be the item equipped to the hidden 10th item slot.
* Be a hit rate out of 75.
* Be part of a set of battlefield effects that are set and unset.
* Be absolutely nothing; wasted, in short.

Byte 0x01 is in many cases the power constant or base power for a given EP. This is a value in and of itself that determines the power of a skill, and to some degree the power of some stats that power that skill depending on the EP. In most cases this is the base damage, and while I don't remember if I tested it I'm pretty sure it doesn't affect healing at all.

In other cases it can be:
* The debuff inflict growth rate, which is
* The base amount of buff granted by a stat boost.
* The full or partial amount of fixed damage
* The amount of WP and JP restored by an EP.
* Part of a set of battlefield effects that are set and unset.
* Absolutely nothing; wasted, in short.

Byte 0x02 is in many cases the power growth or power multiplier for a given EP. This directly affects the damage or healing it deals, and it determines how much certain stats affect the results too. Higher values mean that the ceiling of the damage or healing is higher if your stats are higher.

In other cases it can be:
* The upper byte of a 2 byte value that determines the debuffs inflicted in as a bit field.
* The additional amount of stats boosted based on the user's will, in conjunction with byte 0x01.
* The percentage of the target's maximum HP that is healed - this amount is multiplied by the caster's maximum HP and divided by 4.
* Some part of fixed damage
* The amount of LP restored.
* Part of a set of battlefield effects that are set and unset.
* Absolutely nothing; wasted, in short.

Byte 0x03 is usually the status effect inflicted on the target. This can be either:
* The lower half of a 2 byte value that is inflicted as a bitfield - I call these "Bitwise Status Effects".
* Or as any of a number of miscellaneous effects that can be helpful or harmful - I call these "Extended Status Effects".

Extended status effects duplicate all of the same effects as Bitwise status effects, but the former can't be stacked while the latter can. In addition there are status effects found only in the Extended list. The Extended list is also just one byte, and is a range of values apparently from 0 to I assume 0x39. Some of them are duplicate effects of other Extended status effects; others are duplicates of various EP effects. Many are hardcoded to do all sorts of things, and there are things that can only done with Extended status effects such as stat debuffs and setting certain skills to trigger as counters or interrupts.

There is no way to cancel the full range of Bitwise status effects except through the Extended status effects list; and of course some of these effects are bugged. The worst offender is Extended status effect 0x16, which apparently sets all of a character's status effect bytes to zero... including those for Stasis Rune, Overdrive, Revolution9, and I assume other things like the V-Max cooldown effect that debuffs all stats.

I don't understand why stat debuffing is done through the Extended status effects instead of as an EP. I assume it's the result of poor planning or lack of foresight on the part of whoever programmed the formulas.

I am also not sure how exactly specific types of mess are inflicted. Testing reveals that the Bitwise status effect infliction seems to vary depending on the skill slot or perhaps the EP used, despite there being 3 different bits in the Bitwise status effect data block and up to 5 free status effect bits.

In the Extended status effect data block there are at least 5 different ways to automatically kill a target besides Stone. One of those is what Zaraktheus called Coup de Grace, which is instant KO whose success rate increases the lower the target's current HP is relative to it's maximum HP. Why there are so many different ways to do the exact same thing is something that no one but the original programmer knows. I think I tested them and determined that they are all exactly the same except some may prevent credit drops, item drops, monster absorbs, and mec program downloads. This is further complicated by what is apparently bit 0x40 in byte 0x11 of the primary skill data table that prevents all drops, absorbs, and downloads.

Many of the more obscure Extended status effects are similar to other effects that are hardcoded to specific EPs. Notable examples include the Light Sword Extened status effect being similiar to Al-Kaiser Change EP or skill slot (which changes the character's sprite and equips a Ray Sword in a hidden slot), and the Mystic Change Extended status effect also being similiar to the Al-Kaiser Change EP or skill slot.

Many effects are hardcoded to specific EPs, and even specific skill slots. Thse skill slots use dummy data that are all identical or nearly so.

If you removed the duplication of effects and moved the hardcoded effects to Extended status effects or EPs, you could probably save a lot of room in executable size and RAM, and you'd vastly decrease the complexity of the code base. My theory for why this never happened are that:
* Not much was planned in advanced, or even sketched out as they went along.
* Very little thought was put into organiztion.
* Someone coded before they started planning.
* Multiple people worked on the same aspects of the project with very little communication.
* Someone came along late in the project to finish someone else's work before it was finished.

2. There are several separate data tables, bytes, and bit flags that deal with the various counters, interrupts, and blocks. Some of them apparently do the same thing, and in some cases several of them must be set in all skills that do the same thing despite every separate flag and byte being set on the skill that triggers them.

They are also mixed in with several other things, among them in the primary skill data table:
* Byte 0x09, the blocking byte. In it's favor the shield blocking portion is sane.
* Byte 0x0A, the menu visibility byte. For some reason some of this byte's effects are also duplicated in the targeting byte, and it does things related to item breaking.

There are literally so many of these that I can't keep track of them all myself, and testing them all would take months of 8 hour work days.

This is classic data duplication and probably why many of the more complex counters like the unique counters for Swayback, KO Throw, and Dragon Turn work very rarely or not at all. With so much stuff going on across so many different (and differently formatted) data, no one will ever know how to implement these effects until this data duplication if fixed and an update is pushed to the remaster, or until someone disassembles or decompiles some version of SaGa Frontier.

Among these flags are multiple "contact" flags, along with the contact flag found in the special attributes byte 0x05 of primary skill data.

3. The targeting and area of affect (AoE) bytes may depend on one another to implement more complicated effects.

Area of effect has two parts: shape and size.

Instead of doing something sane and making the upper nybble of the byte the AoE shape and the lower nybble AoE size, instead it is a maze of different effects mapped to specific collections of bits. I had to manually test all 256 bit combinations to find the results, and even them I'm not sure about many of them and I didn't finish testing them all.

The targeting byte, which I am at least thankful that it is adjacent to the AoE byte, is even worse. It is a collection of various effects related to targeting and skill selection. Some of these effects are present only in the lower nybble of the targeting byte; while others vary with the upper nybble of the byte. I am also unsure of they have any effect that work with the AoE byte, so I need to test at least the five basic AoE shapes with all 256 values of the targeting byte, or about 1100 combinations.

One bit of the targeting byte may be related to shield blocking, I'm not sure but that's what someone told me. Testing shield blocking would be a nightmare.

Upon discovering this, I rage-quit SaGa Frontier modding after several weeks of pure despair.

There is no pattern to the targeting byte - it's apparently a combination of range values and bit flags, and of course the bit flags aren't arranged in a sane manner. Actually it must be a combination of bit flags or maybe even range checks, I honestly have no idea because the pattern makes no sense to me.

I assume it's chock full of bugs and code totally not understandable to anyone, as is normal for SaGa Frontier. I seriously doubt that any Japanese hackers understand it, and if they do they are famous for not sharing what they find so it will in all likelyhood never be modifiable. It would literally be easier to clone SaGa Frontier than to reverse engineer this pile of shit, and at that point why not make your own game and at least potentially make some money from your efforts.

Whoever implemented the formulas section of SaGa Frontier absolutely deserves to suffer, or barring that to be mocked on the internet.

4. There are a ton of unknown bits that seem to be related to either animations or monster parts. I assume this is yet another duplicated effort dealing with monster forms, which was later hardcoded to specific skills and skill ranges, and therefore these bits and bytes are wasted.

5. About 1/3 to 1/2 of the Effects Processes (EPs, or formulas if you want a simpler word) should not exist. They:
* Duplicate other EPs effects with some minor modification that should be a bit flag somewhere or by making better use of the first four bytes of primary skill data.
* Duplicate other EPs effects in such a way that could easily be contained in another EP with little or no data changes.
* Literally do nothing.
* Are bugged.
* Are hardcoded to set character status bits or trigger certain counters or interrupts in such a way that could easily be done with a byte or two as parameters... and they usually do not actually use any or some of the first four bytes, or any of the unused bytes of primary skill data for anything. In other words, they wasted coding space in hardcoding that could easily have been done with data, and in less space and complexity overall.
* There are separate physical and magical skills, when this should be set as bit flags and the stats that power them should also be set as bit flags.
* Are hardcoded to all sorts of effects and formulas that are done elsewhere in a less hardcoded fashion.
* Duplicate other EPs with hardcoded status effect infliction, in some cases with a status effect immunity bypass that could just be a flag somewhere.
* Deal additional damage or bypass resistances based on specific values in the gender and species byte - hardcoded, of course, instead of making use of one of the unused bytes in the primary skill data table.

5. There is literally one full byte that is not used at all, and which is full of zeros except for a single transcription error in the case of Final Strike.

6. Only half of combo data is actually present in the primary skill data table. It's formatted as a bit field, at least; the other half is if i remember correctly as a 2 bytes per entry list of all the skills that have specific combo properties.

In other words, the other half of combo data is formatted in the least optimal way that you could format combo data before you start manually converting ASCII character set strings for "Enabled" followed by skill names and implementing search algorithms. It really makes me wonder how much alcohol was consumed by the average Square coder during work from 1995 to 1998, or if there were clandestine drug labs operating in the area (perhaps their basement) and channeling their fumes into some hapless coder's basement office.

Perhaps someone was in their youthful experimentation phase, and they dropped tabs of acid and snorted cocaine off the art team's asses during crunch time.

If I had written something like this, I would have been fired for this alone, nevermind all the other collossal fuck ups present in the formulas code and skill data.

7. For some reason the "disable drops, absorbs, and downloads" flag was put in the ammo used byte, limiting the ammo used per skill to a range of 0 to 63. There's also an unused flag there for I assume "use all ammo"... naturally, this flag is not used in either the ally or enemy versions of Shoot-All.

8. The secondary skills data table and linked skills data table contain a few unknown or wasted bits and bytes, but to be honest this is such a mild offense compared to the rest of what I've suffered through that it barely merits a comment.

I assume some of them are animations, but unfortunately effects for, say, spell animations are tied to I'm guessing the JP use flag or each spell school's range of skills.

9. The conditional martial arts counters for swayback, ko throw, and dragon turn have their own little table that could maybe have been used as parameters in a generic counter formula or EP, with the formula or EP of the counter triggered itself also being a parameter in each skill's primary data table entry. That would allow much more flexibility and allow you to create similar effects for other conditional counters.

@michael2001 Thank you for the information , it so helful ^^