Possible infinite cross-reference loop

ID:2012626
 
Jan 5 2016, 2:11 am
(See the best response by Ter13.)
 
mob/proc/CheckInjured()
    usr << "You check yourself for injures."
    sleep(10)
    var/mob/M = new/mob
        usr << M.health  //<== Here it is.


I tried to practice some variable stuff, but byond keeps saying about "possible infinite cross-reference loop", when i use references. What am i doing wrong now?

Jan 5 2016, 2:56 am
Best response
As a rule of thumb, you shouldn't use usr in procs.

Give this a read. It'll help you understand a bit more about procs, verbs, usr, and src: http://www.byond.com/forum/?post=2003116#comment17822051

As for a quick fix:

mob/proc/CheckInjured()
    src << "You check yourself for injuries..."
    sleep(10)
    src << health
Jan 5 2016, 6:22 am (Edited on Jan 5 2016, 6:29 am)
In response to Ter13
But now it says "Undefined var"

Nevermind, figured it.
Jan 5 2016, 11:30 am
By the way! Another stupid question.

I have a verb, which locates turf under src and prints it, i wanted to print also turf's var, but if i set "Condition" in turf - it says "duplicate definition", and if i just use "M.condition" - it says undefined var.


turf/floor
    icon = 'floor.dmi'
    var/condition = 1
turf/water
    icon = 'water.dmi'
    var/condition = 0


and here the checking proc:

obj/machines/Extractor/attack()
    var/turf/M = locate(src.x, src.y, src.z)
    usr << "Extractor placed on [M]"
    if (M.condition == 0)
        usr << "Extractor succed."
    else
        usr << "Exctractor fail."
Jan 5 2016, 11:57 am
The var definition for condition should go under turf; the places where you're changing that var should not have the var keyword.

And unless attack() is a verb, no put usr in proc. Ungh.
Jan 5 2016, 11:57 am
That's because condition is not defined under /turf. It is defined under a subtype of turf.

/turf/floor is a descendant of /turf. It will have all of the properties of /turf and more.

Given your extractor code there, I'm going to assume that all turfs require a condition variable. That means that it needs to be declared under /turf:

turf
    var/condition = 0 //this is a variable declaration.


This declaration also assigns the variable to the default value of 0. /turf/floor, on the other hand, needs to have a condition value of 1, so when we subclass /turf to create /turf/floor, we will override the value of condition.

turf
    var/condition = 0 //this is a variable declaration.
    floor
        icon = 'floor.dmi'
        condition = 1  //this is the variable override


This is a concept called polymorphic inheritance. since /turf/floor is a child (subtype) of /turf, it inherits all of the members (variables, procs, and verbs) of its parent class. But polymorphism comes into play after inheritance has done its work. Polymorphism allows you to create new behavior in the members of the child by either adding new members or changing old ones.

Since /turf/water keeps the default value of /turf's condition member, we can simply define it only specifying the new change:

turf
    var/condition = 0 //this is a variable declaration.
    floor
        icon = 'floor.dmi'
        condition = 1 //this is the variable override
    water
        icon = 'water.dmi'


Now, we can take this a step further. Since /turf/floor's condition member has been given a value of 1, if we create a child class of that, any subsequent child classes will default to a condition of 1. This is inheritance at work.

As for your example here, there's a shorthand:

obj/machines/Extractor/attack()
    if(!isturf(loc)) return
    var/turf/t = loc
    usr << "Extractor placed on [t]"
    if (t.condition == 0)
        usr << "Extractor succed."
    else
        usr << "Exctractor fail."


You don't have to use locate, because presumably the object is in a turf already. If it's not on a turf, the extractor probably shouldn't work.