/***************************************************************************
 * Alright. This is part educational for newbie C Rom programmers,	   *
 * even though a lot of people this day and age are using the C++	   *
 * codebase. Many people actually use the standard Rom 2.4b6 or sim-	   *
 * ilar base because it's easier, less complicated, and some people	   *
 * are just old school. At the same time, many new MUD coders are	   *
 * directed towards, and better off starting with ROM 2.4b6 based on	   *
 * 'C' compared to C++ because if you don't know C++ at all, then it's	   *
 * ten times more of a foreign language to newbie programmers.		   *
 * I myself love C, as I'm only a novice, and though I do have some	   *
 * C++ programming experience, when it comes to MUDs, I'd rather use C.	   *
 * Primarilly for the fact that this is a TEXT BASED GAME. Download	   *
 * A stock C++ MUD and C++ actually takes more space as more 		   *
 * modifications despite the ability to make things "run faster.	   *
 * Don't believe me? Here's something in C that WON'T compile in C++:	   *
 *									   *
 * int *x = malloc(sizeof(int) * 10);					   *
 * -------------------------------------				   *
 * Now here's the same thing in C++:					   *
 *								  	   *
 * int *x = new int;							   *
 * int *x_array = new int[10]; 						   *
 * -------------------------------------				   *
 * Now... Let's get to the point for new programmers who "want to run"	   *
 * a MUD. The smaller your files, the better. And though they don't take   *
 * up a lot of space, this little shortcut can still reduce the size of	   *
 * your code. Look at interp.h, and magic.h. These files are based on	   *
 * "DECLARE_DO_FUN" for interp, and "DECLARE_SPELL_FUN" for magic.	   *
 * And after adding modifications, you may find that some snippets add	   *
 * A DO_FUN "declaration" shortcut (some MUD snippets add it in merc.h).   *
 * But what if... just what if you could shrink that down a little smaller?*
 * Believe it or not, each character of text in those files takes up more  *
 * space and those little bytes add up. The code below is designed to	   *
 * make it take even LESS space in stock ROM. And it's a very quick and    *
 * small snippet. 100 times smaller than this big lesson. So let's do that.*
 * Koqlb of Subversive Visions (subversive.themudhost.net port 7500) 	   *
 ***************************************************************************/
I've tried to make this snippet explain even for the most uneducated beginner
when it comes to ROM. Because Rom is based on C originally. Yes. But it's not.
I've programmed in C, I've programmed in C++... and I even put Rom down on my
resume because certain things in ROM are their own language. Any coder whether
they don't agree with me on some things SHOULD agree with me on this.
Now I could keep boring you with education, but blahblahblah. You don't want
to take the time, and you'd rather just get your game running, and smoothly.
SO here ya go.
---------------------------------------------------------------------------
Code with + signs on it are bits of code to copy/paste into your file.
NOTE: Don't forget to take out the + signs when you're done. Trust me,
it's easy to forget one.

In interp.h you'll notice all the DECLARE_DO_FUN functions. If you've added
mods and have DO_FUN declared in merc.h, great. But this is still a great plus.
Every time you add commands, you increase the size. So let's take the declare
down to two characters. Underneath this code:

First, open the pico editor, or gedit, or wordpad, etc.
Whichever your favorite editor is, and do a find/replace.
Text to replace: "DECLARE_DO_FUN"
Text you want to replace this: "DF"
WITHOUT the quotes.

Now for the meat.
Below the code in interp.h

#define COM_IGNORE

and ABOVE 

struct cmd_type call, put this.

+/* Make adding new commands faster.
+ * Koqlb of Subversive Visions.
+ * (koqlb@subversive.themudhost.net)
+ * subversive.themudhost.net 7500
+ */
+#define DF(fun)          DECLARE_DO_FUN(fun);
+

And your function calls should look more like this now:
DF( 	   do_advance          );
----End interp.h ---------
Now let's make the spell function calls smaller.
In magic.h, do the same thing, except the text
to find is "DECLARE_SPELL_FUN" and replace it with
"DSF" I've looked, and haven't found a bit of code
that uses these declarations at all.

Then in magic.h underneath the "ROM License Comment"

and above:
/*
 * Spell functions.
 * Defined in magic.c.
 */

Add this:
+/* Make adding new commands faster.
+ * Koqlb of Subversive Visions.
+ * subversive.themudhost.net 7500
+ */
+#define DSF(fun)          DECLARE_SPELL_FUN(fun);
+

And your spell functions should look more like this:
DSF(    spell_null              );
------ End magic.h -----

Keep reading if you want to some more on shrinking and cleaning
of you code, keep reading.

If you didn't notice, a lot of stock ROM code has crap
"centered" in those little bitty parentheses to make it easier
really do see, such as the spell functions. This is not necessary.
And all those little spaces take up space. EMPTY space.
What I've done to my MUD is taken those empty spaces a lot of time
there's a tab between the first '(' and the function name. ( i.e.- do_auto)
Therefore, what I did is make it so only the LAST closing ')' parenthesi lined
up. After the spell or command function name, you SHOULDN'T need to tab the
closing ')' that far over. And face it, if you have a function name that is
"do_supercalifragilisticexpialidocious" then you REALLY should consider a
way to superbly shrink that sucker, or "abbreviate it" (i.e.- sfe). Nobody
wants to type that out....
Let's use interp.h for example. After you did the "shrinking" bit shown above,
change the functions as shown:
DF( 	   do_advance          ); (why do we need all those spaces???
Replacement. This is what it looks like on my MUD.
DF( do_advance          );

Now you can do this type of thing in ALL the code if you'd like,
but you don't have to. This is really just to make adding spells,
skills, and commands faster, and easier, plus it takes less space when
it's compiled. Whatever you do, try not to use some "file formatting"
plugins or programs. Many of those are designed to yes, remove extra
spaces, but they also remove extra new lines when they're not needed.
While is shrinks your code down a HUGE amount, it will make it hard
as shit for an inexperienced coder to read. Trust me... I've done it
before early on... and had to revert all my code back.
Another thing you could possibly look into in ALL of your .c and .h
files is extra blank lines. You shouldn't need anymore than ONE blank
line before functions, structs, or calls, etc. in order to be able
to distinguish from one function to another.
So for example, here's some code from the stock interp.c:
----------------
/*
 * Command logging types.
 */
#define LOG_NORMAL  0
#define LOG_ALWAYS  1
#define LOG_NEVER   2



/*
 * Log-all switch.
 */
bool fLogAll = FALSE;
char    last_command[MAX_STRING_LENGTH];


/*
 * Command table.
 */
const struct cmd_type cmd_table[] = {
----------------
See all those empty lines? Let's get rid of them and make this look more 
like this:
-------------------
/*
 * Command logging types.
 */
#define LOG_NORMAL  0
#define LOG_ALWAYS  1
#define LOG_NEVER   2

/*
 * Log-all switch.
 */
bool fLogAll = FALSE;
char    last_command[MAX_STRING_LENGTH];

/*
 * Command table.
 */
const struct cmd_type cmd_table[] = {
-----------

While doing this is VERY time consuming, I really don't recommend this until
You pretty much have your mud up, running, open to the public, etc. and
don't have much of anything else to do, but it WILL make your files smaller.
And by making your C, and H files smaller, and you will have more storage space
to add more things, as well as have code that's in my opinion easier to find,
read, and change. It just looks purty okay?
I mean, of course you could have "DF(do_advance);"
and so on, but this would make your code brackets ALL over the place.
 Because "DF_do_holylight" is longer, so your brackets wouldn't be lined up
at all. This may not matter to you, but I've found it makes your code look
pretty organized to have a "standard" lineup for things. There are just a lot
of tabs and spaces in ROM code that aren't truly necessary.
That's enough of today's lesson. Enjoy, and hope the snippet above
makes things a little easier for people. ^_^
If you have any problems with it, feel free to logon to my MUD (i may or may not
be on), or just shoot me an e-mail.