ScriptThis() versus object ID

#1 I don't understand your question.

The object handles in the editor are the server ID's.

The ID's for each object will be different for the client as they are ghosted.

So long story short, this may explain why you're seeing different ID's.

#2 Okay, thanks. So basically, how can I get scriptThis() to return server IDs? Do I have to do something to the client ID after I get it? Or do I have to usesomething other than scriptThis()?

#3 I'm still wrapping my head around this area of Torque however I believe you might want to take a look at the getGhostID() function.

I'm still not sure I fully understand your question though. What exactly is scriptThis()?

#4 Daniel - i think Tim has the right suggestion here.

ScriptThis() is just a convenience function around doing a Con::getReturnBuffer() and sPrinting the object's ID into it:

const char* SceneObject::scriptThis()
{
   return Con::getIntArg(getId());
}

...

char *getIntArg(S32 arg)
{
   char *ret = STR.getArgBuffer(32);
   dSprintf(ret, 32, "%d", arg);
   return ret;
}

so if you're seeing a discrepancy between scriptThis() and the ID you're expecting,
it's likely because in one case you're dealing with a server-side object and in the other a client-side one.

Objects are instanciated on both the server and each client, even if you're running in single-executable, single-player mode, and the server instance and each client instance of the 'same' object will have different simIDs. This is definitely the most confusing thing to grasp in TGE networking, but there are many posts in the forums and hopefully in TDN describing it. Tim is also correct that the key to correlating server and client simIDs for the 'same' object is the getGhostID() family of functions.

#5 Okay, thanks everyone for the info! I did a little research, which got me to the point of understanding tht things have different IDs on server and client. However, looking for the documentation of things like getGhostID and resolveObjectFromGhostIndex didn't return very much (broken links in TDN, web filter blocking... grr...).

EDIT: In addition, can this be done without using a server command? Every implementation of this sort of stuff I've seen uses a server command to do something, and only calls the server command from the client. I have a somewhat different setup, I think:
-GUI element executes script callback, passing a server ID
-Function in client script calls function on LocalClientConnection's player's datablock
-When a key is pressed, client function (in default.bind) executes functions on the Player datablock depending on the Player object's member fields