I would strongly suggest that you not mess with Schedule.  The approach you describe wouldn't work for a number of special cases, not the least of which is various parallel Steppable stuff.

There is already a method for killing a simulation.  It's called GUIState.kill().  It clears and stops the simulation after all the Steppables of the current timestep have been stepped.  If you need the simulation to *immediately* stop, you could also post some signal somewhere asking current Steppables to not step themselves even if they are scheduled for the current timestep (this can't be done in the Schedule: there are subsidiary steppables, asynchronous steppables, etc., which are out of its control).  Or you could wrap them all in TentativeSteps and store all of the TentativeSteps somewhere, and stop() them in addition to the big kill().

On Aug 9, 2015, at 8:49 AM, Joerg Hoehne <[log in to unmask]> wrote:

> On Sat, 8 Aug 2015 21:54:33 +0200, Sean Luke <[log in to unmask]> wrote:
> 
> Hi Sean, hi Axel,
> I was struggling with the same problem and found a solution by extending the Schedule class to do some checks before deciding if the overwritten step() method returns true.
> 
> My proposal for a MASON extension is the introduction of a method, invoked at each end of the step() method, which returns true if to continue. This method may be overwritten by the user to decide if a simulation should be continue. In this method any arbitrary computations can be performed by accessing the agents.
> A general purpose solution as suggested by Axel I consider to complex as each simulation heads for different criteria and not every agent is important for the simulation run, e.g. some of my agents are sometimes monitoring only but will remain in the schedule queue.
> 
> Jörg
> 
> 
> 
>> Axel, I really think that this need would probably be too specific to be including in as general a library as MASON.
>> 
>> Sean
>> 
>> On Aug 8, 2015, at 4:12 PM, Axel Kowald <[log in to unmask]> wrote:
>>> 
>>> But this seems to be a very non-reproducible and cumbersome way of doing it.
>>> Maybe this would be a job for the Schedule class of MASON ?