28 Apr, 2010, vidar1987 wrote in the 1st comment:
Votes: 0
Ok, so Im using my old smaug code now. You know where on creation it says like this:

Pick a Race:

–Blabla
–Blabla

and so on, where it shows the different races you can select. I have a few new races I want to add, but cant find out where to add them. Ive already added them in races and classes folder. What do I do from there to get them to show and be selectable on creation?
28 Apr, 2010, Kayle wrote in the 2nd comment:
Votes: 0
They need to be added to race.lst, and the mud needs to be rebooted/hotbooted.
28 Apr, 2010, Kayle wrote in the 3rd comment:
Votes: 0
As an aside, it's generally better to make and maintain the races with the setrace/showrace commands inside the mud then manually adding files. Any mistake in one of those files could prevent the mud from booting successfully.
28 Apr, 2010, vidar1987 wrote in the 4th comment:
Votes: 0
They are both added in race.lst and class.lst already, and when I type in showrace in the mud, they are listed there too, but still dont show on creation
28 Apr, 2010, tphegley wrote in the 5th comment:
Votes: 0
Do you pick the class first on smaug or race? Maybe you didn't add a class for them to be?
28 Apr, 2010, Kayle wrote in the 6th comment:
Votes: 0
Aha. Good catch, Tphegley. I forgot about that particular quirk (as I removed it from my own MUDs).

You'll need to make sure that the new races are not disallowing the classes. Or that the classes are not disallowing the races. I believe this is stored on the Race rather than the Class, but like I said, I've removed this from my own MUDs so I don't really recall off-hand.
28 Apr, 2010, vidar1987 wrote in the 7th comment:
Votes: 0
You can only pick race on creation. Its an anime mud, so yeah, you can only choose a race, not a class. No idea by what you mean there Kayle and tphegley. I tried the whole "adding them in shell", but since they are already created, shouldnt need to use setrace create right?
28 Apr, 2010, Kayle wrote in the 8th comment:
Votes: 0
You removed support in the code for classes?
28 Apr, 2010, vidar1987 wrote in the 9th comment:
Votes: 0
I didnt remove anything lol…
28 Apr, 2010, Kayle wrote in the 10th comment:
Votes: 0
I'm a little confused here. You said you don't have classes, but that you didn't remove anything. So how exactly did you get rid of the need for classes and have only races?

If you haven't removed anything, then new characters have to have a class assigned to them. It's what determines in Smaug which races to display. Because not all races can be every class. If they pick a class that is currently disallowed on the race, said race doesn't display. Okay. To be of any help, I'm going to need to see some code, but to tell you where to look for the code I need, I'm going to need a version number and flavour of Smaug that you're working with. Is it a SmaugFUSS flavour? Smaug 1.4a? Smaug 1.8b?
28 Apr, 2010, Mudder wrote in the 11th comment:
Votes: 0
And also pick up a book on coding. A lot of these questions are simply the result of not having a basic understanding.
28 Apr, 2010, Sharmair wrote in the 12th comment:
Votes: 0
Mudder said:
And also pick up a book on coding. A lot of these questions are simply the result of not having a basic understanding.

Actually, though coding might be an issue here, a lot of the questions here might very well
have to do with data setups. And if code has been changed from stock enough to be the
problem, it is unlikely that any book on coding would be of much direct help (unless there
is a book on how SMAUG works out there some place).

Now, some code that might be of help in figuring out what we have here would be the
CON_GET_NEW_RACE case of nanny() in comm.c to see how it is validated. Also, the
case that is executed right before the CON_GET_NEW_RACE case would be helpful to
see how the listing is done.
28 Apr, 2010, vidar1987 wrote in the 13th comment:
Votes: 0
Hmm, I guess the closest thing to what I use is a dbsc2.5 codebase. And to why it has no classes, anime muds (at least the ones Ive played) Say the DBZ Muds, they only have races, saiyan, etc. etc. Not classes, but there is a classes file in the classes folder as well, just has the same thing as in the races folder, in races folder there is i.e. saiyan.race and in class there is saiyan.class
28 Apr, 2010, vidar1987 wrote in the 14th comment:
Votes: 0
Just asked a friend, he said it needs to be added in comm.c I have no idea where though in comm.c
28 Apr, 2010, Sharmair wrote in the 15th comment:
Votes: 0
In the SMAUG derivative I work with, if there is only one choice for race, class or sex
the MUD picks it automatically. You need at least one race in the system, but you can
actually run with no classes (the case of no class is an offshoot of the multi-class
system). You can also go without classes as the somewhat unfinished (in stock)
system of race skills has been completed. Now, he is not using the same code as I am,
but his code might still have classes, but hide it. You could even setup an 'each race
has it's own class' mud with stock. SMAUGs generally have quite advanced OLC/E of
content. In my case the setting of all the classes and races, including all the max
levels and how classes can multi (or not) are all set with setclass and setrace (with a
few cset options thrown in).

With all that said, not all coders stick as much to the OLC/E ideals of SMAUG and
start hard coding things that should be content. I suspect that some of that is going
on here. As a wild guess (without seeing the code) I would not be surprised if the
list of the races was changed to be a hard coded list. Though the code I asked for
should confirm or disprove this theory.
28 Apr, 2010, Kayle wrote in the 16th comment:
Votes: 0
Well, this is the comm.c from dbsc2.5 and from what I can tell, it's a hard-coded list. So they've basically invalidated the entire purpose of switching the races from tables in const.c to the OLC versions anyway.
28 Apr, 2010, vidar1987 wrote in the 17th comment:
Votes: 0
so I should just delete the ones I created in the shell that arent showing up, and create them using setrace, and if I do that, would it put that race into the race folder? Also do I need to use setclass, or just setrace?
28 Apr, 2010, Kayle wrote in the 18th comment:
Votes: 0
I honestly don't know. I've never worked with, or had any kind of desire to work with a DBZ codebase. But after looking at DBSC 2.5's nanny() I don't know that making them using setrace will change anything. It looks like someone tried to make the OLC Race stuff do something it just wasn't initially designed for, and did it in a very poor fashion. You can try deleting them and making them using setrace, but I can't guarantee that's going to change anything.
29 Apr, 2010, Sharmair wrote in the 19th comment:
Votes: 0
Ok, after taking a look at the DBSC 2.5.0 code I can make a few comments. First, it
looks like they did in fact lock class to race so when you pick one, you are picking the
other too. From a quick look, the class_type and race_type structures look pretty
much unchanged. In nanny they decided to use the CON_GET_NEW_CLASS case to
set the class/race, and the case before (where the list to pick from is sent) is
CON_GET_NEW_SEX. Though they still seem to use (at least some of) the data from
the class and race files, so setclass/setrace should still work to edit the data. The
class/race numbers do seem to be hard coded for listing and verifying though. The
code seems to allocate room for 40 class/races, but only uses 31, of these, only 11
are listed and can be picked (I assume the other 20 are class/races that will be set
at some higher level as some kind of specialization system, though I have not checked
into this).

Assuming you are keeping all the existing class/races and just adding new ones to
the end (starting at number 31), you would have to replace the hard coded 31 in
the for loops in the CON_GET_NEW_SEX and CON_GET_NEW_CLASS cases of
nanny() in comm.c with your new number of class/races (or the MAX_PC_CLASS
variable as it looks like it is still being updated on load, though I am not sure why
they commented out the exact line that should have worked for both them and
now you). You also might have to make the letters[] array longer to handle the
helps part, but it looks like it will handle 3 more with the 14 it is set at (as a note
here, when setting a char array with a string literal, shouldn't the array be large
enough to hold the terminating NIL?). Then in CON_GET_NEW_CLASS where there
are two lists of ifs checking i == a number from 0 to 10 add checks for your new
class/races like so:
if(i == 10)
c = 30; // android-fm (last existing one)
if(i == 11)
c = 31;
if(i == 12)
c = 32;

You might have to change the line closer to the end CON_GET_NEW_CLASS:
if( iClass != 28 && iClass != 29 && iClass != 30 )

to include your new class/race numbers, or just make it:
if(iClass < 28 || iClass > 32)

If you are adding just two new classes/races.
0.0/19