Skill Variable Issue

[Sunaries]

Kanna in GMS will soon receive a buff. I compared the old and new version and I noticed that some numbers are missing in the new version.

Example)

BEFORE ↓ Skill description

Variables

AFTER ↓ Skill description

Variables > indieMdd was replaced by indiePdd

If you read the skill description in the BEFORE version, you will read: Haku's Blessing - DEF: +200, Hakku's Fan ATT: +20%, Duration: 40 Sec. However, in the updated version, you will read: Haku's Blessing - DEF: , Hakku's Fan ATT: +20%, Duration: 40 Sec. - The value after DEF is missing.

This happens to other values as well, take a look at the next example.

BEFORE ↓ Skill description

Variables

AFTER ↓ Skill description

Variables > x is replaced by indieIgnoreMobpdpR

Checking other skills, I see madX. So far, the issue that is causing this is: indieMdd and indieIgnoreMobpdpR

[KENNYSOFT]

Do you re-initialize StringLinker with new version? Variable names linked to skill description is stored in string.wz, so you should do that.

[Sunaries]

@KENNYSOFT I actually opened two WCR2. One loading the current version and one with the new update.

[Kagamia]

(That's the reason why I leave a default '0' there 😆 ) SummaryParser.cs

[Sunaries]

@Kagamia Ah, @KENNYSOFT commented that line. If I uncomment it, I will see this:

indieIgnoreMobpdpR 25 + x (x=15) = 40% - Yet it outputs as 0%.

Also, I've encountered another bug.

Mana Cost: #epCon, Transformation Duration: #time sec.\n#cBreath of the Unseen:# Haku grants +#prop% Knockback Resistance and +#a% Ignore Enemy Defense.\n#cHaku's Gift:# Haku restores up to #u% of your Max HP.\n#cFoxfire:# Haku summons #y foxfires for #w sec. Has #z% chance to nullify magic. Reflects #x% of damage. Each reflected attack consumes 1 fire.\n#cHaku's Blessing:# Haku casts a spell lasting #v sec that increases Defense by #indiePdd, and Magic ATT by #indieMad% of the equipped fan's Magic ATT.\n#cIncreases Final Damage by #q% for each party member affected by Haku's buffs\n#c[Passive Effect - Magic ATT: +#madX]#"

See last line. The simulated tooltip says Magic ATT: +10]0 - It should be: Magic ATT: +100]

EDIT: Ah, it seems to be related to sb.Append(0);//默认值. If I uncomment it, that will happen, if I comment it, it won't happen and it will output as it should.

↑ in-game version

↑ Simulated version

If I uncomment sb.Append(0);//默认值, it will show in-game version. If I comment it, it will show like simulated version. This issue or the 10]0 issue, one of the two will always exist.

[Sunaries]

@KENNYSOFT said he commented sb.Append(0);//默认值 due to the following issue with skill ID 400001024:

↑ comment

↑ uncomment

String: MP Cost: #mpCon, Duration: #s sec, Max Stacks: #x, Each stack provides an additional buff.\n#cStack 1# - Skill Cooldown: -#w% (excludes skills unaffected by cooldown reduction)\n#cStack 2# - Knockback Resistance: +#z%\n#cStack 3# - All Stats: +#q\n#Stack 4# - Attack Power & Magic ATT: +#u\n#Stack 5# - Boss Damage: +#v%\n#Stack 6#: Invincible for duration of skill\nCooldown: #cooltime sec. Cooldown increased to #y sec when buff expires (including character death) or max stack count is reached."

It should say Stack 4, yet it doesn't on both outputs and it shows orange text where it should not show.

In-game version:

[Kagamia]

@Sunaries I've simply tested with the skill summary. Yes, this annoying bugs maybe only appear from GMS/MSEA client. 😞

Here explains the working model of SummaryParser class: 1> Find a '#' character. (L26) 2> Get a vaild property name after '#', as long as it could be, allows empty. (L29-42) 3> Matching with common properties. (L45-56) 4> If failed, matching with global reserved properties. (L64-89) 5> If failed, and already in orange font color (beginC), then close it. (L91-96) 6> Else, a 'c' character is after '#', then begin orange color. (L97-102) 7> If not find a word after '#' (important!!!!!!!!! A single '#' character is treated as '#c'), the same as <6>. (L103-108) 8> If all failed, consider that the given property name is missing, return a '0' as default. (L109-121)

The issue is, <7> will never take effect, because in GMS/MSEA, It could always find an valid property name after '#' at most time (they are always English characters 😃), if I fix that, <8> could never be triggered.

I need both common properties and skill H summary in string.wz for testing. I'm sure that CMS/KMS can't find these bugs.

[KENNYSOFT]

Right. So we should make assumption like 'all of property names are like camelCase'; which starts with small letters.

BTW, let's see this string: Mana Cost: #epCon, Transformation Duration: #time sec.\n#cBreath of the Unseen:# Haku grants +#prop% Knockback Resistance and +#a% Ignore Enemy Defense.\n#cHaku's Gift:# Haku restores up to #u% of your Max HP.\n#cFoxfire:# Haku summons #y foxfires for #w sec. Has #z% chance to nullify magic. Reflects #x% of damage. Each reflected attack consumes 1 fire.\n#cHaku's Blessing:# Haku casts a spell lasting #v sec that increases Defense by #indiePdd, and Magic ATT by #indieMad% of the equipped fan's Magic ATT.\n#cIncreases Final Damage by #q% for each party member affected by Haku's buffs\n#c[Passive Effect - Magic ATT: +#madX]#". For the last two lines, it has '#c ~ #c ~ #' structure: nested #c.

[Kagamia]

So, what is the right order?

 beginC(#c) -> single#(# as #c) -> endC(#) -> missing Property(#blabla = default(0))

Does it make sense?

I have to check all common property names from skill.wz, Nexon make a joke again. 😆