Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


- - - - -

Spawning coroutines from script and providing params


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 iraxef   Members   -  Reputation: 382

Like
0Likes
Like

Posted 18 December 2013 - 01:39 PM

(To follow up on http://www.gamedev.net/topic/591814-funcdefs-to-member-functions/ and http://www.gamedev.net/topic/607706-lambda-functions/ and http://www.angelcode.com/angelscript/sdk/docs/manual/doc_adv_coroutine.html ...)

 

I'm wondering how to allow a script to spawn a coroutine where the function signature (of the function to call in the newly-spawned script context) is not fixed/known ahead of time (and provide those parameters).

 

 

Using the script funcdef syntax, a script can create a function handle to a function-signature that I can't anticipate ahead of time. I'd like the script to then be able to spawn a coroutine using that handle as the starting point, and provide whatever params that function needs.

 

Is there any precedent for doing this? Or is it best to limit the script-side spawning of coroutines to a function signature that takes no params, or predefined-ahead-of-time number/type of params?

 

Thank you.


Edited by iraxef, 18 December 2013 - 02:01 PM.


Sponsor:

#2 Andreas Jonsson   Moderators   -  Reputation: 3416

Like
0Likes
Like

Posted 18 December 2013 - 02:06 PM

My recommendation is to design it so that the co-routine can take a dictionary. This way the script can pass any information it wants to the co-routine without the need for the application to have any knowledge of whatever the script wants to pass to the co-routine.

 

With the newly implemented support for initialization lists in the dictionaries the syntax doesn't become too weird for the script writer either. biggrin.png

 

void MyCoRoutine(dictionary @dict)
{
   ... do some processing as a co-routine
}
 
void main()
{
   dictionary values = {{'first', 1}, {'second', 2}, {'third', 3}, {'etc', 4}};
   SpawnCoRoutine(MyCoRoutine, values);
}

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

#3 iraxef   Members   -  Reputation: 382

Like
0Likes
Like

Posted 18 December 2013 - 02:22 PM

That seems really elegant... I'll have to investigate (I'm not using the dictionary add_on quite yet)!

 

Thank you very much.



#4 iraxef   Members   -  Reputation: 382

Like
0Likes
Like

Posted 22 December 2013 - 08:34 PM

I've created a CScriptDictionary object in C++, filled it in with some elements, and called script with that param.. and was able to print out all the dictionary keys.

 

Is there any guidance in the documentation which would be helpful as to the type id to use for this CScriptDictionary signature?

void Set(const std::string &key, void *value, int typeId);

So far I used asTYPEID_SCRIPTOBJECT when passing an std::string& to a script string (registered with the add_on), and asTYPEID_APPOBJECT when passing a void* to an application object registered as a reference type with script. Is that correct? Would I use asTYPEID_OBJHANDLE in any situation?

 

Thank you very much.


Edited by iraxef, 22 December 2013 - 09:30 PM.


#5 Andreas Jonsson   Moderators   -  Reputation: 3416

Like
0Likes
Like

Posted 23 December 2013 - 01:31 PM

No, that isn't the way it works. Except for the built-in primitive types no types have a specific type id that can be determined before hand.

The only way of getting the correct type id is by querying the engine for it. You can GetTypeIdByDecl on the asIScriptEngine for application registered types, and the same method on the asIScriptModule for script declared types.

The asTYPEID_ flags can be used as bit masks on the typeid to get limited information on the type it represents.

Regards,
Andreas
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

#6 iraxef   Members   -  Reputation: 382

Like
0Likes
Like

Posted 26 December 2013 - 09:15 PM

I got the below working, but it appears that if the dictionary (that's passed to the coroutine) contains some application-defined value types, modifying the value type in the dictionary in the coroutine affects the dictionary that was passed into MyCoRoutine() once SpawnCoRoutine() returns.

 

Before I execute "MyCoRoutine" from C++, I probably have to manually create a 2nd CScriptDictionary instance, fill it in element-by-element (creating copies of application-registered value types), and pass that instance to MyCoRoutine?

 

 

 


 
void MyCoRoutine(dictionary @dict)
{
   ... do some processing as a co-routine
}
 
void main()
{
   dictionary values = {{'first', 1}, {'second', 2}, {'third', 3}, {'etc', 4}};
   SpawnCoRoutine(MyCoRoutine, values);
}

Edited by iraxef, 26 December 2013 - 09:16 PM.


#7 Andreas Jonsson   Moderators   -  Reputation: 3416

Like
0Likes
Like

Posted 28 December 2013 - 08:51 AM

If you absolutely do not want the co-routine to modify the original dictionary, then you'll need to do what you say, i.e. do a manual deep copy of the dictionary and all its values.

 

However, are you sure you need this? Perhaps you can instead take advantage of allowing the co-routine to modify the original dictionary to return values, or even allowing the caller to add extra information for the co-routine afterwards. 


AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS