In response to Robertbanks2
I see. Honestly I forgot all about giving my NPC's weps and skills all they do right now is pummel me into a pulp lol
In response to Wrath69
Arguments are what go in the () at the end of procedures. Think of this like mathematics.

sin(x)

When you code procedures, you are coding the equivalent of a mathematical function. The argument of the sine function in my example is x. Sooooo... you can define your own proc to be something like this.

mob
proc
CheckAwesome(mob/M) // M is a defined argument that should be a mob
if(M.Awesome = 1) // Do the conditionals
M << "You are awesome"
else
M << "You suck"

You can go further and further in the argument definition by adding commas

mob
proc
ProcDefinition(Arg1,Arg2)
In response to Robertbanks2
Robertbanks2:

1) If I use the whip, then it is scheduled for deletion, I can keep using it(which is fine, if you wanted it that way), however it will keep getting scheduled and then you'll get some runtime errors.

2) proc/DeleteWhip(var/mob/M,var/obj/whip/W,var/timer), the var/ infront of each argument is not necessary.

3) What happens if I drop the whip after using it, say, 5 times? Then it doesn't disappear and I pick it back up and continue lashing away!

4) Why is DeleteWhip() a global procedure? It can easily be defined within obj/whip itself and then called, and then you don't need to worry about passing through the user or the whip itself, only the time until it is deleted.

5) Why not just have the monsters call use() on the whip instead of having separate code to do that?

Lugia:

The last example you posted should have == instead of =. You can also do this:

if(something) // same as if(something == 1) / if(something == TRUE) / etc.

In response to ANiChowy
In response to 1-5, the code that I posted was meant to show him how to use arguments, not to provide a functional code snippet that handled his issue, I probably should have labeled things differently and stated that more clearly than I did.
In response to Robertbanks2
Lugia319 wrote:
Well Robertbanks2 has laid down the law lolz. I always assumed usr is okay as long as there will always be a user. I guess I'll just ask a quick question here.

Is there a general practice rule of "too many args" in a proc definition? I know that a few built in procs can have 6+ args. What does one do to handle such a situation?

You'd use the argslist to pass on however many arguments you want without having to explicitly define them.

For example, an excerpt from my deck demo:
        add_card_multi() //adds multiple cards, note the lack of arguments?
for(var/list/cardlist in args) args += cardlist
for(var/card/card in args) // args list takes care of this, each argument is another list entry
//mostly so people can call this proc like this: add_card_multi(a, b, c, d) and expect them all to get added
cards += card
Page: 1 2