Typing variables

#1 I beleive what your are referring to is when you create a function like:

myFunction(%this, %obj, %col){}

The %this param returns the ID of whatever called the function. That said, it could very well look like:

myFunction(%data, %obj, %col){}

and %data would return the ID of whatever called the function. TorqueScript just uses the 1st param to return the ID. So if the player object called your function then %this would be the player objects ID. Something like that... :)


edit: i just realized thats not what your asking... i just woke up sorry. I have no idea if torsion can figure out what called your function but that would make things easier.

#2 @mb: I believe hes interested in accessing/seeing member functions/params inside Torsion.

@Brian:
if you want to see properties - Torsion shows only for the "this" parameter:

function Player::myCustomFunction(%this, %anotherPlayer)
{
   // %this - the player object on which the function called
   // thus this is the only actual "object" Torsion aware of.

   // %anotherPlayer - just a parameter, Torsion does not know
   // if that is another player or whatever, even bool var.
}

So, if you want to see members/functions to the "player" object in Torsion - it's possible only in methods-functions and only for the "%this" parameter.
If you are using something like:

function GameConnection::testFunc(%this, %player)
{
   // %this = %client, the client connection
   // we assume that %player is "PlayerObject", 
   // but Tosion fails on displaying properties, as variable name 
   // can be whatever you make it - it does not show/tell the object type.
}

Hope this helps understanding :)

Edit: adjusted code to remove scrolling :)

#3 I already know all of this..

I just want to know if Torsion implements one of the features of CodeWeaver.

And that is you can use a metatag (a comment containing XML in the case of CodeWeaver) to tell it what type ANY variable is.

Thus (this is an example only, I don't know the proper syntax for CodeWeaver):

function myFunction(%myPlayer, %myConnection)
{
   // <varType name="%myPlayer" type="Player"/>
   // <varType name="%myConnection" type="GameConnection"/>
}

This should be pretty easy to implement but I think I remember something about Torsion's feature list being frozen?

#4 I've discussed this point several times regarding Torsion and as far as I am concerned it's the only really bad thing about it.

I understand why this is not implemented, and it really saddens me because it's what separates Torsion being a good tool from being the ultimate Torquescripting tool.

#5 I am almost positive Tom has said this is on the slate of possible things to add to Torsion 2

AFAIK Tom is working on wrapping up the release of Torsion 1.1 and then working on a feature list for Torsion 2

#6 Sweet, I hope that this does get added in. As Ricardo points out this would make Torsion the ultimate scripting tool.

It would be nice if Torsion had a built in interpreter too but thats a different topic altogether.

#7 Hey guys.

Actually on my wish list for a Torsion 1.2 (this is the release that includes the Mac port) is improving the ScriptSense to make a few logical assumptions. Like if you do this...

function someFunction()
{
   %player = new Player();

   // blah

... every other mention of %player within, and ONLY WITHIN, someFunction() will be considered to be a Player object.

Further in situations like this...

function someFunction()
{
   %player = new Player();
   return %player;
}

%player = someFunction();

... we can keep track of the return type in many cases. Of course this breaks as soon as your function returns multiple types.

Finally cases like this...

new GuiControl(DebuggerGui) {
profile = "GuiWindowProfile";
};

... we can make the reasonable assumption that your not changing 'DebuggerGui.profile' from a GuiProfile type.

This all takes a little more work parsing the script and will expand the size of the ScriptSense database, but it would help in many cases without the need for a bunch of superfluous and error prone comments.

#8 Fantastic news Tom, I've been praying for this and I'm agnostic! :)

#9 But that really doesn't help when your variables aren't newed.

Think about it.. The most common script function is the callback:

function Player::OnCollision(%datablock, %player, %colObj)
{
     // sure so it knows %datablock is a player datablock (maybe)
     // and hopefully it knows %player is a player
     // but how is it gonna even guess %colObj is a ShapeBase or anything else?
}

#10 @Brian - I never said it would fix everything... it indeed wouldn't fix any engine to script callbacks.

My hope is to fix this via the exports generation process. Currently ToqueScript callbacks are completely haphazard. You just Con::execute() it when you feel like it and there is no way to know the callback even exists unless you search the C++.

I'd like to see something like this...

ConsoleCallbackMethod(PlayerData, void, 5, 5, "(Player player, ShapeBase shapeBase)");

... this documents (imagine that) the callback in a way that we can then dump for Torsion and/or other tools to find. I then can display it in the browser as well as know what the members are for ScriptSense. Of course this is a much bigger task to accomplish, but its something i've thinking about for a while.

Still... of course this doesn't fix everything...

function PlayerData::OnCollision(%datablock, %player, %colObj)
{
   // i may know %player and %colObj here!
   %datablock.handleCol(%player,%colObj);
}
 
function PlayerData::handleCol(%datablock, %player, %colObj)
{
   // but knowing them here is much much harder!
}

... but i'm thinking about it.

#11 I like your ideas Tom. Documenting the callbacks would be wonderful. But what about programmatic callbacks?

I have a targeting class that calls a different callback method on the AIPlayer based on it's name.

So if my target is named "Attack" then AIPlayer::onAttackTargetEnterLOS is called. If the target name is "Follow" then AIPlayer::onFollowTargetEnterLOS is called.

Requiring a ConsoleCallbackMethod macro as the current console methods are done would make this very hard.

I would love to be able to use ConsoleCallbackMethod but I would still like an EASY way to register my own callbacks.

Something simple like:

Con::registerScriptCallback(method*, callbackName, description);

Still this doesn't fix most of the script typing issues. Regardless of how much you implement on the intelli-sense side could you please provide a stupid-sense fall back for me. What if I want to change the type of my variable?

Example:

// This callback was exported as:  void MyObject::MyCallback(MyObject, ShapeBase)
function MyObject::MyCallback(%this, %object)
{
    //I'm doing this 'if' from memory it might be wrong...
    if (%player.getType() & $TypeMasks::PlayerObjectType)
    {
        // object is expected to be a ShapeBase but I know for a fact that it is a player and I 
        // want intellisense to think so too.
        %player = %object;
    }
}

Suggestions:

[b]// Type suggestions, add types into the script but TorqueScript ignores them[/b]
    Player %player = %object;    [b]// This works as if the word 'Player' wasn't there[/b]

[b]//  or how about a proxy object...[/b]
    %player = new ObjectProxy(Player, %object);    [b]// TS will see this call as: %player = %object[/b]

[b]// or a typecasting keyword..[/b]
    %player = Player(%object);   [b]// function style type cast based on type names[/b]
  // or
    %player = %object as Player;  [b]// declarative type casting[/b]

[b]// or typecasting as a method of the object itself[/b]
    %player = %object;
    %player.setScriptType(Player);

[b]// or typecasting as a global method[/b]
    setScriptType(%player, Player);

With all of these methods you can properly pull out the required information for any variable. The last two suggestions would probably be easiest to implement all around.

Please forgive all the bold print above. Its hard for me to read without it.

#12 @Brain - I think your first example is valid, but there are simple workarounds. In C++ you would have...

ConsoleCallbackMethod( AIPlayer, void, 3, onTargetEnterLOS, "(string targetName)" );
 
void AIPlayer::processTick()
{
   // fire off the callbacks.
   onTargetEnterLOS( "attack" );
   onTargetEnterLOS( "follow" );
}

If you want callbacks whose name and signature change at runtime, then your sort of stuck without automatic ScriptSense in that case. Its just a design decision on the coders part.

Quote:What if I want to change the type of my variable?

That's a reasonable point.

TorqueScript is very loose with variables and they can change type... which is exactly why good ScriptSense is hard to implement. Still i'm sort of convinced that changing a vars type, while useful in some cases, is a good thing to do often.

Your next example...

// This callback was exported as:  void MyObject::MyCallback(MyObject, ShapeBase)
function MyObject::MyCallback(%this, %object)
{
    //I'm doing this 'if' from memory it might be wrong...
    if (%player.getType() & $TypeMasks::PlayerObjectType)
    {
        // object is expected to be a ShapeBase but I know for a 
        // fact that it is a player and I want intellisense to think so too.
        %player = %object;
    }
}

Well that's not exactly changing the type, but i get your point.

I think this is the best bet...

%player = %player as Player;
if ( %player == 0 )
   echo( "This is not a Player class type!" );

... this now serves two purposes. It gives Torsion a hint on the expected type and a new cast.