09 Mar, 2014, Whitenoise wrote in the 1st comment:
Votes: 0
so this is the first mud I am building… mostly just a project for lulz…
so as for my questions:

when i create a race in the races folder… (I've also adjusted mud.h around line 790 for smaug 1.4) the Affected lists a series of numbers and I am unfamiliar where i find those so i may correctly build my new races and know what affects they are givien.

Also, when building a world (maps races classes items etc) from scratch I started with races then moving on to skills then classes then maps and items… I looked through the code and thought this would be the best way to put it all together… is this smart or is there a better way to go about rewriting the server?

:alien: Thanks in advance :alien:
09 Mar, 2014, Whitenoise wrote in the 2nd comment:
Votes: 0
oh and one other question… the as is server when listing classes during character creation cuts off short and doesnt show them all when you choose a class .. i assume i need to find the appropriate c or h file and set the string length larger but not sure where to find this.
09 Mar, 2014, Sharmair wrote in the 3rd comment:
Votes: 0
SMAUG 1.4a+ has OLC/E for both classes and races (races were added to 1.4, classes were in the 1.4a version). Though you
can edit the race files (and in some cases you have to edit them, I will get to that) setrace is the command to create and edit
races. The stock OLC/E system is good at adding new races (or classes) or tweaking existing ones, it has issues with removing
existing ones, and as I recall renaming existing ones (the SMAUG I work with has had these issues fixed and is fully OLC/E with
classes and races with no coding at all required or any need to hand edit files). The only thing you MIGHT have to change is
the MAX_RACE define that (as I recall) was set to just the current active number of races in one of the versions, it is the max
number of races you CAN have, the MAX_PC_RACE variable is the current number and you can create new ones with setrace
until you fill all the empty spots and setrace tells you to up the max number. The main problems come from the system still
using the race number in the race files, you MUST have one and only one of each number starting at 0 in the set of loaded
races (no gaps or repeats), this is where you might have to edit the files, renaming or deleting can make gaps or repeats.

The affected_by is an extended bit vector and setclass and setrace set based on names (the names it uses are in build.c
near the top in the a_flags array). If you really want to figure the number, going by the order of the a_flags array, starting
with the first entry as 1, then doubling with each entry (1,2,4,8,16 etc) will give the value for each bit up to 32 entries. If
you happen to get past 32 entries, you start over (stock has 128 bits in the extended bit vector, but most of the flag sets
that have been converted at most only use a few entries in the 2nd field). The format for extended bit vectors in files is
<ValueFirst32>[&<Value2nd32>[&<Value3rd32>[&<Value4th32>]]] - that is, the value of the added up values in each set with
an & between the numbers. A couple of examples (I am using my code for the entry numbers, I don't think they are changed
from stock, but be aware just in case):
protect_evil (14th entry) - value = 8192 - saved 8192
acidmist (35th entry) - value = 4 in 2nd set (3rd in set) - saved 0&4
I would use setclass and setrace though. This same thing can be used with other flag sets using the right name array.
Note that the normal bit vectors use just the first value number, unlike some codebases that extended bit vectors, the SMAUG
system is upward compatible with the saving of a standard vector the same as an extended with bits just in the lower set.

One caution, be careful removing skills, some are used in the code and can cause issues if they don't exist. Also, you mention
about rewriting and imply coding, SMAUG differs from many codebases in being much more data driven and many things that are
hard coded in other bases can be changed with settings and data setup.

The issue with the classes not showing on create might be caused by an issue with changing classes if you have gaps, though
if you are using stock, there is an issue of some code the RoD team had in to not allow the last 2 classes when they were in
development and forgetting to remove this code when they released it. In comm.c nanny function about line 1800 find:
* Take this out SHADDAI
for ( iClass = 0; iClass < MAX_PC_CLASS-2; iClass++ )

remove the -2.

A final note, while getting the info for that comm.c fix, I noticed a few things. First that fix is for 1.4a not 1.4, but I
was thinking you really might be using 1.4a and just dropped the a anyway, also I noticed from a quick scan of what I
looked at that it seems 1.4 may not have as much support for OLC/E of classes that I thought (though we were talking
race and that is in 1.4). If by chance you are in fact using 1.4, I really would suggest going to 1.4a
09 Mar, 2014, Whitenoise wrote in the 4th comment:
Votes: 0
yes I am using 1.4a i didnt mean to misinform and I'll edit previous posts. When downloading i didnt notice personally and hence me leaving it out.

– edit –

I after recompiling see also that I do not want to remove old races just not include them it would seem as i got thrown an error due to it IS_VAMPIRE and i had removed RACE_VAMPIRE as it did not apply to my mud storyline… So i assume i should just not include the races in race list.

Correct me if I am wrong and I do in fact need to rewrite all occurences of race specific code.
09 Mar, 2014, Whitenoise wrote in the 5th comment:
Votes: 0
As for your comment about MAX_PC_CLASS-2 and removing the -2 that worked perfectly. Thank you and glad to know I dont have to edit string lengths.

as for the editor… I am not having an easy time locating a linux area / race class editor so i will keep looking for now
though i dont mind hand editing though I am sure In a week I will regret saying that :P
09 Mar, 2014, Sharmair wrote in the 6th comment:
Votes: 0
Setclass and setrace are in game commands. The code is all in act_wiz.c, it looks like in stock they
are set to level 60. If by chance they are not setup with your setup use cedit to create the commands:
cedit setrace create
cedit setclass create
This will create the commands, using the code do_setrace and do_setclass at your level.
But if you just type setrace or setclass you might just get their mini help, it also looks like the stock
helps has setrace but not setclass. If you type wizhelp they should show there if they are set up.
10 Mar, 2014, Whitenoise wrote in the 7th comment:
Votes: 0
so just so that i fully understand what you are saying combined with what i am aware of… setclass & setrace are ingame commands(have found them thank you btw) I can build classes races etc. Not going to go into detail about the affected but i believe i grasp it. and as for skills/spells dont remove them as I noticed the issue with hard coding when removing vampire race. Now I assume I can add skiills to the data file in the appropriate format or is there a similar in game command to do so…. Seems I am likely to either keep the old races however not include them or is the best advice to find a more customizable less hard coded code base? I do like many things about smaug but knowing this and doing what is needed to correct the server code I see perhaps I should revisit the idea of other codebases…. Thank you so much sharmair for you quick response and helpful input. I am very grateful.
10 Mar, 2014, Sharmair wrote in the 8th comment:
Votes: 0
Well, just be careful what skills you remove, actually possess might be about the only one that will really cause problems.
First only ones used by the code (mob defense, attacks, specs etc) might have issues, depending on how they are called,
but most likely they will just not work. Yes there is a command to create and set up skills, sset. You can fully create many
types of skills using the spell_smaug system, but even if you have to (or want to) code the skill, you will still use sset to set
many of the attributes of the skill (what classes have it, the level etc).

As far as the races, I think only the RACE_VAMPIRE symbol is used in the code, and you probably can just set it to -1 and
just no player will ever match it, you might want to check nanny where it checks the race the player picked and make sure
it does not ignore race 4 (stock vampire, which BTW is not used anyway - I think making vampire a race was a failed idea
that was worked on a bit, then abandoned). Or you could just make sure you keep the dummy _Vampire_ race at position
4 and put your races around it.

As far as hard coding in the codebase, most others are much more hard coded then SMAUG. The SMAUG I work with does
go further in the online setup of things (though it is still not fully soft coded), if you have interest, I might be able to set you
up with it, though it has many added features, it has been designed to still play pretty much like stock SMAUG if you don't
change the setup (like you just run it with a stock data file set).
10 Mar, 2014, quixadhal wrote in the 9th comment:
Votes: 0
Generally speaking, it's safer to just make the skill unusable by players, rather than actually removing it. Dikurivatives all tend to hard-code things in various places, and it's a pain to walk through all the code to try and find where skills get accessed by number, rather than by a lookup.

If you're using SmaugFUSS, you might also check out their site for more info.
10 Mar, 2014, Whitenoise wrote in the 10th comment:
Votes: 0
Hey thanks guys for the inputs…. Yea I had decided to just render the skills unusable as I am already sifting through the code replacing class name variables in different places. Just to clarify before I go changing too much… If I add / change skills for a class ex my immortal character I am using to build races / classes and lets say one of the changes break the character I can just remove him from the player folder and recreate?

Also, It seems when i "setrace <name> create" it crashes the server… should I fill in all the other variables and then create? or should i just be preparred to restart the server Every time I make a change?


By the way… Thanks very much for the information you both have given. Seeing as the coding is my part of this and I am running solo on it at this time I appreciate the Info as it has already made this infinitly more possible and I am glad to be doing this correctly rather than figuring out later that I did something wrong. I'm not sure how many new to server coding people you talk to over the time and though I am happy doing the work myself I am very glad you have saved me headaches in the future.
10 Mar, 2014, Whitenoise wrote in the 11th comment:
Votes: 0
I will go see if i can find some other documentation regarding smaug1.4a coding as well so that I am not asking all my questions here. Hopefully narrowing down the amount I ask so I dont wear you all out.

Cheers for the info you have given and hopefully in 8 months or so a new mud will appear :)
10 Mar, 2014, Sharmair wrote in the 12th comment:
Votes: 0
Whitenoise said:
Hey thanks guys for the inputs…. Yea I had decided to just render the skills unusable as I am already sifting through the code replacing class name variables in different places. Just to clarify before I go changing too much… If I add / change skills for a class ex my immortal character I am using to build races / classes and lets say one of the changes break the character I can just remove him from the player folder and recreate?

I don't see how your character would be broken with skill changes. If you remove a skill a player has, it will record a bug of the missing skill on the first
log in after the skill is removed, but still load ok. If you do get the pfile messed up (or you just want to delete a character), removing the pfile will do it.
Well mostly anyway, immortals also have a file in the gods dir and maybe a proto area in the building dir, but unless you want to totally delete the character,
I would not worry about them, and if you do want to totally delete a character, use the destroy command.

Whitenoise said:
Also, It seems when i "setrace <name> create" it crashes the server… should I fill in all the other variables and then create? or should i just be preparred to restart the server Every time I make a change?

I would fix whatever is making it crash. You should not have to restart. I took a look at my code to see if I could see something that
might be an issue, though many things have been changed from stock I was reminded of some things. An invalid or too long name could
cause problems. The name is also used as the filename and I would only use letters and maybe numbers, -, _ or ' and not be over 15
char long. Also I seem to recall an issue with the stock race.lst file (that is written with a race create) on *nix, seems it was read only,
but it was something to do with permissions.
10 Mar, 2014, Whitenoise wrote in the 13th comment:
Votes: 0
Yea Once I went through the code and set my own class variables and recompiled the error is gone… seems perhaps because I somehow had doubled up the class numbers. At this point it is going smoothly and have spent the day building my classes. I still need to find some source reference to guild and also to double check that I am doing weapons correctly.

For weapons I am using : http://www.realmsofdespair.com/smaug/her...

that is to say using the value3 number

and going by that list. If I test and it comes out wrong I'll have to look elsewhere but from what I see that reference is correct. I'll finish building the 5 classes I have started and make another race today and test a few things to see how it all works out.
10 Mar, 2014, Patriot wrote in the 14th comment:
Votes: 0
Hi Whitenoise,

There are lots of helpful people here and some frequent both sites, but would just like to point out http://smaugmuds.org if you didn't know about it.
10 Mar, 2014, Whitenoise wrote in the 15th comment:
Votes: 0
Ahh thanks. I will have a look there now. I have also answered my own questions about weapon and guild numbers in the class template. Had mostly just posted so that no one had to explain it anyway.


Also I may switch to smaugFUSS now before I get to far into this… It seems it is the current platform for smaug servers. Thanks for pointing this out.
11 Mar, 2014, Sharmair wrote in the 16th comment:
Votes: 0
Actually there are a few maintained SMAUG offshoots, smaugFUSS is just one, and frankly not one I would use.
I was once asked on a MUD I helped out on if to start with stock 1.4a or FUSS, after some thought I decided stock
was better. Though stock does have some issues, they are mostly known, FUSS though an attempt was made to
fix some bugs, many are fixed wrong, or things that are not bugs at all have been changed, and in some cases some
very bad things have been added. So you might have just as many bugs, but not as well known and a lot of things
changed for no reason other then the whims of the developer.
11 Mar, 2014, Whitenoise wrote in the 17th comment:
Votes: 0
Ahh alright then… I will have to look over the different forks of smaug. However it seems you are saying smaug1.4a is still a solid base to build a mud and is not incomplete from what I understand. And the issues mostly are known. Well so much info to take in today. I think I will have to revisit this in the morning. I have both now and will look over the two and decide.
11 Mar, 2014, quixadhal wrote in the 18th comment:
Votes: 0
The issues may be known, but nobody else has bothered to actually FIX them.

One of the bizzaro things in the Dikurivative world is this idea of forcing people to hunt down and apply patches, which of course only work if you haven't actually started customizing the codebase yet. Personally, I think it's probably easier to work with SmaugFUSS and revert a few of the changes you dislike, rather than re-re-re-re-re-patching 1.4a again. The only two major "features" I can think of are the weather system (let's face it, Smaug's weather sucks… the new version is different, maybe better, maybe not), and the reset changes (which fixed long-standing containment bugs, but introduced a couple quirks by ditching area-based resets).

Also, there *IS* Smaug 1.8b, which was a surprise bugfix release from the original Smaug people. I think it popped up in 2008 and shocked everyone. YMMV.

There's also the LOP smaug derivative, which I think Remcon is still maintaining more-or-less, likely at the same smaugfuss site. Not sure what all is different, but unlike most of the orphans out there, it at least gets a bugfix or update every so often.

If you do dredge out the antique code, you'll be spending far too much time fixing things for modern compilers… If you DO, you might consider making a github project and checking in the updated version, so perhaps others don't have to spend days re-doing it again and again. :)
11 Mar, 2014, Whitenoise wrote in the 19th comment:
Votes: 0
Alright, given all this info… I'll have a look over them and see if I can find info on all the bugs mentioned. I would as I said rather do my homework now on a codebase rather than find out I need to rewrite a large portion of the codebase and hunt down the bugs. Thanks again all.
11 Mar, 2014, Whitenoise wrote in the 20th comment:
Votes: 0
After a little research on 1.8b and double checking the compile process it seems there are enough compile errors in the stock code to make me not want to even give that a go. conflicting types for getline and what not… doesnt seem the fixes they applied are actually worth what to me looks like poor coding and quite possibly an unstable codebase. Thank you for pointing 1.8 out but I think I will have a look over which of the smaugFUSS or smaug1.4a codebases I will actually use. I'll have a look at LOP as well hopefully by the end of today I can decide on a codebase and get back to writing.