09 Jul, 2010, triskaledia wrote in the 1st comment:
Votes: 0
I coded up a simple spell system that makes it so you have to have one spell mastered before you can go to the next.
Like, water to water blast to tidal wave to typhoon.
It all works fine for the most part, but sometimes during combat it likes to error and claim that the previous spell in the chain isn't at 100% when it is.
I have looked through the daze code bit because that seems to be where it's erroring, but I haven't found anything that causes the spell to drop by a percentage. I've not changed the standard QuickMUD ROM 'daze' state code any, so was wondering if anyone knows where or what causes a spell or skill to drop percentage randomly.
This is what I have coded:

void spell_typhoon (int sn, int level, CHAR_DATA * ch, void *vo, int target)
{
CHAR_DATA *victim = (CHAR_DATA *) vo;
int dam;
AFFECT_DATA af;

if (get_skill (ch, skill_lookup ("tidal wave")) < 100)
{
stc("You need to max the spell 'tidal wave' first.\n\r", ch);
return;
}
etc…
}
09 Jul, 2010, Kline wrote in the 2nd comment:
Votes: 0
Once it fails does it remain that way, or does it revert to working again? Most of the problems I've ever encountered that were hard to reproduce like this were memory errors where I was writing out of boundaries elsewhere within the struct. Stuff like int skills[2]; skills[2] = 5. May not always crash, or always error, but will certainly cause some very odd and hard to find problems.
09 Jul, 2010, Mudder wrote in the 3rd comment:
Votes: 0
Daze stats does affect proficiency. In fact it is skills/2 and spells/3

I'm not 100% where it does this though, but I am 100% that it does.
09 Jul, 2010, Hades_Kane wrote in the 4th comment:
Votes: 0
What I did on my MUD was put a check in check_skills (I believe that's the function where it checks for skill improvement) and if a character meets the requirement to learn a new spell, they learn it that way.

So if a character maxed tidal wave, they would automatically pick up typhoon. This way, if the character knows the spell, they only know it because they maxed out the previous spell and there's no need to continually check back to other one.

I don't know if this would work for you with what you've designed, but it's another thought none the less. Unfortunately, I can't think of anything that would help with the specific bug in question.
09 Jul, 2010, Koron wrote in the 5th comment:
Votes: 0
I'm not really familiar with roms these days, but I would suspect looking in get_skill would be a fine guess. Honestly, though, you're probably best served by just grepping for daze. If you see an instance of it appear in get_skill, check there first.
28 Jul, 2010, Rarva.Riendf wrote in the 6th comment:
Votes: 0
void spell_typhoon (int sn, int level, CHAR_DATA * ch, void *vo, int target)
{
CHAR_DATA *victim = (CHAR_DATA *) vo;
int dam;
AFFECT_DATA af;

if (get_skill (ch, skill_lookup ("tidal wave")) < 100)
{
stc("You need to max the spell 'tidal wave' first.\n\r", ch);
return;
}
etc…
}


Just telling, but do not have some code that will be useless if you return just underneath.
It will help you to think how the method works logically

Declaring variable at the start of a method when you are not even sure you will use them is really an artifact.

I suggest you to add a get_unmodifed_skill(CHAR_DATA *ch, int sn) that will return you the skill unmodified by any object or spell or anything else. And when I say that, I am not saying to duplicate code :p
0.0/6