ok, thank you!

Ah, thanks for the clarification, I think I've got what I need to get started now. I'll try something that's fairly similar to yours and see how it goes.

context->Execute returns when the script is done or it yield():s right? The reason you've got timeout-limits in the samples.

I thought about only using a onMessage but onProximity and onTimer was fairly nifty ideas too. Support for timers will be a little work but is probably very nice to have once it's done. Think I might have an old scheduler somewhere...

Yes, the Execute() method returns with asEXECUTION_FINISHED when the script ended, or with asEXECUTION_SUSPENDED if the script yielded. In the latter case the execution can be resumed by calling Execute() again on the same context.

The timeout mechanism is a failsafe you probably want to add in your game, otherwise a poorly written script can freeze the entire game, e.g. by entering an infinite loop.

My timers are really trivial at the moment. Each CEntity keeps a list of timers, which is basically the time remaining and the id. In the game loop I simply iterate over all the CEntities and decrement the remaining time for each of the timers, and if it reaches 0 the event handler is called.

[quote name='WitchLord' timestamp='1312304054' post='4843656']
I'm not a big fan of co-routines. They are excellent for controlled sequences where you know exactly the order that things happen, but I think they will complicate things when it comes to a game where the future is not known. Instead I prefer an event based model, where the scripts implement event handlers.

I'm having a bit of a rethink of how I want coroutines to work in my integration now, based on your comments. I don't feel there is necessarily any conflict between coroutines and an event based model, although for that conflict to be removed coroutines need to be "named" and stoppable.  I supposed that is reaching towards treating coroutines as states that can be entered and left, or possibly stacked. For example a placeable bomb script may look like:

...

Admittedly for something more complex like an AI involved in tactical behaviour (like presently engaging a player, as opposed to patrolling or pursing long-term activities) this may not work as well, as you want to be constantly reassessing the situation. There is probably room for both things to be mixed together in the same class though, for different purposes.

Anyhow I'm looking at things in light of my previous experiences with UnrealScript and its State construct (with simple coroutine support) and Unity, and perhaps I need to review those previous learnings.
[/quote]


I think this example is one where co-routines work quite well. Patrolling, that you mentioned probably also work well. Though, both of these are quite easy to implement with an event based model as well. However, as you say, there is really nothing that prevents both models to co-exist, and it is really mostly a matter of preference than anything else.
However, it's currently not possible to serialize the AngelScript contexts, so if you plan on supporting saving a game in the middle of the game play this is something you need to take into account if you plan on using co-routines. I plan to address this restriction with a future release of AngelScript, but it will probably be several months before I have that fully working.

Yes, the Execute() method returns with asEXECUTION_FINISHED when the script ended, or with asEXECUTION_SUSPENDED if the script yielded. In the latter case the execution can be resumed by calling Execute() again on the same context.

So calling Execute() either starts the script from the beginning again or resumes it. What happens if I run a script, it yields(), change function ID and then run execute(). Would I be correct to assume the function id is actually the adress of the entry point, or the index of the adress table, or something similar. So changing the function id mean beginning execution from that point instead?

The timeout mechanism is a failsafe you probably want to add in your game, otherwise a poorly written script can freeze the entire game, e.g. by entering an infinite loop.

Ah yes, will fix a timeout then, shouldn't bee to hard. Remember seeing something along those lines in the samples.

My timers are really trivial at the moment. Each CEntity keeps a list of timers, which is basically the time remaining and the id. In the game loop I simply iterate over all the CEntities and decrement the remaining time for each of the timers, and if it reaches 0 the event handler is called.

Neat and simple version of timers, I'll probably borrow that until I need something more fancy.

Yes, function id's are basically indexes into an array of asIScriptFunction's.

You cannot Prepare() a context with a different function id, while a script is running or suspended. First you would have to Abort() the execution, after which it is no longer possible to resume it. If you want to call a different script function while another script is executing or is suspended you need to use a different context.

Aha, okies. Thanks for the answers.