Today I did a bunch of work behind the scenes, starting with automatically determining the exclusivity of components based on their defined capacities, where appropriate. Queue, Process, Bag, and Combined components are exclusive if their governing capacities are finite and not exclusive if they are infinite. All other component types are always non-exclusive. It could be argued that Process components should never be defined to have infinite capacities when modeling any real system, since the whole purpose is to examine its finite constraints. The same might also be true of bag components. I should probably have the system throw a warning if a user specifies an infinite capacity for a Process or Bag component. Components that can operationally handle an infinite capacity are as a practical matter limited in two ways. One is by the amount of memory that can be allocated to store entities in internal queues and the other is by the number of entities that can be individually displayed.
Next I streamlined a bunch of the initializers for the graphic display components by defining a lot of default parameter values and embedding an assignment into a constructor. This was especially germane to the graphic characteristics of Path components, whose endpoints are usually determined automatically by the non-Path components they are connected to. I also removed references to the internal DisplayGroup mechanisms in the initialization code, but the mechanics remain in place within the component objects.
Finally, in preparation for doing something a little cleaner with the specification of internal entity locations, I redefined the internal arrays that store those locations to be multidimensional. The code is otherwise unchanged, and all locations are saved in master array zero. The goal is to be able to specify locations for different internal entity queues (e.g., parking and exit queues in Bag components, waiting and process queues in Combined components) in their own arrays rather than having to figure out which of the latter locations apply to entities in the second queue. This should also allow for a process to represent multiple, parallel operations, possibly each with their own sub-queues, but that is an idea for later.
The only visible change in the model is that I lowered the queue capacity in the Combined component down to two so I could test to ensure it handles exclusivity properly, which it does. You may have to reset and rerun a couple of times to see enough entities back up in that component, but it happens.