Hmm… I get the feeling me and grep are going to be good buddies soon.

heh are you kidding? grep is EVERY mud coders best friend.

I don't like using grep on *.* because it often searches possible binary files (including obj files) like smaug.exe, shutdown.txt, etc.

but you're not likely to find any results in shutdown.txt and when you get results in the exe file it doesn't list every single occurance, just says that there are results in the binary file. and if you're like me and put all the .o files in an obj directory you don't get any results from those either. i do that because those files are never touched by me except to rm -rf *.o and they just clutter up the screen when you type dir (or ls whichever you prefer) so the *.* method works just fine for when you're looking for every instance of the search term in the code. especially useful for inexperienced coders or coders like me who have terrible memories. and if you're trying to add a skill that has similarities to another skill then you can just search for everywhere the similar skill is mentioned and add your new one in all those places. although now that i've typed all this out i realize that the [ch] is basically the same as grep do_score *.c *.h and everything i've just said is kinda a moot point when i think about it.

$ ctags *.c *.h
$ vi -t do_score

And bam, you're there. :cool:

Yes, grep is useful :)

Since I do all of my coding on my hdd in EditPlus, I have a /src folder locally and I'll just hit search and type in the box "a word or phrase in the file" for what function I'm looking for. Grep will narrow it down by line I believe and show you the line that your result is in, so it is a bit more accurate, but the less I'm in the shell, the better :p

You'll find that most of the files in stock ROM are named quite appropriately. act_info.c should include most of the information functions like score, worth, who, look, etc. While act_obj.c you'll find most of the object manipulation commands like brandish, quaff, get, drop, etc. As you get more familiar with ROM, you'll begin to be able to accurately guess which file you are looking for just based on the file names and the function. But yeah, getting familiar with grep isn't a bad thing at all. But again, if you decide to code locally like I do, the Windows search function isn't bad either.

Well, I do code it locally and upload it. And edit it. And upload it. And edit it. And upload it again. And… you get the idea :P

Hey, you may not know this either, but check out this post I made earlier. Some insight into how you can skip the edit/upload and upload straight from your text editor.

I already use editplus, hehe. It just feels like it takes forever sometimes, even though it's only 5 seconds.

Delayyyyed. Motherboard died on me.

I'm sorry to hear that, when is your motherboards funeral? Is your fatherboard taking it well? If you have a little brotherboard or sisterboard you might wanna take special care with them cause little ones sometimes hide their grief and then turn into serial killers later in life. :lol:

IT LIVES!

I can get back to work now :D

Just because I didn't see it noted up there anywhere….

| and || do similar, but not identical things.
& and && likewise, are not actually the same.

The single character versions are bitwise operators, they combine bits of integers, returning the result. 2 & 3 == 2. 2 & 0 == 0.
The doubled versions are logical operators, they evaluate true/false. 2 && 3 == true (and usually is 3). 2 && 0 == false (and usually 0).

The C language treats any 0 value as false, and any non-zero value as true.

The reason I mention it is that it can be very painful if you typo one of these….

Let's assume the function belly_is_not_full() will eat the food you pass in, and then return true if you're still hungry.

if (belly_is_not_full( chocolate ) && belly_is_not_full( peanut_butter ) )
  burp();

In this case, if the chocolate filled you up, you won't eat the peanut_butter since the first function returned false, and thus there's no need to continue the logical comparison… you know the whole AND expression has to be false.

if (belly_is_not_full( chocolate ) & belly_is_not_full( peanut_butter ) )
  burp();

But in this case, you're doing a bitwise comparison, which means you evaluate both sides anyways. So, you now go ahead and eat the peanut butter even though you were already full…. you still don't burp, but now you are overfull.

Better that they be serial killers, than parallel killers.

Usually in C, but not in C++, where the logical operators actually do evaluate to booleans.

$ cat test.cpp

#include <iostream>
#include <string>

int main(char ** argv, int argc)
{
    int i = 2 && 3;
    std::cout << i << std::endl;
}

$ g++ test.cpp
$ ./a.out
1

The type-theoretician in me has always been irritated that integers are or can be used as booleans. If you want to test if i is not zero, I think you should do so and write "i != 0". Well, fleh.

That's actually one of the things C# did right that C++ has to do wrong for legacy support. In C#, you have to say if ( x == NULL )…. the good old if( !x ) doesn't work.

I'd also like to have a real NULL, rather than using 0. The DBA in me really hates not knowing if something is 0 or NULL without having to check a totally seperate property.

Ok, something I've been meaning to ask. It's been awhile, so I'm a bit sketchy on the actual syntax…

But from quickmud's /area folder, doing startup… which is… er… something like ../st… ok I have no idea what it is anymore. But! I did have a problem where sometimes it wouldn't startup… other times when it would startup, then leave me with no prompt in the shell, and the sometimes it decides to run the mud nicely and give me back my command line. this is with the same command to boot up the mud… Any idea what I may have been doing wrong here?

Also, what's the friggin syntax so I'll have an answer when I wake up? If I have it written down and verified in a place I can check quickly, I think it'll stick to mind a lot faster.

From the area directory, type "nohup ./startup &"
If you use that syntax, you'll get your prompt back promptly and you wont have the game shutdown on you when you logout ;).

Thank ye :)

It makes sense in C, where there was not boolean type until C99, iirc. Plus C is really just syntactic sugar of assembler. Same as C++ is just syntactic sugar over C (except for exceptions).

I do agree that good code should explicitly state what it is doing. if (i) { .. } is a lot less clear than if (i != 0) { … }. My personal pet peeve is if (!strcmp(foo, bar)) { … }.