Paul Johnson 8-3-1999

Now I took all model parameters and put them into a class called
Parameters.  This is a class which combines the command line
parameters and the probe display input. Because that is now a separate
class, it can exists between runs of the model and it can be used to
change model parameters.  Also, note I've solved the problem of the
overlapping control panels.


Paul Johnson 7-18-1999

While reading NeuroLib files, I saw a command to the actionCache I'd
never noticed before. waitForControlEvent turned out to be the magic
bullet that makes the RepeatingHeatbugs work in every way. Both
control panel function as they ought to.  The ManagerSwarm can create
instances of the simulation, and the ObserverSwarm's panel can
start,stop, and next the simulation.

The 2 control panels have the same name, "ProcCtrl", I can't figure a
way to change it.  Other than that, they function in a completely
logical way.  If you press "start" in the first one, the sim starts
spawning observer/model swarms, one after another.
 
If you press stop in that first control panel, then the models that
are queued up will still run, so you have to be patient. Usually you
have to wait for one or two models to run before the whole thing comes
to a stop.

The only remaining issue, then, in making any Swarm app "resetable" is
solving the probeLibrary problem.  As it stands, the repetition does
not work unless you use default probeMaps in the model swarm level.
This had to do with the fact that probeLibrary is a "global, permanent
object" and it cannot be dropped and recreated by each model swarm
that comes along.  That's a pretty small price to pay..



Paul Johnson 1-28-99

This is Repeating_Heatbugs. During the Swarm 1.3 era, I became
interested in taking screenshots to summarize simulations after a long
time.  I also wanted to run "batch" simulations that would repeat
their work and save their results. Then I discovered that the batch
approach imagined by the Swarm design team had not allowed usage of a
GUI.

It seemed important to provide some method within Swarm itself to make
a simulation repeat itself and this application is my first stab at
it.  I'm no code genius and there is without a doubt room for
improvement. Some of the elements in this package may be ugly or
ungainly, and I take resonsibility, except also want to slough some
blame on the Swarm code itself, because bugs inside the Swarm kernel
itself were causing the code to crash and I kept making modifications
to try to make it work.  So there are some things that are not as
elegant as they ought to be. And also some opportunities for
modernization were not exploited because they made Swarm 1.3 crash,
and I've not tried them again in Swarm 1.4.


The approach is to create a "ManagerSwarm" that sits on top of the
ObserverSwarm and this Manager can create, run, and kill
ObserverSwarms.  There are slight code changes in the ObserverSwarm
level to 1) make the simulation start itself and stop itself after a
given number of time periods and 2) to drop the ModelSwarm after the
given number of periods.

There is still the problem that the simulation crashes if the user
uses the control panel of an ObserverSwarm (a single run of the model)
to control the simulation. (Fixed as of 7-18-99)

TODO

Now that Swarm 1.4 allows this simulation to run without crashing, I'm
considering beautifications.  I want to stop using the ControlPanel in
ObserverSwarm and replace it with the thingie called
"ActivityControl." 


ORIGINAL README CONTENT: This is the Heatbug demo app.  The code is
very well commented, so the only thing that needs to be said here is
that if you want to see little pictures (pixmap) running around
instead of squares, then run make like so:

   make CPPFLAGS=-DUSE_PIXMAP

Also, you can write screenshots for each update to PNG files if you
build like this:

   make CPPFLAGS=-DSCREENSHOTS
