After finally getting the movement tolerances working the jACT-R so that the robo-monkeys could finally see each other as they move around, I came upon a motor bug. Actually, I’m still trying to hunt down the exact circumstances under which it occurs. It’s particularly challenging because it involves the interaction of the robot/simulation sending a movement status and colliding with the model’s desire for things to complete in a predictable amount of time.
Since this bug is so hard to track down given the current tools, I decided it was about time to implement a long desired feature. In my experience, and the reports of others supports that, most of us just run the models and when something goes wrong we dig through the trace. Only as a last resort do we ever really step into the models. (Basically, all that work I did to integrate break-points and a debugger were for naught 
)
However, once we’ve found where something went wrong we immediately want to know what fired (easy enough from the trace) and what the state and contents of the buffers were (not so easy). The log view jACT-R has provided is good, but not great. The tabular format and filters makes it easier to ignore irrelevant info, but you still don’t get a clear picture of the buffer contents. To rectify this I’ve added the ability to dynamically modify the tooltip for the log viewer. Combined with the buffer event listener and the runtime tracer, the log view can now display the full contents of any buffer as well as its flag values both before and after conflict resolution.
The buttons on the tooltip allow you to toggle between seeing the buffer contents before and after conflict resolution. It’s not completely correct right now in two regards: some state information may be lost at the start and end of a run (i.e. your model starts with buffers pre-stuffed or the runtime terminates before sending the last bits of info), and the changes to the chunks while in the buffer are not being tracked. The first issue I don’t care about, but the second will be addressed soon.
This added information does carry with it a moderate performance penalty so I’ll be including it as a runtime configuration option. A little later I will also add tooltip information for the declarative (i.e. visualization of encoded chunks) and procedural (i.e. fired production and resolved instantiation, encoded productions) module traces.
But for now, I’m quite happy and this is making tracking down that spurious motor.state=error soooo much easier.
