ID:264664
 
Code:
         Bump(atom/M)
if(istype(M,/obj/Skills/Kamehameha/Head))
M.Struggling=1
src.Struggling=1
if(src.Owner.Ki>=M.Owner.Ki)
world<<"lol"


Problem description:

Skills\Kamehameha.dm:41:error: M.Struggling: undefined var
Skills\Kamehameha.dm:43:error: M.Owner.Ki: undefined var

How do i fix it? :/


Bump(atom/M)
if(istype(M,/obj/Skills/Kamehameha/Head))
var/obj/Skills/Kamehameha/Head/H = M
H.Struggling=1
src.Struggling=1
if(src.Owner.Ki>=H.Owner.Ki)
world<<"lol"
If you originally defined M as an atom (as in Bump(atom/M)) but want to use a variable that is only defined to one atom type (in this case a mob), first put in a check to make sure you are dealing with a mob (which you did).

After that, you can use a colon instead of a period when referencing variables that aren't directly defined for all atoms.

So the line
M.Struggling=1
would be
M:Struggling=1

This attempts to locate that variable on M. If you are accessing the wrong mob type, it would give you the error at runtime, but since you included

if(istype(M,/obj/Skills/Kamehameha/Head))

It should work okay. Do the same for M:Owner.
In response to Gunbuddy13
However, it's much better practice to just store it in a variable of the appropriate type, so the compiler can throw errors at you rather than having to hunt them at runtime, which is ALWAYS worse. So:

obj/Bump(atom/A)
if(istype(A, /mob))
var/mob/M = A
M.key = "BLAH" // whatever


The colon operator really isn't something you should ever be using except, perhaps, when dealing with types that do not actually exist (such as appearance objects).
In response to Garthor
I personally have always preferred to use the : operator. As long as you use if(istype(blablah)) to make sure you are accessing the proper atom, it shouldn't cause any problems. Defining a second atom of the right type just creates more variables to deal with and takes more code, neither of which I am a fan of.

For beginners though, I can see why it would help to do it the way you described.
In response to Gunbuddy13
"Shouldn't" cause any problems and "doesn't" cause any problems are two different things. The purpose of the . operator is that it checks whether the variable or procedure you are attempting to access even exists in that context. Using the : operator bypasses this.

Defining more variables to deal with is a silly argument because you are no longer using the first variable at all: var/mob/M has replaced var/atom/A. Complaining about it being "more code" is even sillier, as it's ONE LINE.

And no, this isn't "for beginners". This is "for everybody". It is a GOOD PRACTICE, not a "BUH BUH BUH I NO WUR IM DOIN SOZ I KAN IGNUR DIZ". That doesn't even make sense, but I don't care because it's just THAT DUMB.

Basically, your whole argument is equivalent to saying "Oh yeah while() is good 'for beginners' but I prefer to use goto". It's objectively wrong and you need to stop suggesting otherwise before I figure out a way to get people banned from How-To and Code Problems for providing bad advice.
In response to Garthor
Garthor wrote:
before I figure out a way to get people banned from How-To and Code Problems for providing bad advice.

It's not terribly hard, if they're amazingly bad. I believe it happened to Superbike32.

Twice.
In response to Popisfizzy
ok, Thanks and Lol