Undefined proc problem with .src

ID:2050611
 
Mar 10 2016, 5:38 pm
(See the best response by Konlet.)
Proc:
/obj/item/device/shop/hidden/proc/trigger(mob/user)
    if(!active)
        toggle()
    interact(user)

Proc with src
/obj/item/proc/active_shop_check(mob/user as mob)

    if(src.hidden_shop)
        if(src.hidden_shop.active)
            src.hidden_shop.trigger(user)
            return 1
    return 0

Problem description:
There is a undefined proc on the line "src.hidden_shop.trigger(user)", and i dont know what it is

Obs: yes, there is a proc for the hidden_shop

Mar 10 2016, 5:47 pm
Best response
Well, you need to assure src.hidden_shop exists and that it has the trigger() proc defined..

obj/item/var/tmp/example/hidden_shop

example
  parent_type = /obj
  proc/trigger(mob/user)
Mar 10 2016, 6:49 pm
To elaborate a bit on what Konlet said, you need to make sure to properly type-cast the variable in question. Type-casting means telling the compiler what procs and variables to look up using the . operator.

obj
    someobj
        proc
           Hello(mob/user)
               user << "[src] says hello!"

mob
    var/obj/someobj/myobj = new() // The "myobj" variable is casted to the /obj/someobj type.
    verb/Stuff()
        if(myobj) myobj.Hello(usr)


HOWEVER, this is simply a compile-time thing, at runtime, the variable doesn't actually have to be /obj/someobj, it can be set to anything. If you try to access variables or functions that don't belong to the reference you'll get a runtime error. This is where things like istype() come into play for double-checking if things are what they should be.

Mar 10 2016, 6:52 pm
To add, at compile-time you can use the ":" operator to bypass the type checks and access things without type-casting the variable, the runtime check still exists and will error out the same if you do something wrong. The : operator is generally reserved for experienced programmers who do things in a way where they know for sure it's not going to cause a problem; after an istype() for instance, but don't want to take the extra step in defining a new variable of the type they just checked.

For the most part it's a good idea to avoid the : operator just to keep both the compile-time and runtime checks in tact so things don't go awry in weird ways.