• Advertisement
Sign in to follow this  

Call different script functions: Best approach?

This topic is 2738 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

I have an application that can optionally execute a script (through a separate worker thread). Currently, the app just uses one script module that is executed through a single script context. The script thereby is required to feature the script entry point 'void main()'.
I now want to add two additional features and wonder what would be the best approach in terms of optimal use of the AngelScript API:

1.) Give the user the possibility to implement additional predefined functions like 'OnScriptAbort()' for example that would be called under certain circumstances in case they are found in the script (for the given example the function would be called when the script aborts due to some other event).

Questions:
Can/should I use the same script context in order to call these functions and re-configure this context? If 'yes' then what interfaces of the context must I call in order to properly be set up for the new function to be called?
Is a call to 'pCtx->Prepare(funcId)' enough or is there some additional cleanup to be made beforehand?

2.) Give the user the possibility to kind of 'overwrite' application internal functions by own scripted versions. These functions would be called very frequently and could massively influence the performance of the app.
Thus, my questions here are:
- Can I prepare a script context for a certain script function call and then execute this function over and over again (through pCtx->Execute()) without re-configuring the context prior to every call?
- Would the best approach be to have a separate context be created for each of these functions or is there some better approach?
- Is there an issue if the same engine object is used for this set of functions as for the main scripting functionality described in the beginning of the thread? I.e. should I consider to use a separate engine object?
- If I can/should use the same engine object: Is there a possibility to register script elements in a way so that they are only available in certain contexts? This way I could register only a subset of functions to be available for the 'overwritables' as opposed to the full interface being available for the main scripting feature.

Many thanks for your feedback!

Thomas


Share this post


Link to post
Share on other sites
Advertisement
1)

You can use the same context, if the previous execution already finished. It's only necessary to call the Prepare method to reset the context for the new execution.

2)

You must always call Prepare to start a new execution, but if the Prepare is called for the same function as the last execution, then the context will recognize that and will be a little faster. If you have a single script function being called very often it may be advantageous to dedicate a single context to that function. But the benefits will most likely only be noticeable if you make tens of thousands of calls to that function per second.

It is possible to expose different application interfaces to different modules through the use of configuration groups. If there is an overlap in the interfaces exposed to the different modules, it is better to use the configuration groups instead of the separate engine objects, but both solutions are possible.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement