ModSAF is a distributed simulation which causes problems when agents are created on separate hosts. When an agent is created, a user interface is created for that agent, whether it be a new X window or a new I/O stream interleaved onto standard input/output (used by SDE). This is no problem when one ModSAF is running on a local host. However, if more than one ModSAF is running and ModSAF's load balancing is active, then locally created agents will be simulated on remote hosts and their user interface will appear remotely. Fortunately, there are simple methods for forcing agents to remain on a local host. In the long term, it would be useful to find a method for allowing load balancing without interfering with the placement of the user interface.
Another issue concerns vehicle control in ModSAF. Control of a vehicle occurs through setting the desired state of the vehicle such as its speed, heading, and altitude. This level of control makes certain tasks difficult. For instance, it is not possible to cause the vehicle to climb without providing a desired altitude. Thus, attempting to stay in formation with another vehicle during a climb is very difficult since the agent must constantly monitor the altitude of the other vehicle and reset its desired altitude accordingly, rather than simply climbing until the other vehicle levels off. To more accurately model the vehicle control available to a pilot, the SMI will need to access lower-level ModSAF libraries.
The problem of connecting Soar to ModSAF has brought some interesting technical challenges. The challenges have helped the Soar system developers to generalize Soar's extension mechanisms enabling all Soar users to benefit. And the ModSAF environment has been an effective tool enabling Soar agent developers to focus more closely on modelling human pilots.