----- Original Message -----
From: "Mysidia" <jmhess@I-55.COM>
To: <CIRCLE@post.queensu.ca>
Sent: Monday, April 02, 2001 23:57
-ok.. it's not april 1st anymore.. can we get rid of this now?
> > eforeBay Iway osepay ymay estionquay, Iway'llay atestay atthay Iway'evay
> > alwaysway eenbay onway ethay idesay atthay ayssay oneway ouldnshay'tay
> > avehay otay eray-ocumentday ethay Cay anguagelay orfay uturefay oderscay.
<snip of gibberish>
<OBCircle>
About those 'training mobs' we heard about earlier. This is a pretty nifty way
of doing it. However, have anyone (but me) considered making a 'guild editor'
much the same style as the shop editor in oasisOLC 2.0? This should, via an
easy costumizable menu allow greater control over who is allowed to train
by that particular mob, so particular classes and level ranges have different
trainers to go to.
For example:
A mob can train Thieves backstab, but only from 10% to 40%,
it also teaches thieves and warriors their lore skill to max, but
refuse to teach mages or clerics this skill (which they _can_
learn from another mob) above 10 %. Also, the mob is a battleveteran,
and can teach 'cure light' to clerics only up to 10 %.
As far as I see it, this would mean I'd need to assign something like
this to each training mob on bootup:
struct mob_special_data {
...
struct teacher_type *teacher;
...
}
struct teacher_type {
struct teacher_skill_type *taught; /* See below */
char *will_not_teach; /* if class/race is wrong according to flags */
char *can_not_teach; /* if char hasn't got the prerequisites. */
char *cannot_afford; /* if char hasn't got the gold.. */
char *not_enough_pracs; /* do. pracs. */
char *spell_skill_not_known; /* if char types badly.. */
}
struct teacher_skill_type {
int skillnum;
int min_learnedness[NUM_CLASSES]; /* minimum learnedness required to
be taught this skill/spell */
int max_taught[NUM_CLASSES]; /* highest taught level in this skill */
int train_cost_gold[NUM_CLASSES]; /* price per practice session in gp */
int train_cost_pracs[NUM_CLASSES];/* number of practices used - though
this might be skipped if pracs are
removed later in the process. */
bitvector_t flags; /* flags determining whether or not the
mob will train evil chars,
certain races, etc. this skill */
struct teacher_skill_type *next;
}
Now - This system would, just as the formerly mentioned one, be settable
through olc, though I'd (as stated) rather make it a seperate editor.
As far as I see it, the biggest problem with this model is the saving of
the guild data. Since the Espec saving method would require a lot of
data to be added to the current game files (we have 11 classes..), I
figure we'd make an extra directory called lib/world/gld, and thought
up a specification for the file. How would I be able to 'attach' the
trainer info to a specific mob? - would I have to save the mob vnum along
with the trainer info ? or do you think it's generally a good idea to put
it all in especs ? My thought would be they'd clobber the mob files.
Any and all feedback is welcome, and I seriously hope Alex have taken that
filter off by now.
Welcor
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST