Skill - DivinePulse - Githubissues

MokhaLeee / fe8u-cskillsys-kernel

Morden c-skillsystem for fireemblem8u

6 stars 4 forks source link

Skill - DivinePulse #161

Closed JesterWizard closed 1 week ago

JesterWizard commented 1 week ago

A 30% + Skill chance to turn a missed attack into a hit.

Figured it was about time we added some more Engage skills.

Would be nice if we could replicate the Three Houses verson of this too, but I'm not sure if the GBA will allow it.

MokhaLeee commented 1 week ago

Apart from the appearance of animation, I don't see any other meanings of this function?

JesterWizard commented 1 week ago

gBattleHitIterator->attributes |= BATTLE_HIT_ATTR_MISS is used to determine if an attack has hit or missed and is set after the 2RN check has failed. In this case, if that happens, one of two things will occur.

If the DivinePulse is defined, then a 1RN check will be executed (based on a 30% + skill % chance) to avoid setting gBattleHitIterator->attributes |= BATTLE_HIT_ATTR_MISS (essentially turning the missed attack into a hit). If this check fails, then the attack misses.
If DivinePulse isn't defined, then we just proceed as usual with #else where a missed attack sets gBattleHitIterator->attributes |= BATTLE_HIT_ATTR_MISS.

MokhaLeee commented 1 week ago

seems that this should check on lck rather than skl

https://fireemblem.fandom.com/wiki/Divine_Pulse

JesterWizard commented 1 week ago

So it should, fair enough. Luck makes more sense thematically anyway.

JesterWizard commented 1 week ago

"Chance increases with high luck" doesn't exactly state how luck affects the proc rate. I feel my initial explanation was better.

MokhaLeee commented 1 week ago

yeah, I also think this explanation is strange. But that this vanilla

JesterWizard commented 1 week ago

Maybe so, but there's no reason to stick to it if a better definition can be provided.

On the subject of vanilla, FE8 has multiple well known glitches. Following your logic, does that mean we shouldn't remedy them because it is default behaviour?

MokhaLeee commented 1 week ago

Your point is reasonable. Although I'd prefer to follow to the original if there are no obvious suitable reasons, but it makes sense to make the necessary changes if it's obvious that there is a need for optimization.

JesterWizard commented 1 week ago

I can respect that. I personally wouldn't suggest a change to wording if the original implementation makes sense. Only in cases where definitions can be ambiguous.