RE: does anyone else miss a coroutine.reset() feature ?

[Benoit Germain <bgermain@...>]

My thanks to all of you for reminding me that a coroutine can also do normal
returns. I'll experiment a bit more and keep you informed.

BTW, didn't you want to write this instead ?

modeA =
{
        execute = function ( )
		local mode --@@@
		while(true) do --@@@
		if(mode == 'reset') --@@@
		then --@@@
			coroutine.yield() --@@@
			mode = nil --@@@
		end --@@@
		print "modeA"
		mode = doSequence ( ) --BBB take the sequence's return value
        end
end --@@@
}

But anyway, this might not be so simple, because inside modeA, it is very
likely that I will do other stuff after the sequence has completed (for
example launch another one). Therefore, I need to 'continue' the infinite
loop so that it can yield just before its job part. But unfortunately, there
is no 'continue' in the language yet.

> > And I fear that
> > 1) I need coroutines to achieve this in a simple way
> Well your objects have finite number of states and all you 
> want to do is to do transition between these states following 
> certain rules. You don't need co-routines to do this but they 
> are very helpful. 

Well, I have another restriction that I didn't mention yet. The behaviours
of our game entities won't be written by the developement team, but for the
most part written by 'production people' with no engineering background.
Therefore, I need to offer them something they can understand, if you get my
point :-). I already have a state machine builder that is up and running.
This is a framework for them to code the behaviours. We feel it necessary
because in a previous project there was no such framework, and each
behaviour was coded in a style highly dependent on the 'programmer'. This
led to unmaintainable, untransferable and most buggy code. BTW this was done
with an in-house (and badly designed) developed script engine, which
contrived in implementing exactly what I want to achieve now.

Anyway, I understand that there is no real need for coroutines when
implementing a state machine. The coroutines add another feature, that is
interesting for framerate control. For example, in a given mode, a behaviour
(or several) might need to perform a pathfinding or any other costly
request. Since I want to limit the total number of such requests per game
frame, and to prevent a particular behaviour to prevent the next in line
from executing, requests are filed in a list and fulfilled in another
spacially alloted CPU time slot in the frame pipeline. Therefore, a
behaviour might need to wait for the request to be fulfilled before it can
proceed, but then, this does not prevent the other behaviours to do what
they have to.

My first version of the behaviour framework had the full state machine
wraped in a coroutine per game instance, therefore interrupting it and
resuming it caused no problem, because a mode could not be aborted. But
then, if the request is fulfilled quite lately, the behaviour is stuck for a
long time. Therefore I still needed to have coroutine-interruptible modes,
but to keep the state transitions active.
I also feel that I had to give a tool to the behaviour coders to define
interruptible sequences (so that implementing something like my previous
example can be done easily), and that, even if a sequence is nothing more
than an automaton, having to somehow "encompass" a state machine running
inside another might prove too much for them. Remember they have no
engineering background, and their way of solving problems is to add hacks
upon one another.

>From this stems my problem of 'cancelling' a mode because of a transition
(either while inside a sequence or while waiting for a request to complete),
and go back to it at its start point in that case.

> 2) the current implementation of coroutines does not enable 
> this kind of
> mechanism
> Not in the fashion you had envisioned it. But it gives you 
> more powerful tool (call it co-routine messages if you will) 
> to do this and a lot more.

I'll have to look at this, but I want to expose the minimum of internals to
the behaviour coders. This means that I want to avoid the need for them to
take care about mode cancellation, and add special code everywhere for this
(such as aborting their mode upon special return values of the sequence
loop). The ideal would be for them to only define the state machine, define
the sequences, let the automaton engine call the transition rules and mode
entrypoints, and take care of the mode interruption problem.
> 
> 3) my knowledge of the core is insufficient to add the 
> necessary C code to
> reset the coroutine
> 
As for this previous remark of mine, so far as I can understand it,
resetting a thread is just a matter of restoring the instruction pointer,
stack pointer and call stack status of the thread to their proper initial
values. But then, is this true ? And what are the proper values ? If these
questions are answered, I can do everything I want, without the coders to
have to do anything specific about it.


Cheers,


Benoit.