I apologize for my last submission on the continued part of this
layout. Was very sketchy unclear, and at parts made absolutely
no sense. In this one I will try to explain in plain english my
goals and what I have to work with so far, along with some questions
I have pertaining to both of these factors.
My structs.h related code
--------------------------------------------------------------------
struct trainer_data {
int spell_number; /* Number of spell from 1 - MAX_SKILLS + 1 */
int percent; /* Max percent mobile will teach char to */
int cost; /* Gold cost of learning spell/skill */
int qp_cost; /* Quest point cost of learning skill/spell */
struct trainer_data *prev; /* Used in adding/subtracting entries */
struct trainer_data *next; /* Used in running through the list */
};
struct trainer_data *train;
--------------------------------------------------------------------
Now I am having a bit of trouble understanding ESPEC's, I'm not
exactly sure what the use of ESPEC's is, any information pertaining
to the topic, in terms of what it does, and how it goes about doing
it would be greatly appreciated.
Tony Robbins wrote:
>Then, I'd recommend saving the data as an E-Spec, which
>you can look up in parse_espec. It will take some
>modification, but on loading it, you could:
>struct trainer_data *new_train;
>CREATE(new_train, struct trainer_data, 1);
>new_train->next = mob->train_skills;
>new_train->... = /* parsed values */
>mob->train_skills = new_train;
>By doing this, you'll only allocate as much memory as
>you need, and the only difference is you'll have to
>step through the list and be careful when removing
>stuff from the list. It also means that in Oasis,
>using numbers in the interface won't translate as
>easily to array values. To make it a little easier to
>remove stuff from the list, you might think about
>adding a "struct trainer_data *prev;" and linking it
>properly that way. Then, when you go to remove
>something from the list:
>this_train->prev->next = this_train->next;
>this_train->next->prev = this_train->prev;
>free(this_train);
-------------------------------------------------------
The below would be contained in db.c.
------------------------------------------------------
Now I'm guessing mob would have to be referenced before hand
as something similiar to:
struct char_data *mob;
And then the following would appear as:
struct trainer_data *new_train;
CREATE(new_train, struct trainer_data, 1);
^ immediate guess is all elements are initialized to 1.
new_train->next = mob->train_skills;
new_train->spell_number = ? <- Not sure how this could be initialized.
new_train->percent = 100; /* Now from an immediate guess */
new_train->cost = 0; /* I'm thinking the values designated in */
new_train->qp_cost = 0; /* this section, are what is to be assigned */
mob->train_skills = new_train; /* on new creation of a mob, or is that
wrong? */
Also, judging by the syntax of train_skills, I'm guessing an integer
related
variable need be set up in struct char_data { to represent train_skills
ie:
int train_skills;
------------------------------------------------------
And the below here found in medit.c, when inputting values for
assignment to specific mobs.
-To make it a little easier to
-remove stuff from the list, you might think about
-adding a "struct trainer_data *prev;" and linking it
-properly that way. Then, when you go to remove
-something from the list:
-this_train->prev->next = this_train->next;
-this_train->next->prev = this_train->prev;
-free(this_train);
^ so would this be just a means of assigning the pointers/linked lists
in the right directions, or used as a guide line for running through
the list to decipher what spell/skill of the mob we are trying to
remove.
-------------------------------------------------------------
Now if everything above is fine and dandy, would genmob.c take similar
form to db.c, or would the assignment take a different form (with
saving)
to file.
* Overall Objective *
Is being able to edit any mob, assign SKILLS/SPELLS to that mob, that
will save on reboot, that of which that mob will be able to teach
players. In a nice fashionable form much like AFF_FLAGS for medit.
Now, would there be a need to assign every MOB on the mud, values
pertaining to 0's if they don't teach spells, or can I utilize only
the mobs that I want teaching spells/skills without running into
boot-up errors with db.c.
- Thanks again for all the help so far.
Aswell, I am not responsible for the loss of hair, chewing of nails,
and or violence towards your computer while reading this message. I'm
still getting adapted to the CircleMUD environment and am open to all
forms of criticism, laughter and ridicule. =]
Thanks in advance,
Bill
--
+---------------------------------------------------------------+
| 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/04/01 PST