Interlude Interlude & HF: invalid debuff cubic success rates

[quasilyte]

Short version

Here is the offending line:
https://gitlab.com/MobiusDevelopment/L2J_Mobius/-/blob/master/L2J_Mobius_CT_0_Interlude/java/org/l2jmobius/gameserver/model/stats/Formulas.java#L1283
It should most likely be:

Code: [Select]

final double baseRate = skill.getActivateRate();
Because otherwise most of debuffs will have a baseRate of 0, since their power is 0 (but their activation rate is around 80%)

There are more places like that in the same method:
https://gitlab.com/MobiusDevelopment/L2J_Mobius/-/blob/master/L2J_Mobius_CT_0_Interlude/java/org/l2jmobius/gameserver/model/stats/Formulas.java#L1260

I have a feeling it should be rate check too, not a power check.

If it ever worked as intended, maybe browsing the file history could be beneficial. It looks like a post-refactoring break

----

A concrete example: phantom cubic and associated debuffs have activation rates, but not power:

Code: [Select]

<skill id="4055" levels="8" name="Decrease Atk.Speed">
<!-- Temporarily reduces Atk. Spd. Effect 3. -->
<table name="#effectPoints">-379 -438 -495 -549 -590 -611 -635 -655</table>
<table name="#magicLevel">40 46 52 58 62 66 70 74</table>
<set name="abnormalLevel" val="3" />
<set name="abnormalTime" val="120" />
<set name="abnormalType" val="ATTACK_TIME_UP" />
<set name="activateRate" val="80" />
<set name="basicProperty" val="MEN" />
<set name="effectPoint" val="#effectPoints" />
<set name="icon" val="icon.skill1206" />
<set name="isDebuff" val="true" />
<set name="isMagic" val="1" /> <!-- Magic Skill -->
<set name="lvlBonusRate" val="2" />
<set name="magicLevel" val="#magicLevel" />
<set name="operateType" val="A2" />
<set name="targetType" val="ONE" />
<for>
<effect name="Debuff">
<mul stat="pAtkSpd" val="0.77" />
</effect>
</for>
</skill>

Notice activateRate property.

Because of this bug, the phantom cubic does nothing, getting a land rate of ~10% because of some other values (I printed the finalRate to verify it).

This bug is also present in HF file
https://gitlab.com/MobiusDevelopment/L2J_Mobius/-/blob/master/L2J_Mobius_CT_2.6_HighFive/java/org/l2jmobius/gameserver/model/stats/Formulas.java#L1433

[Skache]

Because otherwise most of debuffs will have a baseRate of 0, since their power is 0 (but their activation rate is around 80%)

Hello, have a nice day!
Could you check if this issue is also related to Surrender-type skills, like Surrender to Fire?

[quasilyte]

Hello, have a nice day!
Could you check if this issue is also related to Surrender-type skills, like Surrender to Fire?

I don't believe it does. When speaking about the "debuffs" here I was mentioning the DEBUFF type cubics that are handled in a separate code path (see CubicAction and its execution path).

You might experience some problems with default l2jmobius configs though! I was thinking about reporting a weird default setting for the max debuff land rate of 25%:

Code: [Select]

# Minimum and Maximum Abnormal State Success Rate.
# This affect all skills/effects chances, except in skills where minChance or maxChance parameters are defined.
# Default: Interlude minimum of 0% and maximum of 25%.
MinAbnormalStateSuccessRate = 0
MaxAbnormalStateSuccessRate = 25

https://gitlab.com/MobiusDevelopment/L2J_Mobius/-/blob/master/L2J_Mobius_CT_0_Interlude/dist/game/config/Character.ini?ref_type=heads#L354

I am 100% certain these values apply to spells like Poison and Curse Poison, but I have a hunch they affect all debuffs (e.g. Hex, Power break, Slow) by capping their land rate at 25%. It means that even in a perfect situation: blessed spiritshot, vast magic attack, 80 lvl character, and 0 magic defense 1 level target, the effect will only succeed once in 4 casts (25%). The base activation rate of ~80% of the skill doesn't matter either as your chance can only go down - 25% is a hard limit via config.

This is something I never saw before. I changed this value to something around 80% and now it feels more like something I've experienced on other servers. Note that it's still taking the per-skill chance in its calculation, it's just 25% won't be a cap anymore. It will make all matk-vs-mdef calculations and so on. I really wonder why 25% is a default  there. It felt like *none* of debuffs were working - you just waste mana and get no effects.

So I suggest taking a look at this setting if you're having problems with magic debuff success rate. Also, take a look at calcEffectSuccess method in Formulas class for more info.

It is a bit surprising not to see any search results for "MaxAbnormalStateSuccessRate". Like it's only me having issues with 75% debuffs (in perfect conditions) not working, even if it's something that usually worked with ~80% land rate even with lower matk classes like Shillien Knight. I used to land 7/10 poisons on average as assassin on many x1 C4-Interlude servers on self buffs (and I think it was with a normal spiritshot, not a blessed one). Here, it's like 2/10 will ever work (because reaching 25% cap is also not a given), even with blessed spiritshots.

[Mobius]

We are currently rewriting a lot of stuff to be more performant and more simplified.
I would wait a couple of weeks for the next project release.

I doupt that the skill or effect systems will be the same.
Could the changes affect what you reported? No clue.

[quasilyte]

The performance is good but the downside is that some of the custom code written on top of it would break. I hope the new code will provide some comments to make it easier to make a transition.

Still though, I think many people value correctness and "make it work" first, and then optimizations later. There are some bugs I hope we don't miss fixing and not introduce some new ones.

Imagine the player playing with their fav class only to find out that some of their skills don't work or don't work properly. It would be personally a deal breaker for me, as a player.

[Mobius]

It appears this issue is a significant concern for you.
While you've highlighted a problem that went unnoticed for over a decade,
it's worth noting there have been 18.000+ commits addressing plenty "make it work" issues.

As an open-source project, we welcome contributions from the community.
If this is a priority for you, I would encourage you to submit a patch with your fix.
If you have proof it is retail, it will be accepted.

[BazookaRpm]

Apparently the problem still persists, I'm still looking for a possible solution or something closer to the real operation.

[Pavlov]

Isn’t tweaking the value of the config making it closer to what you might want? If higher value in the configuration works, why can’t we stick with it?