In response to Lummox JR
Ugh, guess you are right. Whenever you have a problem like this, test it.
mob
mob2
var/MyVar=1
verb
Test()
src:MyVar=1
src << "[src:MyVar]"

That's what I used, and it did return error. So every time I passed that line in my game, it just so happened that the mob had the var. Good job Lummox, althought you were a little hasty. ^_^

This topic is FINALLY over.

Something -> No usr -> mob/M -> .-vs-:

That's the direction this went, a little off center. Well, at least it is done. Goodbye. *snores*

System: Yota signs off at 2:27a EST
In response to Lummox JR
Lummox JR wrote:
Volte wrote:
M may be defined as /mob, and /mob does not have the var, whereas M may be /mob/mob2, and that DOES have the var. If "M:DmgDelt+=D" is executed, it will only take effect if the datum has that variable. If you would have used . then, you would get the "variable not defined" error, would you not?

You're right.

No he isn't

Sorry, I wasn't being as specific as I should have been. I meant he was right about the variable not defined part.

~>Volte
In response to Yota
I myself fall prey to 'lazy programming'. However, if you do not wish to define another variable within the proc and/or typecast it as /mob/mob2 then you must provide adequate error checking. If more than just the /mob/mob2 type can have the variable, then you should define it as either a /mob variable or a /atom variable. Re-defining a variable among child types is very inefficient, and leads to the problems you are facing now. I can't see how it would be better to do excessive error checking (or simply taking many possible errors) than to define the variable at a higher level and just not use it with all the sub-types.

It should be:
if(istype(M,/mob/mob2))
M:var
else
return


The problem lies here: you said that the proc can take ANY mob type. You have yet to fix the probable error that will happen if a mob of a type other than /mob/mob2 is passed to the procedure.

In more relation to your topic (usr in proc fued), I think you are misunderstanding what usr is. usr is the client that called the proc, if any. usr can be and often will be null, unless you garuntee that it will only be called by a client.

Yes, it can be done. You can run rough shod over your program and make sure that the proc is ONLY called by a client.

The point being made is that usr is generally NOT SAFE when used within a proc. If you must make use of usr, put it in a variable like var/mob/M = usr, and double check that !isnull(M). I would recommend having the proc pass the caller as an arugment. Ie:

proc/myproc(other_args,mob/caller)

and pass it whenever it's called like so:
mob/proc/call_myproc()
myproc(args,src)


To sum up (and I apologize for the length of this post): if you are going to keep things the way they are, you need error checking. There are more efficient, less error prone ways to do what you are doing.
In response to sapphiremagus
Actually, you nearly posted something I forgot about last night. Fatigue can really wear down the mind. As I was saying...
if("DmgDelt" in vars)
M:DmgDelt+=D

Not sure if I'm using "vars" right, but doing things like this, and having the variable in certain types, you would need : as not to get a compile error.

If that's not how to use "vars", is this?
for(var/V in vars) if(V=="DmgDelt") M:DmgDelt+=D
In response to Yota
I'm not sure if it would work they way you have it, but the idea is solid (I think). Besides, at least that way you have error checking :P
In response to Yota
vars is an associative list that looks like so:
vars = list("v1_name"=v1_val,"v2_name"=v2_val,"v3_name"=v3_val,...)


if("DmgDelt" in vars) works fine to check if the mob has a variable called that, although I don't see how thats useful in this case. The only reason I see for looping through vars like that (Not bearing specific needs in mind) here would be if you DIDN'T know what the variable was called, and all you knew was you had to set it to a specific value that you don't know either. Something like:
for(var/V in myList)
if(!(V in src.vars)) continue
src.vars["[V]"] = myList["[V]"]


That doesn't seem to be the case here, though. If all you want to do is make sure the mob has the variable, its very simple in most cases. If there's one specific datum type which has that variable, do an istype(whatever,/that/datum/type) before setting it.

I guess you could also check for it in vars, but I don't see the point since its more processor intensive to loop through the list than to use a built-in procedure to check datum type.

In response to Yota
Good job Lummox, althought you were a little hasty. ^_^

He was too hasty?

So.... we should wait a week or so to tell you if we spot a lurking error in your code that you're trying to pass onto others?

What exactly are you faulting Lummox for? Being hasty, as in, leaping to a conclusion or being quick to judge? He knew exactly what he was talking about... you're the one who made an assumption and stuck fast too it without checking it out (until now.) You wanna fault someone for undue haste, grab yourself a heaping handful of mirror.
In response to Hedgemistress
Hedgemistress wrote:
You wanna fault someone for undue haste, grab yourself a heaping handful of mirror.

*Grabs mirror.*

*Hits self over head with mirror.*

That didn't help...

*Steps on piece of glass.*

AHH!!!
Page: 1 2