Mike,
   I think you are on the right track. In general, a Steppable
represents an activity to the discrete event simulator. It does
not matter what this activity is - an "agent", "event", or whatever.
The representation is dependent on your modeling.
   If you model an environment where all activity is agent-centric
then scheduling agents can be viewed akin to scheduling activities.
As you point out, one may want to support numerous discrete
agent activities; only to have the convention support a single entry
point.
   Some standard approaches to support differentiation of activities
from a single entry point, that are applicable here, are via data
space and/or encapsulation. Data space approaches generally include
object local memory state such as the flag you mention, shared memory
via data objects that are "passed" from one agent to another or known
in common, and/or a global memory state often represented as "the
environment" (this is essentially equivalent to shared memory with
universal visibility as a constraint).
   Consider also encapsulation as a useful technique. For example, create
SENSE, THINK, ACT objects that encapsulate your agent. Then you can
schedule SENSE activities, THINK, and ACT activities any way you see
fit. MASON allows the type of phase-based scheduling this example
implies, where you can guarantee that all SENSE activities occur before
subsequent THINK activities, and once all of these have been considered
then the ACT activities occur for a given "phased" timestep. Imposing
such fixed phase orderings is relatively straight-forward.
Non-stationary phase orderings can be a bit more of a challenge, but
I'm not sure that's what you are getting at here, is it?

					-Mike


Michael Lees wrote:

> Hi all,
> 
> I seem to writing a lot of emails with suggestions and questions. 
> Hopefully I'll be able to contribute answers soon.
> 
> Anyway,
> 
> For the purposes of my simulation I've designed a new type of steppable 
> which has a phase. The design is not particularly elegant so I was 
> wondering if there is a correct way of doing what I'm attempting.
> 
> Basically the way I've understood and learnt mason is that agents are 
> steppables. You implement an agent by extending some form of steppable. 
> You then schedule the agent and perhaps repeat the step every time-step. 
> So say you have n agents the schedule at each time-step looks like:
> 
> [a_1,a_2,...,a_n]
> 
> Where a_i is the step method of agent i.
> 
> What I want to be able to do is basically split the step method of each 
> agent in a single time-step, so we have the agent i has two step methods 
> a_i and a'_i.
> This would allow to have a repeatable schedule as...
> 
> [a_1,a_2,...,a_n, b, a'_1,a'_2,...,a'_n]
> 
> Where b is some other form of steppable.
> 
> The steppable would then have a flag which indcates the current 'phase' 
> of the agent and which flipped on each call to step. The invocation of 
> step would call a different step method (a_i or a'_i) according to the 
> current value of the flag or 'phase'. (This could be generalised to n 
> phases)
> 
> You would then schedule the agent in the same schedule multiple times at 
> different orderings to achieve the desired affect.
> ie.,
> schedule.scheduleRepeating(a_i,1,1.0d);
> schedule.scheduleRepeating(b,2,1.0d);
> schedule.scheduleRepeating(a_i,3,1.0d);
>     
> 
> So I thought about it some more and I wasn't sure if I was thinking 
> about steppables in the correct way. You can think of steppables as 
> events rather than agents? So rather than implementing your agent by 
> extending steppable, the agent contains steppables which represent the 
> events the agent can schedule. This way seems cleaner and slightly more 
> natural to me, but I wasn't sure which way I should think about 
> steppables. I have currently implemented the former but was thinking 
> about changing.
> 
> 
> 
> Thanks
>