]> control flow abstractions are used camera There is little to none of the repetitive code left. The mission agent can be automatically created by iterating over the task structure and creating resource getters and so on. 2000-12-10T11:37:00Z simulators are no longer aircraft camera Simulators are currently aircraft which is arbitrary (they could also be ranges, for example). We should make simulators a different first-class input to SNAP - so there will be a simulators.xml input file which will contain some of what is now in aircraft.xml. 2000-12-11T18:03:00Z different task types are strongly typed camera Currently, we use Mission for FRAGs, for training missions, and for simulator rides - which leads to code such as "if my type enumeration says I'm a simulator then only the first of the two sorties needs an airplane and I don't need a range". This should be more cleanly modelled by having Simulator be a different type than TrainingMission which never needs a range. For pits, it is probably the best solution to have both missions of a pit modelled as a single task rather than having them modelled as two single tasks that have to closely coordinate (if one switches a pilot or aircraft the other one must do the same). 2000-12-11T18:16:00Z pits and turns are implemented camera SNAP computes the exact time slots of pits and turns centrally, then the slots become another resource that a task has to acquire to get on (probably best the first one). 2000-12-11T18:19:00Z the (non-time-interval) Marbles scheme used camera The flow controller works differently: (1) it generates a long list of possible missions, (2) going from left to right, it lets all of them Marbles-compete for a slot, then moves all of the losers to the next slot. (This is not the envisioned ultimate solution - tasks should decided to move to a different time slot in a less centralized fashion - but is still an order-of-magnitude improvement over what we currently have.) 2000-12-11T20:29:00Z