Re: Querying the newingness (sic!) of character in interpreter.c

From: Thomas Arp (
Date: 02/16/03

From: "Vladimir Romanov" <rovlad@IPBI.RU>
>   Since subject may seem confusing, I'd like to get straight to the
>   point and explain what I have in mind. I wish to add Q_IFNEW
>   connectedness state in interpreter.c, which solely point is to be
>   called ahead of CON_GET_NAME to ask the player if the character he
>   wants to play is a new one. The reason I have for doing that is
>   quite simple - I want to alter character creation (as to let the
>   player choose his/her class and race ahead of sex and name) while
>   letting those who already have their character log in quickly and
>   painlessly.

Ok, let's have a look at what you need to do:

1. Add new connected state CON_Q_IFNEW
2. Decide on a login sequence.
3. Make new descriptors start in the correct mode
4. make nanny() handle the new con state.
5. adjust the rest of the login sequence.

Let's go through them one at a time:

1. too easy to spend time on
2. This is actually the most important step. If you do this right,
   the rest is very easy. In this case, you've already decided on[1]

              Race, Class, Sex, Name, name confirm,
               /                   Password, Password confirm, menu
   new char ?
            \ \(no) Name, Password, menu
              \(no input) Disconnect

3. in comm.c - new_descriptor(), change the default state to CON_Q_IFNEW.
   Search for CON_GET_NAME.

4. The new state should logically handle this:

   if input is yes
     start character creation sequence
   else if input is no
     start login sequence

Mailer code:
   case CON_Q_IFNEW:
     if (!d->character) {
       CREATE(d->character, struct char_data, 1);
       CREATE(d->character->player_specials, struct player_special_data, 1);
       d->character->desc = d;

     if (UPPER(*arg) == 'Y') {
       STATE(d) = CON_Q_RACE;
     } else if (UPPER(*arg) == 'N') {
       write_to_output(d, "By what name do you wish to be known ? ");
       STATE(d) = CON_GET_NAME;
     } else {
End mailer code

5. The most difficult step, since it requires modification of current
   code. My suggestion is stepping through the login sequence, one step
   at the time (corresponding with point 2, above). Look at each step,
   making sure you don't do anything you shouldn't be doing, and you're
   sending people the correct texts and setting them to the correct
   state. Be aware that since stock circlemud assumes a specific order,
   it _will_ do things you don't want it to. For instance, if you are
   creating a new character, and decide the name isn't what you want,
   it calls free_char() which invalidates all other info already
   stored in the d->character struct[2]. In stock circlemud there _is_
   no such info. You change it, you make the code deal with it...

Good luck.


[1] It's a lot nicer (and quite a bit more complex) when written
    on ordinary graph paper instead of ASCII art.

[2] I realize calling free_char() (case CON_NAME_CNFRM) is good for
    memory. However, this seems a bit overkill, since the memory
    will eventually be free'd anyway, if the character enters a
    blank name the second time around. Wouldn't simply freeing
    the name be sufficient?

      write_to_output(d, "Okay, what IS it, then? ");
-      free_char(d->character);
+      free(d->character->;
      STATE(d) = CON_GET_NAME;

    (just a proposition)

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/26/03 PDT