Spelltracking quirks

[AcadiusLost]

A few questions with spelltracking, primarily for Cipher:

How are we treating things like racial and class abilities, for restoration and persistence? Everything from the paladin's Smite Evil to the Duegar's Invis/day, to Undead Turning, to summoning Animal Companions is, on some level, spell-like in implementation. How are the uses being enforced across relogging, and resting? I'd expect they should ideally restore on resting like Innate abilities if they're racial, though things like Turn Undead or Smite Evil (or Domain abilities) might make more sense restoring at the same time as Divine spells.

Also, is our system set up to handle multiclassed casters yet, with differing types of caster classes? (bard/wizard, sorc/druid, etc)

I made some edits to acr_spelltrack to add Favored Soul and Spirit Shaman to the handling of ACR_GetHasCasterClass() - but do we need to account for them elsewhere as well?

[ç i p h é r]

Spell like abilities are implemented as "spells" I believe so they should be treated in the same way. IIRC, this proved to be the case with Smite but I didn't do an extensive test by any means.

ATM, spell uses are recorded by class. So yes, we should be able to handle multiclass characters. Studying will not restore clerical spells any longer or vice versa. The downside of this implementation is that if we add additional caster classes, we'll have to update our studying/praying code to make sure those classes restore spells as well.

[AcadiusLost]

Found the bug in the spelltracking- my offline resting code (for players who had been logged off more than 24 IG hours) wasn't calling ACR_RemoveSpellUses() - the naming of the function threw me when I was getting that functionality set up, really does sound like it should decrement spell uses (rather than adding to them by clearing the DB entry). Seems to work OK now, though I'm hearing reports that those logging in and having their spells renewed by the offline resting have to rest again before they are able to pray or study for spells, which was unintended.

[AcadiusLost]

Did another piece of work on this last night- realized in the course of it that we were only tracking one timestamp for spell restoration, which was being used for both studying and praying. Since a multiclassed caster with wizard and divine caster levels would have these restored separately, I split this into two separate timestamps. So far, seems to be working as intended.

I also added a bit more functionality to the offline resting- if the PC's last spell restoration timestamp was after their last resting timestamp (say, they prayed for spells just before logging off last week), when they came back in, it would not allow praying to change out spell memory until after the PC had rested again. Instead, I added a check to see if the spell restoration timestamp > last rest timestamp- if so, it updates the rest timestamp to one rest cycle prior to current- leaving both resting and spell restoration by prayer and/or studying available.

Racial spells: These get spelltracked as coming from caster class #255, and are not being cleared by ACR_RemoveSpellUses(). Guessing they're falling through the cracks- they seem to work OK ingame, but probably need special handling to be technically correct.

Also, the acr_spelltrack_i.nss script has the following:

Code: Select all

   35 //! this is the total number of spells in the game
   36 //! this is a workaround for knowing the spells a player has in their spell book
   37 const int SPELL_ID_COUNT = 1123;

Does this need to change with MotB? Seems there are more spells in game now.

[Rusty]

Potentially, we could have up to four caster classes on a single PC. Do we need separate timestamps?

[AcadiusLost]

The importance is in separating timestamps by means of restoration- to make sure no one gets more than one spell restoration of each kind per rest cycle (ie, no rest, study, cast, pray, cast, study, cast- without some more restings in there).

So, in that light, we need 3 timestamps (which we have now).

#1: ACR_REST_PRAYER_TIME (last time PC prayed for spells- applies to druid, cleric, ranger, and paladin spells)

#2: ACR_REST_STUDY_TIME (last time PC studied their spellbook- wizards only)

3# ACR_REST_TIME (last time a PC rested- this can also be assumed to be the time any sorcerer, bard, favoured soul, spirit shaman, or innate/racial abilities were last restored.)

I don't /think/ any of the casting PrCs will change these- Eldrich Knight spells will still be wizard or sorc spells, depending on the base class. If there are special blackguard or assasin spell listings, those would need special treatment, I suppose- but that's doable down the line.

[Rusty]

OK.

[ç i p h é r]

That's left over from the old logging method, AL. We can remove that w/o affecting the current implementation.

[AcadiusLost]

That's left over from the old logging method, AL. We can remove that w/o affecting the current implementation.

The "current" logging method still compares ACR_REST_TIME to ACR_REST_SPELL_TIME to determine if a PC is able to pray or study from spells. As such, it would only allow a multiclassed caster to perform one or the other (but not both: praying and studying) per rest cycle.

I think I've got it working on the OAS2 with the split timestamps, but currently the innate/racial spells like drow darkness, or duergar invisibility, write to the spelltracking DB without ever being cleared. I'll look into it a bit more tonight- I believe that's been a bug for quite a while, as most of the OAS2's spelltracking records have class=255, and show multiple uses (which should never happen for most abilities- a 1/day ability should never have 8 uses recorded in spelltrack)

Perhaps I missunderstood you on the timestamps? The one I altered (ACR_REST_SPELL_TIME) is certainly still used in acr_resting_i in the most recent version on sourceforge. I just subdivided it into 2 more specific timestamps, removing the old one.

[ç i p h é r]

Sorry for being vague. I was referring to this:

Also, the acr_spelltrack_i.nss script has the following:

Code: Select all

   35 //! this is the total number of spells in the game
   36 //! this is a workaround for knowing the spells a player has in their spell book
   37 const int SPELL_ID_COUNT = 1123;

Does this need to change with MotB? Seems there are more spells in game now.

We can simply remove it. The rest sound like good fixes to me.