ID:272244
 
mob
proc //eh, lets make it a proc.
gold_check(obj/O) //defining an obj, as thats what you'd buy
if(usr.gold <= O.value) //this i have a question about. it's SUPPOSED to be (in english) "if your gold is LESS then the object's value, i wont let you buy it", its to prevent negative gold.
alert("Uhm, you dont have enough money for this...") //haha, keep trying~!
return //it may not be needed, but can it hurt?


for something?
Firstly, no use usr in proc. Ungh.

That's saying if it's less than or equal. Since you prolly want to allow players to buy something if they have exactly enough money for it, you'll probably want to change it to this:
mob
proc //eh, lets make it a proc.
gold_check(obj/O) //defining an obj, as thats what you'd buy
if(src.gold < O.value) //this i have a question about. it's SUPPOSED to be (in english) "if your gold is LESS then the object's value, i wont let you buy it", its to prevent negative gold.
alert("Uhm, you dont have enough money for this...") //haha, keep trying~!
return //it may not be needed, but can it hurt?
In response to Hazman
The alert() is still using usr as the default argument, so it should be alert(src, "blah").

Anyway: return alone won't do anything. You need to return a value. In this case, it just needs to be TRUE or FALSE, to indicate whether you do or don't have enough gold to buy O. So, you'd do this:

if(gold < value)
return FALSE
return TRUE


and, to use it:

if(gold_check(O))
//bought successfully
usr.gold -= O.value
O.Move(usr)
In response to Garthor
Isn't the default return value 0?
In response to Darkmag1c1an11
The default return value is null (. = null, by default, and . is the default return value).
In response to Darkmag1c1an11
No, it is null, (look up the '.' variable) which is also a false value, so it indeed would do, Garthor wasn't too accurate on the "return alone won't do anything" part. You could say returning 0 is more robust/consistent, but null also does the job as a false value, and it is generally a value code should account for anyway and it is also sometimes returned by some built-in functions, so there isn't any problem with using it instead.
In response to Kaioken
Kaioken wrote:
Garthor wasn't too accurate on the "return alone won't do anything" part.

Wrong. These two are equivalent:

proc/thing1()
if(gold < 10)

proc/thing2()
if(gold < 10)
return


Namely: neither of them does anything useful. A null return value is meaningless unless if there's a possibility for a non-null return value.
In response to Garthor
Garthor wrote:
Kaioken wrote:
Garthor wasn't too accurate on the "return alone won't do anything" part.

Wrong. These two are equivalent<font color=red>*</font>:

That's quite irrelevant, though it is why I called you inaccurate rather than wrong here. Saying "return alone won't do anything" is only right in this context, therefore inaccurate, because it can lead people to believe it actually doesn't do anything and lead to confusion, which is probably evidenced in [link] which was likely a direct reply to that statement. So your sentence, taken literally, could easily be incorrectly interpreted as these being equivalent:
proc
thing()
return //<-- "return alone"
world << "hi"

thing2()
world << "hi"

//of course, in the former, nothing would be output


<small><font color=red>*: They're not totally equivalent because the former wouldn't compile =P</small></font>
In response to Kaioken
Well gee, I guess I'm a fool for assuming that when I make a reply to a post, people would take it as a reply to a post, and any information contained within said reply would be specifically referring to whatever information was contained within the post I was replying to.

And both of my examples would compile. The first one would just generate a warning.