monsterUndeadLevelDrain and monsterParalyze Spells Display Saving throw failed script when saving throw succeeds

[grannypron]

This is a general problem that muddied the waters with #74 and #73.

I have watched this happen partially in the debugger in the case of monterUndeadLevelDrain, I saw the debugger slip into ExecuteSavingThrowSucceededScript() and then when I resume execution and return to the program, I see the message "Character feels diminshed". Then, when looking at their stats, I see no effect on the character level.

[grannypron]

To debug this, set a breakpoint at the end of CHARACTER::DidSaveVersus() and modify the success boolean to be true, return out from the function and trace the rest of the way through.

The problem here COULD be that the
"cast msg" is "/t feels diminished." when perhaps that should be blank and the savingThrowFailedScript should instead be that. Should try to set that and see if the call to spellGPDL.ExecuteScript() actually returns the value set in the SET_HOOK_PARAM(5,"") call.

[grannypron]

Those savingThrow***Script values do seem to be compiled and returned properly, but the displayText object passed in is NULL . This value is passed in all the way from the Globals call to InvokeSpellOnCombatant(). I am having a hard time understanding how any success saving throw messages are appearing at all.

[grannypron]

It looks like spell saving throws can be displayed when using an actual spell. This is because there are several ways that InvokeSpellOnCombatant() is called. In some of these, combatData.m_sSpellEffectMessage is passed in as the displayText and in others, NULL is passed in. In the case of a simple spell that is being cast at range, combatData.m_sSpellEffectMessage, but in the case of a spell that is "attached" to a creature's melee attack like monsterUndeadLevelDrain, NULL is passed in (from Globals.cpp).

So, I think this problem only affects melee attack spell effects - or probably any spells that are spawned by InstantSpellActivate()

[grannypron]

This will probably require a non-trivial code fix. ATM, I have a lot of things out for the community to review, so I am going to pause on this one for a while. In the meantime, we could change all the "cast msg" values to the be something like "/c attempts to ... /t" so they are, at the very least, not misleading.

[grannypron]

Just changing Globals.cpp's InvokeSpellOnCombatant() to pass in &combatData.m_sSpellEffectMessage does not change anything. I need to investigate more to understand where these messages are / are supposed to be displayed.

[grannypron]

The stack trace for when the cast msg is displayed:

UAFWin.exe!DisplayText(int x, int y, int fontNumber, const char * ptext, FONT_COLOR_NUM colorNum, int customColor, int highlight, int slowText, int UseBackBuffer) Line 4292	C++
UAFWin.exe!displayCombatStats(int dude, int fontNumber) Line 1511	C++
UAFWin.exe!UpdateCombatTimeDelayMsg(int dude) Line 868	C++
UAFWin.exe!TIME_DELAY_MSG_DATA::OnDraw() Line 21629	C++
...

The magic line is DisplayText(x,y, fontNumber, combatTextData.GetTextLine(i)->text, whiteColor, FALSE); and the magic property is FormattedText::combatTextData.

[grannypron]

My gut says changing this will involve a considerable amount of work/planning/analysis/risk.