Issue with handling commands to land when dealing with the UAV having a
crashed transition even when the UAV isn't set to crash for another 100
time steps, and the command to land will terminate in less than that
time. (issue with priorities and durations on perisitent durations)
Fixed an issue in the interpreter, also made it so the first state in a
JTR file is the start state of the class.
fixed the issue where the operator wouldn't land the plane before the
battery failed.
added UAVFlightPlan into the mix. An output isn't deasserting though,
not ready to merge with master.
Got the flight plan to respond correctly to take offs and landings,
still needs to handle reduction in time due to previous flights.
added the beginning functionality for persistent durations.
Fixed errors. They drive me cray-cray sometimes, alright?
added actor name to asserts when checking actor variables (memory)
Integrated DURATION into the simulator.
The System can now handle a flight plan that extends over several
battery life spans.(UAV has to land twice during execution of a flight
plan). Durations can now be persistent.
Made a format for persistent transitions. Made the Interpreter recognize
the new format as a correct one.
The Interpreter correctly handles translating the new persistent
transitions.
The Interpreter correctly implements the new persistent duration
transitions.
Added another scenario to the system, it can now handle seeing a target
Added instructions to installing jpf and the new jpf plugin for eclipse
on an apple machine
Finished the installation file for jpf on an apple computer
WorkloadBuilder produces updated csv header row, WorkloadListener adds
duration time to data in metric, NewWiSARTeam has correct flight plan
outputs, ActorVariableWrapper has more explanatory assert statements,
Transition has better checking on START_TIME calls. JPF now runs, but
exceeds memory, I'm not sure why. Did we change durations?
jpf no longer records uav actors or subactors with UAV in the name.
decision workload is now correctly measured, it was a bit buggy before.
oops.
task starts and stops are now being recorded