On Fri, 3 Jan 1997, Robert Ward wrote:
> 1) Is there anyway to implement THAC0's of less than 1 in class.c?
> I've read building.doc and it mentions THAC0 bottoming out at 0 but
> browsing through the stock code I see that for pc's it seems to stop
> at 1. What I'd like to do is add some -x for the higher level warrior
> classes.
To my knowledge, there's no actual coded restriction. Try it and
find out.
> 2) My next question is concerning MAX_LEARNED in class.c. I'm looking
> for a way to base the max learned level on class and the particular
> skill. I don't think that a cleric who can learn second attack should
> be able to get Subperb while a Fighter with the same skill can only get
> to good.
Change spell_level to accept the max learned for that class and
add the following to the spell structure:
int max_learned[NUM_CLASSES];
I guess you'd change spell_level(), spello(), and unused_spell()
as follows:
void spell_level(int spell, int class, int level, int max) {
.
. put all the code up to the section below here
.
if (level < 1 || level > LVL_IMPL) {
sprintf(buf, "SYSERR: assigning '%s' to illegal level %d",
skill_name(spell), level);
log(buf);
return;
}
if (max < 10 || max > 100) {
sprintf(buf, "SYSERR: spell '%s', class %d, illegal max of %d",
skill_name(spell), class, max);
log(buf);
return;
}
// CHANGE THE BELOW CODE, IT'S IN STOCK
if (!bad) {
spell_info[spell].min_level[class] = level;
spell_info[spell].max_learned[class] = max;
}
}
Now for spello() and unused_spell(), we change the 'for' loop from:
for (i = 0; i < NUM_CLASSES; i++)
spell_info[spl].min_level[i] = LVL_IMPL+1;
...to:
for (i = 0; i < NUM_CLASSES; i++) {
spell_info[spl].min_level[i] = LVL_IMPL+1;
spell_info[spl].max_learned[i] = 100;
}
Now, go through class.c and change the calls to spell_level() to
conform (don't forget to change the prototype in spells.h for the
function to corespond with the) change to the number of arguments.
Afterwhich, change the guild code in spec_procs.c to use the
max_learned in the spell_info[] table, instead of the classes.
When you've done all of that, you can get away with removing the
maximum learned from prac_params[][] (eg., making it
prac_params[3][NUM_CLASSES] instead of prac_params[4][NUM_CLASSES]
and delete the first line of it :)). You'll need to go back into
spec_procs.c to account for the change. Even thought it's rather
troublesome to change prac_params when it's unneccessary, it does
help keep the code clean. And from a lot of experience, here, when
you don't keep your code clean, you eventually get tangled in it
and have strange side-affects in newer code that you can't find and
crashes where there couldn't logically be crashes, etc. While these
odd side-affects most likely would not result from leaving
prac_params as is, it does help to get yourself in the habbit of
cleaning up after you've obsoleted some code.
--
Daniel Koepke
dkoepke@california.com
Forgive me father, for I am sin.
+-----------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://cspo.queensu.ca/~fletcher/Circle/list_faq.html |
+-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST