Way to test for valid client?
by Lee Latham · in Torque Game Engine · 03/24/2008 (5:05 pm) · 8 replies
I've done a bunch of searching to no avail--but I'm badly in need of a way to test whether or not an object is a valid client.
For example, if I test to see if the classname is GameConnection, if it's not a valid client I get an error saying that it can't find the function "getClassName" on the object, because it does not exist. So I know, personally, that it isn't valid, but my scripts just keep on going because as far as it knows, that was just a failed function call.
I had noticed that %client.armor is set to "Light" all the time, but at some mysterious point sometimes that gets stripped off, or even changed to "Player". I realize I should find that problem...and I sure have been trying, to no avail.
So it would still be nice to be able to do some sort of test that the scripts can actually do something with, and reliably. Any input would be greatly appreciated!
For example, if I test to see if the classname is GameConnection, if it's not a valid client I get an error saying that it can't find the function "getClassName" on the object, because it does not exist. So I know, personally, that it isn't valid, but my scripts just keep on going because as far as it knows, that was just a failed function call.
I had noticed that %client.armor is set to "Light" all the time, but at some mysterious point sometimes that gets stripped off, or even changed to "Player". I realize I should find that problem...and I sure have been trying, to no avail.
So it would still be nice to be able to do some sort of test that the scripts can actually do something with, and reliably. Any input would be greatly appreciated!
#2
There are three basic ways to have a reference to an object:
--you've stored the reference yourself, such as when a player avatar stores a reference to it's controlling client in %player.client.
--you are in a callback handler or script method, and %this is passed to you.
--you are iterating over a SimSet/SimGroup that contains objects (such as ClientGroup). Normally, these groups are set up to be one type of object, especially when dealing with GameConnection objects.
Otherwise, you're probably doing something rather unusual--if so, you may want to explain and we might be able to point out an alternate solution.
If you are just trying to confirm that a reference is still valid, then isObject(%id) is a great recommendation.
03/24/2008 (5:50 pm)
I'm wondering when you would be in a position to not "know" what class a particular object reference already is in TorqueScript...There are three basic ways to have a reference to an object:
--you've stored the reference yourself, such as when a player avatar stores a reference to it's controlling client in %player.client.
--you are in a callback handler or script method, and %this is passed to you.
--you are iterating over a SimSet/SimGroup that contains objects (such as ClientGroup). Normally, these groups are set up to be one type of object, especially when dealing with GameConnection objects.
Otherwise, you're probably doing something rather unusual--if so, you may want to explain and we might be able to point out an alternate solution.
If you are just trying to confirm that a reference is still valid, then isObject(%id) is a great recommendation.
#3
@Stephen: You are doubtless quite right in your implication that I screwed something up. In fact, I am quite certain...I'm just stumped finding it. Seems like certain playing styles cause something to happen at some point that whacks %client.armor. Naturally, it doesn't happen to me so I can't duplicate it at will.
But thanks for the refresher in any case, as I hadn't considered that it could be one of the places where I do do some iterating through SimGroups, and that might well be where the problem lies.
I've done lots of searching through files with Torsion and stuff, which would not yield what I want to find if that is the case! Thanks!
03/24/2008 (6:13 pm)
@Orion: Dude! So simple, thanks, I suspect that is just what I need!@Stephen: You are doubtless quite right in your implication that I screwed something up. In fact, I am quite certain...I'm just stumped finding it. Seems like certain playing styles cause something to happen at some point that whacks %client.armor. Naturally, it doesn't happen to me so I can't duplicate it at will.
But thanks for the refresher in any case, as I hadn't considered that it could be one of the places where I do do some iterating through SimGroups, and that might well be where the problem lies.
I've done lots of searching through files with Torsion and stuff, which would not yield what I want to find if that is the case! Thanks!
#4
Also, might want to do the same type of search for wherever you are getting the value of %client itself populated, and finally just set a breakpoint or two and check the callstack to see what code has been recently executed prior to the value not being what you expect.
03/24/2008 (6:18 pm)
One suggestion would be to use Torsion's "find in files" and search for .armor and see if any lines are doing things they shouldn't.Also, might want to do the same type of search for wherever you are getting the value of %client itself populated, and finally just set a breakpoint or two and check the callstack to see what code has been recently executed prior to the value not being what you expect.
#5
So I think you might be on to something.
03/24/2008 (6:25 pm)
Yeah, i did quite a lot of that to no avail. It appeared that it didn't happen anywhere--which I knew not to be true. That's why I was interested in what you said about iterating Simgroups, because it could make a change to that value, potentially, by creating a client without the value. Thus, searching for "armor" would not find that--as it didn't.So I think you might be on to something.
#6
stephen is right of course, tho.
if you have a variable which should be of type X and isn't (or worse, isn't an object), then you should probably try to ferret out the root of the issue instead of applying a band-aid.
03/24/2008 (10:05 pm)
Glad isObject() can help.stephen is right of course, tho.
if you have a variable which should be of type X and isn't (or worse, isn't an object), then you should probably try to ferret out the root of the issue instead of applying a band-aid.
#7
But I'll take the bandaid in the meantime!
Keeping fingers crossed :-)
P.S. I kinda feel like it will fix like 95% of the problem, but the remainder of the issue will now point more closely to the actual problem as it manifests itself in new and exciting ways.
03/25/2008 (2:29 am)
Agreed.But I'll take the bandaid in the meantime!
Keeping fingers crossed :-)
P.S. I kinda feel like it will fix like 95% of the problem, but the remainder of the issue will now point more closely to the actual problem as it manifests itself in new and exciting ways.
#8
www.garagegames.com/mg/forums/result.thread.php?qt=73594
03/27/2008 (6:40 pm)
You may be amused to know that implementing this had exactly zero effect on my problem. Even I'm amused, and I'm very frustrated. I was chasing red herring for quite a long time. If you're interested, I've posted about it specifically here:www.garagegames.com/mg/forums/result.thread.php?qt=73594
Associate Orion Elenzil
Real Life Plus
testing on classname is probably fine,
but if you're interested in defending against the case where someone subclasses GameConnection,
you might be interested in the i-admit-not-very-elegant-but-not-so-bad-either-and-fairly-performant method i outline here.