# [RM2K3] DOING SOME QUICK TESTS/CALCULATIONS. UNEXPECTED RESULTS. FRONT/BACK ROW DAMAGE MULTIPLIERS?

## Posts

Pages: 1
For balance's sake, I'm trying to accurately compare the strength of skills as defined in the database to the regular Attack command. Here is the test:

I made a new skill that uses 10 ATK influence (no INT inf. or variance or uses attributes or conditions) that reduces HP (does damage). This skill has 0 effect rating so the skill is only based off of ATK influence.

I thought that this kind of skill should equate to a regular attack command. However, after using both an attack and the skill on the same enemy, attacking with the same character (so ATK/DEF on each side should be the same), these are some samples:

206 damage with the new skill. (the same every time because of 0% variation)
297 damage with the Attack command.

Now, if this skill was of the same power as the attack command, then 206 would be the average (0% variation) amount of damage dealt with the Attack command. However, this cannot be as the attack command's variation is only +/-20%. Therefore, I should be seeing only about 165-247 damage dealt with the Attack command.

I'm not sure why this is happening...Thoughts?
I think this extra damage might have to do with Row Formations, and having the character in the front row would give an increasing multiplier to the damage total.

Might anyone have any more info on the exact damage multipliers that front/back rows grant?
Yes, RowBonus is +|- 25% on physical attacks.
[QuickPatches]
NoFrontDamagePlus(Hero)=4B9880,EB4A
NoBackRowDefensePlus(Hero)=4C0D68,EB44

There's also a damage variance of 10 on physical attacks (attack command)
[QuickPatches]
HeroPhysVariance(Inverted)=49B2AB,#10
EnemyPhysVariance(Inverted)=49B687,#10

Inverted, meaning:
100 -> +|- 0.02 BaseDMG
10 -> +|- 0.2 BaseDMG
1 -> +|- 2.0 BaseDMG

In case you want to level out differences in Skills and PhysAttacks, here's a breakdown of the damage formulas:

PhysBaseDamage =
([0.50]Str(u) - [0.25]Def(t)) x [1.25](if user in FrontRow) x PhysAttributeDmg x MagicAttributeDmg x [0.75](if target in the BackRow)

SkillBaseDamage =
(EffectRating + [1/20]Str(u) x Atk-Influence + [1/40]Int(u) x Int-Influence) - [1/40]Def(t) x Atk-Influence - [1/80]Int(t) x Int-Influence x PhysAttributeDmg x MagicAttributeDmg

final damage =
BaseDamage +|- Variance

(u) ~ user
(t) ~ target
(applies to both the player and the enemies)

Variance gets applied to the BaseDamage:

Variance for Skills:
Variance =
([Random] - ((BaseDamage x [0.05]Variance(Slider 1..10)))
[Random] =
randomized between 0 and ((BaseDamage x [0.1]Variance(Slider 1..10)))

resulting in +|- x0.5 of the BaseDamage (in case of slider set to 10)
No randomization if variance for the skill is set to 0 in the database.

Variance for physical attacks:
Variance =
(randomize [0.4]BaseDamage) - [0.2]BaseDamage

resulting in +|- x0.2 of the BaseDamage
author=bugmenot
Yes, RowBonus is +|- 25% on physical attacks.
[QuickPatches]
NoFrontDamagePlus(Hero)=4B9880,EB4A
NoBackRowDefensePlus(Hero)=4C0D68,EB44

There's also a damage variance of 10 on physical attacks (attack command)
[QuickPatches]
HeroPhysVariance(Inverted)=49B2AB,#10
EnemyPhysVariance(Inverted)=49B687,#10

Inverted, meaning:
100 -> +|- 0.02 BaseDMG
10 -> +|- 0.2 BaseDMG
1 -> +|- 2.0 BaseDMG

In case ou want to level out differences in Skills and PhysAttacks, here's a breakdown of the damage formulas:

PhysDamage =
([0.50]Str(u) - [0.25]Def(t)) x [1.25](if user in FrontRow) x PhysAttributeDmg x MagicAttributeDmg x [0.75](if target in the BackRow) +|- Variance

SkillDamage =
(EffectRating + [1/20]Str(u) x Atk-Influence + [1/40]Int(u) x Int-Influence) - [1/40]Def(t) x Atk-Influence - [1/80]Int(t) x Int-Influence x PhysAttributeDmg x MagicAttributeDmg +|- Variance

(u) ~ user
(t) ~ target
(applies to both the player and the enemies)

Could you explain a little more for what's going on with that hex that you quoted?

Also, I assume since the enemy party does not have row formation that their damage would increase by x1.25 when the hero character is in the front row while it decreases by x0.75 when the hero character is in the back row. Is that right?

I was finding numbers along the lines of back row regular attack damage being based on ATK/2-DEF/4, and then front row would give a bonus to damage dealt and taken. Or does this median actually fall between the front and back row variances, such that front row gives up to +25% while back row gives down to -25% variance?

Thanks.
author=Shoobinator
Could you explain a little more for what's going on with that hex that you quoted?
The player deals 25% more damage (of the calculated base damage) when having a character in the front row. And suffers 25% less damage in the back row.

The first two patches just get rid of that (some people calculate the base damage for DynPlugins but get deviances) ...another solution would be to apply the +|- 25% RowBonus to Skills with physical/weapon attributes (might take a while, I got other things to do).

author=Shoobinator
Also, I assume since the enemy party does not have row formation[...] Is that right?
Row positions aren't tracked if the enemy is of the type 'monster', so you could say they don't get +|- 25% on any of their attacks.

So enemies only deal x0.75 damage when the targetted hero character is in the back row. (or rather: the hero just suffers 25% less damage)

author=Shoobinator
such that front row gives up to +25% while back row gives down to -25% variance?

The RowBonus gets added(or subtracted) to the BaseDamage before the variance is applied.
Is Variance in this post supposed to be substituted into your formulas that you gave in your first post? It looks like you're referring to 2 or more different things as 'Variance'.
edit
@post below:

Sorry, you're right. Some BaseDamage was out of place.

See post #3.
This still looks confusing because I think you're including 'BaseDamage' inappropriately when defining 'Variance'. Shouldn't the 'Variance' here just be the parts you highlighted in green? And then I can plug that in up top for the final result? Thanks.

And to be clear on those quick patches:

-the first two are essentially eliminating the 'Rows' mechanic, except for the aesthetics of being forward or back
-the second two patches are entirely eliminating variance on physical attack damage (the regular Attack command)

Am I right by saying this?
Okay those formulas make sense now.

But can you please further explain those quick patches? How were they derived? How exactly to include them? They look very useful. However, when I tried adding them to my DynRPG.ini, I didn't observe any different results. All my quick patches are under the one heading in the .ini file.

---

Also, would you happen to know how much an enemy gets buffed if they use the basic "Charge Up" command?

EDIT: I eventually observed the no attack bonus from the front row. However, it still looked like weapon damage had a +/-20% variance. Where did you find these quick patches?
author=Shoobinator
quick patches?
NoFrontDamagePlus(Hero)=4B9880,EB4A
NoBackRowDefensePlus(Hero)=4C0D68,EB44

...removes the effects of the rows on damage output. Some people removed the row command, calculated the base damage for an attack, but the game itself output 125% of the base damage. Not that useful, really.

Something like:
HeroPhysVariance(Inverted)=49B2AB,#1000
EnemyPhysVariance(Inverted)=49B687,#1000

...would remove the +|- 20% variance on physical attacks

author=Shoobinator
how much an enemy gets buffed if they use the basic "Charge Up" command?
Seems to be +100% BaseDamage for one turn... with a forced physical hit (haven't looked into that yet)

author=Shoobinator
Where did you find these quick patches?

Well, here's a thing:

The RPS patch makes skills (with a physical attribute) behave more like regular physical attacks. (Less damage suffered in the back row, more damage dealt in the front row. Does not apply to pure healing skills.) This makes it easier to have Skills that equate a regular attack. (if I understood your first post up there correctly)

The skill just needs at least 1 attribute checked, that has the attribute type 'Weapon' / 'physical' and target either an enemy or the enemy party (not self/ally/allies)

Also remove the QuickPatches
NoFrontDamagePlus(Hero) and NoBackRowDefensePlus(Hero)
to not unneccessarily crash the game.
Ah, thank you. I think I understand the physical attack variance patch. I will probably keep in a little bit of variance, but 20% was way too much especially with other multipliers increasing the damage range further.

I will have to look more into that RPS patch for sure.

EDIT: Oh btw, did you just make that RPS patch? Thanks a lot! So the RPS patch is not compatible with your NoRowBonus quick patch? Just realized that the whole point of your RPS patch is that you are assuming that there is still the back/front row bonus for damage. However, are these "physical" skills affected by factors such as accuracy (and conditions like Blind that may affect accuracy) and odds of hitting someone in the front row versus the back row?
Yeah, the RPS patch is borrowing the mechanic of the 'back/front row bonus for damage' from the regular attacks. It only makes sense, when the row bonus still applies to regular attacks as well.

PhysicalAccuracy =
Failure% = { 100% - (WeaponHit%* x [0.01]Hit%(u)**) } x (Agi(t) / 2x Agi(u)) +25%(IncreaseEvasionArmor) +25%(if target in BackRow)

*90% on unarmed, 90% on monster attack (70% if 'often misses' is checked)
**100% on default, changed by afflicted Conditions that lower the HitRate

SkillAccuracy =
Failure% = { 100% - (SkillHit% x [0.01]Hit%(u)**) } x (Agi(t) / 2x Agi(u)) +25%(IncreaseEvasionArmor)

The accuracy wouldn't change for "physical" skills when you attack an enemy (on physical attacks as well, as the enemy is normally of the type monster) from any row position. Unless you plan on giving enemies "physical" skills, too... I mean, them hitting more often being seen as a problem.

There's no 'ignore enemy evasion' on skills, too. (gets rid of the (Agi(t) / 2x Agi(u)) factor on physical attacks)

The weapon does carry over its 'ignore enemy evasion' trait.
author=bugmenot
Well, here's a thing:

The RPS patch makes skills (with a physical attribute) behave more like regular physical attacks. (Less damage suffered in the back row, more damage dealt in the front row. Does not apply to pure healing skills.) This makes it easier to have Skills that equate a regular attack. (if I understood your first post up there correctly)

The skill just needs at least 1 attribute checked, that has the attribute type 'Weapon' / 'physical' and target either an enemy or the enemy party (not self/ally/allies)

Would you be able to change this so that instead of checking whether the attribute has Weapon or Magic ticked in the database, it checks the actual name/string value of the attribute and sees if it equals "Physical"? If not, I cannot really use this because with the way I have my attributes set up, I have a Physical Weapon type and a Magical Weapon type, so just checking for "Weapon" is not going to cut it.

And if you were also able to make changes to the patch regarding Blind, accuracy, row targeting, etc., I would only want those changes affecting skills with the "WNonElem" attribute (if you are able to go by checking the exact string name of the attribute). This would be so that only regular attacks are affected by these things, while stronger physical attacks would not be. I don't want stronger physical attacks that cost high amounts of MP/SP to be able to miss as easily.

----

Separate question: is IncreaseEvasionArmor a boolean or variable value? In other words, does wearing multiple pieces of equipment that increase evasion (by ticking the box in the database) stack?

Does row formation actually affect whether you are more likely to be targeted? So, would an enemy be more likely to target anyone in the front row than anyone in the back row?
author=bugmenot
SkillAccuracy=
Failure% = { 100% - (SkillHit% x Hit%(u)**) } x (Agi(t) / 2x Agi(u)) +25%(IncreaseEvasionArmor)

This formula cannot be right because even while inflicted with a condition that gives a 0% hit rate, the skill still hits. After some tests, I would also surmise that the target evasion, (Agi(t) / 2x Agi(u)), part is also not really included in the calculation.

If possible though, the following formula is the one that I would want for skills that have the "WNonElem" attribute (again, if you can compare exact strings):

author=bugmenot
PhysicalAccuracy =
Failure% = { 100% - (WeaponHit%* x Hit%(u)**) } x (Agi(t) / 2x Agi(u)) +25%(IncreaseEvasionArmor) +25%(if target in BackRow)

This way I can make a skill that is truly equivalent to a regular attack for enemy regular attacks while still retaining physical skills for enemies and heroes that are not affected by condition hit rates (such as the hit rate for a Blind condition).
author=Shoobinator
Would you be able to change this so that instead of checking whether the attribute has Weapon or Magic ticked in the database, it checks the actual name/string value of the attribute and sees if it equals "Physical"?
I am not a programmer (getting only parts of strings is... something). How about a single attribute_ID?

[QuickPatches]
RPSAttribute=4B9A6F,04,4B9A70,%1

So anything that has at least that specific attribute_ID checked gets the row bonus. % means it has to be somewhere within 1..127

edit:
Dammit, attribute damage multipliers would mess this up when calculating AttributeDmg bonus (highest percentages get picked out -> "Physical" attribute needs to be at 0% Dmg -> PhysAttributeDmg x MagicAttributeDmg may result in a zero.)

author=Shoobinator
And if you were also able to make changes to the patch regarding Blind, accuracy, row targeting, etc.
So... magic Skills that can still hit regardless of the caster being blind?

It sure would be possible to split up the accuracy calculation between two types of skills. Needs some time, though.

author=Shoobinator
is IncreaseEvasionArmor a boolean
It does not stack. Just like attribute resistance on equipment.

author=Shoobinator
Does row formation actually affect whether you are more likely to be targeted?
No. It's random.
author=bugmenot
I am not a programmer (getting only parts of strings is... something). How about a single attribute_ID?

RPSAttribute=4B9A6F,04,4B9A70,%1

So anything that has at least that specific attribute_ID checked gets the row bonus. % means it has to be somewhere within 1..127

Actually, I think attribute ID should work just as well in this case. Thank you! I will have to look into this soon.

author=bugmenot
So... magic Skills that can still hit regardless of the caster being blind?

It sure would be possible to split up the accuracy calculation between two types of skills. Needs some time, though.

Yeah, something like this. Except right now, conditions do not affect the success rate of skills, and it seems that the success rate of a skill is entirely determined by the success rate that you set for it in the "Skills" tab in the database.
author=Shoobinator
This formula cannot be right
Mildly interesting: a weapon without "ignore enemy evasion" seems to cap the lowest success rate of skills to 50% if the quotient of Agi(t) / Agi(u) approaches zero.

If a hero has a weapon with IgnoreEnemyEvasion and has his hit rate reduced to zero, the Skill will fail at a 100% rate.

Here's what's happening in the game:

Float(A) = 100 - (SkillHit% x ConditionHit% x0.01)

without "ignore evasion" weapons:

Float(B) = ((Agi(t) / Agi(u))-1)x0.5+1

And the result is:
Success = 100 - Float(A) x Float(B) -25(EvasionArmor)

Might be a mistake in converting the negative floating point number.
Pages: 1