Ok, so Im using my old smaug code now. You know where on creation it says like this:
Pick a Race:
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?
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.
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.
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?
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?
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:
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
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.
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:
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?
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.
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: