runtime error T.T

ID:145950
 
Oct 26 2005, 7:05 am
Code:
proc
    hidez(obj/j in oview(1))
        if(usr.IT)
            return
        else
            if(j.hide) // Line 74
                usr.loc = locate(j.x,j.y,j.z)
                usr.hiding = 1
            else
                return
--------------------------------------------------
obj
    Hide
        icon_state = "Hide"
        screen_loc="1,1"
        Click()
            hidez()


Problem description:
runtime error: Cannot read null.hide
proc name: hidez (/proc/hidez)
source file: Game.dm,74
usr: Mysame (/mob)
src: null
call stack:
hidez(null)
Hide (/obj/Hide): Click(null)

Oct 26 2005, 7:08 am
Firstly, you're abusing usr.

Secondly, procs TAKE arguments. In that, you're trying to CREATE an argument.
Oct 26 2005, 7:10 am
In response to DeathAwaitsU
I always tend to abuse usr..
And the proc is because Click() can only call upon a proc, so I have to make everything in a proc-form
Oct 26 2005, 8:37 am
In response to Mysame
Mysame wrote:
I always tend to abuse usr..

Then learn to stop, so you won't have nearly as many code problems.

And the proc is because Click() can only call upon a proc, so I have to make everything in a proc-form

Click() can call verbs too, and that would actually be usr-safe.

Lummox JR
Oct 26 2005, 12:43 pm
In response to DeathAwaitsU
DeathAwaitsU wrote:
Firstly, you're abusing usr.


Actually, I barely consider that an option here.

From the code that he showed, usr isn't being abused at all. Sure, usr's in a proc, but hte proc is being called from Click(). The usr from click (the clicker) will be transferred to the proc, making it perfectly safe.
Oct 26 2005, 5:28 pm
In response to Shinichi Kudo
Shinichi Kudo wrote:
DeathAwaitsU wrote:
Firstly, you're abusing usr.


Actually, I barely consider that an option here.

From the code that he showed, usr isn't being abused at all. Sure, usr's in a proc, but hte proc is being called from Click(). The usr from click (the clicker) will be transferred to the proc, making it perfectly safe.

Calling that usr-safe is a bit dicey. Click() itself is usr-safe unless you're screwing with client/Click() in some unusual way or calling Click() directly, which most games won't do. So if Click() was calling a verb, I'd consider that kosher, just as if a verb called another verb.

However, Click() is calling a proc. Just like when a verb calls a proc, usr is still passed along, but once you cross the boundary from verb territory into proc territory, you're basically taking foolish chances if you still use usr. A proc should be a discrete unit, more or less independent, able to do whatever it needs with the data it's sent, the object it belongs to (src), or vars and procs belonging to same. A verb is allowed to make the assumption usr is valid, because it's supposed to be. A proc has no such luxury; it's not supposed to assume anything.

Lummox JR
Oct 26 2005, 6:48 pm
In response to Lummox JR
Er, well, the thing is; I can't use src.var in most of my procs.. Gives unidentified var.
And er... I also thought usr in procs that were called by Click() were safe...
Oct 27 2005, 8:16 am
In response to Mysame
Mysame wrote:
Er, well, the thing is; I can't use src.var in most of my procs.. Gives unidentified var.

Then you're doing something wrong there that needs to be addressed. Better to address it now and learn how to avoid the problem.

And er... I also thought usr in procs that were called by Click() were safe...

No, usr is only safe in verbs called by Click(). It's no safer in a proc called by Click() than one called by a verb, and that's an obvious no-no.

Either your proc is a verb or it isn't. If it's a verb, you should expect it's going to be called directly by players, or in an almost-direct fashion, all the time. It should be treated like a verb, just as if the player themselves typed it in. If you're not going to be treating it that way, and it's just a regular proc that happens to be related to some form of user action, then assume nothing about usr; just give the proc all the information it needs.

Lummox JR