This is my train of thought, I don't know if it would be beneficial to your or not. But you've figured out you can grep to find where the message is, right?

That's a good first step. Now that you know -where- in the code that message is being presented, now you just need to take a look at everything else around it. Copy/paste the function in and let's see if we can't help nudge you toward your next step on figuring out how that works.

Grep always confused me so I did what I had learned to help me in other parts, I backed up my mud to my computer and used my computers search features. Hasn't failed me yet.

That's actually what I do too. I code on my hard-drive in EditPlus, then upload my changes and compile. I find that to be a lot easier.

Grep is handy in that you get the exact line of the file, but a search within a text editor can find things easily and quickly enough.

Yeah I use boxer text editor for my editing, I find it to be easy and its functions work perfectly for me in anything I need to use it for. Never heard of EditPlus, I will be looking into that…

I like EditPlus for a number of reasons, particular the syntax highlighting and everything. It makes reading code quite a bit easier when you have color output helping denote certain things you might need to check for.

Like if in a sprintf or send_to_char, you forget a " then you'll notice quite quickly because most of the text on the page will be pink, or if you forget to close out a comment, that'll be obvious because most of the page will be green.

I use Visual Studio for the same reason. Oh. And because IntelliSense will give me options for class members or member functions based on the letters I type after the . or ->

Like Kayle i prefer a full blown IDE, in linux i use Kdevelop or Netbeans and in windows Netbeans or Eclipse. The benefit of using a full blown IDE is that you get syntax highlighting, block collapsing, brace matching, source formatting, integrated grep searches with 1 click to open to that line, and a whole lot more other things that using them worth while to me.

That means that you're trying to go too fast. Books will never teach you how to solve specific problems in a MUD, however, you will learn about the various building blocks that you can later assemble yourself to solve whatever problem you are facing. Reading a foreign language textbook will not teach you how to write a specific novel, but it will teach you how to write the sentences to write that novel, if that makes any sense.


I think you're being a little hard on yourself, just go with the flow, keep an open mind, try to be patient and don't think you will succeed very quickly because this takes time for everybody.

And to MB admins: pls to fix forum formatting? Kthxbai :tongue:

Read this, all your questions will be answered.

Oh, and my IDE is screen, using vim and ctags, with a side helping of grep, awk, and perl. :)

Now that was just funny, especially the part about one OS crashing the other lol

Here's how I use grep whether it's correct or not.

If you were looking for A magical force prevents you from attacking then I would use the following in the src folder:

grep 'A magical force prevents you from attacking' *.c -ni

So the command is basically:

grep ' your text here ' *.c means that you want to search in all the .c files and -ni means that you are going to return the number line and it is going to be case insensitive.

* is a wildcard. If you wanted to search in all the files in the folder then you could just use the * without the .c at the end. If you just wanted to look in mud.h then you would do:

grep 'your text' mud.h -ni

Hope that helps.

Just to expand on tphegley's suggestions, to grep through a whole directory hierarchy, GNU grep supports the -R flag for recursion. If your grep doesn't you can also do something like:



That's assuming you don't use spaces in your filenames… you don't, do you? Every time someone uses a space in a filename, a windows machine somewhere on the planet crashes.

Nope I never use spaces on filenames.