Sign in to follow this  

Registering functions with overloads?

This topic is 3284 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Now I have a second question, And I can't seem to find this around. I'm trying to register a Class. Objects of this type will be passed to the script. But I don't want them to be managed by GC or be created inside the scripts. So, so far this is what I have:
    // Register our Creep
    r = m_engine->RegisterObjectType("Creep", 0, asOBJ_APP_CLASS );
    r = m_engine->RegisterObjectMethod("Creep", "int health() const", asMETHOD(Creep,Creep::health), asCALL_THISCALL); assert( r >= 0 );


My problem though is, "int health()" has an overload: "void health( int )", how do I specify which overload to get?

Share this post


Link to post
Share on other sites
You can use the asMETHODPR() macro instead of asMETHOD(). Ex:

asMETHODPR(Creep, health, (int), void)

Share this post


Link to post
Share on other sites
Ok, I changed it to:


// Register our Creep
r = m_engine->RegisterObjectType("Creep", 0, asOBJ_APP_CLASS );
r = m_engine->RegisterObjectMethod("Creep", "int health()", asMETHODPR(Creep, health, (int), void), asCALL_THISCALL); assert( r >= 0 );




But I'm still getting a compile time error:
Quote:

|error: address of overloaded function with no contextual type information|


I'm compiling with MinGW GCC 4.3.5

Share this post


Link to post
Share on other sites
What does your Creep class look like? This code:

struct Creep {
int health(void) const { return 0; };
void health(int) {};
};

int main(int, char **) {
asIScriptEngine * engine;
int r;

// Register our Creep
r = engine->RegisterObjectType("Creep", 0, asOBJ_APP_CLASS );
r = engine->RegisterObjectMethod("Creep", "void health(int)", asMETHODPR(Creep, health, (int), void), asCALL_THISCALL); assert( r >= 0 );
r = engine->RegisterObjectMethod("Creep", "int health()", asMETHODPR(Creep, health, (void) const, int), asCALL_THISCALL); assert( r >= 0 );
}

Compiles fine under both MSVC 2008 and gcc 3.4.4.

Share this post


Link to post
Share on other sites
Aaahhh it was my bad, the function signature was a short, not an int :/

Thanks for the help!

Btw, are shorts registered by default?

Or do I need to register them?

Share this post


Link to post
Share on other sites
It compiles now, but fails to register with error code: -21


r = m_engine->RegisterObjectMethod("Creep", "short health()", asMETHODPR(Creep, health, (void), short), asCALL_THISCALL); assert( r >= 0 );





Also, i am registering short like so:

r = m_engine->RegisterObjectType("short", sizeof(short), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_PRIMITIVE); assert( r >= 0 );


Share this post


Link to post
Share on other sites
You don't need to register short. The AngelScript type that corresponds to short is int16.

If you wish to use the name short you can register a typedef for int16. Example:


engine->RegisterTypedef("short", "int16");




If you register 'short' as a new type rather than a typedef, you won't have the benefit of implicit conversions between number types. Unless you also register the cast operators for this.

Also, AngelScript currently allocates all registered types on the heap, so until I get a chance to fix this you'll have a rather large performance hit due to lots of dynamic memory allocations.


Manual: Datatypes in AngelScript and C++

Regards,
Andreas

Share this post


Link to post
Share on other sites
Oh, I didn't see that DataTypes page in the docs that ship with the lib, good resource though.

I'll move to using int16 right away :)

Also, are there any docs around about Control Groups (or was it Config Groups?) for exposing different interfaces to different scripts?

[Edited by - Wavesonics on January 16, 2009 3:39:31 PM]

Share this post


Link to post
Share on other sites
So, if I'm understanding this correctly, I would do:


engine->BeginConfigGroup( "someGroup" );

// Register types with the engine

engine->EndConfigGroup();




Then I create some module, and do:

engine->SetConfigGroupModuleAccess( "someGroup", mod1, true );




Do I have to explicitly disallow modules access to groups like:

engine->SetConfigGroupModuleAccess( "someGroup", mod2, false );




Once I kinda get things figured out more, I wouldn't mind writing up some tutorials on a few common topics, like registering overloaded functions. Config groups, and so on. Just to explain the nitty gritty that is hard to deduce from the straight docs, would that be helpful?

I found some wiki with some of thee topics, but it seems to be out of date, the code wouldn't compile.

Share this post


Link to post
Share on other sites
As the documentation says, the default is for a module to have access to the group. Though if you want to change this you can do:


engine->SetConfigGroupModuleAccess("group", asALL_MODULES, false);


This will set the default access to denied.

Tutorials for AngelScript would be very welcome. Feel free to update the wiki as well. The wiki was started a long time ago, but unfortunately the community hasn't really taken to adding information to it. And I prefer to spend my time on the actual SDK itself, rather than writing tutorials. I try to add the necessary information to the documentation, but it is difficult to foresee what needs newcomers have.

Share this post


Link to post
Share on other sites
Can I do this:

// Register a class with definition
engine->BeginConfigGroup( "someGroup" );

// register some methods inside

engine->EndConfigGroup();

And then, I can configure permission access for modules.

Is this possible?




Quote:
Original post by WitchLord
As the documentation says, the default is for a module to have access to the group. Though if you want to change this you can do:


engine->SetConfigGroupModuleAccess("group", asALL_MODULES, false);


This will set the default access to denied.

Tutorials for AngelScript would be very welcome. Feel free to update the wiki as well. The wiki was started a long time ago, but unfortunately the community hasn't really taken to adding information to it. And I prefer to spend my time on the actual SDK itself, rather than writing tutorials. I try to add the necessary information to the documentation, but it is difficult to foresee what needs newcomers have.


Share this post


Link to post
Share on other sites
Yes, this is how I do things, I have a common group of functions for scripts that can run on both client and server, and one that only runs on client. So I don't both putting the common ones into a config group.:


void initScriptEngine() {

// Some initial set up here
{
...
}

engine->BeginConfigGroup( CLIENT_SCRIPT_GROUP );

// All the client specific registrations here
{
...
}

// Dissalow by default, only enable for client side scripts
engine->SetConfigGroupModuleAccess( CLIENT_SCRIPT_GROUP, asALL_MODULES, false );

engine->EndConfigGroup();
}



Then, when I am loading a script, I first explicitly allow the script access to the client group of registrations, and THEN load the script:


void enableClientBindingsForScript( const std::string& path ) {
// Enable the client script bindings
asIScriptEngine* scriptEngine = gScriptEngine.getScriptEngine();
asIScriptModule* mod = scriptEngine->GetModule( path.c_str() );

// Only set access if the script as not been loaded yet
if( mod == NULL )
// Enable the Client script binding config group
scriptEngine->SetConfigGroupModuleAccess( CLIENT_SCRIPT_GROUP, path.c_str(), true );
}


// Later on when loading a new script:
enableClientBindingsForScript( m_description->effectsScript );
gScriptEngine.preload( m_description->effectsScript );




You MUST set the access BEFORE trying to compile the script. Hope that helps.

Share this post


Link to post
Share on other sites
Cool, Thanks

Quote:
Original post by Wavesonics
Yes, this is how I do things, I have a common group of functions for scripts that can run on both client and server, and one that only runs on client. So I don't both putting the common ones into a config group.:

*** Source Snippet Removed ***

Then, when I am loading a script, I first explicitly allow the script access to the client group of registrations, and THEN load the script:

*** Source Snippet Removed ***

You MUST set the access BEFORE trying to compile the script. Hope that helps.


Share this post


Link to post
Share on other sites

This topic is 3284 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this