Beam proc

Page: 1 2
Dec 20 2006, 10:20 am (Edited on Dec 20 2006, 10:29 am)
In response to Avren
Avren wrote:
obj/portal
>     var/atom/target
>     New(loc,atom/target,duration=300)
>         .=..() //perform anything else you redefine later
>         if(target) src.target=target
>         if(duration) spawn(duration) del src
>     //TODO: use Bump() or something to have the portal teleport people
> 
> ...
> 
> new/obj/portal(src.loc,locate(5,5,3),500)
> new/obj/portal(locate(5,5,3),null,500)
>

--This code was by Android Data

Just curious from what Kaioken said about the new being passed on to New. Just to confirm, but does that work like this? :
New(loc,atom/target,duration=300)
> //Ok, starting with src.loc in the bottom code; src.loc. So in the upper code, loc is src.locate from the bottom code?
Yes (you mean "src.loc from the bottom",not locate)

> //and so fourth with all the arguments? That would mean the duration for the portal would be 500?

Yes. new() passes the arguments to New()
> //If that is true, how does atom/target work with "locate(5,5,3)"?

locate() is a proc. That proc returns the turf that is at the specified coordinates. Then, new() is called with that turf, and passes it to New().

> //And in this case, since no one said who src was in the bottom code, ...
Eh? You're just CREATING a new object, how can you specify what its gonna be? Obviously, in New(), src is the object created (as New() belongs to the object).

Pardon the answering in code tags. :P


The final question is, what is null... Oh, hehe, it just came to me.. You don't have anything to set for that! It would be good if you could confirm though.

Null means precisely - NOTHING. It's also a FALSE value (like 0 and "" - all 3 are different values). The fact he passed nothing to the proc, means it will be set in the proc to the default value specified. However, in his New() argument definiton, 'target' has no default value, so it will be set to 'null' in it, therefore the first if() check will fail. An example of a default value specified is in his 'duration' argument definition - if the duration isn't specified, it defaults to 300).
Look up 'null' in the reference. :P 
proc/My_Custom_Proc(atom/arg1,arg2="something",arg3=30,arg4)
...
//calling it:
My_Custom_Proc(variable) //arg2 and arg3 aren't specified, so they are their default values. arg4 is null because it has no default value

My_Custom_Proc(variable,null,null,50) //arg2 and arg3 aren't specified, so they are their default values. arg4 is specified and so it is passed to the proc
My_Custom_Proc(variable,,,50)//this is the same as the above line


//doing this line:
proc/My_Custom_Proc(atom/arg1,arg2="something",arg3=30,arg4)

//Is the same as doing:
proc/My_Custom_Proc(atom/arg1,arg2,arg3,arg4)
    if(!arg2) arg2 = "something"
    if(!arg3) arg3 = 30
Dec 20 2006, 10:29 am (Edited on Dec 20 2006, 10:39 am)
In response to Kaioken
Ok, it all came together, your demo started becoming more clear near the end. I only have one; no, two final questions. 1: 
"[src.icon_state]head"
That code I find... Rather confusing. That's the question in itself. 2: .=..() That's all fine and dandy, something to do with only excecuting in in objs of the sort. Any way you can explain it in baby words? ;)




EDIT: In reply to the same post, but the part I missed (the code at the very bottom), That all makes sence now, but when you showed an example of passing them to the proc, there was one part I didn't understand: 
proc/My_Custom_Proc(atom/arg1,arg2="something",arg3=30,arg4)
...
//calling it:
My_Custom_Proc(variable)
) Ok, the question is, atom/arg1 is defined as "variable". Since when is variable one of the four object types?
Dec 20 2006, 10:36 am (Edited on Dec 20 2006, 10:41 am)
In response to Avren
Avren wrote:
Ok, it all came together, your demo started becoming more clear near the end. I only have one; no, two final questions. 1:
"[src.icon_state]head"


Why is that confusing? A regular embedded text expression. That line is the same as 
src.icon_state+"head"

(I need to check which method takes less CPU proccessing sometime :))
For example, if src.icon_state is "ka_", that line equals "ka_head".

2: .=..() That's all fine and dandy, something to do with only excecuting in in objs of the sort. Any way you can explain it in baby words? ;)

OK. That's frequently used (for a reason). First, look up the '.' var, and the '..()' proc. Understand them both.
What we are doing, is calling the parent proc (or the built-in proc behaviour), and storing what it returned to the '.' var. The '.' var is automatically returned by procs if they reach the end without a 'return' statement, or they use a 'return' statement with nothing after it.
In that case, I am specifically checking the return value (stored to '.') to see if movement was allowed - however, even if you aren't, that code expression is good practice when overriding procedures. If the proc that called Move() checks it's return value, and we don't return the right one, it will cause problems. That way we still return the correct return value, as if we never overriden the proc.
'.' can generally be used for anything untypecasted, but it's the return value var, and should be used for that.
Again, if you have a 'return' with nothing after it, the value of '.' is returned. Also, in the end of EVERY proc/proc overridation, there is this "invisible line": 
return .


Generally, if you're unsure if you should use the expression or not, using it causes no harm. So anywhere in your code you have 
..()

If you're unsure whether you want to preserve the return value or not, it usually wont do harm, replace it with 
. = ..()


Also, note that having . = ..() in the very end of a proc should be replaced with return ..().
Of course, both work.
Dec 20 2006, 10:46 am
In response to Kaioken
Kaioken wrote:
OK. That's frequently used (for a reason). First, look up the '.' var, and the '..()' proc. Understand them both.
What we are doing, is calling the parent proc (or the built-in proc behaviour), and storing what it returned to the '.' var. The '.' var is automatically returned by procs if they reach the end without a 'return' statement, or they use a 'return' statement with nothing after it.
In that case, I am specifically checking the return value (stored to '.') to see if movement was allowed - however, even if you aren't, that code expression is good practice when overriding procedures. If the proc that called Move() checks it's return value, and we don't return the right one, it will cause problems. That way we still return the correct return value, as if we never overriden the proc.
'.' can generally be used for anything untypecasted, but it's the return value var, and should be used for that.
Again, if you have a 'return' with nothing after it, the value of '.' is returned. Also, in the end of EVERY proc/proc overridation, there is this "invisible line":
return .

Ok, so if you did 
return .
if you check . = ..() in another proc and you go: if(.) usr<<"YAY", you would get that message?
Dec 20 2006, 10:52 am
In response to Avren
Do you grasp the concept of returning values? Look up the 'return' statement.

Avren wrote:
Ok, so if you did
return .
if you check . = ..() in another proc and you go: if(.) usr<<"YAY", you would get that message?

Yes, if . was a true value. To make your example always work, change the beginning to 
return 1
Dec 20 2006, 12:14 pm
In response to Kaioken
Kaioken wrote:
//calling it:
My_Custom_Proc(variable) //arg2 and arg3 aren't specified, so they are their default values. arg4 is null because it has no default value

My_Custom_Proc(variable,null,null,50) //arg2 and arg3 aren't specified, so they are their default values. arg4 is specified and so it is passed to the proc
My_Custom_Proc(variable,,,50)//this is the same as the above line

Also, I'd just like to add that you don't have to set every argument to its default value when inputting information. Say you have 30 arguments but, you only want to change three of those arguments without having to keep track of each & every argument & their order just simply use the arguments name directly.

EX:
My_Custom_Proc(variable,,,50)
//Can also be set like this >>
My_Custom_Proc(arg4=50)
Dec 20 2006, 12:36 pm
In response to Teh Governator
Yeah, that is using 'named arguments' (*sings* look look.. look it up in the..the reference! :D).

They're convienent, but using mixed non-named and named arguments can be very confusing and cause issues.
Also, using named arguments slightly slows the code more than positional ones.
Page: 1 2