Update documentation -- mostly formatting changes.
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/about.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/about.html
deleted file mode 100644
index 65d4bc2..0000000
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/about.html
+++ /dev/null
@@ -1,28 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

-    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

-<html xmlns="http://www.w3.org/1999/xhtml">

-<head>

-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>

-<title>About</title>

-</head>

-<body lang="EN-US">

-<h2>About This Content</h2>

- 

-<p>October 5, 2009</p>	

-<h3>License</h3>

-

-<p>The Eclipse Foundation makes available all content in this plug-in (&quot;Content&quot;).  Unless otherwise 

-indicated below, the Content is provided to you under the terms and conditions of the

-Eclipse Public License Version 1.0 (&quot;EPL&quot;).  A copy of the EPL is available 

-at <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>.

-For purposes of the EPL, &quot;Program&quot; will mean the Content.</p>

-

-<p>If you did not receive this Content directly from the Eclipse Foundation, the Content is 

-being redistributed by another party (&quot;Redistributor&quot;) and different terms and conditions may

-apply to your use of any object code in the Content.  Check the Redistributor's license that was 

-provided with the Content.  If no such license exists, contact the Redistributor.  Unless otherwise

-indicated below, the terms and conditions of the EPL still apply to any source code in the Content

-and such source code may be obtained at <a href="http://www.eclipse.org">http://www.eclipse.org</a>.</p>

-

-</body>

-</html>
\ No newline at end of file
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/about.ini b/org.eclipse.amp/doc/org.eclipse.amp.doc/about.ini
deleted file mode 100644
index 48d5ee8..0000000
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/about.ini
+++ /dev/null
@@ -1,11 +0,0 @@
-# about.ini

-# contains information about a feature

-# java.io.Properties file (ISO 8859-1 with "\" escapes)

-# "%key" are externalized strings defined in about.properties

-# This file does not need to be translated.

-

-# Property "aboutText" contains blurb for "About" dialog (translated)

-aboutText=%featureText

-

-# Property "featureImage" contains path to feature image (32x32)

-featureImage=amp32.png
\ No newline at end of file
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.mediawiki b/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.mediawiki
index 98c0b17..ad9e981 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.mediawiki
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.mediawiki
@@ -24,7 +24,7 @@
 
 Agent-Based Models (ABMs) seek to represent important real-world dynamics by designing communities of software agents that mimic real entities. Rather than make simplifying assumptions about such systems and then representing them in equation form or as off the shelf algorithmic constructs, the ABM researcher aims to identify key agent state, interaction spaces, and behaviors. Agents are then "let loose" on our computers and we explore what happens next. The computational horsepower exists today to simulate large numbers (e.g. >>10) of interacting, adaptive and autonomous agents but often desktop computers are all we need to explore significant domains. ABMs have been designed to represent all kinds of important natural systems, at scales reaching from cellular mechanics to international trade and are being used to solve truly hard problems in government, business, and academia. ABMs are not a solution to every problem, but they can help us to appreciate and gain unique insight into many systems, and often they can help us to come up with better practical decisions than we might using classic approaches.
 
-===Other Uses==
+==Other Uses==
 
 Many kinds of objects share characteristics of ABM agents -- after all, software agents are used in many other contexts. The Agent Modeling Framework meta-modeling support is potentially suitable (or extendible) for a number of approaches outside of ABM; for example business rules, object interactions, systems dynamics models and traditional discrete event models. Similarly, AMP execution and graphic support can be used for modeling natural systems but could also be used to manage other software agents -- for example independent reasoning tasks or dynamic visualization support.
 ==Credits==
@@ -349,31 +349,36 @@
 
 ====Kinds of Actions====
 
-Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. All of these are discussed in detail in the section that follows this one.
-
-These are all summarized in the diagram below:
-
-[[Image:images/actions/ActionsBlocks.png]] 
+{| border="0"
+|-valign="top"
+|Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. The various actions are discussed in depth in the Details section.
+|[[Image:images/actions/ActionsBlocks.png]] 
+|}
 
 ====Flow====
 
 First, let's look at how actions define the basic path that agents take during a model run. As with any programming language, the path we take through the program specification is what determines our state when we get there. In a pure object oriented program, the path just defines the control flow -- what we are doing. The actual state of our model is defined within the object itself. If we call a method B from another method A, we'll be relying on method A to set the values that we need into the object state itself. In a purely functional program the path defines how we are going to deal with whatever has been explicitly passed in to a function that has been called, that is the function parameters. In fact, most languages such as Java combine aspects of both approaches.
 
 In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.
-
 An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically ''need'' loop structures. By far the most common use of loops in conventional programming langauges is to loop through collections of objects. As selections (see below) refer to the entire collection of agents, any actions on a selection apply to all members of that collection. Recursive structures are needed for some particular usages and will be supported in future releases, but not through an explicit looping construct.
 
-Again, behaviors in Actions are always defined by a set of ''selections'' and ''queries''. In the following diagram, we can see the pattern.
+{| border="0"
+|-valign="top"
+|Again, behaviors in Actions are always defined by a set of ''selections'' and ''queries''. In the diagram to the right, we can see the pattern. First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent.
+|[[Image:images/actions/ActionsSequence.png]]
+|}
 
-[[Image:images/actions/ActionsSequence.png]]
+{| border="0"
+|-valign="top"
+|The diagram to the right depicts a simple example. Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them.
+|[[Image:images/actions/ActionsSimpleSequence.png]]
+|}
 
-First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent. The next diagram depicts a simple example.
-
-[[Image:images/actions/ActionsSimpleSequence.png]]
-
-Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them. In the next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.
-
-[[Image:images/actions/ActionsSimpleSequence2.png]]
+{| border="0"
+|-valign="top"
+|In this next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.
+|[[Image:images/actions/ActionsSimpleSequence2.png]]
+|}
 
 In the following example, we've defined a set of actions and their relationships. We have a selection, a few queries and a couple of logic operators leading to a Set Action. We'll describe in detail below how Logic Actions are used in conjunction with other actions to assemble any kind of query structure needed. But for now, we'll focus on the control flow itself.
 
@@ -404,22 +409,28 @@
 
 Selections are a key concept in Actions. Put simply, selections define what we are searching for and where. They are defined by a combination of Select, Query and Logic Actions. Each time we create a new Select Action, we define a new selection. Queries can be used to further refine selections either immediately after or later in the Action flow, as described in the next section. Logic Actions are used to combine and organize the Action flow defined by Query Actions. In order to understand how these three pieces work together, we need to understand the idea of selection boundaries.
 
-A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.
+{| border="0"
+|-valign="top"
+|A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.
+|[[Image:images/actions/ActionsSelBoundarySimple.png]]
+|}
 
-[[Image:images/actions/ActionsSelBoundarySimple.png]]
+{| border="0"
+|-valign="top"
+|Each time we create a new selection, we define a new set of boundaries. In the diagram to the right, Selection 1 and Selection 2 eaach start with a new Select Action. 
+|[[Image:images/actions/ActionsSelBoundary2Parts.png]] 
+|}
 
-Each time we create a new selection, we define a new set of boundaries.
-
-[[Image:images/actions/ActionsSelBoundary2Parts.png]] 
-
-A very important aspect of boundaries is that they apply to a group of actions that begin with a Query Action, and not just such a group that begins with a Select Action. This is because Query Actions can be directly part of a selection definition, but they can also refine selections, as we'll see. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:
+But boundaries can be defined for a group of actions by a Query Actions as well. This is because Query Actions can be directly part of a selection definition, but they can also refine selections. We'll see how that works below. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:
 
 #A Query Action is not followed by a Logic Action, or
 #A Logic Action is not followed by another Logic Action
 
-In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as we can see in the following example. 
-
-[[Image:images/actions/ActionsSelBoundary11A.png]]
+{| border="0"
+|-valign="top"
+|In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as shown in the example to the right. 
+|[[Image:images/actions/ActionsSelBoundary11A.png]]
+|}
 
 Note that we refer to "Selection 1" and Selection 1A". This is because Selection 1A is a refinement of Selection 1 along its particular path of flow. When a query appears for the same selection but past a particular boundary, you can think of it as a sort of filter on the selection contents. We don't have a "Selection 2" here because any Actions that refer to "Selection 1" along the current path of flow will be acting on the selection defined by Selection 1 and Selection 1A.
 
@@ -431,31 +442,37 @@
 
 ====Weaving====
 
-Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.
+{| border="0"
+|-valign="top"
+|Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.
+|[[Image:images/actions/ActionsWeavingSetAnother.png]]
+|}
 
-[[Image:images/actions/ActionsWeavingSetAnother.png]]
+{| border="0"
+|-valign="top"
+|Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)
+|[[Image:images/actions/ActionsWeavingEvaluate.png]]
+|}
 
-Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)
+{| border="0"
+|-valign="top"
+|But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.
+|[[Image:images/actions/ActionsWeaving1A.png]]
+|}
 
-[[Image:images/actions/ActionsWeavingEvaluate.png]]
-
-But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.
-
-[[Image:images/actions/ActionsWeaving1A.png]]
-
-Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Now, consider the following example:
-
-[[Image:images/actions/ActionsWeaving2.png]]
-
-Before going into further details we need to introduce one more important concept. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.
+{| border="0"
+|-valign="top"
+|Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Consider the example to the right. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.
+|[[Image:images/actions/ActionsWeaving2.png]]
+|}
 
 ===Details===
 
-In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general.
-Let's look at the overall view again amd then dig into the details.
-
-[[Image:images/actions/ActionsBlocks.png]] 
-
+{| border="0"
+|-valign="top"
+|In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general. Again, the block diagram to the right provides an overview of how the various actions are related. You might want to take a look at the meta-class diagrams in the referernce section as well.
+|[[Image:images/actions/ActionsBlocks.png]] 
+|}
 
 ====Selections====
 
@@ -813,7 +830,11 @@
 #Keep your usage of external API references to a minimum. If you can use only code provied by the core Java classes as well as the Apache Collections library, your code should work on every current Java target. On the other hand, if you make use of a specific ABM platform APIs your code will obviously only compile and run against that target.
 #Code should be in the form of a method body, excluding the signature. A single Java method is created using this code body. There is no support for input parameters -- if you need access to evaluated values from source actions, create agent attributes for them, set their values for the selected agents, and use them as sources for your Method Action.
 #All Java class references should be fully qualified. For example, if you wish to use the eclipse Draw2D Graphics class, you should refer to "org.eclipse.draw2d.Graphics", not simply "Graphics". If classes are not fully qualified, you will recieve compile errors. You can usually easily fix these by selecting your source code directory and choosing '''Source > Organize Imports..''' but it prevents automatic code generation.
-#The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context: <pre>(new org.me.SpecialFileLoader()).load(this);</pre>Then create a new source directory in your project called "src" ('''New > Source Folder...''') and create the class for the specialized file loader including the following method: <pre>public void load(MyRootModel model) {...}</pre> This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.
+#The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context:
+ (new org.me.SpecialFileLoader()).load(this);
+Then create a new source directory in your project called "src" ('''New > Source Folder...''') and create the class for the specialized file loader including the following method:
+ public void load(MyRootModel model) {...}
+This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.
 
 ======Selection======
 
@@ -1360,13 +1381,13 @@
    
 ===Modeling Tree Editor===
 
-The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models incude textual languages and custom editors that are part of commercial offerings.
+The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models include textual languages and custom editors that are part of commercial offerings.
 
 ====Opening the Editor====
 
-To open a model in the editor, simply double-click on it. If the model doesn't open in the model editor (if for example it had been previously opened using another editor), you can always access the editor using '''Open With > Other...''' and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll dicuss at the end of this section.
+To open a model in the editor, simply double-click on it. If the model doesn't open in the model editor (if for example it had been previously opened using another editor), you can always access the editor using '''Open With > Other...''' and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll discuss at the end of this section.
 
-====Editing Structure====
+====Structure====
 
 The model is composed of nodes representing specific model entities such as agents, actions and spaces. For details about any of these entities, see the Concepts section.
 
@@ -1376,18 +1397,18 @@
 
 [[Image:images/tools/Editor.png]]
 
+=====Creating Components=====
+
+You add nodes by right-clicking on a node, like so:
+
+[[Image:images/tools/EditorAdd.png]]
+
 =====Editing Components=====
 
 To edit components, select the node you want to modify. The '''Properties View''' will be updated with the agent details. Use the properties view to modify the values. In the screenshot below, we're editing the values for the City space.
 
 [[Image:images/tools/EditorEditing.png]]
 
-=====Adding Components=====
-
-You add nodes by right-clicking on a node, like so:
-
-[[Image:images/tools/EditorAdd.png]]
-
 =====Moving Components=====
 
 You can often rearrange model components by dragging them from one place to another. In the following example, we're creating a model of a regional epidemic by creating a City sub-context and moving the agent into it: 
@@ -1396,7 +1417,7 @@
 
 =====Removing Components=====
 
-You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entitiy still exist.
+You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entity still exist.
 
 =====Copying Components=====
 
@@ -1414,15 +1435,25 @@
 
 [[Image:images/tools/EditorStyles.png]]
 
-====Editing Actions====
+====Actions====
 
-Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying strucuture of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.
+Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying structure of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.
 
 Like attributes and styles, every agent has a single Actions nodes which contains its Root Action(s).
 
+=====Creating Actions=====
+
+You create actions as with any other component, by right-clicking on the source action and choosing the new action. The menu is organized by usage.
+
+[[Image:images/tools/EditorActionMenu.png]]
+
+=====Editing Actions=====
+
+Actions and their inputs are edited just like any other model component. Click on the action or input you want to edit and then make changes to it in the properties editor.
+
 =====Order=====
 
-Generally, action sources will appear above their targets. In the case where there is only one source for a given target, and that target has no other sources, they will appear directly above one another. Its important to note however that ''the order of the nodes does not indicate a specific source and target relationship''. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part .
+Generally, action sources will appear above their targets. In the case where there is only one source for a given target, and that target has no other sources, they will appear directly above one another. Its important to note however that ''the order of the nodes does not indicate a specific source and target relationship''. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part of the label.
 
 [[Image:images/tools/ActionsExample.png]]
 
@@ -1446,7 +1477,7 @@
 
 =====Removing Actions=====
 
-You can remove actions in the same way as with strucutral model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from igh in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.
+You can remove actions in the same way as with structural model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from high in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.
 
 =====Copying Actions=====
 
@@ -1456,7 +1487,7 @@
 
 The number of inputs is determined by the selected functions. (In rare cases where a function can take an arbitrary number of arguments you may need to create additional values or delete existing ones.) In the following example, we're picking the Symptom Infectious status for a query that will affect the potentially exposed agents. Note that is instead you wanted to compare another kind of value -- for example an Integer value -- you would need to change the first input listed before changing the second input so that you will be able to get the appropriate options for the second.
  
-[[Image:images/tools/ActionsExample.png]]
+[[Image:images/tools/Inputs.png]]
 
 
 =====Input Literals=====
@@ -1528,19 +1559,16 @@
 ===Launching a Model (AMF)===
 
 
-When an AMF file is selected -- in any of the perspectives -- the pop-up menu looks like this:
-
-[[Image:images/tools/EditorMenu.png | left]]
-
-(In this case we've selected the "Execute Headless" option.) Note that the toolbar and Application menus are updated to reflect the file you've selected and can provide more convenient access to many of the functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. An important note: the execution framework doesn't know whether your code exists in an Escape project or anohter target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.
-
-[[Image:images/tools/EditorToolbar.png]]
-
-To launch a model, select one of the options.
+{| border="0"
+|-valign="top"
+|Launching AMF and Escape models is easy. When an AMF file is selected -- in any of the perspectives -- the toolbar and Application menus are updated to reflect the file you've selected and provide convenient access to other functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. If you right-click on a file a pop-up menu appears like the one to the far right -- in this case we're selecting the "Execute Headless" option. To launch a model, just select one of the options. (Note that the execution framework doesn't know whether your code exists in an Escape project or another target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.)
+|[[Image:images/tools/EditorToolbar.png]]
+|[[Image:images/tools/EditorMenu.png]]
+|}
 
 One a model has been launched, the Agent Execution Perspective automatically becomes active. The Provides a custom layout menus and tools specific to executing agent models.
 
-[[Image:images/execution/EpidemicModelRunning.png]]
+[[Image:images/execution/EpidemicExecNew.png]]
 
 The execution options are:
 
@@ -1858,7 +1886,7 @@
 
 The first part of the Bug Rule is exactly the same as the Initialize rule. Create a Selection Action. As before, we'll make the Select statement "Agent" property blank, as we want to move to a cell. As before, we want to make sure the Cell is free before we try to move in, so we'll select a "Spatial: Available" Query function.(By the way, to make scrolling through the list easier, you can type the first letters of the selection, in this case "SP".)
 
-But now, instead of moving <i>anywhere</i> we want to move nearby. So now, we create a ''parallel'' or "sibling" Query from the same Select root. Because this new Query Action is a child of the Select Action and not the "Space Available" Query we've just created, we'll right-click on the ''Select'' Action and choose '''Create Target > Select > Query'''. Like so:
+But now, instead of moving ''anywhere'' we want to move nearby. So now, we create a ''parallel'' or "sibling" Query from the same Select root. Because this new Query Action is a child of the Select Action and not the "Space Available" Query we've just created, we'll right-click on the ''Select'' Action and choose '''Create Target > Select > Query'''. Like so:
 
 [[Image:images/edit_tutorial/SimpleTutorial26CreateQuery2.png | right]]
 
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.xml b/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.xml
index 3eb524a..d122283 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.xml
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/build/amp.xml
@@ -49,8 +49,8 @@
 			<para>Existing scientific models are very good at representing relatively simple systems, but generally speaking aren't very good at representing complex systems. The world is full of complex systems, and our misunderstanding of these systems has prevented us from addressing many of the key challenges facing the world, including the global financial crisis and climate change -- in fact once could argue that our misunderstanding of these systems has strongly contributed to these crises.</para>
 			<para>Agent-Based Models (ABMs) seek to represent important real-world dynamics by designing communities of software agents that mimic real entities. Rather than make simplifying assumptions about such systems and then representing them in equation form or as off the shelf algorithmic constructs, the ABM researcher aims to identify key agent state, interaction spaces, and behaviors. Agents are then "let loose" on our computers and we explore what happens next. The computational horsepower exists today to simulate large numbers (e.g. &gt;&gt;10) of interacting, adaptive and autonomous agents but often desktop computers are all we need to explore significant domains. ABMs have been designed to represent all kinds of important natural systems, at scales reaching from cellular mechanics to international trade and are being used to solve truly hard problems in government, business, and academia. ABMs are not a solution to every problem, but they can help us to appreciate and gain unique insight into many systems, and often they can help us to come up with better practical decisions than we might using classic approaches.</para>
 		</section>
-		<section id=".3DOther_Uses">
-			<title>=Other Uses</title>
+		<section id="Other_Uses">
+			<title>Other Uses</title>
 			<para>Many kinds of objects share characteristics of ABM agents -- after all, software agents are used in many other contexts. The Agent Modeling Framework meta-modeling support is potentially suitable (or extendible) for a number of approaches outside of ABM; for example business rules, object interactions, systems dynamics models and traditional discrete event models. Similarly, AMP execution and graphic support can be used for modeling natural systems but could also be used to manage other software agents -- for example independent reasoning tasks or dynamic visualization support.</para>
 		</section>
 		<section id="Credits">
@@ -442,50 +442,65 @@
 				<para>In this section, we'll describe how modelers can assemble actions into sets of behavior that accomplish complex tasks on interrelated agents and spaces over time.</para>
 				<section id="Kinds_of_Actions">
 					<title>Kinds of Actions</title>
-					<para>Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. All of these are discussed in detail in the section that follows this one.</para>
-					<para>These are all summarized in the diagram below:</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsBlocks.png"/>
-							</imageobject>
-						</mediaobject> 
-					</para>
+					<informaltable>
+						<tr>
+							<td>Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. The various actions are discussed in depth in the Details section.</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsBlocks.png"/>
+									</imageobject>
+								</mediaobject> 
+							</td>
+						</tr>
+					</informaltable>
 				</section>
 				<section id="Flow">
 					<title>Flow</title>
 					<para>First, let's look at how actions define the basic path that agents take during a model run. As with any programming language, the path we take through the program specification is what determines our state when we get there. In a pure object oriented program, the path just defines the control flow -- what we are doing. The actual state of our model is defined within the object itself. If we call a method B from another method A, we'll be relying on method A to set the values that we need into the object state itself. In a purely functional program the path defines how we are going to deal with whatever has been explicitly passed in to a function that has been called, that is the function parameters. In fact, most languages such as Java combine aspects of both approaches.</para>
-					<para>In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.</para>
-					<para>An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically 
+					<para>In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.
+						An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically 
 						<emphasis role="italic">need</emphasis> loop structures. By far the most common use of loops in conventional programming langauges is to loop through collections of objects. As selections (see below) refer to the entire collection of agents, any actions on a selection apply to all members of that collection. Recursive structures are needed for some particular usages and will be supported in future releases, but not through an explicit looping construct.
 					</para>
-					<para>Again, behaviors in Actions are always defined by a set of 
-						<emphasis role="italic">selections</emphasis> and 
-						<emphasis role="italic">queries</emphasis>. In the following diagram, we can see the pattern.
-					</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsSequence.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
-					<para>First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent. The next diagram depicts a simple example.</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsSimpleSequence.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
-					<para>Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them. In the next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsSimpleSequence2.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
+					<informaltable>
+						<tr>
+							<td>Again, behaviors in Actions are always defined by a set of 
+								<emphasis role="italic">selections</emphasis> and 
+								<emphasis role="italic">queries</emphasis>. In the diagram to the right, we can see the pattern. First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent.
+							</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSequence.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable>
+						<tr>
+							<td>The diagram to the right depicts a simple example. Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them.</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSimpleSequence.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable>
+						<tr>
+							<td>In this next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSimpleSequence2.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
 					<para>In the following example, we've defined a set of actions and their relationships. We have a selection, a few queries and a couple of logic operators leading to a Set Action. We'll describe in detail below how Logic Actions are used in conjunction with other actions to assemble any kind of query structure needed. But for now, we'll focus on the control flow itself.</para>
 					<para>
 						<mediaobject>
@@ -522,23 +537,31 @@
 				<section id="Selections">
 					<title>Selections</title>
 					<para>Selections are a key concept in Actions. Put simply, selections define what we are searching for and where. They are defined by a combination of Select, Query and Logic Actions. Each time we create a new Select Action, we define a new selection. Queries can be used to further refine selections either immediately after or later in the Action flow, as described in the next section. Logic Actions are used to combine and organize the Action flow defined by Query Actions. In order to understand how these three pieces work together, we need to understand the idea of selection boundaries.</para>
-					<para>A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsSelBoundarySimple.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
-					<para>Each time we create a new selection, we define a new set of boundaries.</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsSelBoundary2Parts.png"/>
-							</imageobject>
-						</mediaobject> 
-					</para>
-					<para>A very important aspect of boundaries is that they apply to a group of actions that begin with a Query Action, and not just such a group that begins with a Select Action. This is because Query Actions can be directly part of a selection definition, but they can also refine selections, as we'll see. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:</para>
+					<informaltable>
+						<tr>
+							<td>A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSelBoundarySimple.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable>
+						<tr>
+							<td>Each time we create a new selection, we define a new set of boundaries. In the diagram to the right, Selection 1 and Selection 2 eaach start with a new Select Action. </td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSelBoundary2Parts.png"/>
+									</imageobject>
+								</mediaobject> 
+							</td>
+						</tr>
+					</informaltable>
+					<para>But boundaries can be defined for a group of actions by a Query Actions as well. This is because Query Actions can be directly part of a selection definition, but they can also refine selections. We'll see how that works below. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:</para>
 					<orderedlist>
 						<listitem>
 							<para>A Query Action is not followed by a Logic Action, or</para>
@@ -547,14 +570,18 @@
 							<para>A Logic Action is not followed by another Logic Action</para>
 						</listitem>
 					</orderedlist>
-					<para>In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as we can see in the following example. </para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsSelBoundary11A.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
+					<informaltable>
+						<tr>
+							<td>In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as shown in the example to the right. </td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSelBoundary11A.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
 					<para>Note that we refer to "Selection 1" and Selection 1A". This is because Selection 1A is a refinement of Selection 1 along its particular path of flow. When a query appears for the same selection but past a particular boundary, you can think of it as a sort of filter on the selection contents. We don't have a "Selection 2" here because any Actions that refer to "Selection 1" along the current path of flow will be acting on the selection defined by Selection 1 and Selection 1A.</para>
 					<para>These rules allow actions to be defined in the simplest possible way, but it is important to understand their implication as they result in behavior that can be different from what someone used to and imperative programming environment such as Java might expect. In a simple case the distinction might not matter. For example, if we are using a Query 1 to test whether an agent's attribute a == x and attribute b == y, we would get the same outcome if we placed intersected the queries as if we simply put them in sequence. Internally we would actually be searching for agents with a == x, and 
 						<emphasis role="italic">then</emphasis> taking those agents and choosing those agents with b==y, but the outcome would be the same. But consider a more sophisticated case, where we are searching for neighboring available cells.
@@ -572,52 +599,70 @@
 				</section>
 				<section id="Weaving">
 					<title>Weaving</title>
-					<para>Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsWeavingSetAnother.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
-					<para>Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsWeavingEvaluate.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
-					<para>But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsWeaving1A.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
-					<para>Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Now, consider the following example:</para>
-					<para>
-						<mediaobject>
-							<imageobject>
-								<imagedata fileref="images/actions/ActionsWeaving2.png"/>
-							</imageobject>
-						</mediaobject>
-					</para>
-					<para>Before going into further details we need to introduce one more important concept. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.</para>
+					<informaltable>
+						<tr>
+							<td>Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeavingSetAnother.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable>
+						<tr>
+							<td>Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeavingEvaluate.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable>
+						<tr>
+							<td>But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeaving1A.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable>
+						<tr>
+							<td>Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Consider the example to the right. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.</td>
+							<td>
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeaving2.png"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
 				</section>
 			</section>
 			<section id="Details_3">
 				<title>Details</title>
-				<para>In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general.
-					Let's look at the overall view again amd then dig into the details.</para>
-				<para>
-					<mediaobject>
-						<imageobject>
-							<imagedata fileref="images/actions/ActionsBlocks.png"/>
-						</imageobject>
-					</mediaobject> 
-				</para>
+				<informaltable>
+					<tr>
+						<td>In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general. Again, the block diagram to the right provides an overview of how the various actions are related. You might want to take a look at the meta-class diagrams in the referernce section as well.</td>
+						<td>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/actions/ActionsBlocks.png"/>
+								</imageobject>
+							</mediaobject> 
+						</td>
+					</tr>
+				</informaltable>
 				<section id="Selections_2">
 					<title>Selections</title>
 					<para>A selection defines a particular set of agents that we want to do something with. Selections are made up of the Select action itself, along with Query and Logic actions. When we refer to a selection in any target command, we are referring to the selection in the context of where we have defined the behavior.</para>
@@ -993,11 +1038,17 @@
 								</para>
 							</listitem>
 							<listitem>
-								<para>The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context: <pre>(new org.me.SpecialFileLoader()).load(this);</pre>Then create a new source directory in your project called "src" (
-									<emphasis role="bold">New &gt; Source Folder...</emphasis>) and create the class for the specialized file loader including the following method: <pre>public void load(MyRootModel model) {...}</pre> This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.
-								</para>
+								<para>The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context:</para>
 							</listitem>
 						</orderedlist>
+						<literallayout>(new org.me.SpecialFileLoader()).load(this);
+</literallayout>
+						<para>Then create a new source directory in your project called "src" (
+							<emphasis role="bold">New &gt; Source Folder...</emphasis>) and create the class for the specialized file loader including the following method:
+						</para>
+						<literallayout>public void load(MyRootModel model) {...}
+</literallayout>
+						<para>This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.</para>
 						<section id="Selection_14">
 							<title>Selection</title>
 							<para>The selection determines what Agent class the code will be created within and the set of agents the method will be called upon.</para>
@@ -1981,15 +2032,15 @@
 			</section>
 			<section id="Modeling_Tree_Editor">
 				<title>Modeling Tree Editor</title>
-				<para>The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models incude textual languages and custom editors that are part of commercial offerings.</para>
+				<para>The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models include textual languages and custom editors that are part of commercial offerings.</para>
 				<section id="Opening_the_Editor">
 					<title>Opening the Editor</title>
 					<para>To open a model in the editor, simply double-click on it. If the model doesn't open in the model editor (if for example it had been previously opened using another editor), you can always access the editor using 
-						<emphasis role="bold">Open With &gt; Other...</emphasis> and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll dicuss at the end of this section.
+						<emphasis role="bold">Open With &gt; Other...</emphasis> and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll discuss at the end of this section.
 					</para>
 				</section>
-				<section id="Editing_Structure">
-					<title>Editing Structure</title>
+				<section id="Structure_2">
+					<title>Structure</title>
 					<para>The model is composed of nodes representing specific model entities such as agents, actions and spaces. For details about any of these entities, see the Concepts section.</para>
 					<section id="Opening_Components">
 						<title>Opening Components</title>
@@ -2002,6 +2053,17 @@
 							</mediaobject>
 						</para>
 					</section>
+					<section id="Creating_Components">
+						<title>Creating Components</title>
+						<para>You add nodes by right-clicking on a node, like so:</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorAdd.png"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
 					<section id="Editing_Components">
 						<title>Editing Components</title>
 						<para>To edit components, select the node you want to modify. The 
@@ -2015,17 +2077,6 @@
 							</mediaobject>
 						</para>
 					</section>
-					<section id="Adding_Components">
-						<title>Adding Components</title>
-						<para>You add nodes by right-clicking on a node, like so:</para>
-						<para>
-							<mediaobject>
-								<imageobject>
-									<imagedata fileref="images/tools/EditorAdd.png"/>
-								</imageobject>
-							</mediaobject>
-						</para>
-					</section>
 					<section id="Moving_Components">
 						<title>Moving Components</title>
 						<para>You can often rearrange model components by dragging them from one place to another. In the following example, we're creating a model of a regional epidemic by creating a City sub-context and moving the agent into it: </para>
@@ -2039,7 +2090,7 @@
 					</section>
 					<section id="Removing_Components">
 						<title>Removing Components</title>
-						<para>You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entitiy still exist.</para>
+						<para>You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entity still exist.</para>
 					</section>
 					<section id="Copying_Components">
 						<title>Copying Components</title>
@@ -2068,14 +2119,29 @@
 						</para>
 					</section>
 				</section>
-				<section id="Editing_Actions">
-					<title>Editing Actions</title>
-					<para>Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying strucuture of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.</para>
+				<section id="Actions_3">
+					<title>Actions</title>
+					<para>Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying structure of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.</para>
 					<para>Like attributes and styles, every agent has a single Actions nodes which contains its Root Action(s).</para>
+					<section id="Creating_Actions">
+						<title>Creating Actions</title>
+						<para>You create actions as with any other component, by right-clicking on the source action and choosing the new action. The menu is organized by usage.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorActionMenu.png"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Editing_Actions">
+						<title>Editing Actions</title>
+						<para>Actions and their inputs are edited just like any other model component. Click on the action or input you want to edit and then make changes to it in the properties editor.</para>
+					</section>
 					<section id="Order">
 						<title>Order</title>
 						<para>Generally, action sources will appear above their targets. In the case where there is only one source for a given target, and that target has no other sources, they will appear directly above one another. Its important to note however that 
-							<emphasis role="italic">the order of the nodes does not indicate a specific source and target relationship</emphasis>. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part .
+							<emphasis role="italic">the order of the nodes does not indicate a specific source and target relationship</emphasis>. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part of the label.
 						</para>
 						<para>
 							<mediaobject>
@@ -2104,7 +2170,7 @@
 					</section>
 					<section id="Removing_Actions">
 						<title>Removing Actions</title>
-						<para>You can remove actions in the same way as with strucutral model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from igh in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.</para>
+						<para>You can remove actions in the same way as with structural model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from high in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.</para>
 					</section>
 					<section id="Copying_Actions">
 						<title>Copying Actions</title>
@@ -2116,7 +2182,7 @@
 						<para>
 							<mediaobject>
 								<imageobject>
-									<imagedata fileref="images/tools/ActionsExample.png"/>
+									<imagedata fileref="images/tools/Inputs.png"/>
 								</imageobject>
 							</mediaobject>
 						</para>
@@ -2239,28 +2305,30 @@
 			<title>Exploring</title>
 			<section id="Launching_a_Model_.28AMF.29">
 				<title>Launching a Model (AMF)</title>
-				<para>When an AMF file is selected -- in any of the perspectives -- the pop-up menu looks like this:</para>
-				<para>
-					<mediaobject>
-						<imageobject>
-							<imagedata fileref="images/tools/EditorMenu.png "/>
-						</imageobject>
-					</mediaobject>
-				</para>
-				<para>(In this case we've selected the "Execute Headless" option.) Note that the toolbar and Application menus are updated to reflect the file you've selected and can provide more convenient access to many of the functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. An important note: the execution framework doesn't know whether your code exists in an Escape project or anohter target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.</para>
-				<para>
-					<mediaobject>
-						<imageobject>
-							<imagedata fileref="images/tools/EditorToolbar.png"/>
-						</imageobject>
-					</mediaobject>
-				</para>
-				<para>To launch a model, select one of the options.</para>
+				<informaltable>
+					<tr>
+						<td>Launching AMF and Escape models is easy. When an AMF file is selected -- in any of the perspectives -- the toolbar and Application menus are updated to reflect the file you've selected and provide convenient access to other functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. If you right-click on a file a pop-up menu appears like the one to the far right -- in this case we're selecting the "Execute Headless" option. To launch a model, just select one of the options. (Note that the execution framework doesn't know whether your code exists in an Escape project or another target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.)</td>
+						<td>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorToolbar.png"/>
+								</imageobject>
+							</mediaobject>
+						</td>
+						<td>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorMenu.png"/>
+								</imageobject>
+							</mediaobject>
+						</td>
+					</tr>
+				</informaltable>
 				<para>One a model has been launched, the Agent Execution Perspective automatically becomes active. The Provides a custom layout menus and tools specific to executing agent models.</para>
 				<para>
 					<mediaobject>
 						<imageobject>
-							<imagedata fileref="images/execution/EpidemicModelRunning.png"/>
+							<imagedata fileref="images/execution/EpidemicExecNew.png"/>
 						</imageobject>
 					</mediaobject>
 				</para>
@@ -2598,7 +2666,7 @@
 					</para>
 				</section>
 			</section>
-			<section id="Structure_2">
+			<section id="Structure_3">
 				<title>Structure</title>
 				<section id="Bug_Agent">
 					<title>Bug Agent</title>
@@ -2717,7 +2785,7 @@
 					</section>
 				</section>
 			</section>
-			<section id="Actions_3">
+			<section id="Actions_4">
 				<title>Actions</title>
 				<section id="Create_Initialize_Rule">
 					<title>Create Initialize Rule</title>
@@ -2863,7 +2931,8 @@
 					<section>
 						<title>Create Select and Query Actions</title>
 						<para>The first part of the Bug Rule is exactly the same as the Initialize rule. Create a Selection Action. As before, we'll make the Select statement "Agent" property blank, as we want to move to a cell. As before, we want to make sure the Cell is free before we try to move in, so we'll select a "Spatial: Available" Query function.(By the way, to make scrolling through the list easier, you can type the first letters of the selection, in this case "SP".)</para>
-						<para>But now, instead of moving <i>anywhere</i> we want to move nearby. So now, we create a 
+						<para>But now, instead of moving 
+							<emphasis role="italic">anywhere</emphasis> we want to move nearby. So now, we create a 
 							<emphasis role="italic">parallel</emphasis> or "sibling" Query from the same Select root. Because this new Query Action is a child of the Select Action and not the "Space Available" Query we've just created, we'll right-click on the 
 							<emphasis role="italic">Select</emphasis> Action and choose 
 							<emphasis role="bold">Create Target &gt; Select &gt; Query</emphasis>. Like so:
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/build/ampPDF.xml b/org.eclipse.amp/doc/org.eclipse.amp.doc/build/ampPDF.xml
new file mode 100644
index 0000000..ba9f987
--- /dev/null
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/build/ampPDF.xml
@@ -0,0 +1,3364 @@
+<?xml version="1.0" encoding="UTF-8"?><book>
+	<title>Agent Modeling Guide</title>
+	<chapter id="Introduction">
+		<title>Introduction</title>
+		<para>In this manual we provide an in-depth understanding of what goes into an Agent Model, how you can use the Agent Modeling Framework and related tools to design one and present tutorials to get you started. But before going into details, let's take a quick overview at what agent-based modeling is is and how the Agent Modeling Framework can help you to develop models for ABM or other problem domains.</para>
+		<para>We hope you enjoy using the tool, and we look forward to your comments and feedback and most of all participation!</para>
+		<section id="Agent-Based_Modeling">
+			<title>Agent-Based Modeling</title>
+			<para>The primary focus of the Agent Modeling Platform tools is "Agent-Based Modeling" (ABM). ABM is an innovative technique used to explore complex phenomenon in many domains, including economics, social sciences, biomedicine, ecology and business operations. ABMs share characteristics with object models, but are:</para>
+			<variablelist>
+				<varlistentry>
+					<term>Spatial</term>
+					<listitem>
+						<para>Models have explicit environment(s) in which agents interact. (An environment need not be a physical landscape; other examples of spatial relationships include social networks or positions within a logic system.)</para>
+					</listitem>
+				</varlistentry>
+				<varlistentry>
+					<term>Temporal</term>
+					<listitem>
+						<para>Models change over discrete units of time.</para>
+					</listitem>
+				</varlistentry>
+				<varlistentry>
+					<term>Autonomous</term>
+					<listitem>
+						<para>Agent behaviors are activated independently from other object requests.</para>
+					</listitem>
+				</varlistentry>
+				<varlistentry>
+					<term>Heterogeneous</term>
+					<listitem>
+						<para>Agents may share behavior definitions but have apparent and distinct states and behaviors.</para>
+					</listitem>
+				</varlistentry>
+				<varlistentry>
+					<term>Collective</term>
+					<listitem>
+						<para>Models contain large communities of agents which exhibit collaborative and competitive behaviors.</para>
+					</listitem>
+				</varlistentry>
+				<varlistentry>
+					<term>Emergent</term>
+					<listitem>
+						<para>Agents have collective macro-behaviors that are non-obvious from agent micro-specifications.</para>
+					</listitem>
+				</varlistentry>
+			</variablelist>
+			<para>Existing scientific models are very good at representing relatively simple systems, but generally speaking aren't very good at representing complex systems. The world is full of complex systems, and our misunderstanding of these systems has prevented us from addressing many of the key challenges facing the world, including the global financial crisis and climate change -- in fact once could argue that our misunderstanding of these systems has strongly contributed to these crises.</para>
+			<para>Agent-Based Models (ABMs) seek to represent important real-world dynamics by designing communities of software agents that mimic real entities. Rather than make simplifying assumptions about such systems and then representing them in equation form or as off the shelf algorithmic constructs, the ABM researcher aims to identify key agent state, interaction spaces, and behaviors. Agents are then "let loose" on our computers and we explore what happens next. The computational horsepower exists today to simulate large numbers (e.g. &gt;&gt;10) of interacting, adaptive and autonomous agents but often desktop computers are all we need to explore significant domains. ABMs have been designed to represent all kinds of important natural systems, at scales reaching from cellular mechanics to international trade and are being used to solve truly hard problems in government, business, and academia. ABMs are not a solution to every problem, but they can help us to appreciate and gain unique insight into many systems, and often they can help us to come up with better practical decisions than we might using classic approaches.</para>
+		</section>
+		<section id="Other_Uses">
+			<title>Other Uses</title>
+			<para>Many kinds of objects share characteristics of ABM agents -- after all, software agents are used in many other contexts. The Agent Modeling Framework meta-modeling support is potentially suitable (or extendible) for a number of approaches outside of ABM; for example business rules, object interactions, systems dynamics models and traditional discrete event models. Similarly, AMP execution and graphic support can be used for modeling natural systems but could also be used to manage other software agents -- for example independent reasoning tasks or dynamic visualization support.</para>
+		</section>
+		<section id="Credits">
+			<title>Credits</title>
+			<para>Miles Parker is a consultant and software developer with over ten years of experience in the agent-based modeling field and twenty years developing object-oriented tools and frameworks and is the architect and project lead for the Eclipse Agent Modeling Platform (Incubation).</para>
+			<para>Metascape, LLC is the primary contributor to AMP and provides Agent-Based Modeling tools, including sophisticated tools based on the AMF platform, and comprehensive consulting services. For more information on Metascape products and services visit 
+				<ulink url="http://metascapeabm.com">http://metascapeabm.com</ulink>.
+			</para>
+			<para>The AMF meta-model started life as 
+				<ulink url="/wiki/http://www.agent2005.anl.gov/2006procpdf/Parker_Agent_2006.pdf">"score"</ulink>, a component of the Repast Simphony environment. Argonne National Labs supported the initial development in 2007 and agreed to contribute the relevant IP to the Eclipse project in 2009. It wasn't fully utilized within Simphony, and migrated from there to the MetaABM project supported by Metascape. The MetaABM project defined a complete editor, code-generation and model execution suite that formed the initial AMP AMF contribution. Metascape has sponsored the development of AMF from 2007 through the present.
+			</para>
+			<para>The AMP logo was inspired by the 
+				<ulink url="/wiki/http://swarm.org_Swarm_logo">http://swarm.org Swarm logo</ulink> with their kind permission.
+			</para>
+		</section>
+		<section id="The_Agent_Modeling_Platform_.28AMP.29">
+			<title>The Agent Modeling Platform (AMP)</title>
+			<para>The Eclipse Agent Modeling Project (Incubation) or "AMP" provides extensible frameworks and exemplary tools for representing, editing, generating,
+				executing and visualizing agent-based models (ABMs) and any other domain requiring spatial, behavioral and functional features. AMP has two main themes that complement but don't depend on one another, modeling of agent systems (AMF) and execution and exploration of those systems (AXF, AGF and Escape).</para>
+			<para>The overall AMP architecture and project dependencies are summarized in the architectural diagram below:</para>
+			<para>
+				<mediaobject>
+					<imageobject>
+						<imagedata fileref="images/AMPArchitectureDiagram.jpg" scale="50"/>
+					</imageobject>
+				</mediaobject>
+			</para>
+			<section id="Agent_Modeling_Framework_.28AMF.29">
+				<title>Agent Modeling Framework (AMF)</title>
+				<para>AMF provides an ABM meta-model representation, editor, generator and development environment. The AMF Acore meta-model is similar to EMF Ecore and defined in Ecore, but provides high-level support for complex agents.AMF generates complete executable models for Escape, Ascape and Repast Simphony, as well as Java Skeletons and Interfaces, JUnit test cases and documentation and is easily extensible to support additional targets. For more on AMF, see the Modeler Guide.</para>
+			</section>
+			<section id="Agent_Execution_Framework_.28AXF.29">
+				<title>Agent Execution Framework (AXF)</title>
+				<para>The execution framework provides services and UI for model management, execution, and views. Arbitrary toolkits can easily integrate with Eclipse and AXF by implementing pluggable providers like engines, agents and view parts. AXF is not just for ABM -- anyone who needs support for executing, managing and visualizing collections of objects may find it useful. AXF user tools are covered extensively in the User Guide, and the forthcoming Platform Developers Guide will provide information about integrating AXF in your own tools.</para>
+			</section>
+			<section id="Agent_Graphics_Framework_.28AGF.29">
+				<title>Agent Graphics Framework (AGF)</title>
+				<para>The graphics framework extends GEF, GEF3D, Zest, and the BIRT charting engine to support real-time visualization of and interaction with agent models. AGF currently provides support for 2D, 2 1/2 D. and graph structures, and will be extended to 3-D, GIS and others. As with other AMP components, the AGF design focus is to provide an extensible infrastructure so that platform adopters can easily create their own view and editor parts. AGF user tools are covered extensively in the User Guide, and the forthcoming Platform Developers Guide will provide information about integrating and extending AGF in your own tools.</para>
+			</section>
+			<section id="Escape">
+				<title>Escape</title>
+				<para>Escape is an exemplar ABM toolset. It's based on Ascape, which has been in use for more than 10 years. The core API is very stable, and that should give users a way to explore the features of AMP without concerns about keeping in synch with the rapidly evolving AXF /AGF API. It allows modelers to code in Java and/or generate models with AMF and then execute those models within the same development environment. Escape is the primary target for most of the models in this guide. Those users interested in writing code directly to the Escape API can refer to the Programmer Guide.</para>
+			</section>
+		</section>
+		<section id="Getting_Started">
+			<title>Getting Started</title>
+			<para>AMP has many potential facets and use cases.</para>
+			<section id="Setting_up_Eclipse">
+				<title>Setting up Eclipse</title>
+				<para>If you're reading this from the Eclipse help browser, you've already done this! Otherwise, if you aren't using a full download version of AMP, you'll need to 
+					<ulink url="http://eclipse.org/amp/installing/">install it</ulink>. Once you've done that, select the 
+					<emphasis role="bold">Help &gt; Help Contents</emphasis> menu, find the Agent Modeling Guide and open this overview page within that guide.
+				</para>
+				<para>Some installations will also include a Welcome screen which will guide you through the same set of steps.</para>
+			</section>
+			<section id="Get_the_Example_Projects">
+				<title>Get the Example Projects</title>
+				<para>You can do that using a cheat sheet. Select 
+					<emphasis role="bold">Help &gt; Cheat Sheets...</emphasis> and then under the "Agent Modeling" category, select "Load Sample Projects".
+				</para>
+				<para>Then check out the following sections of the manual for more information about..</para>
+			</section>
+			<section id="ABM_Researchers">
+				<title>ABM Researchers</title>
+				<para>Run an example model using the "Run an Example Model" cheat sheet.</para>
+			</section>
+			<section id="ABM_Modelers">
+				<title>ABM Modelers</title>
+				<para>Create Agent-Based models using simple visual tools and deploy them to a number of popular ABM platforms, including Escape. Follow the tutorial section of the Modeler's guide.</para>
+			</section>
+			<section id="ABM_Java_Developers">
+				<title>ABM Java Developers</title>
+				<para>Write "Plain Old Java" models within a full-featured agent-based modeling framework. Read Programmers Guide and then try the "Create an Escape Java Model" cheat sheet.</para>
+			</section>
+			<section id="Eclipse_Plugin_Developers">
+				<title>Eclipse Plugin Developers</title>
+				<para>AXF and AGF provide a number of features based around Eclipse technologies such as GEF, GEF3D, BIRT Charts and Zest. For example, AGF supports dynamic visualization of objects in space, and AXF supports managed UI and headless execution for models of any kind. There isn't currently any general documentation for these features, but we encourage you to look at the APIs and at Escape's implementation of them. They're straightforward and can be useful for a variety of general science platform needs.</para>
+			</section>
+		</section>
+	</chapter>
+	<chapter id="Modeler_Guide">
+		<title>Modeler Guide</title>
+		<section id="Overview">
+			<title>Overview</title>
+			<para>In this section we present the design of the Agent Modeling Framework and explain how it can be used to create models that are transparent, composable and adaptable. Fundamentally, an agent-based model, or "ABM", is composed of five pieces: Agents and Context Agents, Attributes, Spaces, and Actions. The first three refer to structural components, whereas Actions define behavior. Agent models also have styles, which are a special kind of Action used to determine how to portray an agent in a visualization. Finally Actions make use of Functions. We'll describe of these components in a separate section.</para>
+			<section id="Agent_Modeling_Framework">
+				<title>Agent Modeling Framework</title>
+				<para>The Eclipse Platform provides many unique features that make it ideal for an ABM platform. AMF provides easy to use and powerful tools and techniques for designing Agent-Based Models, including a common representation, editors, generators and development environment.</para>
+				<para>The Agent Modeling Framework (AMF) provides high level representations for common ABM constructs, and introduces novel ways of representing agents and their behaviors. As detailed in other documentation sections, the Agent Modeling Framework and related tools have been designed to allow researchers to explore complex models in an intuitive way. One of our major design goals has been to create tools that non-programmers can use to create sophisticated models. It has been our experience that using Model-Driven Software Development (MDSD) techniques increase productivity for all developers regardless of skill level. </para>
+				<para>The foundation of the Agent Modeling Framework is "Acore". The current version uses an interim version of Acore called "MetaABM". We refer to the AMF models as "meta-models" because they are used to define 
+					<emphasis role="italic">how</emphasis> Agent-Based Models are themselves modeled. For those familiar with Eclipse Model-Driven Development tools, AMF is analogous to EMF but is targeted toward the design and execution of models composed of agents. Acore and MetaABM are defined in Ecore but provide a more direct and high-level ABM representation of agents, including spatial, behavioral and functional features sufficient to generate complete executable models for the target platforms. AMF is fully integrated with the Eclipse IDE platform, but Acore models themselves need have no dependencies on any particular technology beyond XML/XSD.
+				</para>
+				<para>Models designed in AMF are transparently converted to Java code for leading Agent-Based Modeling tools, such as the Escape tools which are included in AMP and allow direct execution of models within the AMP environment, and Repast Simphony, another popular Java based ABM tool. These tools create Java code that can then be compiled, executed and event modified in these environments just as with any other Java program. AMF's generative capability is designed to be pluggable and modular so that other developers can create AMF generators for their own tools. In fact, targets can be designed that have no inherent dependencies on Eclipse or even on a traditional platform.</para>
+				<para>The Acore / MetaABM meta-model is made up of three main packages. This is all based on MetaABM, and while names and important details will change for Acore, the core design should be quite similar.</para>
+			</section>
+		</section>
+		<section id="Structure">
+			<title>Structure</title>
+			<section id="Overview_2">
+				<title>Overview</title>
+				<para>The basic structure of an agent-based model can be quite simple. While there are many subtle complexities  -- beyond the scope of this manual -- we can construct most models following some straightforward and elegant design principles. And in fact, one of the main goals of the Agent Modeling Framework is to provide a consistent framework that can support using those principles to support the creation of models that can be easily understood, shared, and that can be used interchangeably as components in other models.</para>
+				<para>Unlike the approach of a traditional Object Oriented environment, the dominant organizing principal for agents within AMF follows a compositional hierarchical model, not an inheritance model. (Inheritance-like behavior will be supported in forthcoming versions of Acore, but in a more sophisticated, flexible and dynamic way than is supported by traditional programming languages such as Java.) Contexts -- also referred to as "Swarms" or "Scapes", are simply Agents that are capable of containing other agents. With this basic construct -- known as a Composition in design pattern language -- agents are able to contain other agents.</para>
+			</section>
+			<section id="Details">
+				<title>Details</title>
+				<section id="General">
+					<title>General</title>
+					<para>Everything represented in an Acore model needs to be referred to in some way. Just as software classes have names, Acore provides a way to label and describe every entity, but in a richer and more maintainable way. All entities in Acore -- including Actions and Functions which we describe in the next two sections -- have a number of shared values.</para>
+					<section id="Named_Entities">
+						<title>Named Entities</title>
+						<section id="Label">
+							<title>Label</title>
+							<para>A reasonably short, human readable name for the agent. For example, "Timber Wolf", "Exchange Trader" or "Movement Probability". These should be defined so that they fit in well with auto-generated documentation. Note that Labels must be unique throughout the model. (This may change in future releases for Action names.) If you try to provide an object with a name that is already in use, "Copy" will be appended to the end of the name. </para>
+						</section>
+						<section id="ID">
+							<title>ID</title>
+							<para>An ID is an identifier that can be used to represent the object in a software program. This means that it must follow certain rules such as no-spaces or non alpha-numeric characters. The editing tools will help make sure that this value is legal. Note that when you enter a label, a legal ID is automatically created for you! Usually you won't need to change this, but you might if for example you want the value to match up with some database or other external representation. So reasonable values here might be "timberWolf" or perhaps "MVMNT_PRB" if say you're trying to match up to some old statistics records you have. (Note that currently IDs by default use "camel case", i.e. "thisIsAnExampleOfCamelCase" to match with Java variable naming conventions, but this is likely to change.) Like labels, IDs need to be unique across the model, and the editing tools will assign a different id if you attempt to give two entities the same id.</para>
+							<para>And most entities also define:</para>
+						</section>
+						<section id="Description">
+							<title>Description</title>
+							<para>A complete textual description of the object. Don't overlook this -- it is the most important part of your model. The description will show up in your auto-generated html documentation, software documentation and even in your running model. You should include enough information that model users will understand what the entity is for and what it does without referring elsewhere. This is also where any attributions and references should go. You can put html tags in here -- such as href's to external papers, but keep those to a minimum as they won't be rendered as html in all contexts.</para>
+						</section>
+						<section id="Plural_Label">
+							<title>Plural Label</title>
+							<para>The plural representation of an entity. This can be a surprisingly useful thing to have in generated documentation and software code, so it's worth maintaining. The editor will automatically add an "s" at the end of the label you've entered above, but you change it to whatever is appropriate. For example "Person", or "Timber Wolves".</para>
+						</section>
+					</section>
+				</section>
+				<section id="Agents">
+					<title>Agents</title>
+					<section id="Simple_Agents">
+						<title>Simple Agents</title>
+						<para>An Agent is simply a software object that has autonomous behavior and (generally speaking) exists within some set of spaces. By autonomous, we mean that agents make the choice about when and how to execute a behavior, as opposed to have that controlled from "above", so to speak. Like any software objects, agents have attributes (fields) and actions (methods) associated with them.</para>
+						<section id="Attributes">
+							<title>Attributes</title>
+							<para>As described in the attribute sections above.</para>
+						</section>
+						<section id="Actions">
+							<title>Actions</title>
+							<para>Described in the "Actions" section.</para>
+						</section>
+						<section id="Styles">
+							<title>Styles</title>
+							<para>Special actions that are used to define how to draw an agent graphically as also described in the "Actions" section and detailed in the "Functions" section.</para>
+						</section>
+					</section>
+					<section id="Context_Agents_.28Contexts.29">
+						<title>Context Agents (Contexts)</title>
+						<para>As detailed above, agents also form the basic structural component of an agent-based model. To get an idea for how this works, have a look at the "EpidemicRegional.metaabm" model. Note that in future releases, we will probably refer to Contexts as "Scapes".</para>
+						<section id="Agents_2">
+							<title>Agents</title>
+							<para>The agents that are contained within this context. For example, a context representing a city might contain an Individual Agent for defining all individuals in the model, and a Vehicle agent defining all vehicles. Note that when we refer to an agent in this context, we mean a general type or class of agent, not the agent itself.</para>
+						</section>
+						<section id="Spaces">
+							<title>Spaces</title>
+							<para>The set of all spaces contained or subsumed by the agent. For example, a context representing a city might contain a geographical space and a transportation network space.</para>
+						</section>
+					</section>
+				</section>
+				<section id="Attributes_2">
+					<title>Attributes</title>
+					<para>Agents need some way to represent their internal state. For example, an agent in an economic model might have a wealth attribute, and an agent in an ecology model might have a quantity of food and a particular vision range. These states are represented as attributes just as all software objects do. In an agent model, we keep richer information about these attributes and generally represent them at a higher level. For example, rather than specify that a real value is a "double", a "float" or a "big number", we represent them as "Reals" so that they can be implemented and tested in different environments. This might allow us for instance to ensure that a model's behavior is not dependent on a particular machine implementation of floating point arithmetic. Also, note that attributes only represent so-called "primitive" values -- that is, actual measurable features of a particular agent but not an agent's relationship to other agents or objects. See the discussion about networks for more on this key topic.</para>
+					<para>Here are the basic types of attributes available in Acore models:</para>
+					<section id="Basic_Attributes">
+						<title>Basic Attributes</title>
+						<para>Attributes are single values that a given agent contains. For example, an agent might have an "Age" attribute. In this section we go over the values you can set for the attributes. For those with a tecnical bent, note that we are technically describing the meta-attributes for the meta-class "SAttribute". But it is far too confusing to refer to the attributes of attributes! So we'll just refer to the attributes that any of our model components as "values".</para>
+						<section id="Type">
+							<title>Type</title>
+							<para>These can be anyone of the following: </para>
+							<informaltable frame="none">
+								<tr>
+									<td rowspan="1" colspan="1">Boolean</td>
+									<td rowspan="1" colspan="1">A value that is simply true or false. Note that unless this value really is a simple binary value, you should consider using state instead. (See details below.) For example, rather than representing gender as a 'Female' boolean value, define a 'Gender' state with values 'Male' and "Female'. Generated artifacts and documentation will be much clearer, and you'll be able to easily modify the model later if for example you discover that there are more than two potential gender categories that are relevant to your model.</td>
+								</tr>
+								<tr>
+									<td rowspan="1" colspan="1">Integer</td>
+									<td rowspan="1" colspan="1">A discrete whole number value, such as "100", "-1", "10029920". It's generally a good idea to represent any value that can never have a decimal value as an integer.</td>
+								</tr>
+								<tr>
+									<td rowspan="1" colspan="1">Real</td>
+									<td rowspan="1" colspan="1">A continuous number value. While these are typically represented in software as floating point numbers, they can conceivably represent numbers at any arbitrary precision and in any scheme. Note that while technically speaking we should be representing irrational numbers, this is not currently supported for default values and users should simply use the closest decimal approximation.</td>
+								</tr>
+								<tr>
+									<td rowspan="1" colspan="1">Symbol</td>
+									<td rowspan="1" colspan="1">A string representing some state. More precisely, a computationally arbitrary value with contextual meaning. This could be any kind of identifier. For example, you might use it to store some kind of input coding from data that is then converted into an object state. Or it could simply be an agent's name. But theoretically (though this is not currently supported) one could imagine a symbol using an idiogram, an icon or even a sound that identifies or represents the agent in question.</td>
+								</tr>
+							</informaltable>
+							<para>(Undefined and Numeric types should not be used within a well-defined model.)</para>
+						</section>
+						<section id="Default_Value">
+							<title>Default Value</title>
+							<para>The value that should be assigned to the attribute at the beginning of any model run. The attribute may of course be assigned a different value in an Initialize rule, but its a good idea to specify one here. It's OK to leave it blank, in which case a sensible 'empty' value will be assigned, i.e. false for Boolean, 0 for Integers and Reals, and an empty string for Symbol.</para>
+						</section>
+						<section id="Gather_Data">
+							<title>Gather Data</title>
+							<para>Here you can specify whether executing models should collect aggregate values for the data. For example, if you select this value as true for a 'Wealth' attribute, Escape will automatically keep track of minimum, maximum, average, sum and optionally standard deviation and variance across all agents for each model execution period. All of these statistics will then be selectable with a mouse click to appear in your model charts at runtime.</para>
+						</section>
+						<section id="Immutable">
+							<title>Immutable</title>
+							<para>This value indicates whether you expect the model value to change. If you know that it won't or shouldn't, this value should be true.</para>
+						</section>
+						<section id="Units">
+							<title>Units</title>
+							<para>Specifies what the attribute is actually measuring. For example, if you're defining an attribute for "Wealth" in the context of a model of the world economy, you might specify "USD". If you're defining "Age", you might specify "Years", for "Mass" "Kg". Like description, this value is often overlooked, but can be critically important to allowing yourself and others to understand and correctly calibrate a model. Note that this will also allow you to simplify variable names -- instead of using "Age in Years", you can simply specify "Age" and the appropriate unit. It may be obvious to you that your model is concerned with age in years, but a user who needs to specify a different granularity will be grateful for more clarity.</para>
+						</section>
+					</section>
+					<section id="Arrays">
+						<title>Arrays</title>
+						<para>Arrays are simply attributes with zero or more entries. For example, you might have an array of three Real numbers representing the Red Green and Blue color components for an object. Note that if you find yourself defining very complex sets of arrays, its likely that what you really want to define is a new agent with attributes for each array. In addition to what is defined above, arrays specify:</para>
+						<section id="Size">
+							<title>Size</title>
+							<para>The number of values that the array attribute will contain.</para>
+						</section>
+					</section>
+					<section id="States">
+						<title>States</title>
+						<para>States represent any agent quality that may take on one of a number of well defined values. For example, an "Ice Cream Consumer" Agent might contain a state of "Ice Cream Preference" with options of "Chocolate", "Vanilla" and "Ginger".</para>
+						<section id="State_Options">
+							<title>State Options</title>
+							<para>Create new options for states by adding them to the state node. States are simple described items. Don't forget to provide a description! States also have</para>
+						</section>
+						<section id="Default_Option">
+							<title>Default Option</title>
+							<para>unlike for regular attributes, this option is not optional! Simply pick a state option to be assigned that the agent will take if no other option has been assigned.</para>
+						</section>
+					</section>
+				</section>
+				<section id="Spaces_2">
+					<title>Spaces</title>
+					<para>All contexts can contain spaces. Spaces provide an environment in which agents can have a physical or notional location and upon which they can interact with one another and their environment. Agents can exist in more than one space at a time, and a given agent need not exist in every space. (Note that this is different from the Repast Simphony notion of projections, though the two representational approaches are generally compatible.) Agents need not represent explicit, "real" spatial structures such as a landscape, though this is of course the most common use. They can also represent relational and state information, such as a belief space or a social network. There are four kinds of space represented:</para>
+					<section id="Space_.28Continuous.29">
+						<title>Space (Continuous)</title>
+						<para>In the modeling tools, we simply refer to this as a "Space" as it is represents the general concept of a space. A space is simply something that contains objects with certain locations and extents and has a certain number of dimensions. The space is continuous, in the sense that objects can be placed anywhere with arbitrary position. Spaces hold attributes, which simply define their dimensions-- see below.</para>
+						<section id="Border_Rule">
+							<title>Border Rule</title>
+							<para>A value representing what happens to an agent when that agent is asked to move beyond its extent.</para>
+							<variablelist>
+								<varlistentry>
+									<term>Periodic</term>
+									<listitem>
+										<para>When encountering an edge, the agent will treat the space as wrapping around to the other side of the space. For example, if the agent at location {1,2} (0-based) within a Moore space (see grid discussion below) of size {10,10} is asked to find some other agent within distance 3, the agent look in the square defined between {8,9} and {4,5}. An agent asked to move beyond the confines of the space will simply stop when it reaches the edge. You can imagine this as taking a piece of graph paper and connecting the opposite edges. You can't actually do that with paper, but if you could you would have a toroidal (donut) shape in three dimensions defining the shape in two.</para>
+									</listitem>
+								</varlistentry>
+								<varlistentry>
+									<term>APeriodic</term>
+									<listitem>
+										<para>When encountering an edge, the agent treats it as the edge of the space. For example, if the agent at location {1,2} is asked to find some other agent within distance 3, the agent look between {0,0} and {4,5}. An agent asked to move beyond the confines of the space will simply stop when it reaches the edge.</para>
+									</listitem>
+								</varlistentry>
+							</variablelist>
+							<para>The "Strict" and "Bouncy" values are obsolete and should not be used.</para>
+						</section>
+						<section id="Dimensionality">
+							<title>Dimensionality</title>
+							<para>The number of dimensions that the space has. After selecting a dimensionality, attributes will be added to represent each dimension. For example, if you enter 3 here, you will have an attribute for X, Y, and Z. Be sure to enter default values here, as they will be used to specify the actual size of the space.</para>
+						</section>
+					</section>
+					<section id="Grid">
+						<title>Grid</title>
+						<para>A grid is technically a regular lattice structure. Currently, only rectilinear structures are supported, i.e. a One-dimensional vector, a two-dimensional grid, a three-dimensional cube and so on. (Though none of the current target platforms support n-d spaces yet.) </para>
+						<para>Like continuous spaces, a grid has a border rule and dimensionality. A grid has a couple of other important values:</para>
+						<section id="Multi-Occupant">
+							<title>Multi-Occupant</title>
+							<para>Does the grid allow more than one agent to occupy it at a time? This value may be replaced with another mechanism in future releases.</para>
+						</section>
+						<section id="Neighborhood">
+							<title>Neighborhood</title>
+							<para>This value determines what constitutes a region within a particular distance from the agent. The value for this is often critical in obtaining particular behavior from a model, and shouldn't be overlooked. There are three possible values:</para>
+							<variablelist>
+								<varlistentry>
+									<term>Euclidean</term>
+									<listitem>
+										<para>The distance between any two cells is taken to be the "real" distance. For example, if an agent was within a chess board, and we wanted to find all agents within distance three of it, we could determine that by taking a string of length 3, tacking it to the center of the source square, and including all cells whose centers we can reach with the other string end. Note that although Euclidean space may seem the most reasonable neighborhood configuration to choose, this really isn't the case. Euclidean space is continuous whereas grid space is discrete, and mapping the two to each other can create unexpected issues. Still, this is a good choice for models representing notional real spaces.</para>
+									</listitem>
+								</varlistentry>
+								<varlistentry>
+									<term>Moore</term>
+									<listitem>
+										<para>Here, the distance between any two cells is defined by the number of edge 
+											<emphasis role="italic">or</emphasis> corner adjacent cells crossed to get between them. To continue the chess board analogy, this is the set of moves that a king can make. Note that this does not map well to real space at all, as a cell at distance 1 in a moore space is at distance sqrt(2) in "real" space.
+										</para>
+									</listitem>
+								</varlistentry>
+								<varlistentry>
+									<term>Von-Neumann</term>
+									<listitem>
+										<para>Here, the distance between any two cells is defined by the number of edge adjacent cells crossed to get between them. This is the set of moves that a rook might make on a chess board -- if a rook could only move one square at a time. It is also often referred to as a Manhattan distance for the self-evident reason.</para>
+									</listitem>
+								</varlistentry>
+							</variablelist>
+						</section>
+					</section>
+					<section id="Network">
+						<title>Network</title>
+						<para>A network represents a set of relationships between agents, in a graph structure. The concept is pretty simple, but note that a network is actually a critical part of many AMF models. This is because we use networks to represent any kind of references between agents. You may have noticed in the discussion about attributes that there is no generic "object" type for an attribute. In fact, attributes only contain primitive values. So we will use networks to do the kinds of things that we would often use object references for in a traditional Object-Oriented model. For example, if an agent is a member of a family, rather than have that agent have a member attribute of "family" with a reference to the "Family" object, the modeler would create a "Family Members" network and connect agent's to their families as appropriate. This implies that network members can contain members of many different types.</para>
+						<para>A network has only one value to specify:</para>
+						<section id="Directed">
+							<title>Directed</title>
+							<para>This indicates whether connections between agents are one-way or two-way. If this value is false, then if a connection is made between an agent A and an agent B, and agent B searches within distance 1, agent B will find agent A. If this value is true, agent A can find agent B, but agent B can not find agent A. (Unless of course some other path leads B to A.)</para>
+						</section>
+					</section>
+					<section id="Geography">
+						<title>Geography</title>
+						<para>A geography represents a physical landscape. Here we assume that that landscape is going to be defined by an external data source and representational scheme -- typically a Geographical Information System. We'll describe how to work with GIS in more detail when we discuss builder actions.</para>
+					</section>
+				</section>
+			</section>
+			<section id="Reference">
+				<title>Reference</title>
+				<section id="Diagrams">
+					<title>Diagrams</title>
+					<para>For readers familiar with UML and meta-modeling, the following diagrams give more detail on the structural design.</para>
+					<section id="Meta-Classes">
+						<title>Meta-Classes</title>
+						<para>Our first diagram depicts the core structural design of the model. </para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/structure/StructureComplexDiagram.png" scale="50"/>
+								</imageobject>
+							</mediaobject> 
+						</para>
+						<literallayout format="linespecific" class="normal">There seems to be a lot going on here, but the basic components are pretty straightforward as we can see in the next diagram.
+</literallayout>
+					</section>
+					<section id="Key_Collaborations">
+						<title>Key Collaborations</title>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/structure/StructureSimpleDiagram.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<literallayout format="linespecific" class="normal">Core interactions are in Red. The meta-model structure is essentially a Composite pattern. 
+</literallayout>
+					</section>
+					<section id="Details_2">
+						<title>Details</title>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>Every model has at its root a Context (Scape). Contexts are Agents that are capable of containing other Agents (including other contexts, naturally). </para>
+							</listitem>
+							<listitem>
+								<para>(Meta-level) Contexts contain (meta-level) Agents at the model (design-time) level.  At runtime, (model-level) Context instances defined in a (meta-level) SContext will contain (model-level) agent instances of the defined (meta-level) SAgent. This sounds more complicated than it is, so let's look at a simple example. Suppose we create a new Context, and give it a label of "Wiki Example". Within that Context, we create an Agent and give it a label of "Individual" and another Agent with the label "Block". At runtime when we are actually executing the model we will have one WikiExample model instance  which contains a number of Individuals.</para>
+							</listitem>
+							<listitem>
+								<para>Agents contain Attributes, such as Vision and Age. Context attributes often represent input parameters for contained agents. For example, our Wiki Agent Context might contain an Individual Count as well as a Minimum Age and Maximum Age.</para>
+							</listitem>
+							<listitem>
+								<para>Contexts can contain Projections (Spaces), which represent some kind of spatial or structural interaction space for the agents; either a grid, a continuous (euclidean) space, or a network (graph) or geographic space of some kind. For example, we might want to have a City that contains Blocks and that an Individual can move around within.</para>
+							</listitem>
+							<listitem>
+								<para>Agents are Actable and thus can contain any number of behaviors called "Actions", described in detail in the next section. Actions can describe individual behavior, and at the Context (Scape) level can define how member Agents and Projections are created.</para>
+							</listitem>
+							<listitem>
+								<para>Styles provide a mechanism for defining generic visualization behavior for Agents and so are also Actable. For example, an Agent might have an Action that says effectively "draw a red circle shaded red for the wealth of the agent".</para>
+							</listitem>
+						</orderedlist>
+					</section>
+				</section>
+			</section>
+		</section>
+		<section id="Actions_2">
+			<title>Actions</title>
+			<para>Actions are the most important part of an agent model. While Agents, Attributes and Spaces define what we're modeling, it is Actions that give the models life.</para>
+			<section id="Overview_3">
+				<title>Overview</title>
+				<para>Actions allow the definition of behavior for agents at a very high level. You can think of actions as being analogous to methods in a traditional object-oriented model but that analogy only goes so far. In the same way that methods are defined as part of objects, actions belong to particular agents. (Though even more expressive ways of defining actions are contemplated in future releases.) In the next section we go into detail about what Actions are and how they can be used to define all agent behavior. They are also conceptually more challenging as unlike with structure they have no direct analogies to past agent representations.</para>
+				<para>An action provides simple, well-defined details that a model can use to determine what steps to take in model execution. That definition seems general enough to be almost useless, but its important to understand that an action is not equivalent to an instruction, a method or a query. In fact, actions can have aspects of all of these. But an action is not in itself an instruction specifying exactly 
+					<emphasis role="italic">how</emphasis> the modeling engine should do something -- instead an action represents 
+					<emphasis role="italic">what</emphasis> the modeler intends for the agents to do. (Technically, we might say that Actions takes a "declarative" approach instead of an 'imperative' approach, but that's not quite true, because actions do allow us to define behavior in a richer way than most declarative approaches, and many action constructs map directly to imperative approaches.)
+				</para>
+				<para>Actions are connected together in a series of sources and targets. (Technically, an acyclic directed graph.) In an abstract sense that is similar to the way any programming language is defined although that structure isn't usually obvious because of the constraints of textual representations. But unlike a typical programming language, in Actions it is not the execution thread (the processor) that moves from one instruction to the next, but the result of the previous action. In this way, action results "flow" from the output of one action into the next action.</para>
+				<para>Why are these distinctions between traditional Object-Oriented and the Action approaches important? They give us the advantages of simplicity, clarity and flexibility that 
+					<ulink url="/wiki/http://en.wikipedia.org/wiki/Dataflow_programming">data-flow approaches</ulink> like spreadsheets and some query languages have, but with less restrictions. At the same time, they can bring us much of the power and expressiveness of 
+					<ulink url="/wiki/http://en.wikipedia.org/wiki/Functional_programming">functional languages</ulink> like Lisp or 
+					<ulink url="/wiki/http://en.wikipedia.org/wiki/Logical_programming">logical languages</ulink> like Prolog, but without the level of complexity and obscurity that such languages can have.
+				</para>
+				<para>We can get a better idea for how Actions work by thinking about how a spreadsheet works. In a spreadsheet, we might define a cell A that adds up a row of data, say "Income". We might define another cell C ("Profit") that takes A and adds it to another cell B that adds up another row of data ("Expenses"). Now, if we change a value in any of the rows, all of the other rows are added up and we get the results in A and B updated automatically. We never had to write code that said something like "for each cell in row X, where...". In fact, we don't really care 
+					<emphasis role="italic">how</emphasis> our Spreadsheet program adds up the numbers -- it could have added them all up at once but in backward order, or stored a running total somewhere and updated just the difference in value for the cell we changed -- what we care about is 
+					<emphasis role="italic">what</emphasis> the result is, and whether it is correct.
+				</para>
+				<para>But Actions are much more powerful than a spreadsheet, because what is flowing from Action A to Action B is not just a number, but any model component such as a space or a set of agents that we need to use in target actions.</para>
+			</section>
+			<section id="Concepts">
+				<title>Concepts</title>
+				<para>In this section, we'll describe how modelers can assemble actions into sets of behavior that accomplish complex tasks on interrelated agents and spaces over time.</para>
+				<section id="Kinds_of_Actions">
+					<title>Kinds of Actions</title>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. The various actions are discussed in depth in the Details section.</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsBlocks.png" scale="50"/>
+									</imageobject>
+								</mediaobject> 
+							</td>
+						</tr>
+					</informaltable>
+				</section>
+				<section id="Flow">
+					<title>Flow</title>
+					<para>First, let's look at how actions define the basic path that agents take during a model run. As with any programming language, the path we take through the program specification is what determines our state when we get there. In a pure object oriented program, the path just defines the control flow -- what we are doing. The actual state of our model is defined within the object itself. If we call a method B from another method A, we'll be relying on method A to set the values that we need into the object state itself. In a purely functional program the path defines how we are going to deal with whatever has been explicitly passed in to a function that has been called, that is the function parameters. In fact, most languages such as Java combine aspects of both approaches.</para>
+					<para>In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.
+						An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically 
+						<emphasis role="italic">need</emphasis> loop structures. By far the most common use of loops in conventional programming langauges is to loop through collections of objects. As selections (see below) refer to the entire collection of agents, any actions on a selection apply to all members of that collection. Recursive structures are needed for some particular usages and will be supported in future releases, but not through an explicit looping construct.
+					</para>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">Again, behaviors in Actions are always defined by a set of 
+								<emphasis role="italic">selections</emphasis> and 
+								<emphasis role="italic">queries</emphasis>. In the diagram to the right, we can see the pattern. First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent.
+							</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSequence.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">The diagram to the right depicts a simple example. Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them.</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSimpleSequence.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">In this next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSimpleSequence2.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<para>In the following example, we've defined a set of actions and their relationships. We have a selection, a few queries and a couple of logic operators leading to a Set Action. We'll describe in detail below how Logic Actions are used in conjunction with other actions to assemble any kind of query structure needed. But for now, we'll focus on the control flow itself.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/actions/ActionsFlowSimple.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>As you have probably already guessed, the agents that have the Set Action applied to them could take one of two paths through the Action flow. Readers with experience with programming or formal logic will note that this looks just like a parse tree, and while that's basically what it is, there are important differences. For example, if we looked at the following structure as a definition of control flow for a single agent we'd take them to be equivalent. Both would evaluate the statement (Query 1 AND Query 2) OR Query 3 for each agent.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/actions/ActionsFlowUnion.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>Within Actions in many cases these two approaches will also act equivalently. If we are simply setting a value, it doesn't matter how an agent gets to that Set Action, as long as it gets there. All sources that flow into a given target Action act like a logical union since any of the paths might reach that target. But note that we have two flows moving in parallel in the flow on the right. What happens when the conditions for 
+						<emphasis role="italic">both</emphasis> branches are true? As the set of agents flow through each branch the Set Action on the left will be evaluated once, while the one on the right will be evaluated twice. Again, this often ends up with the same behavior, but not always. If for example, the evaluate Action uses the value of the attribute that we are setting as input, we can get different results. Of course, you can write code in any language that accomplishes the same thing, but the code will look quite different. For example, if we wrote the same basic logic in Java, in the first case we'd have something like:
+					</para>
+					<literallayout format="linespecific" class="normal">if ((query1.evaluate() &amp;&amp; query2.evaluate()) || query3.evaluate()) {
+    doSomething();
+}
+</literallayout>
+					<para>In the second we'd have:</para>
+					<literallayout format="linespecific" class="normal">if (query1.evaluate() &amp;&amp; query2.evaluate()) {
+    doSomething();
+}
+if (query3.evaluate()) {
+    doSomething();
+}
+</literallayout>
+					<para>This is a simple example, but with multiple branches such code design issues can quickly grow complex. The flow approach allows us to express things in a way that is often more natural and expressive. The important thing to keep in mind when desiging action flows is to see the flow as representing a selection of agents moving through streams independently. In the Actions example we expressed both approaches in nearly the same way, except in the case on the left we used a Union Action to bring the two branches of flow back together.</para>
+				</section>
+				<section id="Selections">
+					<title>Selections</title>
+					<para>Selections are a key concept in Actions. Put simply, selections define what we are searching for and where. They are defined by a combination of Select, Query and Logic Actions. Each time we create a new Select Action, we define a new selection. Queries can be used to further refine selections either immediately after or later in the Action flow, as described in the next section. Logic Actions are used to combine and organize the Action flow defined by Query Actions. In order to understand how these three pieces work together, we need to understand the idea of selection boundaries.</para>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSelBoundarySimple.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">Each time we create a new selection, we define a new set of boundaries. In the diagram to the right, Selection 1 and Selection 2 eaach start with a new Select Action. </td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSelBoundary2Parts.png" scale="50"/>
+									</imageobject>
+								</mediaobject> 
+							</td>
+						</tr>
+					</informaltable>
+					<para>But boundaries can be defined for a group of actions by a Query Actions as well. This is because Query Actions can be directly part of a selection definition, but they can also refine selections. We'll see how that works below. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:</para>
+					<orderedlist inheritnum="ignore" continuation="restarts">
+						<listitem>
+							<para>A Query Action is not followed by a Logic Action, or</para>
+						</listitem>
+						<listitem>
+							<para>A Logic Action is not followed by another Logic Action</para>
+						</listitem>
+					</orderedlist>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as shown in the example to the right. </td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsSelBoundary11A.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<para>Note that we refer to "Selection 1" and Selection 1A". This is because Selection 1A is a refinement of Selection 1 along its particular path of flow. When a query appears for the same selection but past a particular boundary, you can think of it as a sort of filter on the selection contents. We don't have a "Selection 2" here because any Actions that refer to "Selection 1" along the current path of flow will be acting on the selection defined by Selection 1 and Selection 1A.</para>
+					<para>These rules allow actions to be defined in the simplest possible way, but it is important to understand their implication as they result in behavior that can be different from what someone used to and imperative programming environment such as Java might expect. In a simple case the distinction might not matter. For example, if we are using a Query 1 to test whether an agent's attribute a == x and attribute b == y, we would get the same outcome if we placed intersected the queries as if we simply put them in sequence. Internally we would actually be searching for agents with a == x, and 
+						<emphasis role="italic">then</emphasis> taking those agents and choosing those agents with b==y, but the outcome would be the same. But consider a more sophisticated case, where we are searching for neighboring available cells.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/actions/ActionsSelBoundaryComplex.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>In the first case, we execute a search for all agents that meet the two criteria. This means that if there are 
+						<emphasis role="italic">any</emphasis> neighboring cells which are available, we're guaranteed to find one (random) cell. In the second case, we first search for all cells that are neighbors. This will match any agents that include both available and non available agents. Now, at this point since our search returns one agent (in the current AMF design -- richer behavior will be supported in the future) the randomly selected agent could be either available or not. So in the second case, we might end up with no cell to move to, and thus make no move at all. This then becomes an important aspect of model design. For example, if one were defining a model where neighbors played a game with each other, one might want to instruct agents to play the game only with neighbors that have a certain wealth threshold. In the real-world situation that we are modeling, we might simply search for neighbors who are over a given wealth threshold and then play the game with them. This would imply that information about other agent's wealth is open knowledge. Or, we might simply select a random neighbor, and ask that neighbor to play a game with us. Upon discovering that our neighbor does not meet our wealth criteria, we would then choose not to play with them. Here we are modeling a cost in time to obtain information about another agent's wealth, because we might miss an opportunity to play the game with another agent on that round.
+					</para>
+				</section>
+				<section id="Weaving">
+					<title>Weaving</title>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeavingSetAnother.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeavingEvaluate.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeaving1A.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+					<informaltable frame="none">
+						<tr>
+							<td rowspan="1" colspan="1">Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Consider the example to the right. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.</td>
+							<td rowspan="1" colspan="1">
+								<mediaobject>
+									<imageobject>
+										<imagedata fileref="images/actions/ActionsWeaving2.png" scale="50"/>
+									</imageobject>
+								</mediaobject>
+							</td>
+						</tr>
+					</informaltable>
+				</section>
+			</section>
+			<section id="Details_3">
+				<title>Details</title>
+				<informaltable frame="none">
+					<tr>
+						<td rowspan="1" colspan="1">In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general. Again, the block diagram to the right provides an overview of how the various actions are related. You might want to take a look at the meta-class diagrams in the referernce section as well.</td>
+						<td rowspan="1" colspan="1">
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/actions/ActionsBlocks.png" scale="50"/>
+								</imageobject>
+							</mediaobject> 
+						</td>
+					</tr>
+				</informaltable>
+				<section id="Selections_2">
+					<title>Selections</title>
+					<para>A selection defines a particular set of agents that we want to do something with. Selections are made up of the Select action itself, along with Query and Logic actions. When we refer to a selection in any target command, we are referring to the selection in the context of where we have defined the behavior.</para>
+					<section id="Select">
+						<title>Select</title>
+						<para>As we discussed above, when we refer to a Select, we're actually referring to the selection as a whole leading up to the current action. The Select Action itself is used to define what we are searching for (Agent), where we are searching for it (Space), and from whose perspective we are doing it (Selection). Create Actions are a sepecial kind of Select Action that are used to create agents. See the decription in the Builders section below for more information.</para>
+						<section id="Selection">
+							<title>Selection</title>
+							<para>The selection that we are searching "from". This seems to be the concept that new users have the most difficulty with, but it is key to understanding how Actions works. Just as with any other Action -- a Move command for example -- a selection needs to know what set of agents that it is working with. For example, if we want to define a selection B that finds the cells neighboring a rule B's agent, we would set selection B's selection to A.</para>
+						</section>
+						<section id="Agent">
+							<title>Agent</title>
+							<para>Here we define what agent we will be looking for. In order for this to make sense, the agent has to be related in some meaningful way to the agent whose behavior we are defining. For example, it might be a partner agent or a location that we might want to move to. An agent must be specified unless we are searching within a continuous space, in which case this value should be empty, and the result of the selection will represent some location in that space. In the current version of the framework, we treat destination cell locations as agents, and require that location to be specified as a target agent, but in a future version we'll allow searches without defining an agent within grid spaces as well.</para>
+						</section>
+						<section id="Space">
+							<title>Space</title>
+							<para>The space that we want to search within. Of course, this must be specified if we use any spatial query terms (see below), but if we simply want to search across all agents it should not be specified.</para>
+							<para>Represent Queries (Controls) on agents and Transformations, or Commands, on the result of those queries. Queries, Transformations and other  in which each child target carries the execution and data context for it's particular path.</para>
+						</section>
+						<section id="For">
+							<title>For</title>
+							<para>This value is obsolete and will be replaced with a different mechanism in the next version of the modeling environment.</para>
+						</section>
+					</section>
+					<section id="Query">
+						<title>Query</title>
+						<para>A Query represents a concrete criteria for our search. The name is a bit confusing because of potential for confusion with a generic query. Queries -- along with their cousin Evaluators -- define a function that is evaluated and that can take Agent attributes and the results of other Actions as input. Queries are combined with each other and with the logic actions to determine the results of a selection for their direct target actions. </para>
+						<section id="Selection_2">
+							<title>Selection</title>
+							<para>As with all other actions, evaluations specify a selection, and just as with the other actions, this determines the set of agents that the evaluation occurs for, but the input selections determine what agent is used for the calculation itself.</para>
+						</section>
+						<section id="Function">
+							<title>Function</title>
+							<para>A query function is evaluated to determine the results of a particular selection. Functions can represent very simple search criteria such as "My Age == Your Age", but they can also represent complex and inter-related concepts such as spatial relationships. They must return logical values. See the functions section for more information on specific functions.</para>
+						</section>
+						<section id="Inputs">
+							<title>Inputs</title>
+							<para>The set of values that will be used to determine the result, in the order specified by the function prototype. Inputs can specify any source evaluation and any agent state or agent parent context state. They can also be literal values -- see the section on literals below. The selection determines which agent's will be used to determine the value, and different inputs can specify different selections.</para>
+						</section>
+					</section>
+					<section id="Logic">
+						<title>Logic</title>
+						<para>These Actions provide us with the ability to combine queries with one another, and follow the basic rules of set logic. But as we've seen above, it is important to understand that there are important differences between Logic Actions and typical programming logic. Most importantly, they apply not to individual agents per se, but to the set of agents that move through them. Also, there is not neccesarily short circuit execution (it's not needed) and much richer criteria can be joined together because of the action flow design.</para>
+					</section>
+					<section id="Intersection">
+						<title>Intersection</title>
+						<para>An intersection contains only those agents that match all of its source actions. This is essentially equivalent to a logical AND statement and has similarities to an &amp;&amp; operator in a java "if" statement. An agent must be able to flow through all incoming actions in order to flow out of an Intersection Action.</para>
+					</section>
+					<section id="Union">
+						<title>Union</title>
+						<para>A union contains all agents that match any of its source actions. This shares similiarities to a logical OR statement and the || operator in a java "if" statement. It does mroe than that however, as it acts to join multiple flows of action. That is, as set logic implies, an agent will never appear in the result of a union more than once.</para>
+					</section>
+					<section id="Difference">
+						<title>Difference</title>
+						<para>A difference contains all agents that do not match any of its source actions. This essentially equivalent to a logical NOT statement, and has similarities to the Java else statement. Like the Union Action, difference implies that a given agent will only appear once in any subsequent targets. No agents that reach a Difference Action will flow through to the next action(s), and all agents (that meet the definition of the Select Action) that cannot reach that action will.</para>
+					</section>
+				</section>
+				<section id="Roots">
+					<title>Roots</title>
+					<para>Root actions are a special case of a selection. These represent behaviors that are defined for all members of agents; these are the highest granularity of an agent's behavior, such as "Find Partners" or "Eat" or "Reproduce". When you want to create a new set of Actions, you have the following choices.</para>
+					<section id="Build">
+						<title>Build</title>
+						<para>The Build Action is a specialized action that allow the construction of member agents and spaces within a parent context. A Build Action executes once for each context before any initialization actions occur for any children agents of that context. Currently it is undefined whether a context's own Initialize Action is executed before the Build Action occurs, so implementors should not rely on any initialized values being available at build time.</para>
+					</section>
+					<section id="Initialize">
+						<title>Initialize</title>
+						<para>An Initialize action is executed once and only once for every agent when the model is first started -- at time 0. Initialize Actions are guaranteed to execute before any other non-builder action occurs.</para>
+					</section>
+					<section id="Rule">
+						<title>Rule</title>
+						<para>A Rule executes once for every agent for every iteration of the model. An important note is that the actual sequence of rules is technically undefined. An implementor should not rely on the fact that a rule occurs before another rule in the list of agent actions though typically the order in which the rules were actually created is respected.</para>
+					</section>
+					<section id="Schedule">
+						<title>Schedule</title>
+						<para>A schedule is executed on a recurring basis, according to the values detailed below. Note that schedules are often overused. In most agent-based models it makes sense to have any behaviors occur at the same granularity using a Rule. Please note that Schedules are not currently supported in the Escap target, but that support should be available soon. In the following descriptions we refer to period as the current iteration of the model, that is where time == t.</para>
+						<section id="Start">
+							<title>Start</title>
+							<para>The period that the schedule will first be invoked. For example, if this value is 100, and interval is 1, the schedue will be executed at times 100,101,102..</para>
+						</section>
+						<section id="Interval">
+							<title>Interval</title>
+							<para>How often the schedule is invoked. For example, if this value is 3 and start is 1, the schedule will be executed at times 1,4,7..</para>
+						</section>
+						<section id="Priority">
+							<title>Priority</title>
+							<para>Where the rule will be placed in the execution queue for a given time period. For example, if Schedule A's priority is set to 3 and Schedule B's is set to 2, Schedule B will be executed for all agents before Schedule B is executed for any agents.</para>
+						</section>
+						<section id="Pick">
+							<title>Pick</title>
+							<para>Controls how many agents to execute the schedule against. While this value will have an effect on the Repast target, it is not recommended to be used for general models and is likely to be replaced by another approach.</para>
+						</section>
+					</section>
+					<section id="Watch">
+						<title>Watch</title>
+						<para>A Watch action is executed any time the watched value is set for any agent. Note that the Action will be triggerred even if the state is simply set back to the value that it already has. It is important to be careful about creating Watches that might set the values of other Watch actions which might in turn trigger this watch. To clarify, if a modeler creates a Watch A for attribute a, and creates a target Set for it for attribute b, and Watch B is watching attribute b, then if Watch B has a target Set for attribute A, a circular execution could occur. This would cause the model to get stuck in its current iteration. To help model developers avoid this case, a warning will be provided if such a set of circular watch dependencies is created.</para>
+						<section id="Attribute">
+							<title>Attribute</title>
+							<para>The attribute that will be monitored for change.</para>
+						</section>
+					</section>
+				</section>
+				<section id="Builders">
+					<title>Builders</title>
+					<para>Builders are a special category of actions that are used to create spaces. They should not be confused with the Build Action itself which is a root selection that defines the time at which builder actions should occur. Generally speaking, specific Builder Actions for spaces and Create Actions for agents are targets of Build Actions.</para>
+					<section id="Create_Agents">
+						<title>Create Agents</title>
+						<para>Agents are crete using the Create Agent action. The Create Agent Action is actually a special kind of Select Action that is used to actually create agents rather than simply search for them. Other than this capability, a Create Agent action can be used just like any other action except that Query and Logic actions aren't needed or genrally appropriate as this action defines a set number of agents to perform an action against. Create Agent actions have the special feature of being usable from the containing context, so that contexts can create initial agent populations before any agents exist within the context to perform actions against. But they can also be used directly within agent rules, for example to create a child agent as the result of a reproducation rule. Note that Initialize Actions are 
+							<emphasis role="italic">not</emphasis> performed on agents that have been created within a model during regular (non-initialization time) execution. If the model creates actions during the regular model run, any state initialization should be handled by the targets of this action directly. (Naturally, if the enclosing context is used to create agents at the beginning of a model run, then the Initialize action is used as part of the normal model life-cycle.)
+						</para>
+						<section id="Agent_2">
+							<title>Agent</title>
+							<para>The kind of agent to create.</para>
+						</section>
+						<section id="Selection_3">
+							<title>Selection</title>
+							<para>The selection to use as the basic for this selection. This is generally not important except to define control flow.</para>
+						</section>
+						<section id="Space_2">
+							<title>Space</title>
+							<para>Not generally relevant for agent actions, as agents are not placed into a space unless explicitly moved to that space. Potential associations between agents and spaces are defined by the space building actions.</para>
+						</section>
+						<section id="Agent_Count">
+							<title>Agent Count</title>
+							<para>The number of agents to create. If used as part of an enclosing context's Initialize Action(s) an Attribute parameter will automatically be created. If not, then an evaluation or agent attribute should be used to define this number.</para>
+						</section>
+						<section id="For_2">
+							<title>For</title>
+							<para>Deprected. Should not be used.</para>
+						</section>
+					</section>
+					<section id="Create_Shaped_Agent">
+						<title>Create Shaped Agent</title>
+						<para>Creates an agent that has a particular shape extent within some continuous (i.e. vector as opposed to raster) space. This action performs just like a Create Action except for the following attribute:</para>
+						<section id="Shape">
+							<title>Shape</title>
+							<para>Determines how each agent's spatial extent will be defined. The actual form of that shape is implementation specific. For example, in a GIS space (the immediate rationale for this Action) a polygon represents a region on a map and the extent of that shape might be determined by a .shape file. The available shape types are:</para>
+							<variablelist>
+								<varlistentry>
+									<term>Point</term>
+									<listitem>
+										<para>A simple point in space, fully equivalent to a standard continuous space location.</para>
+									</listitem>
+								</varlistentry>
+								<varlistentry>
+									<term>Line</term>
+									<listitem>
+										<para>A single line within a continuous space. Technically this represents a line segment as it is expected to have a beginning and ending point. In the future, this might refer more generically to planes in three dimensional space and hypersurfaces in n-dimensional spaces, but this is currently not supported by any AMF target implementations.</para>
+									</listitem>
+								</varlistentry>
+								<varlistentry>
+									<term>Polygon</term>
+									<listitem>
+										<para>A region within a space defined by an arbitrarily large set of line segments. Potentially this could be used to refer to polyhedrons in three-dimeensional space, or even more genrally as polytopes, but this is currently not supported by any AMF target implementations.</para>
+									</listitem>
+								</varlistentry>
+							</variablelist>
+						</section>
+					</section>
+					<section id="Load_Agents">
+						<title>Load Agents</title>
+						<para>Imports and creates a set of agents from some input file. The actual form and manner of the import is implementation specific but should be inferrable from any source file based on the URL provided, assuming that the target platform or the AMF platform supports the appropriate imput type. For example, a Tab-CR delimited file might be used to populate a set of agents with various attributes. Additional meta-data could be provided by the URL, but we will likely add additional extensible meta-data to this action to better support the definition of expected input types and routines from within an AMF model itself. This action is equivalent to the Create Agents action except for:</para>
+						<section id="Source_URL">
+							<title>Source URL</title>
+							<para>The location of the input file or set of meta-data used to determine the location and type of the input file.</para>
+						</section>
+					</section>
+					<section id="Load_Shaped_Agents">
+						<title>Load Shaped Agents</title>
+						<para>Combines the properties of the Create Shaped Agent and Load Agent Actions. The source url should of course specify an input format that supports the shape type specified. See the descriptions of the related actions for more details.</para>
+					</section>
+					<section id="Build_Network">
+						<title>Build Network</title>
+						<para>Creates a network, i.e. a graph structure, supporting the establishment of edges between arbitrary nodes.</para>
+						<section id="Agents_3">
+							<title>Agents</title>
+							<para>Specifies the set of agents that can exist within this network. Agents must be included here in order for them to make connections within the network but agents included here are not required to have connections within the network, nor are such connections created for them. (See important note regarding network types below.)</para>
+						</section>
+						<section id="Attributes_3">
+							<title>Attributes</title>
+							<para>Not currently used for networks.</para>
+						</section>
+						<section id="Network_Type">
+							<title>Network Type</title>
+							<para>Deprecated. This feature is only currently supported for Repast targets and is likely to be removed from future versions of the AMF meta-model. Future AMF implementations are likely will provide a different mechanism for instantiating and importing network structures either within the network defintion or through other Action definitions. Instead of using this feature, modelers should create specific networks by building them up with Connect Actions for indivdual agents. For example to create a small world netowrk, a modeler might create random links between agents and then replace or augment those connections.</para>
+						</section>
+						<section id="Selection_4">
+							<title>Selection</title>
+							<para>Not relevant for network builders except as part of normal control flow.</para>
+						</section>
+					</section>
+					<section id="Build_Grid">
+						<title>Build Grid</title>
+						<para>Creates a grid space.</para>
+						<section id="Agents_4">
+							<title>Agents</title>
+							<para>The set of agents that might exist as occupants of this grid; that is, members of individual cells within a given grid. Agents must be included here in order for instances to exist within the space, but agents included here do not actually have to exist within the space. (In the Repast implementation, all agents technically are memebers of the spatial projection, but are not required to have valid coordinates within that space.) For example, in an agriculture model these might represent agents moving about and harvesting plots of land.</para>
+						</section>
+						<section id="Fill_Agent">
+							<title>Fill Agent</title>
+							<para>The agent that will be used to populate the grid itself. A gird is guranteed to contain one and only one fill agent within each grid locaiton. The grid will be populated with instances of the specified agent and these agents cannot move, leave or die within this space. This value need not be specified -- if left blank a default cell without any state will be used. For example, in an agriculture model, this agent might represent a single plot of land.</para>
+						</section>
+						<section id="Space_Type">
+							<title>Space Type</title>
+							<para>Deprecated. Should not be used.</para>
+						</section>
+						<section id="Selection_5">
+							<title>Selection</title>
+							<para>Not relevant for builders except as part of normal control flow.</para>
+						</section>
+						<section id="Attributes_4">
+							<title>Attributes</title>
+							<para>Not currently used for spaces.</para>
+						</section>
+					</section>
+					<section id="Build_Space">
+						<title>Build Space</title>
+						<para>Creates a continous space. The actual dimensionality and other qualities of the space are currently defined in the space itself though this might change in future versions. All other values are used in the same way as for the gird and other builder actions.</para>
+						<section id="Agents_5">
+							<title>Agents</title>
+							<para>The set of agents that might be a part of this space. Agents must be included here in order for instances to exist within the space, but agents included here do not actually have to exist within the space. (In the Repast implementation, all agents technically are memebers of the spatial projection, but are not required to have valid coordinates within that space.)</para>
+						</section>
+					</section>
+					<section id="Build_Geography">
+						<title>Build Geography</title>
+						<para>Constructs a geographical space. All details of this space are specfied by the implementation, i.e. a specific geographical imported space. Generally these would be defined by a Create Agents action; that is a set of imported agents representing US states would also represent the overall space of interest.</para>
+					</section>
+				</section>
+				<section id="Commands">
+					<title>Commands</title>
+					<section id="Evaluate">
+						<title>Evaluate</title>
+						<para>Evaluate Actions define some calculation on a function based on the model state and a set of input(s). The inputs that an Evaluate Action can take is determined by its functions and can be either agent attributes, prior evaluations or literals. The result is then determined based on those inputs. In some cases Evaluate functions can be used to determine some action indirectly, such as with a graphics fill, but they can never be used to directly change model state.</para>
+						<section id="Selection_6">
+							<title>Selection</title>
+							<para>As with all other actions, evaluations specify a selection, and just as with the other actions, this determines the set of agents that the evaluation occurs for, but the input selections determine what agent is used for the calculation itself.</para>
+						</section>
+						<section id="Function_2">
+							<title>Function</title>
+							<para>A with queries, a function is evaluated against its input set. Functions can represent simple operators as well as complex functions. See the functions section for more information on specific functions.</para>
+						</section>
+						<section id="Inputs_2">
+							<title>Inputs</title>
+							<para>The set of values that will be used to determine the result, in the order of the function prototype. Inputs can specify any source evaluation and any agent state or agent parent context state. They can also be literal values -- see the discussion in the Tools section. The selection determines which agent's will be used to determine the value, and different inputs can specify different selections.</para>
+						</section>
+					</section>
+					<section id="Set">
+						<title>Set</title>
+						<para>The Set Action assigns some value to another value.</para>
+						<section id="Selection_7">
+							<title>Selection</title>
+							<para>Here the selection refers to the agent that we want to change. This does not have to be the immediatily preceeding selection but can be any accessible selection.</para>
+						</section>
+						<section id="Attribute_2">
+							<title>Attribute</title>
+							<para>The attribute to modify. It must be a member of this action's agent or of that agent's parent context.</para>
+						</section>
+						<section id="Parameter">
+							<title>Parameter</title>
+							<para>The value to assign to the attribute. Here, we can use either another agent attribute, or the results of a source evaluation. </para>
+						</section>
+					</section>
+					<section id="Move">
+						<title>Move</title>
+						<para>The Move Action causes an agent to change its location in some space or network. The agent will leave whatever location it was in before within the selection space, and move to its new destination.</para>
+						<section id="Selection_8">
+							<title>Selection</title>
+							<para>As in any other action, the selection determines what agent is affected -- in this case the agent that is being moved.</para>
+						</section>
+						<section id="Destination">
+							<title>Destination</title>
+							<para>Specifies the target agent or location for the movement.</para>
+						</section>
+					</section>
+					<section id="Leave">
+						<title>Leave</title>
+						<para>Causes the agent to leave a particular space.</para>
+						<section id="Selection_9">
+							<title>Selection</title>
+							<para>The selection determines what agent will be leaving and what space the agent will be leaving. If the agent doesn't exist in that space nothing will happen.</para>
+						</section>
+						<section id="Destination_2">
+							<title>Destination</title>
+							<para>The destination is irrelevant for a leave action and should not be specified.</para>
+						</section>
+					</section>
+					<section id="Die">
+						<title>Die</title>
+						<para>Causes the agent to cease to exist within the model as a whole.</para>
+						<section id="Selection_10">
+							<title>Selection</title>
+							<para>The selection determines what space the agent to remove.</para>
+						</section>
+						<section id=".3DDestination">
+							<title>=Destination</title>
+							<para>The destination is irrelevant in this case and will probably be removed.</para>
+						</section>
+					</section>
+					<section id="Connect">
+						<title>Connect</title>
+						<para>Connects two agents within a network space. This Action is not applicable for any other kinds of spaces. Note that unlike with other transformational commands, we do not use the destination space to determine the space that will be impacted by the Action. This provides a more efficient representation without any loss in generality, because it allows us to search for a source and target agent within other spaces and then create a connection without creating a separate selection. As the important structural feature of networks are the relationships themselves, not the nodes this provides a more direct way to specify these relationships.</para>
+						<section id="Selection_11">
+							<title>Selection</title>
+							<para>The selection determines the agent that will be connected to another agent. In the case of a directed graph, this is the source node.</para>
+						</section>
+						<section id=".3DDestination_2">
+							<title>=Destination</title>
+							<para>The destination determines the agent that the selection agent will be connected to. In the case of a directed graph, this is the target node.</para>
+						</section>
+						<section id="Within">
+							<title>Within</title>
+							<para>Specifies the network that the connection will be created within.</para>
+						</section>
+					</section>
+					<section id="Directed_2">
+						<title>Directed</title>
+						<para>Determines whether the connection made is directed or not. If true, selections from source agents will include the target, but target agent selections will not include the source agents (unless they are connected through some other path).</para>
+					</section>
+					<section id="Disconnect">
+						<title>Disconnect</title>
+						<para>Removes the connection between agents within a network space. See the description of the Connect Action for important details.</para>
+						<section id="Selection_12">
+							<title>Selection</title>
+							<para>The selection determines one side of the agent relationship that will be disconnected.</para>
+						</section>
+						<section id="Destination_3">
+							<title>Destination</title>
+							<para>The selection determines one other side of the agent relationship that will be disconnected.</para>
+						</section>
+						<section id="Within_2">
+							<title>Within</title>
+							<para>Specifies the network that the connection will be created within.</para>
+						</section>
+					</section>
+					<section id="Replace">
+						<title>Replace</title>
+						<para>Functions in the same way as a Connect Action excepth that all other connections to other agents will first be removed.</para>
+						<section id="Selection_13">
+							<title>Selection</title>
+							<para>The selection determines the agent that will be connected to another agent. In the case of a directed graph, this is the source node.</para>
+						</section>
+						<section id="Destination_4">
+							<title>Destination</title>
+							<para>The destination determines the agent that the selection agent will be connected to. In the case of a directed graph, this is the target node.</para>
+						</section>
+						<section id="Within_3">
+							<title>Within</title>
+							<para>Specifies the network that the connection will be created within.</para>
+						</section>
+					</section>
+					<section id="Directed_3">
+						<title>Directed</title>
+						<para>Determines whether the connection made is directed or not. See the Connect description for more details.</para>
+					</section>
+				</section>
+				<section id="Other">
+					<title>Other</title>
+					<section id="Method">
+						<title>Method</title>
+						<para>The Method action supports inclusion of arbitrary code within a generated method. Generally, this will be Java code as all of the current target platforms are Java-based but there is no technical requirement that it must be. For example, if a target has been developed to produce code for Swarm running on an iPad (and no, there are no current plans to support such a thing, though it would certainly be cool!) then the modeler could define Objective C code for the method.</para>
+						<para>Please note that the Method Action should be avoided whenever possible. You should consider using it only in the case where there doesn't appear to be a way to construct equivalent functionality using the native Actions framework, such as when interfacing with third party APIs.  The aim of Actions is to provide the most general support for Agent Modeling possible without compromising the core design. Any use of native Java code strongly limits the set of platforms that your model will be able to generate code for and prevents you from using the AMF edit tools to explore the model behavior. In the case where you wish to construct a model feature and believe that it isn't possible or practical to do it with Actions, please contact us (see support section) so that we can suggest how you can accomplish what you want within Actions. If that is not possible, we'll consider developing new features that will support what you want to do.</para>
+						<para>On the other hand, you may simply wish to use the Agent Modeling Framework to build a scaffolding for your model -- perhaps using your own custom Java framework for example -- and Method would be a good way to accomplish that. Also, note there are a number of other approaches to mixing hand-crafted Java together with AMF generated code. Please see the Programmer's Guide section "Integrating Java and AMF Models" for more on that.</para>
+						<para>If you do decide to use the Method Action, keep in mind the following design practice recommendations:</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>Keep your usage of external API references to a minimum. If you can use only code provied by the core Java classes as well as the Apache Collections library, your code should work on every current Java target. On the other hand, if you make use of a specific ABM platform APIs your code will obviously only compile and run against that target.</para>
+							</listitem>
+							<listitem>
+								<para>Code should be in the form of a method body, excluding the signature. A single Java method is created using this code body. There is no support for input parameters -- if you need access to evaluated values from source actions, create agent attributes for them, set their values for the selected agents, and use them as sources for your Method Action.</para>
+							</listitem>
+							<listitem>
+								<para>All Java class references should be fully qualified. For example, if you wish to use the eclipse Draw2D Graphics class, you should refer to "org.eclipse.draw2d.Graphics", not simply "Graphics". If classes are not fully qualified, you will recieve compile errors. You can usually easily fix these by selecting your source code directory and choosing 
+									<emphasis role="bold">Source &gt; Organize Imports..</emphasis> but it prevents automatic code generation.
+								</para>
+							</listitem>
+							<listitem>
+								<para>The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context:</para>
+							</listitem>
+						</orderedlist>
+						<literallayout format="linespecific" class="normal">(new org.me.SpecialFileLoader()).load(this);
+</literallayout>
+						<para>Then create a new source directory in your project called "src" (
+							<emphasis role="bold">New &gt; Source Folder...</emphasis>) and create the class for the specialized file loader including the following method:
+						</para>
+						<literallayout format="linespecific" class="normal">public void load(MyRootModel model) {...}
+</literallayout>
+						<para>This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.</para>
+						<section id="Selection_14">
+							<title>Selection</title>
+							<para>The selection determines what Agent class the code will be created within and the set of agents the method will be called upon.</para>
+						</section>
+						<section id="Body">
+							<title>Body</title>
+							<para>The actual code to insert in the method body. See the detailed recommendations for code use above.</para>
+						</section>
+						<section id="Generate">
+							<title>Generate</title>
+							<para>Determines wether the code is actually inserted. If this is false, a bare method body will be constructed instead. This can be useful if you wish to turn off method generation in certain model implementaitons without removing the actual code.</para>
+						</section>
+					</section>
+				</section>
+				<section id="Query_and_Evaluation_Inputs">
+					<title>Query and Evaluation Inputs</title>
+					<para>Query and Evaluation Actions are both "Sinks" which means that they are capable of containing inputs. When you select a function, the appropriate number of inputs will be created. After selecting a function, you can view and select the inputs. The choices for the inputs will be constrained by the type of the function and the other operands you've selected.</para>
+					<section id="Input_Literals">
+						<section>
+							<title>Input Literals</title>
+							<para>Inputs can take literal values; that is values that you specify simply by entering them directly into the query. In general it is useful to think of literals as similar to local variables in a conventional programming language, whereas attributes are analogous to member variables. (And this is how they are represented in the generated Java code.) As with local variables in model code, literals are not recommended for any values that can change model behavior. The value cannot be easily accessed or changed by other model users. For greater transparency, you should instead create an Attribute with an appropriate default value, setting the "immutable" value to true. Still, literals can be useful for values that are special cases related to the evaluation or query, such as an input code, and for quickly prototyping functionality.</para>
+						</section>
+					</section>
+				</section>
+			</section>
+			<section id="Example">
+				<title>Example</title>
+				<para>In this section, we'll look at an example that should make clear how the basic Actions approach works in a model. Say we want to define a behavior like:</para>
+				<literallayout format="linespecific" class="normal">"Search for a random agent within my vision that is the same age as I am. Find a location next to that agent that is not already occupied and move to it."
+</literallayout>
+				<para>Here, we create a sequence of actions like so:</para>
+				<orderedlist inheritnum="ignore" continuation="restarts">
+					<listitem>
+						<para>Select every agent for every period of the model. ("Find Partner" Rule)</para>
+					</listitem>
+					<listitem>
+						<para>For every member of that selection, search for other agents of the same age within vision distance. ("Partner" selection.)</para>
+					</listitem>
+					<listitem>
+						<para>From "Partners" find a random member and search for a neighboring locations. ("Partner Neighbor" selection.)</para>
+					</listitem>
+					<listitem>
+						<para>Finally, move the agent in "Find Partner" to the "Partner Neighbor" location.</para>
+					</listitem>
+				</orderedlist>
+				<para>Now, notice that although it's convenient to speak as if there is only one "Find Partner" and one "Partner Neighbor" in step 4 above, in fact selections are flowing through for each of the results of each of the previous action sequences, and we can refer to each of the directly. We could represent these behaviors in many different ways. For example, we might want to specify the model in a (hand-drawn) graphical language or in a (made-up) textual language:</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/actions/ActionsExample.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+				<para>This is how it looks in an actual model:</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/actions/ActionsExampleNew.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+				<para>And here is how this works in detail:</para>
+				<orderedlist inheritnum="ignore" continuation="restarts">
+					<listitem>
+						<para>Create a Rule that will trigger the behavior. In this case, we want this rule to apply to all "Individual" agents within the model. (Space isn't relevant in this case.</para>
+					</listitem>
+					<listitem>
+						<para>Create a child Select Action that will find our partner. Two important things to note here:</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>The selection occurs based on the "Find Partner" selection. This means that for each Individual in the model, we'll be searching from the point of view of that agent to some other selection of agents.</para>
+							</listitem>
+							<listitem>
+								<para>We also need to define what type of agent we want and in this case the space does matter. We want to find an agent that is nearby within the City space. If instead we wanted to find a partner in a social network, we'd specify that instead.</para>
+							</listitem>
+						</orderedlist>
+					</listitem>
+					<listitem>
+						<para>Create two child Query Actions:</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>We want to search for someone who is the same age as us. This highlights the importance of the idea of the Selection in the Actions design. We're qualifying Age by the rule agent's partner for the first input and by the rule agent for the second. The selection carries throughout the flow of execution and this context is an explicit part of the entire structure. Note that this is very different from the way control flow works in a traditional imperative language such as Java.</para>
+							</listitem>
+							<listitem>
+								<para>We also want to search using a function for nearness, "within", which takes a parameter of vision. Note that the spatial functions are all polymorphic -- if we decided later on that we would rather search within say "Kevin Bacon space", that is a graph structure representation of space, we would only need to change the space we've defined in Select Partner.</para>
+							</listitem>
+						</orderedlist>
+					</listitem>
+					<listitem>
+						<para>Intersect the results of these two query components. This delineates the end of the selection definition for any target Actions.</para>
+					</listitem>
+					<listitem>
+						<para>Select a neighbor. Again, we can see the importance of Selections. Here, we are selecting from the point of view of the partner, not the initial agent that the current Rule is being executed for. Note that this time our target agent is a "Block", that is, a location within the city.</para>
+					</listitem>
+					<listitem>
+						<para>As above, define some queries. This time we want only those agents that are:</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>available, and</para>
+							</listitem>
+							<listitem>
+								<para>neighbors of our partner.</para>
+							</listitem>
+						</orderedlist>
+					</listitem>
+					<listitem>
+						<para>And another intersection..</para>
+					</listitem>
+					<listitem>
+						<para>Finally, we move to the location we've found. All that's required at this point is to specify:</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>The movement selection, or those agents that are moving, which in this case is the original agent we're executing the rule for, and</para>
+							</listitem>
+							<listitem>
+								<para>The destination, which is the cell that we've found. Note that the framework infers from the space definition that the Block agent is capable of hosting the Individual.</para>
+							</listitem>
+						</orderedlist>
+					</listitem>
+				</orderedlist>
+			</section>
+			<section id="Reference_2">
+				<title>Reference</title>
+				<section id="Diagrams_2">
+					<title>Diagrams</title>
+					<para>The following diagram may be helpful to readers familiar with UML and Meta-modeling:</para>
+					<section id="Meta-Classes_2">
+						<title>Meta-Classes</title>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/actions/ActionsDiagram.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Details_4">
+						<title>Details</title>
+						<para>In the diagram above, all meta-objects except for Input, Literal, and the enumerators (lists of options) are Actions. Blue meta-classes are concrete (you can create and use them directly). Red meta-classes are key collaborations.</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>An Act is anything that might happen during the execution of an Agent-Based Model.</para>
+							</listitem>
+							<listitem>
+								<para>All Actions have as their root-most source action a Root. These are added first to any agent behavior and act as triggers for all target behavior. For example, a Watch will execute any time the watched attribute is modified. (As the diagrams do not refer to elements outside of the current package, we cannot see here that Accessor includes a reference to some Attribute, but it does. To see these kinds of relationships you will want to refer to the metaabm.ecore file itself.)#Actions are targets and sources of one another, but an Act can never have itself as a source. (That is, Actions are acyclic, but branches can re-converge. When we refer to an Act source or target, we typically mean to include all ancestors or descendants, not just the immediately connected Act.)</para>
+							</listitem>
+							<listitem>
+								<para>All Actions (except for root Actions) reference a Select, referred to as the "selected" relation. An ASelect represents the model aspects that the Act is working within; that is, the spatial, temporal and type (agent) "world" that is currently being selected.</para>
+							</listitem>
+							<listitem>
+								<para>Commands trigger some model state change (Set) or spatial transformation (Transform).</para>
+							</listitem>
+							<listitem>
+								<para>Controls determine whether target Actions are executed and against what agents. They are in some sense query terms and include Query actions and Logic Actions.</para>
+							</listitem>
+							<listitem>
+								<para>Transforms also specify a "destination" Select. This represents aspects that the selected agent(s) will transform to. For example, a Move may use a Rule to select all SugarAgents (type) in the SugarGrid (space) every period (time) and move them to a destination of a neighboring SugarCell (type) in the SugarGrid (space, with time implicit).</para>
+							</listitem>
+							<listitem>
+								<para>Sinks are Actions which use some Function (see next section) to interpret state in the form of Inputs. Inputs can come from selected agent attributes, other Actions, or literal values.</para>
+							</listitem>
+						</orderedlist>
+					</section>
+				</section>
+			</section>
+		</section>
+		<section id="Functions">
+			<title>Functions</title>
+			<section id="Overview_4">
+				<title>Overview</title>
+				<para>Functions are relatively simple in terms of model design, but we need to understand how particular functions work in order to develop models. Functions are divided in two ways. By type:</para>
+				<orderedlist inheritnum="ignore" continuation="restarts">
+					<listitem>
+						<para>Operators are simple calculations sharing the same type.</para>
+					</listitem>
+					<listitem>
+						<para>Functions that can represent any general function that takes some well-defined input(s) and returns some well-defined output(s).</para>
+					</listitem>
+				</orderedlist>
+				<para>And by usage:</para>
+				<orderedlist inheritnum="ignore" continuation="restarts">
+					<listitem>
+						<para>Generics can return any value and are used in Evaluate actions.</para>
+					</listitem>
+					<listitem>
+						<para>Logicals return some boolean result and are used by Query actions to decide whether target Actions apply to a particular selection, and by Evaluate actions just as with any other functions. Input types should be defined as generally as possible.</para>
+					</listitem>
+				</orderedlist>
+				<para>These overlap, so we have operators, logical operators, functions and logical functions. Functions are also divided into categories. We'll go through each of these in depth below.</para>
+				<para>The most important thing to point out about functions is that - as we've seen with other Acore concepts -- they provide richer sets of functionality than traditional approaches. Many functions are designed to collaborate with one another as we'll see when looking at Spatial and Graphical functions. Functions can also trigger the creation of related model artifacts as we'll see with the Distribution functions.</para>
+				<para>A technical note: conceptually, functions can return multi-values, but that is not currently implemented in the reference targets because of limitations of the target language Java.</para>
+			</section>
+			<section id="Details_5">
+				<title>Details</title>
+				<section id="General_Functions">
+					<title>General Functions</title>
+					<para>Naturally, the Modeling tools provide general functions for performing calculations, comparisons and more complex mathematical expressions. The function library can be easily extended, and we'll be adding additional capabilities over time. As always, we welcome feedback and we'd like to hear what functions you need that aren't covered here.</para>
+					<section id="Logical_Operators">
+						<title>Logical Operators</title>
+						<section id="Not">
+							<title>Not</title>
+							<para>The result of the expression !X.</para>
+						</section>
+						<section id="Equal">
+							<title>Equal</title>
+							<para>The result of the expression X==Y.</para>
+						</section>
+						<section id="Identical">
+							<title>Identical</title>
+							<para>The result of the expression X==Y.</para>
+						</section>
+						<section id="Greater">
+							<title>Greater</title>
+							<para>The result of the expression X&gt;Y.</para>
+						</section>
+						<section id="Lesser">
+							<title>Lesser</title>
+							<para>The result of the expression X&lt;Y.</para>
+						</section>
+						<section id="Greater_or_Equal">
+							<title>Greater or Equal</title>
+							<para>The result of the expression X&gt;=Y.</para>
+						</section>
+						<section id="Lesser_or_Equal">
+							<title>Lesser or Equal</title>
+							<para>The result of the expression X&lt;=Y.</para>
+						</section>
+						<section id="True">
+							<title>True</title>
+							<para>The result of the expression true.</para>
+						</section>
+						<section id="False">
+							<title>False</title>
+							<para>The result of the expression false.</para>
+						</section>
+						<section id="Identity">
+							<title>Identity</title>
+							<para>The result of the expression X.</para>
+						</section>
+						<section id="Different">
+							<title>Different</title>
+							<para>The result of the expression X!=Y.</para>
+						</section>
+					</section>
+					<section id="Numeric_Operators">
+						<title>Numeric Operators</title>
+						<section id="Negative_Value">
+							<title>Negative Value</title>
+							<para>The result of the expression -X.</para>
+						</section>
+						<section id="Add">
+							<title>Add</title>
+							<para>The result of the expression X+Y.</para>
+						</section>
+						<section id="Subtract">
+							<title>Subtract</title>
+							<para>The result of the expression X-Y.</para>
+						</section>
+						<section id="Multiply">
+							<title>Multiply</title>
+							<para>The result of the expression X*Y.</para>
+						</section>
+						<section id="Divide">
+							<title>Divide</title>
+							<para>The result of the expression X/Y.</para>
+						</section>
+						<section id="Power">
+							<title>Power</title>
+							<para>The result of the expression X^Y.</para>
+						</section>
+						<section id="Modulo">
+							<title>Modulo</title>
+							<para>The result of the expression X%Y.</para>
+						</section>
+						<section id="Increment">
+							<title>Increment</title>
+							<para>The result of the expression ++X.</para>
+						</section>
+						<section id="Decrement">
+							<title>Decrement</title>
+							<para>The result of the expression --X.</para>
+						</section>
+						<section id="Unit_Value">
+							<title>Unit Value</title>
+							<para>The result of the expression 1.</para>
+						</section>
+						<section id="Zero_Value">
+							<title>Zero Value</title>
+							<para>The result of the expression 0.</para>
+						</section>
+						<section id="Original_Value">
+							<title>Original Value</title>
+							<para>The result of the expression o.</para>
+						</section>
+					</section>
+					<section id="Math">
+						<title>Math</title>
+						<para>The math functions use the extremely well specified and tested routines form the Java Math library. (Because of copyright restrictions, we aren't able to include the exact definitions here. Click on the links to get more details on each function.)</para>
+						<section id="Sine">
+							<title>Sine</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#sin(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#sin(double)</ulink>
+							</para>
+						</section>
+						<section id="Cosine">
+							<title>Cosine</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#cos(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#cos(double)</ulink>
+							</para>
+						</section>
+						<section id="Tangent">
+							<title>Tangent</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#tan(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#tan(double)</ulink>
+							</para>
+						</section>
+						<section id="Arc_Sine">
+							<title>Arc Sine</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#asin(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#asin(double)</ulink>
+							</para>
+						</section>
+						<section id="Arc_Cosine">
+							<title>Arc Cosine</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#acos(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#acos(double)</ulink>
+							</para>
+						</section>
+						<section id="Arc_Tangent">
+							<title>Arc Tangent</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#atan(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#atan(double)</ulink>
+							</para>
+						</section>
+						<section id="Convert_Degree_to_Radians">
+							<title>Convert Degree to Radians</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#toRadians(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#toRadians(double)</ulink>
+							</para>
+						</section>
+						<section id="Convert_Radians_to_Degrees">
+							<title>Convert Radians to Degrees</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#toDegrees(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#toDegrees(double)</ulink>
+							</para>
+						</section>
+						<section id="Exp">
+							<title>Exp</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#exp(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#exp(double)</ulink>
+							</para>
+						</section>
+						<section id="Log">
+							<title>Log</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#log(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#log(double)</ulink>
+							</para>
+						</section>
+						<section id="Log_b10">
+							<title>Log b10</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#log10(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#log10(double)</ulink>
+							</para>
+						</section>
+						<section id="Square_Root">
+							<title>Square Root</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#squareRoot(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#squareRoot(double)</ulink>
+							</para>
+						</section>
+						<section id="Cube_Root">
+							<title>Cube Root</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#cbrt(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#cbrt(double)</ulink>
+							</para>
+						</section>
+						<section id="Remainder">
+							<title>Remainder</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#iEEEremainder(double,%20double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#iEEEremainder(double,%20double)</ulink>
+							</para>
+						</section>
+						<section id="Ceiling">
+							<title>Ceiling</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#ceil(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#ceil(double)</ulink>
+							</para>
+						</section>
+						<section id="Floor">
+							<title>Floor</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#floor(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#floor(double)</ulink>
+							</para>
+						</section>
+						<section id="Rount">
+							<title>Rount</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#rint(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#rint(double)</ulink>
+							</para>
+						</section>
+						<section id="Arc_Tangent_Rectangular">
+							<title>Arc Tangent Rectangular</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#atan2(double,%20double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#atan2(double,%20double)</ulink>
+							</para>
+						</section>
+						<section id="Power_2">
+							<title>Power</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#pow(double,%20double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#pow(double,%20double)</ulink>
+							</para>
+						</section>
+						<section id="Absolute_Value">
+							<title>Absolute Value</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#abs(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#abs(double)</ulink>
+							</para>
+						</section>
+						<section id="Maximum">
+							<title>Maximum</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#max(double,%20double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#max(double,%20double)</ulink>
+							</para>
+						</section>
+						<section id="Minimum">
+							<title>Minimum</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#min(double,%20double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#min(double,%20double)</ulink>
+							</para>
+						</section>
+						<section id="ULP">
+							<title>ULP</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#ulp(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#ulp(double)</ulink>
+							</para>
+						</section>
+						<section id="Sign">
+							<title>Sign</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#signum(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#signum(double)</ulink>
+							</para>
+						</section>
+						<section id="Hyperbolic_Sine">
+							<title>Hyperbolic Sine</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#sinh(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#sinh(double)</ulink>
+							</para>
+						</section>
+						<section id="Hyperbolic_Cosine">
+							<title>Hyperbolic Cosine</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#cosh(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#cosh(double)</ulink>
+							</para>
+						</section>
+						<section id="Hyperbolic_Tan">
+							<title>Hyperbolic Tan</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#tanh(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#tanh(double)</ulink>
+							</para>
+						</section>
+						<section id="Hypotuneuse">
+							<title>Hypotuneuse</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#hypotuneuse(double,%20double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#hypotuneuse(double,%20double)</ulink>
+							</para>
+						</section>
+						<section id="Expm1">
+							<title>Expm1</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#expm1(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#expm1(double)</ulink>
+							</para>
+						</section>
+						<section id="Log1p">
+							<title>Log1p</title>
+							<para>See JavaDoc: 
+								<ulink url="http://java.sun.com/javase/6/docs/api/java/lang/Math.html#log1p(double)">http://java.sun.com/javase/6/docs/api/java/lang/Math.html#log1p(double)</ulink>
+							</para>
+						</section>
+					</section>
+				</section>
+				<section id="Random">
+					<title>Random</title>
+					<section id="Design">
+						<title>Design</title>
+						<para>Random functions are especially significant for agent models. Of particular interest are the weighted membership and random state and boolean value functions. You should be familiar with these functions so that you don't have to create more complex Action flows to accomplish the same thing.</para>
+						<para>Note that we only have support for uniform distributions as of this release. We're working on a collaborative design for evaluations that allow easy mixing and matching of random functions and distributions.</para>
+					</section>
+					<section id="Details_6">
+						<title>Details</title>
+						<section id="Random_In_Range">
+							<title>Random In Range</title>
+							<para>A pseudo-random value within that numeric range specified as drawn from a uniform distribution. The minimum values are inclusive. The maximum values are inclusive for integer inputs and exclusive for Real inputs.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Numeral] The minimum value (inclusive).
+[Numeral] The maximum value (inclusive).
+Outputs:
+[Numeral] The random number.
+</literallayout>
+						</section>
+						<section id="Random_To_Limit">
+							<title>Random To Limit</title>
+							<para>A pseudo-random value between zero and the value specified by the (non-zero) input and drawn from a uniform range. That value is inclusive for Integers and exclusive for Reals. (Note that as with the random in range function in the context of real numbers the distinction between an exclusive and inclusive limit is essentially meaningless.)</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Numeral] The maximum value (inclusive).
+Outputs:
+[Numeral] The result.
+</literallayout>
+						</section>
+						<section id="Random_Unit">
+							<title>Random Unit</title>
+							<para>A pseudo-random Real value between 0 and 1 drawn from a uniform distribution. (The distinction between inclusive and exclusive range is essentially meaningless in this context and we can assume that the result will never be greater or equal to 1.)</para>
+							<literallayout format="linespecific" class="normal">Outputs:
+[Real] 
+</literallayout>
+						</section>
+						<section id="Random_Boolean">
+							<title>Random Boolean</title>
+							<para>A value that is randomly true or false, i.e. a fair coin toss.</para>
+						</section>
+						<section id="Random_Weighted">
+							<title>Random Weighted</title>
+							<para>An indexed value weighted against a probability distribution. The total probability must sum to 1.0. For example, an input of {.1,.2,.7} under a uniform distribution would would have 10% probability of producing "0" , 20%  for "1" and 70% for "2". This function can then be used with Item to return a biased result from another list.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Real] A list of values that will determine the resulting weighted index.
+Outputs:
+[Integer] A resulting indexed value bounded by 0 and the length of the input list - 1.
+</literallayout>
+						</section>
+						<section id="Random_Member">
+							<title>Random Member</title>
+							<para>Represents a random value drawn from the set of Real values specified.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Real] Returns a random member of the supplied list of numbers.
+Outputs:
+[Generic] The value of the item at a random index.
+</literallayout>
+						</section>
+						<section id="Random_State">
+							<title>Random State</title>
+							<para>A random specified value (option) from the specified state.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Generic] The state to select items from. All items are included.
+Outputs:
+[Boolean] The resulting option. 
+</literallayout>
+						</section>
+					</section>
+				</section>
+				<section id="Space_3">
+					<title>Space</title>
+					<section id="Design_2">
+						<title>Design</title>
+						<para>Spatial functions provide the core functionality for Agent Models. Spatial functions are polymorphic, which basically means that they don't care what space they are operating on as long as that space is suitable for them. Spatial functions are designed to collaborate with one another. For example, by intersecting the "Neighbor", "Available" and "Toward" functions, we can design a rule that causes the agent to move to the next neighboring cell that get's it closer to some target agent. See the function details for more information.</para>
+					</section>
+					<section id="Details_7">
+						<title>Details</title>
+						<section id="Nearest">
+							<title>Nearest</title>
+							<para>Represents the nearest agents (including gird cells) or locations to this agent. If more than one agent or location is the same distance away they will all be considered. Note that while this function is defined for the selection of an agent, the result of this function is defined by the context within which it is used. If the selection specifies another agent within a space, this function will represent the nearest agent in that space. If the selection specifies a Cell within a grid space, this function will represent that cell.</para>
+						</section>
+						<section id="Toward">
+							<title>Toward</title>
+							<para>Represents a location that is on the shortest path to a particular agent or location from the source agent (that is, the selection's selection's agent). This function collaborates with the within and neighbor functions to allow the agent to move in a particular direction towards some objective.</para>
+						</section>
+						<section id="Within_4">
+							<title>Within</title>
+							<para>Represents a limit to the distance of a spatial search. When used in combination with other spatial functions such as "nearest" requires that all agents or locations must be within the distance specified by the input value.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Numeral] 
+</literallayout>
+						</section>
+						<section id="Neighbor">
+							<title>Neighbor</title>
+							<para>Represents any agents that are nearest neighbors to the agent, that is nominally of distance 1. This function is only relevant in discrete spaces -- grids and networks -- where there are immediate neighboring cells as defined by the geometry of the selection's space.</para>
+						</section>
+						<section id="Include_Self">
+							<title>Include Self</title>
+							<para>Specifies whether the agent that we are searching from -- that is, the agent of the selection for this Query Action's selection -- is included in the results of the search.</para>
+						</section>
+						<section id="Within_2D_Boundary">
+							<title>Within 2D Boundary</title>
+							<para>Represents agents or locations that exist within the boundary specified by the inputs.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Numeral] 
+</literallayout>
+						</section>
+						<section id="Here">
+							<title>Here</title>
+							<para>Represents the location of the searching agent. For example, if a selection is defined for an agent cell, and that selection's selection's agent is an occupant of a cell, the cell that the agent is occupying will be used. </para>
+						</section>
+						<section id="Available">
+							<title>Available</title>
+							<para>Represents cells which are not currently occupied. This function is only relevant for grids which are not multi-occupant.</para>
+						</section>
+						<section id="Distance">
+							<title>Distance</title>
+							<para>The distance between the source agent and an agent represented by this selection. If more than one agent is represented by the other functions in the selection, this function will the distance to an arbitrary (randomly selected) agent as defined by those other functions.</para>
+							<literallayout format="linespecific" class="normal">Outputs:
+[Real] 
+</literallayout>
+						</section>
+						<section id="Away">
+							<title>Away</title>
+							<para>Represents a location that is on the path that will take the source agent (that is, the selection's selection's agent) the farthest distance from the agent(s) represented by the search. This function collaborates with the within and neighbor functions to allow the agent to move in a particular direction away from some location or agent.</para>
+						</section>
+						<section id="Minimize">
+							<title>Minimize</title>
+							<para>This function is not currently supported.</para>
+						</section>
+						<section id="Maximize">
+							<title>Maximize</title>
+							<para>This function is not currently supported.</para>
+						</section>
+						<section id="Location_2D">
+							<title>Location 2D</title>
+							<para>Represents the location of the current agent for use in subsequent selections.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Real] 
+[Real] 
+</literallayout>
+						</section>
+						<section id="Boundary_2D">
+							<title>Boundary 2D</title>
+							<para>Represents a two-dimensional boundary within a space. (Not currently relevant for any general usages.)</para>
+							<literallayout format="linespecific" class="normal">Outputs:
+[Real] 
+[Real] 
+</literallayout>
+						</section>
+					</section>
+					<section id="Example_2">
+						<title>Example</title>
+						<para>For examples of how spatial functions can be used within action flows to provide agents with complex movement behaviors, see the Modelers Guide actions examples. In the following example from that section, we define an action that causes a partner agent to move to an available neighboring space.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/actions/ActionsExampleNew.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+				<section id="Time">
+					<title>Time</title>
+					<section id="Details_8">
+						<title>Details</title>
+						<section id="Now">
+							<title>Now</title>
+							<para>The current simulation period, that is the number of iterations that the model has gone through, or in the case of models with callibrarted time, the number of iterations added to the model's nominal start time.</para>
+							<literallayout format="linespecific" class="normal">Outputs:
+[Integer] The current period.
+</literallayout>
+						</section>
+					</section>
+				</section>
+				<section id="Graphics">
+					<title>Graphics</title>
+					<section id="Design_3">
+						<title>Design</title>
+						<para>Graphic functions are combined within Style Evaluate Actions to determine how to draw an agent within a visualization. One nice aspect of this approach is that the same style definition can be used in multiple places without changing any code. For example, the same style could be used to draw an agent on a two-dimensional grid within Escape, a three-dimensional shape within Escape, a Java Swing based visualization in Ascape, and an XML configured visualizaiton in Repast Simphony.</para>
+						<para>To define a graphic style for an agent, design a flow in which you create Evaluate Actions for color and shape, and then create an Evaluate Action with the graphic fill or outline function as a target of these.</para>
+					</section>
+					<section id="Details_9">
+						<title>Details</title>
+						<section id="Shape_Oval">
+							<title>Shape Oval</title>
+							<para>Draw a generic oval.</para>
+						</section>
+						<section id="Shape_Rectangle">
+							<title>Shape Rectangle</title>
+							<para>Draws a rectangular shape.</para>
+						</section>
+						<section id="Shape_Inset">
+							<title>Shape Inset</title>
+							<para>Shrinks the current shape by the input amount. (The overall scale is currently unspecified, but in most implementations should be 20.)</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Integer] Number of nominal pixels to inset.
+</literallayout>
+						</section>
+						<section id="Shape_Marker">
+							<title>Shape Marker</title>
+							<para>Draw a marker, that is a graphical indicator that can be used to add an additional cue about the object state. For example, in a two-dimensional graphics representation this might be a small shape drawn inset at the corner of the larger shape. </para>
+						</section>
+						<section id="Shape_Marker_2">
+							<title>Shape Marker 2</title>
+							<para>Represents a marker placed in a different location from the other shape markers.</para>
+						</section>
+						<section id="Shape_Marker_3">
+							<title>Shape Marker 3</title>
+							<para>Represents a marker placed in a different location from the other shape markers.</para>
+						</section>
+						<section id="Color_RGB">
+							<title>Color RGB</title>
+							<para>A color specified by the three inputs for Red, Green and Blue color components. Those inputs are expected to be in the range 0..1.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Real] A value from 0.0 to 1.0.
+[Real] A value from 0.0 to 1.0.
+[Real] A value from 0.0 to 1.0.
+</literallayout>
+						</section>
+						<section id="Color_Red">
+							<title>Color Red</title>
+							<para>The color red.</para>
+						</section>
+						<section id="Color_Yellow">
+							<title>Color Yellow</title>
+							<para>The color yellow.</para>
+						</section>
+						<section id="Color_Blue">
+							<title>Color Blue</title>
+							<para>The color blue.</para>
+						</section>
+						<section id="Color_Orange">
+							<title>Color Orange</title>
+							<para>The color orange.</para>
+						</section>
+						<section id="Color_Green">
+							<title>Color Green</title>
+							<para>The color green.</para>
+						</section>
+						<section id="Color_Purple">
+							<title>Color Purple</title>
+							<para>The color purple.</para>
+						</section>
+						<section id="Color_Black">
+							<title>Color Black</title>
+							<para>The color black.</para>
+						</section>
+						<section id="Color_White">
+							<title>Color White</title>
+							<para>The color white.</para>
+						</section>
+						<section id="Color_Gray">
+							<title>Color Gray</title>
+							<para>The color gray.</para>
+						</section>
+						<section id="Graphic_Outline">
+							<title>Graphic Outline</title>
+							<para>Draws an outline of the last evaluated shape, using the last specified color or the default color (usually black) if none has been specified.</para>
+						</section>
+						<section id="Graphic_Fill">
+							<title>Graphic Fill</title>
+							<para>Fills the last evaluated shape with the last specified color or the default color (usually black) if none has been specified.</para>
+						</section>
+					</section>
+					<section id="Example_3">
+						<title>Example</title>
+						<para>In the following action flow for the epidemic style, we've create Query Actions to determine each agent's current state, picked a color based on that, and then used a shared target to select a shape for the agent style and fill it:</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/functions/GraphicsFunctionExampleDesign.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>After saving the model we can execute the two and three dimensional visualizations. Note something really nice -- even the charts have used the colors we've defined!</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/functions/GraphicsFunctionExampleRun.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+				<section id="Lists">
+					<title>Lists</title>
+					<section id="Details_10">
+						<title>Details</title>
+						<section id="Item">
+							<title>Item</title>
+							<para>Returns the item at the specified index from the list of items provided. Those items will typically be input primitives such as Integer or Real values.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Generic] 
+[Integer] 
+Outputs:
+[Generic] 
+</literallayout>
+						</section>
+						<section id="Length">
+							<title>Length</title>
+							<para>The number of items in the provided list of items.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Generic] 
+Outputs:
+[Integer] 
+</literallayout>
+						</section>
+					</section>
+				</section>
+				<section id="Attribute_Distributions">
+					<title>Attribute Distributions</title>
+					<para>One of the most common tasks in the Agent Modeling process is the creation of agents with particular states drawn from a distribution. For example, you might want to create a number of agents with wealth randomly distributed between some minimum and maximum values. The distribution functions greatly ease the process of setting up those initializations and their associated parameters.</para>
+					<section id="Distribution">
+						<title>Distribution</title>
+						<section id="Uniform_Cross_Distribution">
+							<title>Uniform Cross Distribution</title>
+							<para>A random number taken from a distribution of values as defined by a cross of all values. (See Cross Distribution.) This funciton then returns a value drawn from the minimum and maximum values as determined by the current agent state. In the cross distribution, each of the values is treated independently so that an input attribute is created for every potential combination of states.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Generic] The list of states to factor into the distribution. This is a multi-argument, which means that you can specify any number of attributes as arguments.
+[Real] The set of attributes that will determine the minimum value of the function result based on the current state of the agent. Note that this list is automatically created and maintained. These values don't need to be and should not be manually edited.
+[Real] The set of attributes that will determine the maximum value of the function result based on the current state of the agent. Note that this list is automatically created and maintained. These values don't need to be and should not be manually edited.
+Outputs:
+[Real] The resulting random number based on the current agent state and the input parameters.
+</literallayout>
+						</section>
+						<section id="Uniform_Additive_Distribution">
+							<title>Uniform Additive Distribution</title>
+							<para>A random number taken from a distribution of values in which each of the minimum and maximum values are added to determine a total minimum and maximum value. (See Additive Distribution.) In the additive distribution, each of the values is treated as dependent on the others so that an input attribute is only created for each seperate state.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Generic] The list of states to factor into the distribution. This is a multi-argument, which means that you can specify any number of attributes as arguments.
+[Real] The set of attributes that will determine the minimum value of the function result based on the current state of the agent. Note that this list is automatically created and maintained. These values don't need to be and should not be manually edited.
+[Real] The set of attributes that will determine the maximum value of the function result based on the current state of the agent. Note that this list is automatically created and maintained. These values don't need to be and should not be manually edited.
+Outputs:
+[Real] The resulting random number based on the current agent state and the input parameters.
+</literallayout>
+						</section>
+						<section id="Cross_Distribution">
+							<title>Cross Distribution</title>
+							<para>A value taken from a set of (auto-generated) attributes based on the value of each state included. For example, if the multi-values included a state X with values A and B and a state Y with values I and II, this distribution would create separate input attributes for AI, AII, BI and BII. Then for an agent with States A and II this function would return the value specified by the AII input attribute.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Generic] The list of states to factor into the distribution. This is a multi-argument, which means that you can specify any number of attributes as arguments.
+[Real] The set of attributes that when multiplied against each other will determine the value of the function result based on the current state of the agent. Note that this list is automatically created and maintained. These values don't need to be and should not be manually edited.
+Outputs:
+[Real] The resulting value based on the current agent state and the input parameters.
+</literallayout>
+						</section>
+						<section id="Additive_Distribution">
+							<title>Additive Distribution</title>
+							<para>A value taken from a set of (auto-generated) attributes based on the combined values of the states provided. For example, if the multi-values included a state X with values A and B and a state Y with values I and II, this distribution would create input attributes for A, B, I and II. Those values would then be added together, so that for an Agent with state A and II this function would return A + II.</para>
+							<literallayout format="linespecific" class="normal">Inputs:
+[Generic] The states to include in the distribution. This is a multi-argument, which means that you can specify any number of attributes as arguments.
+[Real] The set of attributes that when combined with each other determine the value of the function result based on the current state of the agent. Note that this list is automatically created and maintained. These values don't need to be and should not be manually edited.
+Outputs:
+[Real] The resulting value based on the current agent state and the input parameters.
+</literallayout>
+						</section>
+					</section>
+					<section id="Example_4">
+						<title>Example</title>
+						<para>In the following example, we walk through the process of using a distribution functions, demonstrating how we can easily modify the Epidemic model so that instead of simply setting an initial exposed population, we can define factors that take together will determine an individuals initial exposure state. We simply:</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>Create an Evaluate Action called "Initial Status". </para>
+							</listitem>
+							<listitem>
+								<para>Set the function to "Cross Distribution"</para>
+							</listitem>
+							<listitem>
+								<para>Opened the "Multiple Value" node in the editor, and clicked the "Multiple Values" item within it.</para>
+							</listitem>
+							<listitem>
+								<para>Selected the "Status" attribute.</para>
+							</listitem>
+						</orderedlist>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/functions/DistributionDesignChoice.png" scale="50"/>
+								</imageobject>
+							</mediaobject> 
+						</para>
+						<para>The appropriate attributes are automatically added to the model, as you can see below.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/functions/DistributionDesign.png" scale="50"/>
+								</imageobject>
+							</mediaobject> 
+						</para>
+						<para>In order to assign these values to the agent, we'd simply need to assign the results of this Evaluate Action to the agent.</para>
+					</section>
+				</section>
+			</section>
+			<section id="Reference_3">
+				<title>Reference</title>
+				<section id="Diagrams_3">
+					<title>Diagrams</title>
+					<para>The following diagram may be helpful to readers familiar with UML and Meta-modeling:</para>
+					<section id="Meta-Classes_3">
+						<title>Meta-Classes</title>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/functions/FunctionsDiagram.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+			</section>
+		</section>
+	</chapter>
+	<chapter id="User_Guide">
+		<title>User Guide</title>
+		<para>In this section of the guide, we'll discuss specific aspects of the Agent Modeling tools and show you how to use them in your day to day agent development activities. We discuss only tools specific to Agent Modeling itself. For more general information about the tools, such as how to customize editors, views, and perspectives, see the 
+			<emphasis role="bold">Workbench User Guide</emphasis>.
+		</para>
+		<section id="Overview_5">
+			<title>Overview</title>
+			<para>The Agent Modeling Platform provides two general modes or "perspectives" for working with Agent Models.</para>
+			<para>
+				<mediaobject>
+					<imageobject>
+						<imagedata fileref="images/tools/Perspectives.png" scale="50"/>
+					</imageobject>
+				</mediaobject>
+			</para>
+			<para>
+				<emphasis role="bold">Agent Modeling</emphasis> supports all aspects of working with models, including editing models and automatically generating all the of your code and documentation. 
+				<emphasis role="bold">Agent Execution</emphasis> supports running and exploring those models. A key feature of the Agent Modeling Platform is the ability to execute models within the same environment that they are developed within -- you don't need to launch a separate environment in order to run a model. Agent Execution automatically activates when you launch a model. We'll discuss the agent modeling tools first, and then turn to agent execution.
+			</para>
+		</section>
+		<section id="Modeling">
+			<title>Modeling</title>
+			<section id="Perspective">
+				<title>Perspective</title>
+				<para>The Provides a custom layout menus and tools specific to working with agent models. Because the agent modeling process also often involves Java and Eclipse Plugin development we include easy access to many of those tools here as well.</para>
+			</section>
+			<section id="Creating_Projects_and_Models">
+				<title>Creating Projects and Models</title>
+				<para>You can create projects and project components using the Popup menu. Just click in a blank space within the Package Explorer. Any installed project targets are displayed in this menu. For example, if you've installed the Simphony target, you'd see that displayed in this menu as well.</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/edit_tutorial/SimpleTutorial3CreateModel.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+			</section>
+			<section id="Menus.2C_Popups_and_Toolbar">
+				<title>Menus, Popups and Toolbar</title>
+				<para>The popup menus and application menus provide access to various model features and are context sensitive.  Throughout these screenshots, we've customized the toolbar in order to only show the agent Modeling specific features.</para>
+			</section>
+			<section id="Views">
+				<title>Views</title>
+				<para>By default the workbench includes a number of views. See the Workbench documentation for more details on how they can be customized accessed and used.</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/tools/Workbench.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+				<section id="Editor">
+					<title>Editor</title>
+					<para>This is not technically a view in itself. It is the major focus of the workbench and contains any edit models or other files such as Java source or parameters.</para>
+				</section>
+				<section id="Default_Views">
+					<title>Default Views</title>
+					<para>The default modeling views are visible by default.</para>
+					<section id="Package_Explorer">
+						<title>Package Explorer</title>
+						<para>Supports navigation within projects.</para>
+					</section>
+					<section id="Properties">
+						<title>Properties</title>
+						<para>The properties allows you to view and edit specific details for the currently selected object. For example, if you select a model context, you'll be able to edit its attributes here.</para>
+					</section>
+					<section id="Outline">
+						<title>Outline</title>
+						<para>The outline view supports easy navigation within the edited files. See the model editing sections for more on how the outline can be used to assist exploration of Agent Models.</para>
+					</section>
+				</section>
+				<section id="Diagnostic_Views">
+					<title>Diagnostic Views</title>
+					<para>There are a number of views that can be used to explore issues that might come up during the modeling process. You can see them on the lower left-hand corner of the screenshot above. Click on one of the icons to view their contents.</para>
+					<section id="Problems">
+						<title>Problems</title>
+						<para>This view is one that you'll become very familiar with. It is used to display specific about problems with any of the artifacts (files) in your modeling project. If you see a red or yellow marker on a file, opening the view will present a list of the issues that are currently being reported. For a usage example, please see the Tutorial.</para>
+					</section>
+					<section id="Console">
+						<title>Console</title>
+						<para>This view displays text (console) output for appropriate processes. For example, if you launch an Ascape project, this will display any output that would go to the Java console.</para>
+					</section>
+					<section id="Errors">
+						<title>Errors</title>
+						<para>This is another view that you will find valuable in your day to day modeling activities. The error log lists everything important that happens during model execution. It's the first place to look if something mysterious goes wrong, and when you report problems it's always helpful to include anything that could be relevant in the log. Despite its name, the Errors view is not just for reporting errors -- it is also used to report progress on normal operations. For example, when models are automatically generated that is reported to the log, as we can see in the following example:</para>
+					</section>
+				</section>
+			</section>
+			<section id="Modeling_Tree_Editor">
+				<title>Modeling Tree Editor</title>
+				<para>The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models include textual languages and custom editors that are part of commercial offerings.</para>
+				<section id="Opening_the_Editor">
+					<title>Opening the Editor</title>
+					<para>To open a model in the editor, simply double-click on it. If the model doesn't open in the model editor (if for example it had been previously opened using another editor), you can always access the editor using 
+						<emphasis role="bold">Open With &gt; Other...</emphasis> and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll discuss at the end of this section.
+					</para>
+				</section>
+				<section id="Structure_2">
+					<title>Structure</title>
+					<para>The model is composed of nodes representing specific model entities such as agents, actions and spaces. For details about any of these entities, see the Concepts section.</para>
+					<section id="Opening_Components">
+						<title>Opening Components</title>
+						<para>After opening a model, you can see the contents by clicking the Triangle symbol to the left of an item. For example, opening the root context node, we see:</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/Editor.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Creating_Components">
+						<title>Creating Components</title>
+						<para>You add nodes by right-clicking on a node, like so:</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorAdd.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Editing_Components">
+						<title>Editing Components</title>
+						<para>To edit components, select the node you want to modify. The 
+							<emphasis role="bold">Properties View</emphasis> will be updated with the agent details. Use the properties view to modify the values. In the screenshot below, we're editing the values for the City space.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorEditing.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Moving_Components">
+						<title>Moving Components</title>
+						<para>You can often rearrange model components by dragging them from one place to another. In the following example, we're creating a model of a regional epidemic by creating a City sub-context and moving the agent into it: </para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorMoving.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Removing_Components">
+						<title>Removing Components</title>
+						<para>You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entity still exist.</para>
+					</section>
+					<section id="Copying_Components">
+						<title>Copying Components</title>
+						<para>To make a copy of an entity and place it in a new location, option-drag the entity to the destination. You can make a copy in the existing location by dragging it into the same parent. The name will automatically be updated with "copy" appended to it.</para>
+					</section>
+					<section id="Editing_Attributes">
+						<title>Editing Attributes</title>
+						<para>The attributes node -- along with the actions and styles nodes -- represents a group of components rather than an entity itself. It contains all of the attributes for the parent agent or context. In the examples below, we can see the attributes for the Epidemic route model. Note that the top level attributes in a root context act as the parameters for the model itself.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorAttributes.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Editing_Styles">
+						<title>Editing Styles</title>
+						<para>The Styles node is another group node, in this case representing a set of styles that can be used to visualize the agents. When creating a style, you will need to create a Rule for each style as well, like so:</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorStyles.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+				<section id="Actions_3">
+					<title>Actions</title>
+					<para>Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying structure of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.</para>
+					<para>Like attributes and styles, every agent has a single Actions nodes which contains its Root Action(s).</para>
+					<section id="Creating_Actions">
+						<title>Creating Actions</title>
+						<para>You create actions as with any other component, by right-clicking on the source action and choosing the new action. The menu is organized by usage.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorActionMenu.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Editing_Actions">
+						<title>Editing Actions</title>
+						<para>Actions and their inputs are edited just like any other model component. Click on the action or input you want to edit and then make changes to it in the properties editor.</para>
+					</section>
+					<section id="Order">
+						<title>Order</title>
+						<para>Generally, action sources will appear above their targets. In the case where there is only one source for a given target, and that target has no other sources, they will appear directly above one another. Its important to note however that 
+							<emphasis role="italic">the order of the nodes does not indicate a specific source and target relationship</emphasis>. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part of the label.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/ActionsExample.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>In the above example, the Initialize Location "Initialize Action" is straightforward. We simply define a Select Action, a Query Action target for that selection, and then a Move Action target for the query. The "Transmission" Rule is more complicated. Note for example that the "Infectious" Union Action is the target of both the "Asymptomatic Infectious" and  "Symptomatic Infectious" Query Actions. The "Vulnerable Neighbor" action has the label "Vulnerable Neighbor [Potential Exposure] &lt;- [Potential Exposure]" indicating that the "Potential Exposure" action serves as its selection as well as its source.</para>
+					</section>
+					<section id="Initial_Order">
+						<title>Initial Order</title>
+						<para>A new action's initial target will be the action that you clicked on when creating it. For an action that should always act within a given root action (i.e. Rule, Schedule, etc..), add it to the root action. A root action can have more than one target.</para>
+					</section>
+					<section id="Changing_Sources_and_Targets_.28Reordering.29">
+						<title>Changing Sources and Targets (Reordering)</title>
+						<para>An action's target can be changed by dragging it over the new target action. Note that this is a different behavior from that of standard entity movement. You cannot make an action a target of an action that is itself a source of the modified action! (See the concepts section for why.) Using the default tree editor you cannot change an action's targets directly; instead select the action's target and move that. </para>
+					</section>
+					<section id="Adding_Sources_and_Targets">
+						<title>Adding Sources and Targets</title>
+						<para>As discussed earlier, actions often have multiple sources and targets. To make an action the target of an additional action, click on target action, hold down the control key, and drag the action to its new destination. See the tutorial for a complete example.</para>
+					</section>
+					<section id="Removing_Sources_and_Targets">
+						<title>Removing Sources and Targets</title>
+						<para>You cannot remove single sources from targets directly using the tree editor. Instead, first drag the agent to a source nodes that will be part of its changed set of sources. That will remove all existing actions sources but for the one you have just dragged it to. Then add back any of the other source and target nodes you wish to retain.</para>
+					</section>
+					<section id="Removing_Actions">
+						<title>Removing Actions</title>
+						<para>You can remove actions in the same way as with structural model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from high in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.</para>
+					</section>
+					<section id="Copying_Actions">
+						<title>Copying Actions</title>
+						<para>Copying actions works just as with other entities, and copies will become targets of their option-drag destination. </para>
+					</section>
+					<section id="Query_and_Evaluation_Inputs_2">
+						<title>Query and Evaluation Inputs</title>
+						<para>The number of inputs is determined by the selected functions. (In rare cases where a function can take an arbitrary number of arguments you may need to create additional values or delete existing ones.) In the following example, we're picking the Symptom Infectious status for a query that will affect the potentially exposed agents. Note that is instead you wanted to compare another kind of value -- for example an Integer value -- you would need to change the first input listed before changing the second input so that you will be able to get the appropriate options for the second.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/Inputs.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Input_Literals_2">
+						<title>Input Literals</title>
+						<para>To create an input value, right click on the input and select 
+							<emphasis role="bold">Create Member &gt; Literal</emphasis>. Then specify the actual value in the Value property in the 
+							<emphasis role="bold">Properties View</emphasis>.
+						</para>
+					</section>
+				</section>
+			</section>
+		</section>
+		<section id="Building">
+			<title>Building</title>
+			<section id="Building_Models">
+				<title>Building Models</title>
+				<para>If you've used other development environments, you're probably used to a separate build step. For example, if you edit a set of Java files, you might invoke a compile command. Eclipse and the Agent Modeling Platform support automatic building. This means that in order to build your code, you simply save the model and the environment takes care of the rest. What gets built is defined by the project. For example, if you save a model that is contained within an Agent Modeling Escape Project, the following steps occur automatically:</para>
+				<orderedlist inheritnum="ignore" continuation="restarts">
+					<listitem>
+						<para>The Escape builder generates Java code for the Escape API, including support for specialized graphics and (if enabled) 3D visualization.</para>
+					</listitem>
+					<listitem>
+						<para>The Documentation builder generates custom html documentation for the model.</para>
+					</listitem>
+					<listitem>
+						<para>The Java builder takes the Java code generated above and compiles it.</para>
+					</listitem>
+					<listitem>
+						<para>The Manifest and Schema builders package the project for use as part of the Eclipse plugin environment.</para>
+					</listitem>
+				</orderedlist>
+				<para>So what do you do if you want to generate code for a different target, such as Repast? Here, you simply create another project and drag the model into it. You can also edit the builders for a given project (see the Workbench Documentation) but you'll only want to do that if you're making permanent changes to the project itself.</para>
+			</section>
+			<section id="Generating_Specialized_Model_Artifacts">
+				<title>Generating Specialized Model Artifacts</title>
+				<para>You can also manually generate code for models. This is useful if you want to create code for a model in a non target project and don't want the automatic build capabilities. There are also specialized targets that can be generated manually that are bundled with the tools -- AMP plugin developers can easily add custom generation targets for this menu. To generate custom artifacts, right-click on a model and select 
+					<emphasis role="bold">Generate</emphasis>.
+				</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/tools/GenerateMenu.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+				<para>Targets include:</para>
+				<section id="Platform_Targets">
+					<title>Platform Targets</title>
+					<para>Creates code for one of the installed targets, such as Ascape, Escape, and Simphony. (Again, these generators are unnecessary for projects that already have target specific builders configured.)</para>
+				</section>
+				<section id="Interfaces">
+					<title>Interfaces</title>
+					<para>Creates a complete set of interfaces for the model classes. These can be very useful for development and integration in enterprise environments. Generated classes are placed in the src directory with "I" added to the name. For example, if you generate interfaces for a model with an "Individual" agent, this target will create an "IIndividual" interface that includes getters, setters and methods for all of the agent's attributes and actions.</para>
+				</section>
+				<section id="Skeleton">
+					<title>Skeleton</title>
+					<para>Creates a base class for the model. This is essentially a complete implementation, but without the action implementations. Again, these classes can be useful when generating code for use in enterprise and other specialized environments.</para>
+				</section>
+				<section id="Test_Cases">
+					<title>Test Cases</title>
+					<para>Generates base support (needing customization) test cases for use in JUnit tests.</para>
+				</section>
+				<section id="Text_Documents">
+					<title>Text Documents</title>
+					<para>Creates simple text documentation for use in other documents.</para>
+				</section>
+				<section id="Generate_Key_Graphics">
+					<title>Generate Key Graphics</title>
+					<para>This specialized target supports the creation of graphic keys for the model. To use this target:</para>
+					<orderedlist inheritnum="ignore" continuation="restarts">
+						<listitem>
+							<para>Generate the code.</para>
+						</listitem>
+						<listitem>
+							<para>Add a dependency to the Manifest for "org.eclipse.amp.amf.gen.extras".</para>
+						</listitem>
+						<listitem>
+							<para>In the srcutil directory find the Java source code for the calss {RootContext}GraphicsWriter. For example, for the Epidemic model, this would be srcutil/name.milesparker.epi/EpidemicGraphicsWriter.java.</para>
+						</listitem>
+						<listitem>
+							<para>Right-click, and select 
+								<emphasis role="bold">Run As &gt; Java Application</emphasis>.
+							</para>
+						</listitem>
+						<listitem>
+							<para>Refresh the project by right-clicking on it and selecting 
+								<emphasis role="bold">Refresh</emphasis>.
+							</para>
+						</listitem>
+						<listitem>
+							<para>The Doc directory will now contain a number of new files, including</para>
+							<orderedlist inheritnum="ignore" continuation="restarts">
+								<listitem>
+									<para>{RootContext}Key.png</para>
+								</listitem>
+								<listitem>
+									<para>{RootContext}GraphicsKey.html</para>
+								</listitem>
+							</orderedlist>
+						</listitem>
+					</orderedlist>
+					<para>Both files contain graphic representations of the model using the definitions defined by the model styles, very useful artifacts for inclusion in papers and web pages describing your model. For example, here is the EpidemicKey.png:</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/tools/EpidemicKey.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+				<section id="Function_Docs">
+					<title>Function Docs</title>
+					<para>Generates WikiText documentation for function libraries. We use it to create the function documentation in this guide!</para>
+				</section>
+			</section>
+		</section>
+		<section id="Exploring">
+			<title>Exploring</title>
+			<section id="Launching_a_Model_.28AMF.29">
+				<title>Launching a Model (AMF)</title>
+				<informaltable frame="none">
+					<tr>
+						<td rowspan="1" colspan="1">Launching AMF and Escape models is easy. When an AMF file is selected -- in any of the perspectives -- the toolbar and Application menus are updated to reflect the file you've selected and provide convenient access to other functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. If you right-click on a file a pop-up menu appears like the one to the far right -- in this case we're selecting the "Execute Headless" option. To launch a model, just select one of the options. (Note that the execution framework doesn't know whether your code exists in an Escape project or another target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.)</td>
+						<td rowspan="1" colspan="1">
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorToolbar.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</td>
+						<td rowspan="1" colspan="1">
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/tools/EditorMenu.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</td>
+					</tr>
+				</informaltable>
+				<para>One a model has been launched, the Agent Execution Perspective automatically becomes active. The Provides a custom layout menus and tools specific to executing agent models.</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/execution/EpidemicExecNew.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+				<para>The execution options are:</para>
+				<section id="Execute">
+					<title>Execute</title>
+					<para>Launches the model using default graphics, opening the Agent Execution perspective.</para>
+				</section>
+				<section id="Execute_Headless">
+					<title>Execute Headless</title>
+					<para>Launches the model without graphics, opening the Agent Execution perspective.</para>
+				</section>
+				<section id="Execute_Headless_.28Data.29">
+					<title>Execute Headless (Data)</title>
+					<para>Launches the model with an observer that collects data into the AMF adata model representation.</para>
+				</section>
+			</section>
+			<section id="Executing_a_Model_.28Java_.2F_3D.29">
+				<title>Executing a Model (Java / 3D)</title>
+				<para>You can execute any Escape model directly from its Java file by right-clicking on it. This is used for models that have been written directly in Java, or that you have created or that have been automatically generated, such as the 3D versions of AMF models. In order for the model to launch correctly, it must have as a superclass the Escape "Scape" class. In the following screenshot, we've launched a 3D version of the Epidemic model. The 3D models are automatically generated for all .metaabm models.</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/execution/Epidemic3D.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+			</section>
+			<section id="Controlling_Model_Execution">
+				<title>Controlling Model Execution</title>
+				<para>Once a model has been launched, the toolbar buttons allow you to control model execution.</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/execution/EpidemicModelControls.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+				<para>From right to left, you can start, restart, pause, step, stop and close a model. You can even run multiple models and control them independently. You can also move views around, close them and so on as with any other Eclipse views. Here we're running two separate models for comparison.</para>
+				<para>
+					<mediaobject>
+						<imageobject>
+							<imagedata fileref="images/execution/EpidemicModelComparison.png" scale="50"/>
+						</imageobject>
+					</mediaobject>
+				</para>
+				<section id="The_Active_Model">
+					<title>The Active Model</title>
+					<para>An important concept in the execution workbench is the "active model". The active model is the model that is controlled by the toolbar buttons. As discussed, the Escape environment supports more than one running model at any given time. The active model is the current "focused" or front-most model, there can be only one active model at any given time and whenever any models are running one of them will be active. To make a model become the active model, you simply select a view of that model or select the model in the model manager (see below). When a model is closed, another model is automatically activated.</para>
+				</section>
+			</section>
+			<section id="Views_2">
+				<title>Views</title>
+				<para>There are many views specific to the Agent Execution environment that will enable you to explore and control running models.</para>
+				<section id="Properties_2">
+					<title>Properties</title>
+					<para>If you want to find out more about an agent, show the properties view, and click on agent in the 2D view or any other views that support agent selection such as the tree view.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/execution/EpidemicModelAgentProperties.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>You can experiment with different parameters (settings) for models by then clicking on the model in the Model Manager or by selecting a general mode area such as the gray area enclosing the 2D view.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/execution/EpidemicModelProperties.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+				<section id="Agent_Navigator">
+					<title>Agent Navigator</title>
+					<para>The 
+						<emphasis role="bold">Agent Navigator</emphasis> allows you to select agents from a tree view. The agent selection is coordinated across views so that for example when you select an agent in the navigator it is also selected in the 2D view. In the following screenshot you can see an agent selected in both views as well as the properties editor.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/execution/AgentNavigator.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+				<section id="Model_Manager">
+					<title>Model Manager</title>
+					<para>The 
+						<emphasis role="bold">'Model Manager</emphasis>' allows you to examine and control the status of all running models. In the following screenshot, we've launched four separate models so that we can compare the typical model state at different periods.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/execution/ModelManager.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>The manager shows that two of the models are running and two are paused. By opening the model node, we can see the views that are currently being displayed. Note that we mean something different by "Views" in this context. Here "Views" are any thing that is monitoring the state of a running model. A view may not have a graphical component at all.</para>
+					<para>You can make any model the current active model by clicking on its node in this view.</para>
+					<section id=".22About_this_Model.22">
+						<title>"About this Model"</title>
+						<para>The 
+							<emphasis role="bold">'About this Model</emphasis>' view displays information about a (AMF or Java based) model if it has been provided by the developer. In order to appear in this dialog, create a file named "About[MyModel].html" where "MyModel" is the model's Scape Class Name (not the AMF model file name). The file should be placed in a "res" source folder in the model project directory in a parallel directory path to the root scape's Java class package. For example, an about file for a model defined by the scape "edu.brook.norms.Norms" should be placed at "res/edu/brook/norms/AboutNorms.html". The file should be an html fragment -- that is, without body and head tags -- and can include any valid html tags, including links.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/execution/AboutView.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+			</section>
+			<section id="Visualization">
+				<title>Visualization</title>
+				<para>The Agent Modeling Environment is designed to support many kinds of 2D or 3D visualization. AMP includes the following views for generated models. The Escape API supports a number of additional visualization to support Ascape models that aren't shown here. Look at the example org.ascape.escape.models.examples and org.ascape.escape.models.brook for examples of those.</para>
+				<section id="2D_Views">
+					<title>2D Views</title>
+					<para>The 
+						<emphasis role="bold">Graphic 2D</emphasis> view is the most common view way to work with an Agent Model and is automatically generated and displayed for executing models.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/execution/Epidemic2DView.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>There are a number of view widgets in the upper-right hand corner that you can use to modify the view. You can:</para>
+					<section id="Scaling">
+						<title>Scaling</title>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>Enter or select a specific scale in the combo menu.</para>
+							</listitem>
+							<listitem>
+								<para>Select a button to have the model scale either:</para>
+								<orderedlist inheritnum="ignore" continuation="restarts">
+									<listitem>
+										<para>Freely</para>
+									</listitem>
+									<listitem>
+										<para>Within the bounds of the view</para>
+									</listitem>
+									<listitem>
+										<para>Within the vertical bounds of the view</para>
+									</listitem>
+									<listitem>
+										<para>Within the horizontal bounds of the view</para>
+									</listitem>
+								</orderedlist>
+							</listitem>
+							<listitem>
+								<para>Zoom In</para>
+							</listitem>
+							<listitem>
+								<para>Zoom Out</para>
+							</listitem>
+						</orderedlist>
+					</section>
+				</section>
+				<section id="Charts">
+					<title>Charts</title>
+					<para>A 
+						<emphasis role="bold">Chart</emphasis> view is automatically created and displayed for executing models. It can display aggregate values for any of the agent attributes you have set the "gather data" value to true for. Charts can be easily modified. While the built-in view is not meant to be the sole tool for Escape model data analysis, it provides an easy to use and powerful way to explore models interactively. The Chart view widgets allow you to modify the chart with the click of a button.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/execution/EpidemicChartOptions.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<section id="Chart_Type">
+						<title>Chart Type</title>
+						<para>Several chart types are supported: The line, area, bar and pie chart. Click on one of the icons to select that type.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/execution/LineChart.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/execution/AreaChart.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/execution/BarChart.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/execution/PieChart.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Chart_Legend">
+						<title>Chart Legend</title>
+						<para>Turn the legend on and off by selecting the "T" icon.</para>
+					</section>
+					<section id="Chart_Data">
+						<title>Chart Data</title>
+						<para>To select the statistics to display, show the 
+							<emphasis role="bold">Chart Customizer</emphasis> view. When the customizer has been selected, select a chart to customize. The customizer presents the possible choices in a 2D format. On one axis are the attributes that have data being collected, and on the other are the measurements collected on those axes, i.e. Count, Minimum, Maximum, Variance, Standard Deviation, Sum and Average. To clear all selections, click the Gray "X" button.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/execution/EpidemicChartCustomize.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>There are a number of other things to play around with, such as zooming the agent view or selecting other chart series to display using the Chart Customizer, so just explore. You can always close an active model by clicking on the close toolbar button. Or if you can't access the models controls for some reason, you can open the progress view and close projects form there.</para>
+					</section>
+				</section>
+			</section>
+			<section id="Executing_Internal_Targets">
+				<title>Executing Internal Targets</title>
+			</section>
+		</section>
+	</chapter>
+	<chapter id="Tutorials">
+		<title>Tutorials</title>
+		<section id="Designing_a_Model">
+			<title>Designing a Model</title>
+			<para>In this tutorial, we'll walk through the creation of a complete model. While the tutorial seems lengthy, that's because we've tried to be thorough in describing each step. As we demonstrate in an online video, the actual model can be created in just a couple of minutes.</para>
+			<section id="Model_Goals">
+				<title>Model Goals</title>
+				<para>Before beginning a modeling project it is important to have a clear idea of what is being modeled and how it should be modeled. We need to know a bit about where we are going before we start. For our target, we'll use a model described in a paper written by Railsback, Lytien and Grimm. They describe "Stupid Model", a model that could be used to provide a common standard to demonstrated features of different Agent-Based Modeling platforms. See 
+					<ulink url="http://condor.depaul.edu/~slytinen/abm/StupidModelFormulation.pdf">http://condor.depaul.edu/~slytinen/abm/StupidModelFormulation.pdf</ulink> for the complete specification. Here are the key specifications for the basic model.
+				</para>
+				<orderedlist inheritnum="ignore" continuation="restarts">
+					<listitem>
+						<para>The space is a two-dimensional grid of dimensions 100 x 100. The space is toroidal, meaning that if bugs move off one edge of the grid they appear on the opposite edge.</para>
+					</listitem>
+					<listitem>
+						<para>100 bug agents are created. They have one behavior: moving to a randomly chosen grid location within +/- 4 cells of their current location, in both the X and Y directions. If there already is a bug at the location (including the moving bug itself, bugs are not allowed to stay at their current location unless none of the neighborhood cells are vacant), then another new location is chosen. This action is executed once per time step.</para>
+					</listitem>
+					<listitem>
+						<para>The bugs are displayed on the space. Bugs are drawn as red circles. The display is updated at the end of each time step.</para>
+					</listitem>
+				</orderedlist>
+			</section>
+		</section>
+		<section id="Model_Implementation">
+			<title>Model Implementation</title>
+			<section id="Setup">
+				<title>Setup</title>
+				<section id="Open_Agent_Modeling_Perspective">
+					<title>Open Agent Modeling Perspective</title>
+					<para>A special Agent Modeling 
+						<emphasis role="bold">Perspective</emphasis> can be used to setup your 
+						<emphasis role="bold">Workspace</emphasis> for modeling. Depending on your how you installed the agent modeling tools, you can simply pick the perspective from the choices in the upper-right hand of your workbench:
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial0Perspective.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>Or, if you can't see it there, you can access it by selecting the menu '''Open Perspective &gt; Other... and then selecting the Agent Modeling perspective from the provided options:</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial0Perspective2.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+				<section id="Create_Project">
+					<title>Create Project</title>
+					<para>Before doing anything else, we need a project -- a folder to organize our models within. Right-click in the Package Explorer and select 
+						<emphasis role="bold">New &gt; Agent Modeling Escape Project</emphasis>.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial1.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+				<section id="Name_project">
+					<title>Name project</title>
+					<para>We'll get a dialog allowing us to name the project. Let's call it something simple.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial2.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+				<section id="Create_Model">
+					<title>Create Model</title>
+					<para>We'll need a model as well. This is the container for all of the the agents and behaviors we'll be defining. Right-click on the project folder and choose 
+						<emphasis role="bold">New &gt; Agent Model</emphasis>.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial3CreateModel.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>You'll see a model creation wizard from which you can name the model. Just give it the name "StupidModel.metaabm".</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial4CreateModel.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>Click 
+						<emphasis role="bold">Next</emphasis> to see some other options. We don't need to change any of this:
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial5CreatePage2.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>So just click the 
+						<emphasis role="bold">Finish</emphasis> button and we're ready to move on with the tutorial.
+					</para>
+				</section>
+			</section>
+			<section id="Structure_3">
+				<title>Structure</title>
+				<section id="Bug_Agent">
+					<title>Bug Agent</title>
+					<section id="Create_New_Agent">
+						<title>Create New Agent</title>
+						<para>Our first step is to create an agent. The root contexts and a number of neccessary model components were already created automatically. So right-click on the root "StupidModel1" context and select 
+							<emphasis role="bold">Create Member &gt; Agent</emphasis>.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial6Createagent.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Name_Agent">
+						<title>Name Agent</title>
+						<para>Let's call it "Bug". In the lower left-hand corner you should see the 
+							<emphasis role="bold">Properties</emphasis> View. This is where you'll edit model values when working with the tree editor. The properties view -- as with any other view--- can be moved anywhere within the workbench and if you can't find it -- or any other views -- you can always lcoate it through 
+							<emphasis role="bold">Window &gt; Show View &gt; Other</emphasis>. Find the "Label" property and type our new name into it. You'll see that all of the related name properites are also updated.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial6NameBug.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="The_Create_Agent_Action">
+						<title>The Create Agent Action</title>
+						<para>While we've been making these changes, the modeling framework has also been doing some work behind the scenes. For example, it has created an attribute and a rule to create the agents. Open the Actions node and the Attributes node to see these changes. If we look at the attributes for the model, we can see that an attribute specifying the number of agents has been created called "Bug Count". Select it, then enter "100" as the default value. The default value is the value the model will use if no value is specified anywhere else (like in the parameter launcher).</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial10AgentCount.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>You might want to take a look at the Create Bugs rule, but there isn't anything we need to change there.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial11BuildAgents.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+				<section id="Grid_Space">
+					<title>Grid Space</title>
+					<section id="Create_Grid">
+						<title>Create Grid</title>
+						<para>Next, we'll create a grid for the Bugs to move around upon. Right-click on the StupidModel1 context and choose 
+							<emphasis role="bold">New &gt; Grid</emphasis>.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial7CreateGrid.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Set_Grid_Parameters">
+						<title>Set Grid Parameters</title>
+						<para>Now, looking at the properties for the Grid we've just created, we can see that there are a number of properties to set. We want to make a number of changes.</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>Set the space's "Border Rule" property to be "Periodic" -- the edges wrap around from one ege to the other.</para>
+							</listitem>
+							<listitem>
+								<para>Set the "Neighborhood" property to be "Moore" -- that's how we are going to interpret the statement "in the X and Y directions".</para>
+							</listitem>
+							<listitem>
+								<para>Set the dimensionality to "2". (You might need to enlarge the Property view or use the scroll bar to see the Dimensionality property.)</para>
+							</listitem>
+						</orderedlist>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial8GridParameters.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Again, the framework has taken care of some things for us automatically. If we now open the Grid node, we can see that "Width" and "Height" attributes have been created based on the dimensionality we've just defined. We'll set each of them to "100", so that we end up with a 100 x 100 grid. (Which is pretty large for a model of this kind, but we want to go with the basic specification.)</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial9GridDims.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="The_Build_Grid_Action">
+						<title>The Build Grid Action</title>
+						<para>The Agent Modeling Framework has also created a Build Gird Action for us. If you navigate to the StupidModel1 context Actions node again, you can see the Action. If you click on it you should see the following properties set:</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial14BuildGridParams.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>If you click on the 
+							<emphasis role="bold">...</emphasis> button next to the "Agents" property you'll see see the Bug, which is the agent that will be moving around upon the grid.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial13BuildGridAgents.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+			</section>
+			<section id="Actions_4">
+				<title>Actions</title>
+				<section id="Create_Initialize_Rule">
+					<title>Create Initialize Rule</title>
+					<para>Now we can make these bugs do something. Let's create our first rule. In this case we're going to create a special Initialize Action that executes once when the model is first created for each agent. All Actions begin from the agent (or style) Actions list and there are only a few Actions that can serve as roots. See the Design section of this guide for much more on that. Open the Bug node by clicking the triangle icon, right-click on the Actions node and select the '''Create Member &gt; Initialize Action.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial15CreateInitialize.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<section id="Create_Select_Action">
+						<title>Create Select Action</title>
+						<para>Next, right click on the new Initialize node and choose 
+							<emphasis role="bold">Create Member &gt; Select</emphasis> to create a Select target.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial16CreateSelect.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Selects are the central building blocks of model actions and define the basis for Query and Logic Actions that can be modified and used in subsequent targets. Targets are actions that "follow from" other actions. With this Select we are going to be searching for places for the Bug to move to at the very start of the model run. Here we need to specify the space we will be looking for cells within, so we set the Space property to "Grid 2D". Normally, we'd specify an agent as well, but as the Grid 2D cells don't have any attributes, we don't need to define them explicitly. So we just need to make sure that the Agent property is null (blank).</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial165Select2.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Create_Query_Action">
+						<title>Create Query Action</title>
+						<para>Next, we create a Query Action. A query is really a query term; we're specifying some aspect of the search that we're interested in.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial17CreateQuery.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>In this case we want a special kind of query, a query within space for any agents that are available; that is unoccupied by another agent. So we select "Spatial: Available" form the drop down list of query functions.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial18QueryFunction.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+					<section id="Create_Move_Action">
+						<title>Create Move Action</title>
+						<para>Finally, as the last part of the initial action specification, we'll create a Move Action using 
+							<emphasis role="bold">Create Member &gt; Move</emphasis>. (Not shown.) The properties should be correct, but check to make sure that the selection property is "Initialize" (the root), and the destination property is "Bug" (the Select Action we've defined above). Like this:
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial19Move.png" scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+				<section id="Run_Initial_Model">
+					<title>Run Initial Model</title>
+					<para>That's all we have to do to create our first working model! Now, go to the 
+						<emphasis role="bold">Package Explorer</emphasis> and select the StupidModel1.metaabm file. Right-click on it and select 
+						<emphasis role="bold">Execute</emphasis>. Or click on the first "m" button in the toolbar. (Again, we've simplified the toolbar for this tutorial, so you may have more buttons appearing then we're showing here.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial20ExecuteModel.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>A new perspective for "Agent Execution" will automatically open up and you can see that the agents have placed themselves in the grid. They don't do anything else yet.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial21Execute2.png " scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+			</section>
+			<section id="Styles_2">
+				<title>Styles</title>
+				<section id="Create_Bug_Style">
+					<title>Create Bug Style</title>
+					<section id="Create_Style">
+						<title>Create Style</title>
+						<para>While Escape assigns a default color of black for the agents, we'll want something more interesting -- so let's make the Bugs red. Agent visualization is accomplished using the same mechanism as ordinary agent rules. So first, let's create a new Style. Right click on the "Styles" node and select '''</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial22CreateStyle.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>By default the style will be called BugStyle2D. Open the Style to the Actions node and create a rule.</para>
+					</section>
+					<section id="Create_Style_Rule">
+						<title>Create Style Rule</title>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial23CreateStyleRule.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Now we need to create a series of evaluations. An Evaluation is like a Query in that it performs some kind of function in the broadest sense, but unlike a Query, it does not affect whether target (downstream) Acts are performed. For Styles we have a set of Graphic functions that we will chain together to draw a figure. First we create the Evaluation.</para>
+					</section>
+					<section id="Create_Evaluations">
+						<title>Create Evaluations</title>
+						<para>We make the first Evaluation define a Color of "Red". Right click on the new Rule, and select 
+							<emphasis role="bold">New &gt; Command &gt; Evaluate</emphasis> (not shown) to create an Evaluation. Then in the function property, select "Graphic: Color Red".
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial24EvaluationFunction.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>We'll create two more evaluation targets. Right-click on the "Color Red" evaluation and create an Evaluation. Pick the "Graphic: Draw Oval" fill. For the last part of our style, we need to actually draw the figure. To do this we create a last Evaluation target for "Draw Oval" and give it the "Graphic: Fill Shape" function. By now it should be clear how to do this. "Fill" or "Outline" will always come last in a chain of graphic evaluations, but otherwise the order shouldn't matter. See the Demographic Prisoner's Dilemma model for an example of how this can be used to selectively pick Colors and or Shapes. You should end up with something like this:</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial25FinishStyle.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+					</section>
+				</section>
+			</section>
+			<section id="Actions_2_Movement_Rule">
+				<title>Actions 2 Movement Rule</title>
+				<para>To make our agents move randomly every iteration, we will create a Rule. (For those familiar with Repast or other scheduling oriented AM platforms, a rule is just a schedule that gets activated each and every period for all agents.) At this point in the tutorial, we'll show screenshots only for aspects of the modeling process that haven't already been covered.</para>
+				<section id="Create_Select_and_Query_Actions">
+					<section>
+						<title>Create Select and Query Actions</title>
+						<para>The first part of the Bug Rule is exactly the same as the Initialize rule. Create a Selection Action. As before, we'll make the Select statement "Agent" property blank, as we want to move to a cell. As before, we want to make sure the Cell is free before we try to move in, so we'll select a "Spatial: Available" Query function.(By the way, to make scrolling through the list easier, you can type the first letters of the selection, in this case "SP".)</para>
+						<para>But now, instead of moving 
+							<emphasis role="italic">anywhere</emphasis> we want to move nearby. So now, we create a 
+							<emphasis role="italic">parallel</emphasis> or "sibling" Query from the same Select root. Because this new Query Action is a child of the Select Action and not the "Space Available" Query we've just created, we'll right-click on the 
+							<emphasis role="italic">Select</emphasis> Action and choose 
+							<emphasis role="bold">Create Target &gt; Select &gt; Query</emphasis>. Like so:
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial26CreateQuery2.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Often, we would pick the "Spatial: Neighbor" function to take a random walk, but according to the specification, we actually want to move into some random Cell within distance four (4). So we will pick "Spatial: Within" from the list of functions.</para>
+					</section>
+					<section id="Model_Error_Handling">
+						<title>Model Error Handling</title>
+						<para>Instead of specifying the actual distance now, let's see how the Agent Modeling Framework error checking capabilities can help us in model development. Save the model by selecting 
+							<emphasis role="bold">File &gt; Save</emphasis> from the application menu. Notice that a red marker appears next to the StupidModel1.metaabm file. If you reveal the 
+							<emphasis role="bold">Problems View</emphasis> you'll see a list of current errors and warnings and if you open the errors node in that list, you'll see an item reporting that the input has no value. If you double-click on that item, you'll be taken to the input for the Within query and you'll be able to edit it.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial27NoValue.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>In addition to error markers, metaABM provides warnings designed to help you avoid common design mistakes. For example, a warning will be issued if you attempt to move an agent from its selection to the same selection; this is not strictly speaking an error, but it doesn't make much sense. You'll also recieve warning for default values that have not been specified. You might notice that the Demographic Prisonner's Dilemma model has warning markers, this is because we were happy with the '0' default values for the attributes and didn't provide any. (By the way, you might also notice a number of Java warnings. By default the Eclipse IDE is very conservative when it comes to warnings, and expects the usage of language constructs that we choose not to use. A full discussion of all of this is beyond the scope of the tutorial, but see the Eclipse documentation on problem views for more ideas about how to customize these views.)</para>
+						<para>To fix this error we just need to assign a value for search distance. We 
+							<emphasis role="bold">could</emphasis> simply create a literal for the Spatial: Within Query but that isn't really good practice. (Originally the Agent Modeling Framework didn't even support Literal values, but we added them for convenience.) Now, we will create our first Attribute. In this case, we want the Attribute to belong to the Stupid Model as it will be the same value for all Agents for now. So right-click on the Stupid Model context Attributes node and create a new one.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial28CreateAttribute.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Name the Attribute -- "Bug Vision" seems descriptive -- give it a type of Integer, and assign it a default value of 4. This will allow most ABM platforms to provide the ability to change vision at runtime or through batch definitions, something we couldn't do if we had used a literal value.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial29AttributeValues.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Finally, we assign the Vision attribute to the "Input" node in our Spatial: Within Query.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial30AttributeInput.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Now, we need to combine the requirement that the cell be available with the requirement that it be within 4 cell's distance. To accomplish this, we'll add an Intersection Action. The Logical Actions, including "Intersection", "Union" and "None" define how Query Actions work together. So create an Intersection Actions as a target of the Spatial Available Query. (Not the Within Query).</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial31Intersect.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>The Intersection Action needs to be a target of 
+							<emphasis role="italic">both</emphasis> the Available and Within targets. To accomplish this, drag the Intersection Action over the Within Query. It's a bit hard to see this in a static image, but you simply need to click on the Intersection Action, move it so that it is over the Within target, and release the mouse.
+						</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial32IntersectAdd.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>Finally, add a Move target to the Intersection.</para>
+						<para>
+							<mediaobject>
+								<imageobject>
+									<imagedata fileref="images/edit_tutorial/SimpleTutorial33Move.png " scale="50"/>
+								</imageobject>
+							</mediaobject>
+						</para>
+						<para>A few notes on the screenshot above. To make things a bit clearer, we've edited the names for the final panel. Also, the Intersection node might not appear in the same place. We've expanded the nodes so that you can see that while the actions are all listed together, they are actually defined as a tree structure internally. You can follow that tree to see all of the actions that might be the result of any of the actions in the list. To help understand the structure at a glance, the labels include an &lt;- indicator showing the immediate sources of each of the nodes. 
+							<emphasis role="italic">Note especially than while the targets for actions often appear immediately following their source actions, this is not always the case.</emphasis>
+						</para>
+					</section>
+				</section>
+				<section id="Run_Final_Model">
+					<title>Run Final Model</title>
+					<para>Now, we can select the model in the 
+						<emphasis role="bold">Package Navigator</emphasis> again, and run the model. It doesn't look much different in a snapshot, but those agents should now be moving around. We have built a complete Ascape model from our model.
+					</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/edit_tutorial/SimpleTutorial34RunFinal.png " scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>We hope this tutorial has enabled you to get up and running and given you some familiarity with the basic Agent Modeling Framework approach. The example models include the other "stupid models" from the paper, as well as a number of other interesting models.</para>
+				</section>
+			</section>
+		</section>
+	</chapter>
+	<chapter id="Programer_Guide">
+		<title>Programer Guide</title>
+		<section id="Overview_6">
+			<title>Overview</title>
+			<para>Escape is a full-featured Agent-Based Modeling (ABM) integrated development environment (IDE) with a Java based API and end user modeling tools. It's based on Ascape, which has been in use for more than 10 years. The core API is very stable, and that should give users a way to explore the features of AMP without concerns about keeping in synch with the rapidly evolving AXF /AGF API. It allows modelers to code in Java and/or generate models with AMF and then execute those models within the same development environment.</para>
+			<para>
+				<mediaobject>
+					<imageobject>
+						<imagedata fileref="images/EscapeExecutionScreenshot.png" scale="50"/>
+					</imageobject>
+				</mediaobject>
+			</para>
+			<para>A primary purpose of the Escape project -- apart from the obvious goal of providing a nice Eclipse hosted ABM toolkit -- is to provide an exemplar to demonstrate how any arbitrary agent modeling framework can be integrated within the AMP environment. A cool aspect of this is that AMP has no dependencies on Escape, but also that the underlying ABM modeling framework for Escape has no dependencies on AMP -- instead Escape simply provides the runtime glue between AMP and the ABM framework. The underlying ABM framework uses the Ascape API, an API that first began development more than ten years ago and that has not been modified at all in order for it to work within the AMP environment.</para>
+		</section>
+		<section id="Getting_Started_2">
+			<title>Getting Started</title>
+			<section id="Documentation_and_other_Resources">
+				<title>Documentation and other Resources</title>
+				<para>Because it's API is based on Ascape, Escape is one component of AMP that already has extensive documentation. There is complete Javadoc as well as a manual and other web resources. See the 
+					<ulink url="http://ascape.sourceforge.net">Ascape Website</ulink> to locate these resources. There is a 
+					<ulink url="http://ascape.sourceforge.net/docs/TheAscapeManual5.pdf">full manual</ulink> for Ascape available on that site. Or, you can install the Ascape Manual into the eclipse help system by adding the following update site and selecting the "Documentations and Source Code" feature.
+				</para>
+				<para>
+					<ulink url="http://ascape.sourceforge.net/eclipse">http://ascape.sourceforge.net/eclipse</ulink>
+				</para>
+			</section>
+			<section id="Installation">
+				<title>Installation</title>
+				<para>Escape is 
+					<ulink url="http://eclipse.org/amp/installing/">installed</ulink> by default with the other model components. If you want to do 3D (really 2 1/2) visualizations, you will want AGF3D and the LWJGL dependency. You can build from source but in that case you'l need to launch a self-hosted runtime, so it's best to simply install from the update site if you're not actually doing AMP development.
+				</para>
+			</section>
+		</section>
+		<section id="Developing_Models">
+			<title>Developing Models</title>
+			<para>The easiest way for Java developers to get started doing agent-based modeling in Eclipse is to begin to write programs using it. To develop new models, you can:</para>
+			<orderedlist inheritnum="ignore" continuation="restarts">
+				<listitem>
+					<para>Create a new Escape project. The Escape projects are actually configured for AMF code generation so there are dependencies and builders in there that you don't need; you can remove all of the escape builders and any of the kitchen sink items. The "Create an Escape Java Model" cheat sheet will walk you through the process of creating a new Java based project and model.</para>
+				</listitem>
+				<listitem>
+					<para>Or for more experienced Eclipse users, you can simply to just create a new Plugin Project and add the necessary dependencies there. Have a look at the example escape project to see what you need. Note that you will likely need more dependencies then you need to simply build -- this is because the class loader uses the classes from the project path and so runtime classes have to be there as well. We may simply package an Eclipse runtime convenience plugin to gather these dependencies up a bit.</para>
+				</listitem>
+			</orderedlist>
+			<para>Then just create new Java classes for your root model scape and agents just as you would for an Ascape project.</para>
+		</section>
+		<section id="More_Information">
+			<title>More Information</title>
+			<section id="Integrating_Java_and_AMF_Models">
+				<title>Integrating Java and AMF Models</title>
+				<para>If you're like many Java developers, you might find point-and-click interfaces a bit lame. Personally, I've changed my tune in this, and I now define all of my ABM models from the editor, saving Java for truly specialized tasks. But even without generation of agent behavior, Acore can be a really valuable tool, as the GIS example shows. The way to look at metaABM is as a way to compose your overall model and automate the tedious parts. Apart from Java generated code, the AMF meta-model maintains a number of very useful artifacts. For example, the Repast Simphony target maintains model.score and all of the model.rs component. Generally, AMF should save time and hassle while making your models far more transparent even if you never use the Actions component to define agent behavior.</para>
+				<section id="Method_Action">
+					<title>Method Action</title>
+					<para>As explained in the action section, you can simply create a "Method" act with hand-written Java code. This option is nice because all code is contained within the AMF file. But it can be difficult to maintain large blocks of Java code as you aren't using a Java editor to edit the Java code itself. One way to get around this is to create your code in the generated Java method and then copy it into the Method action. Note one imporant issue here -- you'll generally have to fully qualify your Java references as you won't be able to change the imports statements directly. </para>
+				</section>
+				<section id="Protected_Code_Regions">
+					<title>Protected Code Regions</title>
+					<para>You can mix and match Action behavior with Java and generated code with POJOs. One way to do this is through using protected regions. Select the agent you want to create protected methods for and then select "Generate Protected" from the "Mode" property. Now, create actions just as you have before, or use your existing ones. On code generation, open up the relevant java file and examine the methods that have been created. </para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/pojo/ProgrammingPojoGenerateProps.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+					<para>You can put whatever you want within the PROTECTED REGION comments and those changes will be preserved when the model is regenerated. You can create a schedule, rule or watcher, maintain custom code for the actual implementations, and still have the model adapt to changes in the underlying data structure -- if for example you want to import a modified shape file.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/pojo/ProgrammingPojoGenerateCode.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+				<section id="Implement_Sub-classes">
+					<title>Implement Sub-classes</title>
+					<para>Another approach which can be more robust is to generate the basic model stubs (like an abstract base class except that it isn't abstract) and then override your model with implementations. AMF provides support for generic skeletons and interfaces.</para>
+					<para>
+						<mediaobject>
+							<imageobject>
+								<imagedata fileref="images/pojo/ProgrammingPojoGenerate.png" scale="50"/>
+							</imageobject>
+						</mediaobject>
+					</para>
+				</section>
+			</section>
+			<section id="Converting_Existing_Ascape_models">
+				<title>Converting Existing Ascape models</title>
+				<para>There are only a few changes should have to make to existing Ascape models or to use existing Ascape documentation to develop Escape models.</para>
+				<section id="Model">
+					<title>Model</title>
+					<para>The core model is completely API compatible. No changes!</para>
+				</section>
+				<section id="View">
+					<title>View</title>
+					<para>Because Escape uses SWT and Ascape uses Swing, there are a few unavoidable incompatibilities. Most of these we avoid by using higher level APIs but here are the key changes that you're likely to have to make:</para>
+					<section id="Convert_the_low-level_imports_from_AWT_and_Swing_to_SWT">
+						<title>Convert the low-level imports from AWT and Swing to SWT</title>
+						<para>The simplest way to accomplish this is to remove all of the imports and then organize imports. For example:</para>
+						<literallayout format="linespecific" class="normal">java.awt.Color =&gt; org.eclipse.swt.graphics.Color
+java.awt.Graphics =&gt; org.eclipse.draw2d.Graphics
+</literallayout>
+						<para>Then just do a global find for all of the imports and replace them with nothing. This is a great place for a regexp. Try:</para>
+						<literallayout format="linespecific" class="normal">find: import java\.awt\.(.*);
+replace: [nothing]
+</literallayout>
+						<para>You don't have to replace these with the SWT equivalents, just click on the project, right-click and choose "Source:Organize Imports.."
+							By the way, a great way to avoid having to select the right entries in optimize imports and to alert you when you have missed anything is to prevent the awt and swing classes from being used at all. Right-click on project, choose "Build Path:Configure Build Path", go to Libraries tab, open JRE System Library, choose "Access Rules", edit, and then add entries for java/awt/** and javax/swing/**. The code will regenerate and you'll have error markers for all of the stuff that won't work with Escape and Eclipse.</para>
+					</section>
+					<section id="Convert_color_features">
+						<title>Convert color features</title>
+						<para>You can't use AWT colors either so you'll need to replace any colors. AMP provides a convenience classes for Colors called ColorFeature and ColorFeatureConcrete. You can use these or any of the other ways to define SWT colors. For example:</para>
+						<literallayout format="linespecific" class="normal">Color.lightGray =&gt; ColorFeature.LIGHT_GRAY
+new Color(Math.min(1.0f, (float) (redEnergy + orangeEnergy)), (float) orangeEnergy * .8f, (float) blueEnergy) =&gt; 
+    ColorFeatureConcrete.create(Math.min(1.0f, (float) (redEnergy + orangeEnergy)), (float) orangeEnergy * .8f, (float) blueEnergy)
+</literallayout>
+					</section>
+					<section id="Change_agent_color_getters">
+						<title>Change agent color getters</title>
+						<para>If you've defined colors through overriding Agents as in most models, you'll need to change the method signature. You could just do a global replace for this one.</para>
+						<literallayout format="linespecific" class="normal">public Color getColor( =&gt; public Object getPlatformColor(
+</literallayout>
+					</section>
+					<section id="Get_rid_of_image_features">
+						<title>Get rid of image features</title>
+						<para>Escape doesn't support them. In practice they haven't been used a lot. At some point perhaps we'll have nice sprite support instead. :)</para>
+						<literallayout format="linespecific" class="normal">public Image getImage() {**} =&gt; ""
+</literallayout>
+					</section>
+					<section id="Modify_usages_of_DrawFeatures">
+						<title>Modify usages of DrawFeatures</title>
+						<para>If you've created any of your own draw features, you'll need to change them slightly to accommodate the differences between the AWT and SWT / Draw2D APIs. This should be pretty straightforwrd. For example:</para>
+						<literallayout format="linespecific" class="normal">g.setColor(...
+g.fillOval(..
+becomes:
+g.setBackgroundColor(
+g.fillOval(..
+</literallayout>
+						<para>That's about it, though it's probable that we've missed something. Please post a message on the amp newsgroup if you run into any other conversion issues.</para>
+					</section>
+				</section>
+				<section id="Configuration">
+					<title>Configuration</title>
+					<para>Instead of using Ant, Escape has really nice support for parameterizing and testing models. See 
+						<ulink url="/wiki/Experimenting_and_Testing">Experimenting and Testing</ulink> (todo). If you do want to work with ant you will need to install the plugins from the Sourceforge download site. (These have dependencies that I didn't want to bother with going through the Eclipse IP process to get in. If for some reason you think these should be part of core Escape let Miles know and I'll take care of it.) Ant has not been tested for Escape so it's not even clear it will work.
+					</para>
+				</section>
+			</section>
+		</section>
+		<section id="Running_Agent_Models">
+			<title>Running Agent Models</title>
+			<section id="Exploring_Example_ABM_Models">
+				<title>Exploring Example ABM Models</title>
+				<para>The first thing most people will want to do in AMP is to play with the example models. You can explore AMF models as well as some really interesting classic ABM models.</para>
+				<section id="Downloading_Models">
+					<title>Downloading Models</title>
+					<para>To obtain the models, simply launch the cheat sheet. Go to the 
+						<emphasis role="bold">Help &gt; Cheat Sheets...</emphasis> menu and choose "Load Sample Projects".
+					</para>
+					<para>Or you can get them yourself from the following locations:</para>
+					<section id="AMF_Models">
+						<title>AMF Models</title>
+						<literallayout format="linespecific" class="normal">org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.escape
+</literallayout>
+						<para>To understand the capabilities of AMF, you might also want to try out running the same models automatically generated for Ascape or Repast. These are located at dev.eclipse.org in cvsroot/modeling:</para>
+						<literallayout format="linespecific" class="normal">org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.ascape
+org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.repast
+</literallayout>
+					</section>
+					<section id="Escape_.2F_Ascape_Java_Models">
+						<title>Escape / Ascape Java Models</title>
+						<para>These are SVN projects in the sourceforge SVN. For help, see 
+							<ulink url="/wiki/http://www.eclipse.org/subversive/documentation/teamSupport/find_check_wiz.php_this_page">http://www.eclipse.org/subversive/documentation/teamSupport/find_check_wiz.php this page</ulink>.
+						</para>
+						<literallayout format="linespecific" class="normal">http://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.escape.models.brook
+http://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.escape.models.examples
+</literallayout>
+					</section>
+				</section>
+				<section id="Generating_Models">
+					<title>Generating Models</title>
+					<para>There are a number of models developed with AMF that can automatically generate example models to run in Escape. There are two ways to run the example models:</para>
+					<section id="Creating_a_New_Escape_Project">
+						<title>Creating a New Escape Project</title>
+						<para>The best option is to simply create a new Escape project and drag the models into it!</para>
+						<orderedlist inheritnum="ignore" continuation="restarts">
+							<listitem>
+								<para>If you're not already there, open the Agent Modeling Perspective. Select Window &gt; Open Perspective &gt; Other.. and then Agent Modeling. (Or you can choose Window &gt; Reset Perspective and the Agent Modeling perspective should appear in the Open Perspective list itself.)</para>
+							</listitem>
+							<listitem>
+								<para>Next, let's create the project where we'll place our model. Select File &gt; New &gt; Escape AMF Project. Give it a name like "escape.tutorial", then click Finish.</para>
+							</listitem>
+							<listitem>
+								<para>Finally grab the Epidemic.metaabm model at 
+									<ulink url="http://download.eclipse.org/amp/models/Epidemic.metaabm">http://download.eclipse.org/amp/models/Epidemic.metaabm</ulink> and drag it into the project. (Depending on your browser the file may load as text directly into your browser, in which case just right-click on the link and save it to a file.)
+								</para>
+							</listitem>
+						</orderedlist>
+					</section>
+				</section>
+			</section>
+			<section id="Tutorial">
+				<title>Tutorial</title>
+				<para>We've developer have a complete cheat sheet supporting this tutorial. Simply go to 
+					<emphasis role="bold">Help &gt; Cheat Sheets...</emphasis> and then select "Run an Example Model" from within the "Agent Modeling" category.
+				</para>
+				<section id="Next_Steps">
+					<title>Next Steps</title>
+					<para>To understand the capabilities of AMF, you might also want to try out running the same models automatically generated for Ascape or Repast.</para>
+					<literallayout format="linespecific" class="normal">org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.ascape
+org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.repast
+</literallayout>
+				</section>
+			</section>
+			<section id="Classic_Java_ABM_Models">
+				<title>Classic Java ABM Models</title>
+				<para>Many models have been created using Ascape over the years, including all of the classic models created at Brookings and some other cool models such as Craig Reynold's Boids and a pretty cool little traffic model, and they've all been converted to run in Escape. They're in Java but you can execute and explore them in exactly the same way as the Epidemic model above. All of the Ascape example models have been converted (a straightforward process) from their intial Ascape incarnations. For licensing reasons (they're BSD, not EPL) we can't host them directly on the Eclipse site.  You can get the projects in two ways:</para>
+				<para>Once you've downloaded the projects, open up the src folder and navigate to the Java files for the actual models. For example, to run Conway's Life, you'll want src/edu.brook.life.ConwayLife. Right-click on the Java file and select "Execute". There are many models to explore! (It's not always obvious which Java files are for models, so you may have to poke around a bit. We need to put together a catalog here. Another nice opportunity for user contributions.)</para>
+			</section>
+		</section>
+	</chapter>
+	<chapter id="Resources">
+		<title>Resources</title>
+		<section id="Obtaining_Example_Models">
+			<title>Obtaining Example Models</title>
+			<para>There is a cheat-sheet available for obtaining the example models. If you would rather obtain them yourself, here is the CVS information:</para>
+			<section id="Import_from_CVS">
+				<section>
+					<title>Import from CVS</title>
+					<itemizedlist>
+						<listitem>
+							<para>Import the CVS projects from the AMP project repository. For help, see 
+								<ulink url="http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.user/reference/ref-40a.htm">this page</ulink>. For repository details, see 
+								<ulink url="http://eclipse.org/amp/developers/repositoryDetails.php">http://eclipse.org/amp/developers/repositoryDetails.php</ulink>. These are the example projects:
+							</para>
+						</listitem>
+					</itemizedlist>
+					<literallayout format="linespecific" class="normal">org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.ascape 
+org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.escape 
+org.eclipse.amp/org.eclipse.amp.amf/examples/org.eclipse.amp.amf.examples.repast 
+</literallayout>
+					<itemizedlist>
+						<listitem>
+							<para>Right-click on the models to execute them.</para>
+						</listitem>
+						<listitem>
+							<para>Play around with the model attribute settings and behavior (Acts).</para>
+						</listitem>
+					</itemizedlist>
+				</section>
+			</section>
+		</section>
+		<section id="Websites">
+			<title>Websites</title>
+			<para>
+				<ulink url="http://www.eclipse.org/amp">Eclipse Agent Modeling Project (Incubation)</ulink>
+			</para>
+			<para>
+				<ulink url="http://ascape.sourceforge.net">Ascape</ulink>
+			</para>
+			<para>
+				<ulink url="http://metascapeabm.com">Metascape, LLC</ulink>
+			</para>
+		</section>
+		<section id="Papers">
+			<title>Papers</title>
+			<para>
+				<ulink url="http://www.pnas.org/content/99/suppl.3/7304.full">Ascape</ulink>
+
+				<ulink url="http://www.pnas.org/content/99/suppl.3/7280.full">Agent-Based Modeling</ulink>
+
+				<ulink url="http://jasss.soc.surrey.ac.uk/11/4/12.html">Why Model?</ulink>
+			</para>
+		</section>
+	</chapter>
+	<chapter id="Support">
+		<title>Support</title>
+		<section id="Issues">
+			<title>Issues</title>
+			<para>Eclipse and the AMP project have a mandate for open communication. Please note that unless you are a customer of an AMP project contributor we will not respond to direct requests for support. We 
+				<emphasis role="italic">will</emphasis> make every effort to support your use of AMP in the following ways:
+			</para>
+			<section id="General_Support.2C_Questions_and_Discussion">
+				<title>General Support, Questions and Discussion</title>
+				<para>The 
+					<ulink url="http://www.eclipse.org/forums/index.php?t=thread&amp;frm_id=17&amp;S=f4fa6cb31327772a3b626dc409db409b">Agent Modeling Platform Newsgroup</ulink> is the place to discuss or get support for any of the Eclipse AMP tools. 
+				</para>
+			</section>
+			<section id="View_Existing_Bugs_and_Feature_Requests">
+				<title>View Existing Bugs and Feature Requests</title>
+				<para>If you have a problem or idea for improvement, there's a good chance that its already been discovered. To avoid duplication, please check the current bugs before filing a new bug report or feature request.</para>
+				<para>
+					<ulink url="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;product=AMP&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=">Search Existing Bugs</ulink>
+				</para>
+			</section>
+			<section id="File_a_Bug">
+				<title>File a Bug</title>
+				<para>This may sound obvious, but if something doesn't work as it should, the only way that we're going to find out is if someone reports it. All AMP related bugs or feature requests should use the Eclipse Bugzilla.</para>
+				<para>
+					<ulink url="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AMP&amp;rep_platform=All&amp;op_sys=All">File a Bug or Feature Request</ulink>
+				</para>
+			</section>
+			<section id="Discuss_AMP_Development_and_Project">
+				<title>Discuss AMP Development and Project</title>
+				<para>All discussion about software development, design and project management issues take place on the AMP dev-list. If you're interested in contributing to the AMP project, this is a good place to contact us. 
+					<ulink url="https://dev.eclipse.org/mailman/listinfo/amp-dev">https://dev.eclipse.org/mailman/listinfo/amp-dev</ulink>.
+				</para>
+			</section>
+			<section id="Professional_Support">
+				<title>Professional Support</title>
+				<para>The AMP project developers -- among the most experienced developers of agent models and tools anywhere -- are naturally the best source for Agent Modeling development, support and training. Please feel free to contact the project lead or other project contributors directly to discuss professional support options.</para>
+			</section>
+			<section id="Media_and_Private_Communications">
+				<title>Media and Private Communications</title>
+				<para>For project related but non-public communications such as media enquires or potential project sponsorship, please contact Miles Parker, the Eclipse AMP project lead, at amp_enquiry@metascapeabm.com. (Requests for support and other communications to this address will be ignored.)</para>
+			</section>
+		</section>
+		<section id="Feedback">
+			<title>Feedback</title>
+			<para>If you have ideas, comments or requests for information about the project please contact us at the .</para>
+		</section>
+		<section id="Get_Involved">
+			<title>Get Involved</title>
+			<para>If you find this tool valuable, please be aware that most of its development occurred through volunteer contributions from individuals and companies that have received no direct funding. You can support continual development efforts financially by purchasing related software tools from companies and organizations that help develop it, including funding for developer time in grant proposals. You can support the Eclipse platform in general by becoming a member organization of Eclipse. But the most important thing that you can contribute is your own time and enthusiasm, either through directly contributing to AMP or by promoting its use in blogs and other social media. For more detailed information about contributing to AMP, please see 
+				<ulink url="http://wiki.eclipse.org/AMP/Getting_Involved">our wiki</ulink>.
+			</para>
+		</section>
+	</chapter>
+</book>
\ No newline at end of file
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/convert.xml b/org.eclipse.amp/doc/org.eclipse.amp.doc/convert.xml
index 393e6e3..307414f 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/convert.xml
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/convert.xml
@@ -1,163 +1,163 @@
-<project default="generate-help" name="Generate Docs from Wiki">

-	<property name="dir.eclipse" value="/Developer/eclipse/plugins" />

-	<property name="dir.repos" value="/Volumes/Resources/Developer/repos" />

-	<property name="dir.repos.eclipse" value="${dir.repos}/eclipse" />

-	<property name="dir.repos.ascape" value="${dir.repos}/ascape" />

-	<!--

-		path to wikitext standalone package

-	-->

-

-	<path id="wikitext.classpath">

-		<fileset dir="${dir.eclipse}">

-			<include name="org.eclipse.mylyn.wikitext.*core*.jar" />

-		</fileset>

-	</path>

-

-	<taskdef classpathref="wikitext.classpath"

-		resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties" />

-

-	<target name="generate-help" description="Generate Eclipse help from textile source">

-		<wikitext-to-eclipse-help markupLanguage="MediaWiki"

-			formatOutput="true" prependImagePrefix="image" navigationImages="true"

-			helpPrefix="wiki" overwrite="true">

-			<fileset dir="${basedir}/wiki">

-				<include name="*.mediawiki" />

-			</fileset>

-		</wikitext-to-eclipse-help>

-	</target>

-

-	<property name="vendor" value="Eclipse.org" />

-	<property name="specification.version" value="0.5.0" />

-	<property name="implementation.version" value="0.5.0" />

-

-	<property name="implementation.vendor" value="${vendor}" />

-	<property name="specification.vendor" value="${vendor}" />

-

-	<property name="build.javadoc" value="build" />

-	<property name="dest.javadoc" value="docs/javadoc" />

-

-	<property name="jdk.style" value="1.5" />

-

-

-

-

-	<target name="javadoc">

-

-		<path id="classpath">

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore/bin" />

-		</path>

-

-

-		<path id="srcpath">

-			<pathelement

-				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.chart/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.core/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.ide/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.zest/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.zest.ide/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf3d/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.edit/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.editor/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase/srcgen" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.edit/srcgen" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.editor/srcgen" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.ui/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore.edit/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore.editor/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore/srcgen" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ascape/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.escape/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.extras/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ide/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.repast/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.ide/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.ide.ascape/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.ide.repast/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters.edit/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters.editor/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters.ui/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing.edit/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing.editor/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing.ui/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.axf/plugins/org.eclipse.amp.axf.core/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.axf/plugins/org.eclipse.amp.axf.ide/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.axf/plugins/org.eclipse.amp.axf.views/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.amf.ide/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ascape/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ascape.agf3d/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ascape.chart/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ide/src" />

-			<pathelement

-				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.testing.ide/src" />

-			<pathelement path="../../../plugins/org.eclipse.amp.source/src" />

-

-		</path>

-		<mkdir dir="${build.javadoc}/src" />

-

-		<javadoc packagenames="org.metaabm.*,org.eclipse.amp.*"

-			destdir="${dest.javadoc}" sourcepathref="srcpath" doctitle="Agent Modeling Platform API"

-			access="private" author="true" nodeprecated="false" nodeprecatedlist="false"

-			noindex="false" nonavbar="false" notree="false" source="1.5"

-			splitindex="true" use="true" version="true"

-

-			bottom="Copyright (C) 2007-2009 Metascape, LLC, 2009 Miles Parker, 2006-2007 Argonne National Labs, and Contributors"

-			windowtitle="${ant.project.name} ${specification.version} API"

-

-			classpath="${dir.eclipse}">

-			<!--

-				<link

-				href="jar:file:/Devel/Applications/Eclipse3.3.1.1/plugins/org.eclipse.platform.doc.isv_3.3.1.r331_v20070913.jar!/reference/api""/>

-				<link

-				href="jar:file:/Devel/Applications/Eclipse3.3.1.1/plugins/org.lwjgl.doc_1.1.4/doc.zip!/javadoc/""/>

-			-->

-

-		</javadoc>

-	</target>

+<project default="generate-help" name="Generate Docs from Wiki">
+	<property name="dir.eclipse" value="/Developer/eclipse/plugins" />
+	<property name="dir.repos" value="/Volumes/Resources/Developer/repos" />
+	<property name="dir.repos.eclipse" value="${dir.repos}/eclipse" />
+	<property name="dir.repos.ascape" value="${dir.repos}/ascape" />
+	<!--
+		path to wikitext standalone package
+	-->
+
+	<path id="wikitext.classpath">
+		<fileset dir="${dir.eclipse}">
+			<include name="org.eclipse.mylyn.wikitext.*core*.jar" />
+		</fileset>
+	</path>
+
+	<taskdef classpathref="wikitext.classpath"
+		resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties" />
+
+	<target name="generate-help" description="Generate Eclipse help from textile source">
+		<wikitext-to-eclipse-help markupLanguage="MediaWiki"
+			formatOutput="true" prependImagePrefix="image" navigationImages="true"
+			helpPrefix="wiki" overwrite="true">
+			<fileset dir="${basedir}/wiki">
+				<include name="*.mediawiki" />
+			</fileset>
+		</wikitext-to-eclipse-help>
+	</target>
+
+	<property name="vendor" value="Eclipse.org" />
+	<property name="specification.version" value="0.5.0" />
+	<property name="implementation.version" value="0.5.0" />
+
+	<property name="implementation.vendor" value="${vendor}" />
+	<property name="specification.vendor" value="${vendor}" />
+
+	<property name="build.javadoc" value="build" />
+	<property name="dest.javadoc" value="docs/javadoc" />
+
+	<property name="jdk.style" value="1.5" />
+
+
+
+
+	<target name="javadoc">
+
+		<path id="classpath">
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore/bin" />
+		</path>
+
+
+		<path id="srcpath">
+			<pathelement
+				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.chart/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.core/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.ide/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.zest/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf.zest.ide/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.agf/plugins/org.eclipse.amp.agf3d/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.edit/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.editor/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase/srcgen" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.edit/srcgen" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.editor/srcgen" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.abase.ui/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore.edit/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore.editor/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.acore/srcgen" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ascape/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.escape/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.extras/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ide/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.repast/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.ide/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.ide.ascape/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.ide.repast/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters.edit/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters.editor/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.parameters.ui/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing.edit/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing.editor/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.testing.ui/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.axf/plugins/org.eclipse.amp.axf.core/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.axf/plugins/org.eclipse.amp.axf.ide/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.axf/plugins/org.eclipse.amp.axf.views/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.amf.ide/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ascape/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ascape.agf3d/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ascape.chart/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.ide/src" />
+			<pathelement
+				path="../../../org.eclipse.amp.escape/plugins/org.eclipse.amp.escape.testing.ide/src" />
+			<pathelement path="../../../plugins/org.eclipse.amp.source/src" />
+
+		</path>
+		<mkdir dir="${build.javadoc}/src" />
+
+		<javadoc packagenames="org.metaabm.*,org.eclipse.amp.*"
+			destdir="${dest.javadoc}" sourcepathref="srcpath" doctitle="Agent Modeling Platform API"
+			access="private" author="true" nodeprecated="false" nodeprecatedlist="false"
+			noindex="false" nonavbar="false" notree="false" source="1.5"
+			splitindex="true" use="true" version="true"
+
+			bottom="Copyright (C) 2007-2009 Metascape, LLC, 2009 Miles Parker, 2006-2007 Argonne National Labs, and Contributors"
+			windowtitle="${ant.project.name} ${specification.version} API"
+
+			classpath="${dir.eclipse}">
+			<!--
+				<link
+				href="jar:file:/Devel/Applications/Eclipse3.3.1.1/plugins/org.eclipse.platform.doc.isv_3.3.1.r331_v20070913.jar!/reference/api""/>
+				<link
+				href="jar:file:/Devel/Applications/Eclipse3.3.1.1/plugins/org.lwjgl.doc_1.1.4/doc.zip!/javadoc/""/>
+			-->
+
+		</javadoc>
+	</target>
 </project>
\ No newline at end of file
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/customBuild.xml b/org.eclipse.amp/doc/org.eclipse.amp.doc/customBuild.xml
index f9770f9..bc001bc 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/customBuild.xml
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/customBuild.xml
@@ -1,312 +1,286 @@
-<!--

-	Some of the code below is

-	(c) Chris Aniszczyk <caniszczyk@gmail.com>

-    (c) Lawrence Mandel <lmandel@ca.ibm.com>

-    (c) Peter Friese <peter.friese@itemis.com>

--->

-<project name="org.eclipse.amp.doc" default="build-and-deploy-doc" basedir=".">

-	

-	<!--

-		Global vars

-	-->

-	<property name="document.name" value="amp"/>

-	<property name="document.stylesheet" value="styles/html.xsl"/>

-	<property name="dbpdf.stylesheet" value="styles/dbpdfdb.xsl"/>

-	<property name="document.pdf.stylesheet" value="styles/xmpp.xsl"/>

-

-	<property name="document.eclipse.stylesheet" value="styles/eclipsehelp.xsl"/>

-	<property name="eclipsehelp-css.file" value="styles/book.css" />

-	<property name="html-css.file" value="styles/book.css" />

-	

-	<property name="build.dir" value="build" />

-	<property name="download.dir" value="${java.io.tmpdir}${file.separator}downloads"/>

-	<property name="website.dir" value="../../../amp"/>

-	

-	<!--  

-		WikiText Toolchain 

-	<property name="wikitext.url" value="http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/tools/mylyn/update/weekly/mylyn-wikitext-standalone-latest.zip"/>

-	-->

-	<property name="wikitext.url" value="http://download.eclipse.org/tools/mylyn/update/weekly/mylyn-wikitext-standalone-latest.zip"/>

-	<property name="wikitext.dir" value="${download.dir}${file.separator}wikitext"/>

-

-	<target name="check-wikitext">

-		<condition property="hasWikiText">

-			<and>

-				<available file="${download.dir}${file.separator}wikitext.zip" property="hasWikiTextZIP"/>

-				<available file="${wikitext.dir}" property="hasWikiTextDir"/>

-			</and>

-		</condition>

-	</target>

-	

-	<target name="get-wikitext" description="Downloads WikiText" depends="check-wikitext" unless="hasWikiText">

-		<echo>Downloading WikiText...</echo>

-		<get dest="${download.dir}${file.separator}wikitext.zip" src="${wikitext.url}"/>

-		<unzip src="${download.dir}${file.separator}wikitext.zip" dest="${wikitext.dir}">

-			<patternset includes="**/*.jar"/>

-			<mapper type="flatten"/>

-		</unzip>

-	</target>

-	

-	<target name="install-wikitext" depends="get-wikitext">

-		<taskdef resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties">

-			<classpath>

-				<fileset dir="${wikitext.dir}">

-					<include name="org.eclipse.mylyn.wikitext.*core*.jar"/>

-				</fileset>

-			</classpath>

-		</taskdef>

-	</target>

-	

-	<target name="assemble">

-		<loadfile srcfile="doc/${document.name}-index.txt" property="inputfiles">

-		  <filterchain>

-			<tokenfilter>

-			    <replacestring from="\n" to=","/>

-			</tokenfilter>

-		  </filterchain>

-		</loadfile>

-		<concat destfile="${build.dir}${file.separator}${document.name}.mediawiki" append="false" fixlastline="yes">

-			<filelist dir="doc" files="${inputfiles}"/>

-		</concat>

-	</target>

-	

-	<target name="wikitext2docbook" depends="assemble" description="Generate DocBook from MediaWIki">

-		<wikitext-to-docbook  markupLanguage="MediaWiki"

-			booktitle="Agent Modeling Guide"

-			validate="true">

-			<fileset dir="${build.dir}">

-	 			<include name="${document.name}.mediawiki"/>

-			</fileset>

-		</wikitext-to-docbook>

-	 </target>

-	

-	<!--

-		DocBook Toolchain

-	-->

-	<!-- <property name="docbook.version" value="1.73.2" /> -->

-	<property name="docbook.version" value="1.75.1" />

-	<property name="docbook.dir" value="${download.dir}${file.separator}docbook-xsl-${docbook.version}"/>

-	<property name="docbookxsl.url" value="http://internap.dl.sourceforge.net/sourceforge/docbook/docbook-xsl-${docbook.version}.zip"/>

-	<property name="fop.dir" value="${download.dir}${file.separator}fop-0.95"/>

-	<property name="fop.url" value="http://mirrorspace.org/apache/xmlgraphics/fop/binaries/fop-0.95-bin.zip"/>

-	<property name="jai.dir" value="ENTER_JAI_DIRECTORY"/>

-	

-    <macrodef name="docbook2pdf">

-        <attribute name="source"/>

-    	<attribute name="target"/>

-        <sequential>

-        	<taskdef name="fop" classname="org.apache.fop.tools.anttasks.Fop">

-        		<classpath>

-        			<pathelement location="${fop.dir}${file.separator}build${file.separator}fop.jar" />

-        			<pathelement location="${fop.dir}${file.separator}lib${file.separator}avalon-framework-4.2.0.jar" />

-        			<pathelement location="${fop.dir}${file.separator}lib${file.separator}commons-logging-1.0.4.jar" />

-        			<pathelement location="${fop.dir}${file.separator}lib${file.separator}commons-io-1.3.1.jar" />

-        			<pathelement location="${fop.dir}${file.separator}lib${file.separator}batik-all-1.7.jar" />

-        			<pathelement location="${fop.dir}${file.separator}lib${file.separator}xmlgraphics-commons-1.3.1.jar" />

-        			<pathelement location="${jai.dir}${file.separator}lib${file.separator}jai_core.jar" />

-        			<pathelement location="${jai.dir}${file.separator}lib${file.separator}jai_codec.jar" />

-        		</classpath>

-        	</taskdef>

-        	<fop 

-        		format="application/pdf" 

-        		fofile="@{source}" 

-        		outfile="@{target}"

-        		messagelevel="info"/>

-        </sequential>

-    </macrodef>

-

-	<target name="init">

-		<mkdir dir="${download.dir}"/>

-		<mkdir dir="${build.dir}"/>

-	</target>

-	

-	<target name="deploy-doc">

-		<copy todir="${website.dir}/documentation" overwrite="true">

-			<fileset dir="html/">

-				<include name="**" />

-			</fileset>

-		</copy>

-		<copy todir="${website.dir}/documentation" overwrite="true">

-			<fileset dir="manual/">

-				<include name="**" />

-			</fileset>

-		</copy>

-	</target>

-	

-	<target name="build-doc" depends="init, install-wikitext, get-docbook-xsl, get-fop">

-		<echo>Building Output...</echo>

-		<antcall target="wikitext2docbook"/>

-		<antcall target="docbook2pdf"/>

-		<antcall target="docbook2html"/>

-		<!--

-		<antcall target="wikitext2eclipsehelp"/>

-		-->

-		<antcall target="docbook2eclipsehelp"/>

-	</target>

-	

-	<target name="build-and-deploy-doc" depends="build-doc, deploy-doc">

-	</target>

-	

-	<target name="check-docbook">

-		<condition property="hasDocbook">

-			<and>

-				<available file="${download.dir}${file.separator}docbook.zip" property="hasDocbookZip"/>

-				<available file="${docbook.dir}" type="dir" property="hasDocbookDir"/>

-			</and>

-		</condition>

-	</target>

-	

-	<target name="check-fop">

-		<condition property="hasFOP">

-			<and>

-				<available file="${download.dir}${file.separator}fop.zip" property="hasFOPZip"/>

-				<available file="${fop.dir}" type="dir" property="hasFOPDir"/>

-			</and>

-		</condition>

-	</target>

-		

-	<target name="get-docbook-xsl" description="Downloads docbook xsl" depends="check-docbook" unless="hasDocbook">

-		<echo>Downloading DocBook XSL...</echo>

-		<get dest="${download.dir}${file.separator}docbook.zip" src="${docbookxsl.url}"/>

-		<unzip src="${download.dir}${file.separator}docbook.zip" dest="${download.dir}"/>

-	</target>

-	

-	<target name="get-fop" description="Downloads FOP" depends="check-fop" unless="hasFOP">

-		<echo>Downloading FOP...</echo>

-		<get dest="${download.dir}${file.separator}fop.zip" src="${fop.url}"/>

-		<unzip src="${download.dir}${file.separator}fop.zip" dest="${download.dir}"/>

-	</target>

-	

-	<target name="docbook2html">

-		<echo>Converting article to HTML...</echo>

-		<delete dir="${basedir}/html"

-		        failonerror="false"

-		        excludes="CVS" 

-				includeemptydirs="true"/>

-		

-		<copy todir="${basedir}/html">

-			<fileset dir="doc/">

-    			<include name="images/**" />

-			</fileset>

-		</copy>

-		<copy file="${html-css.file}" todir="${basedir}/html" />

-		

-		<xslt in="${build.dir}${file.separator}${document.name}.xml" extension="xml" out="${basedir}/html${file.separator}${document.name}.html" style="${document.stylesheet}">

-			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">

-				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true"/>

-			</factory>

-			<xmlcatalog>

-				<entity 

-					publicId="docbook.xsl"

-					location="${docbook.dir}${file.separator}html${file.separator}docbook.xsl"/>

-			</xmlcatalog>

-			<param name="header.rule" expression="1" />

-			<param name="admon.graphics.extension" expression=".gif"/>

-			<param name="admon.textlabel" expression="0"/>

-			<param name="ulink.target" expression="_new"/>

-			<param name="ignore.image.scaling" expression="1"/>

-		</xslt>

-	</target>

-	

-	<target name="docbook2pdf">

-		<echo>Converting article to PDF...</echo>

-		<delete file="manual${file.separator}${document.name}.pdf" failonerror="false"/>

-		<delete file="${build.dir}${file.separator}${document.name}.fo"/>

-		<mkdir dir="manual"/>

-		

-		<!-- HACK! images should rather be copied to build/images -->

-		<copy todir="${basedir}/images">

-			<fileset dir="doc/images-pdf">

-				<include name="**" />

-			</fileset>

-		</copy>

-

-

-		<xslt in="${build.dir}${file.separator}${document.name}.xml" extension="xml" out="${build.dir}${file.separator}${document.name}Test.xml" style="${dbpdf.stylesheet}">

-			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">

-				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true"/>

-			</factory>

-			<xmlcatalog>

-				<entity 

-					publicId="docbook.xsl"

-					location="${docbook.dir}${file.separator}fo${file.separator}docbook.xsl"/>

-			</xmlcatalog>

-		</xslt>

-		

-		<xslt in="${build.dir}${file.separator}${document.name}.xml" extension="xml" out="${build.dir}${file.separator}${document.name}.fo" style="${document.pdf.stylesheet}">

-			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">

-				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true"/>

-			</factory>

-			<xmlcatalog>

-				<entity 

-					publicId="docbook.xsl"

-					location="${docbook.dir}${file.separator}fo${file.separator}docbook.xsl"/>

-			</xmlcatalog>

-			<param name="graphicsize.extension" expression="1" />

-			<param name="use.extensions" expression="1" />

-			<param name="generate.toc" expression="book toc" />

-			<param name="show.comments" expression="0" />

-			<param name="header.rule" expression="1" />

-			<param name="admon.graphics.extension" expression=".gif"/>

-			<param name="admon.textlabel" expression="0"/>

-			<param name="admon.graphics" expression="1"/>

-			<param name="scale" expression="10"/>

-		</xslt>

-

-		<docbook2pdf 

-			source="${build.dir}${file.separator}${document.name}.fo"

-			target="manual${file.separator}${document.name}.pdf"/>

-		

-		<!-- Remove the resulting formatting object. This object isn't necessary in the

-		<delete file="${build.dir}${file.separator}${document.name}.fo" />

-		     result of this build. -->

-		<delete dir="${basedir}/images" />

-	</target>

-	

-	<target name="wikitext2eclipsehelp" depends="assemble" description="Generate Eclipse Help from MediaWiki">

-		<wikitext-to-eclipse-help markupLanguage="MediaWiki"

-			multipleOutputFiles="true"

-			navigationImages="false"

-			formatoutput="true"

-			helpPrefix="help">

-			<fileset dir="${build.dir}">

-	 			<include name="${document.name}.mediawiki"/>

-			</fileset>

-			<stylesheet url="book.css"/>

-			<stylesheet file="${basedir}/help/styles/main.css"/>

-		</wikitext-to-eclipse-help>

-	 </target>

-	

-	<target name="docbook2eclipsehelp">

-		<echo>Converting article to Eclipe Help...</echo>

-		<delete dir="${basedir}/help"

-		        failonerror="false"

-		        excludes="CVS" 

-				includeemptydirs="true"/>

-		<copy todir="${basedir}/help/images">

-			<fileset dir="doc/images">

-				<include name="**/*" />

-			</fileset>

-		</copy>

-		<copy file="${eclipsehelp-css.file}" todir="${basedir}/help" />

-		

-		<xslt basedir="${build.dir}" destdir="${basedir}" style="${document.eclipse.stylesheet}">

-			<param name="chunk.quietly" expression="1"/>

-			<include name="amp.xml"/>

-			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">

-				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true"/>

-			</factory>

-			<xmlcatalog>

-				<entity 

-					publicId="chunk.xsl"

-					location="${docbook.dir}${file.separator}html${file.separator}chunk.xsl"/>

-			</xmlcatalog>

-			<param name="header.rule" expression="1" />

-			<param name="ignore.image.scaling" expression="1" />

-		</xslt>

-		<delete file="${basedir}/amp.html" />

-	</target>

-

-	

-	

+<!--
+	Some of the code below is
+	(c) Chris Aniszczyk <caniszczyk@gmail.com>
+    (c) Lawrence Mandel <lmandel@ca.ibm.com>
+    (c) Peter Friese <peter.friese@itemis.com>
+-->
+<project name="org.eclipse.amp.doc" default="build-and-deploy-doc" basedir=".">
+
+	<!--
+		Global vars
+	-->
+	<property name="document.name" value="amp" />
+	<property name="document.stylesheet" value="styles/html.xsl" />
+	<property name="dbpdf.stylesheet" value="styles/dbpdfdb.xsl" />
+	<property name="document.pdf.stylesheet" value="styles/xmpp.xsl" />
+
+	<property name="document.eclipse.stylesheet" value="styles/eclipsehelp.xsl" />
+	<property name="eclipsehelp-css.file" value="styles/book.css" />
+	<property name="html-css.file" value="styles/book.css" />
+
+	<property name="build.dir" value="build" />
+	<property name="download.dir" value="${java.io.tmpdir}${file.separator}downloads" />
+	<property name="website.dir" value="../../../amp" />
+
+	<!--  
+		WikiText Toolchain 
+	<property name="wikitext.url" value="http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/tools/mylyn/update/weekly/mylyn-wikitext-standalone-latest.zip"/>
+	-->
+	<property name="wikitext.url" value="http://download.eclipse.org/tools/mylyn/update/weekly/mylyn-wikitext-standalone-latest.zip" />
+	<property name="wikitext.dir" value="${download.dir}${file.separator}wikitext" />
+
+	<target name="check-wikitext">
+		<condition property="hasWikiText">
+			<and>
+				<available file="${download.dir}${file.separator}wikitext.zip" property="hasWikiTextZIP" />
+				<available file="${wikitext.dir}" property="hasWikiTextDir" />
+			</and>
+		</condition>
+	</target>
+
+	<target name="get-wikitext" description="Downloads WikiText" depends="check-wikitext" unless="hasWikiText">
+		<echo>Downloading WikiText...</echo>
+		<get dest="${download.dir}${file.separator}wikitext.zip" src="${wikitext.url}" />
+		<unzip src="${download.dir}${file.separator}wikitext.zip" dest="${wikitext.dir}">
+			<patternset includes="**/*.jar" />
+			<mapper type="flatten" />
+		</unzip>
+	</target>
+
+	<target name="install-wikitext" depends="get-wikitext">
+		<taskdef resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties">
+			<classpath>
+				<fileset dir="${wikitext.dir}">
+					<include name="org.eclipse.mylyn.wikitext.*core*.jar" />
+				</fileset>
+			</classpath>
+		</taskdef>
+	</target>
+
+	<target name="assemble">
+		<loadfile srcfile="doc/${document.name}-index.txt" property="inputfiles">
+			<filterchain>
+				<tokenfilter>
+					<replacestring from="\n" to="," />
+				</tokenfilter>
+			</filterchain>
+		</loadfile>
+		<concat destfile="${build.dir}${file.separator}${document.name}.mediawiki" append="false" fixlastline="yes">
+			<filelist dir="doc" files="${inputfiles}" />
+		</concat>
+	</target>
+
+	<target name="wikitext2docbook" depends="assemble" description="Generate DocBook from MediaWIki">
+		<wikitext-to-docbook markupLanguage="MediaWiki" booktitle="Agent Modeling Guide" validate="true">
+			<fileset dir="${build.dir}">
+				<include name="${document.name}.mediawiki" />
+			</fileset>
+		</wikitext-to-docbook>
+	</target>
+
+	<!--
+		DocBook Toolchain
+	-->
+	<!-- <property name="docbook.version" value="1.73.2" /> -->
+	<property name="docbook.version" value="1.75.1" />
+	<property name="docbook.dir" value="${download.dir}${file.separator}docbook-xsl-${docbook.version}" />
+	<property name="docbookxsl.url" value="http://internap.dl.sourceforge.net/sourceforge/docbook/docbook-xsl-${docbook.version}.zip" />
+	<property name="fop.dir" value="${download.dir}${file.separator}fop-0.95" />
+	<property name="fop.url" value="http://mirrorspace.org/apache/xmlgraphics/fop/binaries/fop-0.95-bin.zip" />
+	<property name="jai.dir" value="ENTER_JAI_DIRECTORY" />
+
+	<macrodef name="docbook2pdf">
+		<attribute name="source" />
+		<attribute name="target" />
+		<sequential>
+			<taskdef name="fop" classname="org.apache.fop.tools.anttasks.Fop">
+				<classpath>
+					<pathelement location="${fop.dir}${file.separator}build${file.separator}fop.jar" />
+					<pathelement location="${fop.dir}${file.separator}lib${file.separator}avalon-framework-4.2.0.jar" />
+					<pathelement location="${fop.dir}${file.separator}lib${file.separator}commons-logging-1.0.4.jar" />
+					<pathelement location="${fop.dir}${file.separator}lib${file.separator}commons-io-1.3.1.jar" />
+					<pathelement location="${fop.dir}${file.separator}lib${file.separator}batik-all-1.7.jar" />
+					<pathelement location="${fop.dir}${file.separator}lib${file.separator}xmlgraphics-commons-1.3.1.jar" />
+					<pathelement location="${jai.dir}${file.separator}lib${file.separator}jai_core.jar" />
+					<pathelement location="${jai.dir}${file.separator}lib${file.separator}jai_codec.jar" />
+				</classpath>
+			</taskdef>
+			<fop format="application/pdf" fofile="@{source}" outfile="@{target}" messagelevel="info" />
+		</sequential>
+	</macrodef>
+
+	<target name="init">
+		<mkdir dir="${download.dir}" />
+		<mkdir dir="${build.dir}" />
+	</target>
+
+	<target name="deploy-doc">
+		<copy todir="${website.dir}/documentation/contents" overwrite="true">
+			<fileset dir="html/">
+				<include name="**" />
+			</fileset>
+		</copy>
+		<copy todir="${website.dir}/documentation" overwrite="true">
+			<fileset dir="manual/">
+				<include name="**" />
+			</fileset>
+		</copy>
+	</target>
+
+	<target name="build-doc" depends="init, install-wikitext, get-docbook-xsl, get-fop">
+		<echo>Building Output...</echo>
+		<antcall target="wikitext2docbook" />
+		<antcall target="docbook2pdf" />
+		<antcall target="docbook2html" />
+		<!--
+		<antcall target="wikitext2eclipsehelp"/>
+		-->
+		<antcall target="docbook2eclipsehelp" />
+	</target>
+
+	<target name="build-and-deploy-doc" depends="build-doc, deploy-doc">
+	</target>
+
+	<target name="check-docbook">
+		<condition property="hasDocbook">
+			<and>
+				<available file="${download.dir}${file.separator}docbook.zip" property="hasDocbookZip" />
+				<available file="${docbook.dir}" type="dir" property="hasDocbookDir" />
+			</and>
+		</condition>
+	</target>
+
+	<target name="check-fop">
+		<condition property="hasFOP">
+			<and>
+				<available file="${download.dir}${file.separator}fop.zip" property="hasFOPZip" />
+				<available file="${fop.dir}" type="dir" property="hasFOPDir" />
+			</and>
+		</condition>
+	</target>
+
+	<target name="get-docbook-xsl" description="Downloads docbook xsl" depends="check-docbook" unless="hasDocbook">
+		<echo>Downloading DocBook XSL...</echo>
+		<get dest="${download.dir}${file.separator}docbook.zip" src="${docbookxsl.url}" />
+		<unzip src="${download.dir}${file.separator}docbook.zip" dest="${download.dir}" />
+	</target>
+
+	<target name="get-fop" description="Downloads FOP" depends="check-fop" unless="hasFOP">
+		<echo>Downloading FOP...</echo>
+		<get dest="${download.dir}${file.separator}fop.zip" src="${fop.url}" />
+		<unzip src="${download.dir}${file.separator}fop.zip" dest="${download.dir}" />
+	</target>
+
+	<target name="docbook2html">
+		<echo>Converting article to HTML...</echo>
+		<delete dir="${basedir}/html" failonerror="false" excludes="CVS" includeemptydirs="true" />
+
+		<copy todir="${basedir}/html">
+			<fileset dir="doc/">
+				<include name="images/**" />
+			</fileset>
+		</copy>
+		<copy file="${html-css.file}" todir="${basedir}/html" />
+
+		<xslt in="${build.dir}${file.separator}${document.name}.xml" extension="xml" out="${basedir}/html${file.separator}${document.name}.html" style="${document.stylesheet}">
+			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
+				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true" />
+			</factory>
+			<xmlcatalog>
+				<entity publicId="docbook.xsl" location="${docbook.dir}${file.separator}html${file.separator}docbook.xsl" />
+			</xmlcatalog>
+			<param name="header.rule" expression="1" />
+			<param name="admon.graphics.extension" expression=".gif" />
+			<param name="admon.textlabel" expression="0" />
+			<param name="ulink.target" expression="_new" />
+			<param name="ignore.image.scaling" expression="1" />
+		</xslt>
+	</target>
+
+	<target name="docbook2pdf">
+		<echo>Converting article to PDF...</echo>
+		<delete file="manual${file.separator}${document.name}.pdf" failonerror="false" />
+		<delete file="${build.dir}${file.separator}${document.name}.fo" />
+		<mkdir dir="manual" />
+
+		<!-- HACK! images should rather be copied to build/images -->
+		<copy todir="${basedir}">
+			<fileset dir="doc/">
+				<include name="images/**" />
+			</fileset>
+		</copy>
+
+
+		<xslt in="${build.dir}${file.separator}${document.name}.xml" extension="xml" out="${build.dir}${file.separator}${document.name}PDF.xml" style="${dbpdf.stylesheet}">
+			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
+				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true" />
+			</factory>
+			<xmlcatalog>
+				<entity publicId="docbook.xsl" location="${docbook.dir}${file.separator}fo${file.separator}docbook.xsl" />
+			</xmlcatalog>
+		</xslt>
+
+		<xslt in="${build.dir}${file.separator}${document.name}PDF.xml" extension="xml" out="${build.dir}${file.separator}${document.name}.fo" style="${document.pdf.stylesheet}">
+			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
+				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true" />
+			</factory>
+			<xmlcatalog>
+				<entity publicId="docbook.xsl" location="${docbook.dir}${file.separator}fo${file.separator}docbook.xsl" />
+			</xmlcatalog>
+			<param name="graphicsize.extension" expression="1" />
+			<param name="use.extensions" expression="1" />
+			<param name="generate.toc" expression="book toc" />
+			<param name="show.comments" expression="0" />
+			<param name="header.rule" expression="1" />
+			<param name="admon.graphics.extension" expression=".gif" />
+			<param name="admon.textlabel" expression="0" />
+			<param name="admon.graphics" expression="1" />
+			<param name="scale" expression="10" />
+		</xslt>
+
+		<docbook2pdf source="${build.dir}${file.separator}${document.name}.fo" target="manual${file.separator}${document.name}.pdf" />
+
+		<!-- Remove the resulting formatting object. This object isn't necessary in the
+		     result of this build. -->
+		<delete file="${build.dir}${file.separator}${document.name}.fo" />
+		<delete dir="${basedir}/images" />
+	</target>
+
+	<target name="wikitext2eclipsehelp" depends="assemble" description="Generate Eclipse Help from MediaWiki">
+		<wikitext-to-eclipse-help markupLanguage="MediaWiki" multipleOutputFiles="true" navigationImages="false" formatoutput="true" helpPrefix="help">
+			<fileset dir="${build.dir}">
+				<include name="${document.name}.mediawiki" />
+			</fileset>
+			<stylesheet url="book.css" />
+			<stylesheet file="${basedir}/help/styles/main.css" />
+		</wikitext-to-eclipse-help>
+	</target>
+
+	<target name="docbook2eclipsehelp">
+		<echo>Converting article to Eclipe Help...</echo>
+		<delete dir="${basedir}/help" failonerror="false" excludes="CVS" includeemptydirs="true" />
+		<copy todir="${basedir}/help/images">
+			<fileset dir="doc/images">
+				<include name="**/*" />
+			</fileset>
+		</copy>
+		<copy file="${eclipsehelp-css.file}" todir="${basedir}/help" />
+
+		<xslt basedir="${build.dir}" destdir="${basedir}" style="${document.eclipse.stylesheet}">
+			<param name="chunk.quietly" expression="1" />
+			<include name="amp.xml" />
+			<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
+				<attribute name="http://xml.apache.org/xalan/features/optimize" value="true" />
+			</factory>
+			<xmlcatalog>
+				<entity publicId="chunk.xsl" location="${docbook.dir}${file.separator}html${file.separator}chunk.xsl" />
+			</xmlcatalog>
+			<param name="header.rule" expression="1" />
+			<param name="ignore.image.scaling" expression="1" />
+		</xslt>
+		<delete file="${basedir}/amp.html" />
+	</target>
+
+
+
 </project>
\ No newline at end of file
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/015-Guide_ABM.mediawiki b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/015-Guide_ABM.mediawiki
index eb2af85..5715dda 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/015-Guide_ABM.mediawiki
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/015-Guide_ABM.mediawiki
@@ -19,6 +19,6 @@
 
 Agent-Based Models (ABMs) seek to represent important real-world dynamics by designing communities of software agents that mimic real entities. Rather than make simplifying assumptions about such systems and then representing them in equation form or as off the shelf algorithmic constructs, the ABM researcher aims to identify key agent state, interaction spaces, and behaviors. Agents are then "let loose" on our computers and we explore what happens next. The computational horsepower exists today to simulate large numbers (e.g. >>10) of interacting, adaptive and autonomous agents but often desktop computers are all we need to explore significant domains. ABMs have been designed to represent all kinds of important natural systems, at scales reaching from cellular mechanics to international trade and are being used to solve truly hard problems in government, business, and academia. ABMs are not a solution to every problem, but they can help us to appreciate and gain unique insight into many systems, and often they can help us to come up with better practical decisions than we might using classic approaches.
 
-===Other Uses==
+==Other Uses==
 
 Many kinds of objects share characteristics of ABM agents -- after all, software agents are used in many other contexts. The Agent Modeling Framework meta-modeling support is potentially suitable (or extendible) for a number of approaches outside of ABM; for example business rules, object interactions, systems dynamics models and traditional discrete event models. Similarly, AMP execution and graphic support can be used for modeling natural systems but could also be used to manage other software agents -- for example independent reasoning tasks or dynamic visualization support.
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/120-ModelerGuide_Actions.mediawiki b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/120-ModelerGuide_Actions.mediawiki
index d36f36d..96883b1 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/120-ModelerGuide_Actions.mediawiki
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/120-ModelerGuide_Actions.mediawiki
@@ -23,31 +23,36 @@
 
 ====Kinds of Actions====
 
-Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. All of these are discussed in detail in the section that follows this one.
-
-These are all summarized in the diagram below:
-
-[[Image:images/actions/ActionsBlocks.png]] 
+{| border="0"
+|-valign="top"
+|Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. The various actions are discussed in depth in the Details section.
+|[[Image:images/actions/ActionsBlocks.png]] 
+|}
 
 ====Flow====
 
 First, let's look at how actions define the basic path that agents take during a model run. As with any programming language, the path we take through the program specification is what determines our state when we get there. In a pure object oriented program, the path just defines the control flow -- what we are doing. The actual state of our model is defined within the object itself. If we call a method B from another method A, we'll be relying on method A to set the values that we need into the object state itself. In a purely functional program the path defines how we are going to deal with whatever has been explicitly passed in to a function that has been called, that is the function parameters. In fact, most languages such as Java combine aspects of both approaches.
 
 In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.
-
 An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically ''need'' loop structures. By far the most common use of loops in conventional programming langauges is to loop through collections of objects. As selections (see below) refer to the entire collection of agents, any actions on a selection apply to all members of that collection. Recursive structures are needed for some particular usages and will be supported in future releases, but not through an explicit looping construct.
 
-Again, behaviors in Actions are always defined by a set of ''selections'' and ''queries''. In the following diagram, we can see the pattern.
+{| border="0"
+|-valign="top"
+|Again, behaviors in Actions are always defined by a set of ''selections'' and ''queries''. In the diagram to the right, we can see the pattern. First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent.
+|[[Image:images/actions/ActionsSequence.png]]
+|}
 
-[[Image:images/actions/ActionsSequence.png]]
+{| border="0"
+|-valign="top"
+|The diagram to the right depicts a simple example. Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them.
+|[[Image:images/actions/ActionsSimpleSequence.png]]
+|}
 
-First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent. The next diagram depicts a simple example.
-
-[[Image:images/actions/ActionsSimpleSequence.png]]
-
-Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them. In the next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.
-
-[[Image:images/actions/ActionsSimpleSequence2.png]]
+{| border="0"
+|-valign="top"
+|In this next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.
+|[[Image:images/actions/ActionsSimpleSequence2.png]]
+|}
 
 In the following example, we've defined a set of actions and their relationships. We have a selection, a few queries and a couple of logic operators leading to a Set Action. We'll describe in detail below how Logic Actions are used in conjunction with other actions to assemble any kind of query structure needed. But for now, we'll focus on the control flow itself.
 
@@ -78,22 +83,28 @@
 
 Selections are a key concept in Actions. Put simply, selections define what we are searching for and where. They are defined by a combination of Select, Query and Logic Actions. Each time we create a new Select Action, we define a new selection. Queries can be used to further refine selections either immediately after or later in the Action flow, as described in the next section. Logic Actions are used to combine and organize the Action flow defined by Query Actions. In order to understand how these three pieces work together, we need to understand the idea of selection boundaries.
 
-A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.
+{| border="0"
+|-valign="top"
+|A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.
+|[[Image:images/actions/ActionsSelBoundarySimple.png]]
+|}
 
-[[Image:images/actions/ActionsSelBoundarySimple.png]]
+{| border="0"
+|-valign="top"
+|Each time we create a new selection, we define a new set of boundaries. In the diagram to the right, Selection 1 and Selection 2 eaach start with a new Select Action. 
+|[[Image:images/actions/ActionsSelBoundary2Parts.png]] 
+|}
 
-Each time we create a new selection, we define a new set of boundaries.
-
-[[Image:images/actions/ActionsSelBoundary2Parts.png]] 
-
-A very important aspect of boundaries is that they apply to a group of actions that begin with a Query Action, and not just such a group that begins with a Select Action. This is because Query Actions can be directly part of a selection definition, but they can also refine selections, as we'll see. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:
+But boundaries can be defined for a group of actions by a Query Actions as well. This is because Query Actions can be directly part of a selection definition, but they can also refine selections. We'll see how that works below. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:
 
 #A Query Action is not followed by a Logic Action, or
 #A Logic Action is not followed by another Logic Action
 
-In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as we can see in the following example. 
-
-[[Image:images/actions/ActionsSelBoundary11A.png]]
+{| border="0"
+|-valign="top"
+|In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as shown in the example to the right. 
+|[[Image:images/actions/ActionsSelBoundary11A.png]]
+|}
 
 Note that we refer to "Selection 1" and Selection 1A". This is because Selection 1A is a refinement of Selection 1 along its particular path of flow. When a query appears for the same selection but past a particular boundary, you can think of it as a sort of filter on the selection contents. We don't have a "Selection 2" here because any Actions that refer to "Selection 1" along the current path of flow will be acting on the selection defined by Selection 1 and Selection 1A.
 
@@ -105,31 +116,37 @@
 
 ====Weaving====
 
-Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.
+{| border="0"
+|-valign="top"
+|Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.
+|[[Image:images/actions/ActionsWeavingSetAnother.png]]
+|}
 
-[[Image:images/actions/ActionsWeavingSetAnother.png]]
+{| border="0"
+|-valign="top"
+|Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)
+|[[Image:images/actions/ActionsWeavingEvaluate.png]]
+|}
 
-Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)
+{| border="0"
+|-valign="top"
+|But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.
+|[[Image:images/actions/ActionsWeaving1A.png]]
+|}
 
-[[Image:images/actions/ActionsWeavingEvaluate.png]]
-
-But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.
-
-[[Image:images/actions/ActionsWeaving1A.png]]
-
-Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Now, consider the following example:
-
-[[Image:images/actions/ActionsWeaving2.png]]
-
-Before going into further details we need to introduce one more important concept. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.
+{| border="0"
+|-valign="top"
+|Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Consider the example to the right. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.
+|[[Image:images/actions/ActionsWeaving2.png]]
+|}
 
 ===Details===
 
-In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general.
-Let's look at the overall view again amd then dig into the details.
-
-[[Image:images/actions/ActionsBlocks.png]] 
-
+{| border="0"
+|-valign="top"
+|In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general. Again, the block diagram to the right provides an overview of how the various actions are related. You might want to take a look at the meta-class diagrams in the referernce section as well.
+|[[Image:images/actions/ActionsBlocks.png]] 
+|}
 
 ====Selections====
 
@@ -487,7 +504,11 @@
 #Keep your usage of external API references to a minimum. If you can use only code provied by the core Java classes as well as the Apache Collections library, your code should work on every current Java target. On the other hand, if you make use of a specific ABM platform APIs your code will obviously only compile and run against that target.
 #Code should be in the form of a method body, excluding the signature. A single Java method is created using this code body. There is no support for input parameters -- if you need access to evaluated values from source actions, create agent attributes for them, set their values for the selected agents, and use them as sources for your Method Action.
 #All Java class references should be fully qualified. For example, if you wish to use the eclipse Draw2D Graphics class, you should refer to "org.eclipse.draw2d.Graphics", not simply "Graphics". If classes are not fully qualified, you will recieve compile errors. You can usually easily fix these by selecting your source code directory and choosing '''Source > Organize Imports..''' but it prevents automatic code generation.
-#The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context: <pre>(new org.me.SpecialFileLoader()).load(this);</pre>Then create a new source directory in your project called "src" ('''New > Source Folder...''') and create the class for the specialized file loader including the following method: <pre>public void load(MyRootModel model) {...}</pre> This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.
+#The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context:
+ (new org.me.SpecialFileLoader()).load(this);
+Then create a new source directory in your project called "src" ('''New > Source Folder...''') and create the class for the specialized file loader including the following method:
+ public void load(MyRootModel model) {...}
+This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.
 
 ======Selection======
 
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/320-UserGuide_Exploring.mediawiki b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/320-UserGuide_Exploring.mediawiki
index f04ac3e..840aa91 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/320-UserGuide_Exploring.mediawiki
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/320-UserGuide_Exploring.mediawiki
@@ -3,19 +3,16 @@
 ===Launching a Model (AMF)===
 
 
-When an AMF file is selected -- in any of the perspectives -- the pop-up menu looks like this:
-
-[[Image:images/tools/EditorMenu.png | left]]
-
-(In this case we've selected the "Execute Headless" option.) Note that the toolbar and Application menus are updated to reflect the file you've selected and can provide more convenient access to many of the functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. An important note: the execution framework doesn't know whether your code exists in an Escape project or anohter target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.
-
-[[Image:images/tools/EditorToolbar.png]]
-
-To launch a model, select one of the options.
+{| border="0"
+|-valign="top"
+|Launching AMF and Escape models is easy. When an AMF file is selected -- in any of the perspectives -- the toolbar and Application menus are updated to reflect the file you've selected and provide convenient access to other functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. If you right-click on a file a pop-up menu appears like the one to the far right -- in this case we're selecting the "Execute Headless" option. To launch a model, just select one of the options. (Note that the execution framework doesn't know whether your code exists in an Escape project or another target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.)
+|[[Image:images/tools/EditorToolbar.png]]
+|[[Image:images/tools/EditorMenu.png]]
+|}
 
 One a model has been launched, the Agent Execution Perspective automatically becomes active. The Provides a custom layout menus and tools specific to executing agent models.
 
-[[Image:images/execution/EpidemicModelRunning.png]]
+[[Image:images/execution/EpidemicExecNew.png]]
 
 The execution options are:
 
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/420-Tutorial_Tree.mediawiki b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/420-Tutorial_Tree.mediawiki
index 0305269..1a11806 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/420-Tutorial_Tree.mediawiki
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/420-Tutorial_Tree.mediawiki
@@ -137,7 +137,7 @@
 
 The first part of the Bug Rule is exactly the same as the Initialize rule. Create a Selection Action. As before, we'll make the Select statement "Agent" property blank, as we want to move to a cell. As before, we want to make sure the Cell is free before we try to move in, so we'll select a "Spatial: Available" Query function.(By the way, to make scrolling through the list easier, you can type the first letters of the selection, in this case "SP".)
 
-But now, instead of moving <i>anywhere</i> we want to move nearby. So now, we create a ''parallel'' or "sibling" Query from the same Select root. Because this new Query Action is a child of the Select Action and not the "Space Available" Query we've just created, we'll right-click on the ''Select'' Action and choose '''Create Target > Select > Query'''. Like so:
+But now, instead of moving ''anywhere'' we want to move nearby. So now, we create a ''parallel'' or "sibling" Query from the same Select root. Because this new Query Action is a child of the Select Action and not the "Space Available" Query we've just created, we'll right-click on the ''Select'' Action and choose '''Create Target > Select > Query'''. Like so:
 
 [[Image:images/edit_tutorial/SimpleTutorial26CreateQuery2.png | right]]
 
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/Tutorial.txt b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/Tutorial.txt
index 3fc1c5d..a2b76a1 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/Tutorial.txt
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/Tutorial.txt
@@ -1,145 +1,145 @@
-

-    <img src="images/tutorials/stupidmodel1/BugInitialMovement/NameRandomHabitatQuery_75.jpg" alt="" /></li>

-    <span class="note">By the way, you've probably noticed that the platform creates names that often make sense,

-    but you can always replace them with more descriptive names. </span>

-    <li class="arrow1">

-    <p>Now that we know our destination we can Move. Create a Move Rule. (At this point you should be getting

-    familiar with the interface, so we will skip steps here and there.) For the Move we need to define a Select from

-    which we want to Move; "Selected", and a Select that we want to move to; "Destination". MetaABM picks exactly what

-    we want here for this common case.<span></span></p>

-    <img src="images/tutorials/stupidmodel1/BugInitialMovement/AddMoveMethod_75.jpg" alt="" /></li>

-    <hr />

-    <p style="text-align: right"><a name="style" shape="rect" /><a href="#top" shape="rect">contents</a></p>

-    <h3>Agent Styles</h3>

-    <li>

-    <p>There is one other thing to do before we can see what we have accomplished. While most ABM platforms have

-    some kind of default color scheme, let's make the Bugs red. Agent visualization is accomplished using the same

-    mechanism as ordinary agent rules. So first, let's create a new Style. By default the style will be called

-    BugStyle2D, and that will work fine for now.</p>

-    <img src="images/tutorials/stupidmodel1/DefineStyle/CreateBugStyle_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>Now we need to create a series of evaluations. An Evaluation is like a Query in that it performs some kind of

-    function in the broadest sense, but unlike a Query, it does not affect whether target (downstream) Acts are

-    performed. For Styles we have a set of Graphic functions that we will chain together to draw a figure. First we

-    create the Evaluation.</p>

-    <img src="images/tutorials/stupidmodel1/DefineStyle/CreateStyleEval_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>We make the first Evaluation define a Color of "Red".</p>

-    <img src="images/tutorials/stupidmodel1/DefineStyle/BugStyleColor_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>Next, create a "Draw Oval" fill. <span class="note">There are other graphic shapes, but at this

-    writing we only have implementations for Ovals and Rectangles and Markers.</span></p>

-    </li>

-    <li class="arrow1">

-    <p>For the last part of our style, we need to actually draw the figure. To do this we create a last Evaluation

-    of "Graphic: Fill Shape".</p>

-    <span class="info">"Fill" or "Outline" will always come last in a chain of graphic evaluations, but otherwise

-    the order shouldn't matter. See the Demographic Prisoner's Dilemma model for an example of how this can be used to

-    selectively pick Colors and or Shapes.</span> <img

-        src="images/tutorials/stupidmodel1/DefineStyle/BugStyleGraphicFill_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>We can also create a Style for the Habitat. This gives the cells a nice green Color, and will come in handy

-    later when we want to draw state for the Habitat agents. (Also it is currently necessary to make our implementation

-    of Repast graphics work correctly.)</p>

-    <img src="images/tutorials/stupidmodel1/DefineStyle/CreateHabitatStyle_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>It is time to run our model. Right-click on the StupidModel metaabm file, and select Run As..:Ascape metaABM

-    Model.</p>

-    <img src="images/tutorials/stupidmodel1/RunModel/RunInitialModel_75.jpg" alt="" />

-    <p>Voila!</p>

-    <img src="images/tutorials/stupidmodel1/RunModel/RunningInitialModel_75.jpg" alt="" /></li>

-    <hr />

-    <p style="text-align: right"><a name="movement" shape="rect" /><a href="#top" shape="rect">contents</a></p>

-    <h3>Agent Movement</h3>

-    <li class="arrow1">

-    <p>To make our agents move randomly every iteration, we will create a Rule. (For those familiar with Repast or

-    other scheduling oriented AM platforms, a rule is just a schedule that gets activated each and every period for all

-    agents.)</p>

-    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CreateBugRule_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>The first part of the Bug Rule is exactly the same as the Initialize rule. Remember to make the Select

-    statement Agent property "Habitat" instead of "Bug", as we want to move to a habitat cell. (We should really assign

-    a better name then "Bug Rule" perhaps "Random Movement".) As before, we want to make sure the Cell is free before we

-    try to move in, so we'll select a "Spatial: Available" Query function.(By the way, to make scrolling through the

-    list easier, you can type the first letters of the selection, in this case "SP".)</p>

-    <img src="images/tutorials/stupidmodel1/BugRandomMovement/SelectAvailable_75.jpg" alt="" /></li>

-    <li>

-    <hr />

-    <p style="text-align: right"><a name="errors" shape="rect" /><a href="#top" shape="rect">contents</a></p>

-    <h3>Error Checking</h3>

-    <p>But now, instead of moving <i>anywhere</i> we want to move nearby. So now, we create a <i>parallel</i> or

-    "sibling" Query from the same Select root. Often, we would pick the "Spatial: Neighbor" function to take a random

-    walk, but according to the specification, we actually want to move into some random Cell within distance four (4).

-    So we will pick "Spatial: Within" from the list of functions. Instead of specifying the actual distance now, let's

-    examine another feature of metaABM, error checking. Save the model by selecting File:Save or the appropriate

-    keyboard command.</p>

-    <p>You should see an error message.</p>

-    <img src="images/tutorials/stupidmodel1/ErrorChecking/ErrorMessage.jpg" alt="" />

-    <p>Over in the Package Explorer (file list) you can see that the .metaabm file has been marked with an error

-    symbol.</p>

-    <img src="images/tutorials/stupidmodel1/ErrorChecking/ProblemView.png" alt="" />

-    <p>Double-click on the problem marker and the offending item will be highlighted.</p>

-    <img src="images/tutorials/stupidmodel1/ErrorChecking/HighlightedError.jpg" alt="" /> <span class="info">

-    <p>In addition to error markers, metaABM provides warnings designed to help you avoid common design mistakes.

-    For example, a warning will be issued if you attempt to move an agent from its selection to the same selection; this

-    is not strictly speaking an error, but it doesn't make much sense. Notice that the Demographic Prisonner's Dilemma

-    model has a warning marker, this is because we are happy with the default values for the attributes and didn't

-    provide any.</p>

-    </span> <span class="note">You might also notice a number of Java warnings. By default the Eclipse IDE is very

-    conservative when it comes to warnings, and expects the usage of language constructs that we choose not to use. A

-    full discussion of all of this is beyond the scope of the tutorial, but see the Eclipse documentation on problem

-    views for more ideas about how to customize these views.</span>

-    <li class="arrow1">

-    <p>Returning to our model, we need a cell that is <i>both</i> Available and Within 4. To accomplish this,

-    metaABM supports Logical Acts which control how various Queries work together. So create an All Act as a target of

-    the Spatial Available Query.</p>

-    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CreateAllTarget_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>Now for an interesting issue. Option-Drag the All node to <i>also</i> be a target of the Spatial Within Act.

-    (This is a copy and drag action -- the same one you would use to copy a file from one directory to another without

-    removing it form the original location. Depending on your OS, you may need to use the ALT or SHIFT key to accomplish

-    this.)</p>

-    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CopyAll_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>We can then create a Target movement just as we did for the Initialize method above. But now as we have

-    defined parallel but Logically linked Acts the same Move node shows up in our hierarchical editor twice!</p>

-    <span class="note">This is probably a bit confusing for new users, but it is one of the aspects of the

-    metaABM design that provides efficient behavior representation. Supporting tools such as the Metascape IDE

-    Visualizer provide other ways to explore more complex Act structures.</span> <img

-        src="images/tutorials/stupidmodel1/BugRandomMovement/MoveFromAll_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>Now we just need to assign a value for search distance. We <i>could</i> simply create a literal for the

-    Spatial: Within Query but that isn't really god practice. (In fact, originally metaABM didn't allow any literals,

-    but that began to seem a little too hard-headed.) So we will create our first Attribute. In this case, we want the

-    Attribute to belong to Simple Model as it will be the same value for all Agents for now. So right-click on Simple

-    Agent: Attributes and create a new one.</p>

-    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CreateBugVision_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>Name the Attribute -- "Bug Vision" seems descriptive -- give it a type of Integer, and assign it a default

-    value of 4. This will allow most ABM platforms to provide the ability to change vision at runtime or through batch

-    definitions, something we couldn't do if we had used a literal value.</p>

-    <img src="images/tutorials/stupidmodel1/BugRandomMovement/DefineBugVision_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>Finally, we assign the Vision attribute to the "Input" node in our Spatial: Within Query.</p>

-    <img src="images/tutorials/stupidmodel1/BugRandomMovement/SetWithinBugVision_75.jpg" alt="" /></li>

-    <hr />

-    <p style="text-align: right"><a name="run" shape="rect" /><a href="#top" shape="rect">contents</a></p>

-    <h3>Run Final Model</h3>

-    <li class="arrow1">

-    <p>And here is our final model! Not looking much different in a snapshot, but those agents should now be moving

-    around.</p>

-    <img src="images/tutorials/stupidmodel1/RunModel/RunFinalModel_75.jpg" alt="" /></li>

-    <li class="arrow1">

-    <p>We have built a complete Ascape model from our metaABM model. But that's not all -- we also have a complete

-    Repast model! We will leave this as an exercise -- you can simply follow the directions in the example model section

-    on Demographic Prisoner's Dilemma.</p>

-    <span class="info">If you get completely stuck, SimpleModel1 is available in <a href="../downloads/models/StupidModel1.metaabm">model downloads</a>.</span>

-    <h4>That's all for Now</h4>

-    <p>We hope these "Getting Started" has enabled you to get up and running and given you some familiarity with the

-    basic metaABM approach. Upcoming articles will explore metaABM model design in more depth and provide a complete

-    Stupid Model implementation. Technical Articles will provide more explanation of the theoretical and practical

-    decisions that went into metaABM.</p>

-    </li>

-</ul>

-<small>All contents &copy; Copyright 2008 Metascape, LLC. All rights reserved.</small></body>

+
+    <img src="images/tutorials/stupidmodel1/BugInitialMovement/NameRandomHabitatQuery_75.jpg" alt="" /></li>
+    <span class="note">By the way, you've probably noticed that the platform creates names that often make sense,
+    but you can always replace them with more descriptive names. </span>
+    <li class="arrow1">
+    <p>Now that we know our destination we can Move. Create a Move Rule. (At this point you should be getting
+    familiar with the interface, so we will skip steps here and there.) For the Move we need to define a Select from
+    which we want to Move; "Selected", and a Select that we want to move to; "Destination". MetaABM picks exactly what
+    we want here for this common case.<span></span></p>
+    <img src="images/tutorials/stupidmodel1/BugInitialMovement/AddMoveMethod_75.jpg" alt="" /></li>
+    <hr />
+    <p style="text-align: right"><a name="style" shape="rect" /><a href="#top" shape="rect">contents</a></p>
+    <h3>Agent Styles</h3>
+    <li>
+    <p>There is one other thing to do before we can see what we have accomplished. While most ABM platforms have
+    some kind of default color scheme, let's make the Bugs red. Agent visualization is accomplished using the same
+    mechanism as ordinary agent rules. So first, let's create a new Style. By default the style will be called
+    BugStyle2D, and that will work fine for now.</p>
+    <img src="images/tutorials/stupidmodel1/DefineStyle/CreateBugStyle_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>Now we need to create a series of evaluations. An Evaluation is like a Query in that it performs some kind of
+    function in the broadest sense, but unlike a Query, it does not affect whether target (downstream) Acts are
+    performed. For Styles we have a set of Graphic functions that we will chain together to draw a figure. First we
+    create the Evaluation.</p>
+    <img src="images/tutorials/stupidmodel1/DefineStyle/CreateStyleEval_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>We make the first Evaluation define a Color of "Red".</p>
+    <img src="images/tutorials/stupidmodel1/DefineStyle/BugStyleColor_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>Next, create a "Draw Oval" fill. <span class="note">There are other graphic shapes, but at this
+    writing we only have implementations for Ovals and Rectangles and Markers.</span></p>
+    </li>
+    <li class="arrow1">
+    <p>For the last part of our style, we need to actually draw the figure. To do this we create a last Evaluation
+    of "Graphic: Fill Shape".</p>
+    <span class="info">"Fill" or "Outline" will always come last in a chain of graphic evaluations, but otherwise
+    the order shouldn't matter. See the Demographic Prisoner's Dilemma model for an example of how this can be used to
+    selectively pick Colors and or Shapes.</span> <img
+        src="images/tutorials/stupidmodel1/DefineStyle/BugStyleGraphicFill_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>We can also create a Style for the Habitat. This gives the cells a nice green Color, and will come in handy
+    later when we want to draw state for the Habitat agents. (Also it is currently necessary to make our implementation
+    of Repast graphics work correctly.)</p>
+    <img src="images/tutorials/stupidmodel1/DefineStyle/CreateHabitatStyle_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>It is time to run our model. Right-click on the StupidModel metaabm file, and select Run As..:Ascape metaABM
+    Model.</p>
+    <img src="images/tutorials/stupidmodel1/RunModel/RunInitialModel_75.jpg" alt="" />
+    <p>Voila!</p>
+    <img src="images/tutorials/stupidmodel1/RunModel/RunningInitialModel_75.jpg" alt="" /></li>
+    <hr />
+    <p style="text-align: right"><a name="movement" shape="rect" /><a href="#top" shape="rect">contents</a></p>
+    <h3>Agent Movement</h3>
+    <li class="arrow1">
+    <p>To make our agents move randomly every iteration, we will create a Rule. (For those familiar with Repast or
+    other scheduling oriented AM platforms, a rule is just a schedule that gets activated each and every period for all
+    agents.)</p>
+    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CreateBugRule_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>The first part of the Bug Rule is exactly the same as the Initialize rule. Remember to make the Select
+    statement Agent property "Habitat" instead of "Bug", as we want to move to a habitat cell. (We should really assign
+    a better name then "Bug Rule" perhaps "Random Movement".) As before, we want to make sure the Cell is free before we
+    try to move in, so we'll select a "Spatial: Available" Query function.(By the way, to make scrolling through the
+    list easier, you can type the first letters of the selection, in this case "SP".)</p>
+    <img src="images/tutorials/stupidmodel1/BugRandomMovement/SelectAvailable_75.jpg" alt="" /></li>
+    <li>
+    <hr />
+    <p style="text-align: right"><a name="errors" shape="rect" /><a href="#top" shape="rect">contents</a></p>
+    <h3>Error Checking</h3>
+    <p>But now, instead of moving <i>anywhere</i> we want to move nearby. So now, we create a <i>parallel</i> or
+    "sibling" Query from the same Select root. Often, we would pick the "Spatial: Neighbor" function to take a random
+    walk, but according to the specification, we actually want to move into some random Cell within distance four (4).
+    So we will pick "Spatial: Within" from the list of functions. Instead of specifying the actual distance now, let's
+    examine another feature of metaABM, error checking. Save the model by selecting File:Save or the appropriate
+    keyboard command.</p>
+    <p>You should see an error message.</p>
+    <img src="images/tutorials/stupidmodel1/ErrorChecking/ErrorMessage.jpg" alt="" />
+    <p>Over in the Package Explorer (file list) you can see that the .metaabm file has been marked with an error
+    symbol.</p>
+    <img src="images/tutorials/stupidmodel1/ErrorChecking/ProblemView.png" alt="" />
+    <p>Double-click on the problem marker and the offending item will be highlighted.</p>
+    <img src="images/tutorials/stupidmodel1/ErrorChecking/HighlightedError.jpg" alt="" /> <span class="info">
+    <p>In addition to error markers, metaABM provides warnings designed to help you avoid common design mistakes.
+    For example, a warning will be issued if you attempt to move an agent from its selection to the same selection; this
+    is not strictly speaking an error, but it doesn't make much sense. Notice that the Demographic Prisonner's Dilemma
+    model has a warning marker, this is because we are happy with the default values for the attributes and didn't
+    provide any.</p>
+    </span> <span class="note">You might also notice a number of Java warnings. By default the Eclipse IDE is very
+    conservative when it comes to warnings, and expects the usage of language constructs that we choose not to use. A
+    full discussion of all of this is beyond the scope of the tutorial, but see the Eclipse documentation on problem
+    views for more ideas about how to customize these views.</span>
+    <li class="arrow1">
+    <p>Returning to our model, we need a cell that is <i>both</i> Available and Within 4. To accomplish this,
+    metaABM supports Logical Acts which control how various Queries work together. So create an All Act as a target of
+    the Spatial Available Query.</p>
+    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CreateAllTarget_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>Now for an interesting issue. Option-Drag the All node to <i>also</i> be a target of the Spatial Within Act.
+    (This is a copy and drag action -- the same one you would use to copy a file from one directory to another without
+    removing it form the original location. Depending on your OS, you may need to use the ALT or SHIFT key to accomplish
+    this.)</p>
+    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CopyAll_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>We can then create a Target movement just as we did for the Initialize method above. But now as we have
+    defined parallel but Logically linked Acts the same Move node shows up in our hierarchical editor twice!</p>
+    <span class="note">This is probably a bit confusing for new users, but it is one of the aspects of the
+    metaABM design that provides efficient behavior representation. Supporting tools such as the Metascape IDE
+    Visualizer provide other ways to explore more complex Act structures.</span> <img
+        src="images/tutorials/stupidmodel1/BugRandomMovement/MoveFromAll_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>Now we just need to assign a value for search distance. We <i>could</i> simply create a literal for the
+    Spatial: Within Query but that isn't really god practice. (In fact, originally metaABM didn't allow any literals,
+    but that began to seem a little too hard-headed.) So we will create our first Attribute. In this case, we want the
+    Attribute to belong to Simple Model as it will be the same value for all Agents for now. So right-click on Simple
+    Agent: Attributes and create a new one.</p>
+    <img src="images/tutorials/stupidmodel1/BugRandomMovement/CreateBugVision_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>Name the Attribute -- "Bug Vision" seems descriptive -- give it a type of Integer, and assign it a default
+    value of 4. This will allow most ABM platforms to provide the ability to change vision at runtime or through batch
+    definitions, something we couldn't do if we had used a literal value.</p>
+    <img src="images/tutorials/stupidmodel1/BugRandomMovement/DefineBugVision_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>Finally, we assign the Vision attribute to the "Input" node in our Spatial: Within Query.</p>
+    <img src="images/tutorials/stupidmodel1/BugRandomMovement/SetWithinBugVision_75.jpg" alt="" /></li>
+    <hr />
+    <p style="text-align: right"><a name="run" shape="rect" /><a href="#top" shape="rect">contents</a></p>
+    <h3>Run Final Model</h3>
+    <li class="arrow1">
+    <p>And here is our final model! Not looking much different in a snapshot, but those agents should now be moving
+    around.</p>
+    <img src="images/tutorials/stupidmodel1/RunModel/RunFinalModel_75.jpg" alt="" /></li>
+    <li class="arrow1">
+    <p>We have built a complete Ascape model from our metaABM model. But that's not all -- we also have a complete
+    Repast model! We will leave this as an exercise -- you can simply follow the directions in the example model section
+    on Demographic Prisoner's Dilemma.</p>
+    <span class="info">If you get completely stuck, SimpleModel1 is available in <a href="../downloads/models/StupidModel1.metaabm">model downloads</a>.</span>
+    <h4>That's all for Now</h4>
+    <p>We hope these "Getting Started" has enabled you to get up and running and given you some familiarity with the
+    basic metaABM approach. Upcoming articles will explore metaABM model design in more depth and provide a complete
+    Stupid Model implementation. Technical Articles will provide more explanation of the theoretical and practical
+    decisions that went into metaABM.</p>
+    </li>
+</ul>
+<small>All contents &copy; Copyright 2008 Metascape, LLC. All rights reserved.</small></body>
 </html>
\ No newline at end of file
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/images/actions/ActionsSelBoundarySimple.png b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/images/actions/ActionsSelBoundarySimple.png
index 72a1288..bafb515 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/images/actions/ActionsSelBoundarySimple.png
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/images/actions/ActionsSelBoundarySimple.png
Binary files differ
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/images/execution/EpidemicExecNew.png b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/images/execution/EpidemicExecNew.png
new file mode 100644
index 0000000..0dc133e
--- /dev/null
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/doc/images/execution/EpidemicExecNew.png
Binary files differ
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/docs/Legal.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/docs/Legal.html
index f3324a1..2a2a12e 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/docs/Legal.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/docs/Legal.html
@@ -1,23 +1,23 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

-<html lang="en">

-<head>

-

-<meta name="copyright" content="Copyright (c) Metascape LLC and others 2009. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >

-

-   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

-   <LINK REL="STYLESHEET" HREF="book.css" CHARSET="ISO-8859-1" TYPE="text/css">

-   <title>Legal Notices</title>

-

-</head>

-<body>

-

-<h3>

-<a NAME="Notices"></a>Notices</h3>

-<p>

-The material in this guide is Copyright (c) Metascape LLC and others 2009.

-</p>

-<p>

-<a href="../about.html">Terms and conditions regarding the use of this guide.</a>

-</p>

-</body>

+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<html lang="en">
+<head>
+
+<meta name="copyright" content="Copyright (c) Metascape LLC and others 2009. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
+
+   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+   <LINK REL="STYLESHEET" HREF="book.css" CHARSET="ISO-8859-1" TYPE="text/css">
+   <title>Legal Notices</title>
+
+</head>
+<body>
+
+<h3>
+<a NAME="Notices"></a>Notices</h3>
+<p>
+The material in this guide is Copyright (c) Metascape LLC and others 2009.
+</p>
+<p>
+<a href="../about.html">Terms and conditions regarding the use of this guide.</a>
+</p>
+</body>
 </html>
\ No newline at end of file
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Actions_2.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Actions_2.html
index 2dd8745..168d749 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Actions_2.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Actions_2.html
@@ -66,16 +66,19 @@
 </div>
 </div>
 </div>
-<p>Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. All of these are discussed in detail in the section that follows this one.</p>
-<p>These are all summarized in the diagram below:</p>
-<p>
-						
-</p>
+<table id="N1029B">
+<tr>
+							
+<td>Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. The various actions are discussed in depth in the Details section.</td>
+							<td>
+								
 <div class="mediaobject">
-<img src="images/actions/ActionsBlocks.png"></div>
-<p> 
-					
-</p>
+<img src="images/actions/ActionsBlocks.png"></div> 
+							
+</td>
+						
+</tr>
+</table>
 </div>
 <div class="section" title="Flow">
 <div class="titlepage">
@@ -87,40 +90,52 @@
 </div>
 </div>
 <p>First, let's look at how actions define the basic path that agents take during a model run. As with any programming language, the path we take through the program specification is what determines our state when we get there. In a pure object oriented program, the path just defines the control flow -- what we are doing. The actual state of our model is defined within the object itself. If we call a method B from another method A, we'll be relying on method A to set the values that we need into the object state itself. In a purely functional program the path defines how we are going to deal with whatever has been explicitly passed in to a function that has been called, that is the function parameters. In fact, most languages such as Java combine aspects of both approaches.</p>
-<p>In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.</p>
-<p>An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically 
+<p>In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.
+						An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically 
 						<span class="italic">need</span> loop structures. By far the most common use of loops in conventional programming langauges is to loop through collections of objects. As selections (see below) refer to the entire collection of agents, any actions on a selection apply to all members of that collection. Recursive structures are needed for some particular usages and will be supported in future releases, but not through an explicit looping construct.
 					</p>
-<p>Again, behaviors in Actions are always defined by a set of 
-						<span class="italic">selections</span> and 
-						<span class="italic">queries</span>. In the following diagram, we can see the pattern.
-					</p>
-<p>
-						
-</p>
+<table id="N102B9">
+<tr>
+							
+<td>Again, behaviors in Actions are always defined by a set of 
+								<span class="italic">selections</span> and 
+								<span class="italic">queries</span>. In the diagram to the right, we can see the pattern. First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent.
+							</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsSequence.png"></div>
-<p>
-					
-</p>
-<p>First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent. The next diagram depicts a simple example.</p>
-<p>
+							
+</td>
 						
-</p>
+</tr>
+</table>
+<table id="N102D3">
+<tr>
+							
+<td>The diagram to the right depicts a simple example. Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them.</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsSimpleSequence.png"></div>
-<p>
-					
-</p>
-<p>Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them. In the next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</p>
-<p>
+							
+</td>
 						
-</p>
+</tr>
+</table>
+<table id="N102E5">
+<tr>
+							
+<td>In this next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsSimpleSequence2.png"></div>
-<p>
-					
-</p>
+							
+</td>
+						
+</tr>
+</table>
 <p>In the following example, we've defined a set of actions and their relationships. We have a selection, a few queries and a couple of logic operators leading to a Set Action. We'll describe in detail below how Logic Actions are used in conjunction with other actions to assemble any kind of query structure needed. But for now, we'll focus on the control flow itself.</p>
 <p>
 						
@@ -172,25 +187,33 @@
 </div>
 </div>
 <p>Selections are a key concept in Actions. Put simply, selections define what we are searching for and where. They are defined by a combination of Select, Query and Logic Actions. Each time we create a new Select Action, we define a new selection. Queries can be used to further refine selections either immediately after or later in the Action flow, as described in the next section. Logic Actions are used to combine and organize the Action flow defined by Query Actions. In order to understand how these three pieces work together, we need to understand the idea of selection boundaries.</p>
-<p>A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.</p>
-<p>
-						
-</p>
+<table id="N10321">
+<tr>
+							
+<td>A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsSelBoundarySimple.png"></div>
-<p>
-					
-</p>
-<p>Each time we create a new selection, we define a new set of boundaries.</p>
-<p>
+							
+</td>
 						
-</p>
+</tr>
+</table>
+<table id="N10333">
+<tr>
+							
+<td>Each time we create a new selection, we define a new set of boundaries. In the diagram to the right, Selection 1 and Selection 2 eaach start with a new Select Action. </td>
+							<td>
+								
 <div class="mediaobject">
-<img src="images/actions/ActionsSelBoundary2Parts.png"></div>
-<p> 
-					
-</p>
-<p>A very important aspect of boundaries is that they apply to a group of actions that begin with a Query Action, and not just such a group that begins with a Select Action. This is because Query Actions can be directly part of a selection definition, but they can also refine selections, as we'll see. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:</p>
+<img src="images/actions/ActionsSelBoundary2Parts.png"></div> 
+							
+</td>
+						
+</tr>
+</table>
+<p>But boundaries can be defined for a group of actions by a Query Actions as well. This is because Query Actions can be directly part of a selection definition, but they can also refine selections. We'll see how that works below. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:</p>
 <div class="orderedlist">
 <ol class="orderedlist" type="1">
 <li class="listitem">
@@ -201,15 +224,19 @@
 </li>
 </ol>
 </div>
-<p>In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as we can see in the following example. </p>
-<p>
-						
-</p>
+<table id="N10350">
+<tr>
+							
+<td>In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as shown in the example to the right. </td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsSelBoundary11A.png"></div>
-<p>
-					
-</p>
+							
+</td>
+						
+</tr>
+</table>
 <p>Note that we refer to "Selection 1" and Selection 1A". This is because Selection 1A is a refinement of Selection 1 along its particular path of flow. When a query appears for the same selection but past a particular boundary, you can think of it as a sort of filter on the selection contents. We don't have a "Selection 2" here because any Actions that refer to "Selection 1" along the current path of flow will be acting on the selection defined by Selection 1 and Selection 1A.</p>
 <p>These rules allow actions to be defined in the simplest possible way, but it is important to understand their implication as they result in behavior that can be different from what someone used to and imperative programming environment such as Java might expect. In a simple case the distinction might not matter. For example, if we are using a Query 1 to test whether an agent's attribute a == x and attribute b == y, we would get the same outcome if we placed intersected the queries as if we simply put them in sequence. Internally we would actually be searching for agents with a == x, and 
 						<span class="italic">then</span> taking those agents and choosing those agents with b==y, but the outcome would be the same. But consider a more sophisticated case, where we are searching for neighboring available cells.
@@ -235,43 +262,58 @@
 </div>
 </div>
 </div>
-<p>Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.</p>
-<p>
-						
-</p>
+<table id="N1037B">
+<tr>
+							
+<td>Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsWeavingSetAnother.png"></div>
-<p>
-					
-</p>
-<p>Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)</p>
-<p>
+							
+</td>
 						
-</p>
+</tr>
+</table>
+<table id="N1038D">
+<tr>
+							
+<td>Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsWeavingEvaluate.png"></div>
-<p>
-					
-</p>
-<p>But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.</p>
-<p>
+							
+</td>
 						
-</p>
+</tr>
+</table>
+<table id="N1039F">
+<tr>
+							
+<td>But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsWeaving1A.png"></div>
-<p>
-					
-</p>
-<p>Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Now, consider the following example:</p>
-<p>
+							
+</td>
 						
-</p>
+</tr>
+</table>
+<table id="N103B1">
+<tr>
+							
+<td>Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Consider the example to the right. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.</td>
+							<td>
+								
 <div class="mediaobject">
 <img src="images/actions/ActionsWeaving2.png"></div>
-<p>
-					
-</p>
-<p>Before going into further details we need to introduce one more important concept. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.</p>
+							
+</td>
+						
+</tr>
+</table>
 </div>
 </div>
 <div class="section" title="Details">
@@ -283,16 +325,19 @@
 </div>
 </div>
 </div>
-<p>In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general.
-					Let's look at the overall view again amd then dig into the details.</p>
-<p>
-					
-</p>
+<table id="N103C7">
+<tr>
+						
+<td>In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general. Again, the block diagram to the right provides an overview of how the various actions are related. You might want to take a look at the meta-class diagrams in the referernce section as well.</td>
+						<td>
+							
 <div class="mediaobject">
-<img src="images/actions/ActionsBlocks.png"></div>
-<p> 
-				
-</p>
+<img src="images/actions/ActionsBlocks.png"></div> 
+						
+</td>
+					
+</tr>
+</table>
 <div class="section" title="Selections">
 <div class="titlepage">
 <div>
@@ -1266,12 +1311,24 @@
 								</p>
 </li>
 <li class="listitem">
-<p>The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context: <span style="color: red">&lt;pre&gt;(new org.me.SpecialFileLoader()).load(this);&lt;/pre&gt;</span>Then create a new source directory in your project called "src" (
-									<span class="bold"><strong>New &gt; Source Folder...</strong></span>) and create the class for the specialized file loader including the following method: <span style="color: red">&lt;pre&gt;public void load(MyRootModel model) {...}&lt;/pre&gt;</span> This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.
-								</p>
+<p>The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context:</p>
 </li>
 </ol>
 </div>
+<div class="literallayout">
+<p>(new&nbsp;org.me.SpecialFileLoader()).load(this);<br>
+
+</p>
+</div>
+<p>Then create a new source directory in your project called "src" (
+							<span class="bold"><strong>New &gt; Source Folder...</strong></span>) and create the class for the specialized file loader including the following method:
+						</p>
+<div class="literallayout">
+<p>public&nbsp;void&nbsp;load(MyRootModel&nbsp;model)&nbsp;{...}<br>
+
+</p>
+</div>
+<p>This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.</p>
 <div class="section" title="Selection">
 <div class="titlepage">
 <div>
@@ -1324,7 +1381,7 @@
 <div>
 <div>
 <h6 class="title">
-<a name="N105C3"></a>Input Literals</h6>
+<a name="N1062F"></a>Input Literals</h6>
 </div>
 </div>
 </div>
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Credits.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Credits.html
index 65dea5c..ac6515f 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Credits.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Credits.html
@@ -6,7 +6,7 @@
 <meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
 <link rel="home" href="index.html" title="Agent Modeling Guide">
 <link rel="up" href="Introduction.html" title="Introduction">
-<link rel="prev" href=".3DOther_Uses.html" title="=Other Uses">
+<link rel="prev" href="Other_Uses.html" title="Other Uses">
 <link rel="next" href="The_Agent_Modeling_Platform_.28AMP.29.html" title="The Agent Modeling Platform (AMP)">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Exploring.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Exploring.html
index 95420f4..ba419fe 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Exploring.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Exploring.html
@@ -29,31 +29,31 @@
 </div>
 </div>
 </div>
-<p>When an AMF file is selected -- in any of the perspectives -- the pop-up menu looks like this:</p>
-<p>
-					
-</p>
-<div class="mediaobject">
-<img src="images/tools/EditorMenu.png "></div>
-<p>
-				
-</p>
-<p>(In this case we've selected the "Execute Headless" option.) Note that the toolbar and Application menus are updated to reflect the file you've selected and can provide more convenient access to many of the functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. An important note: the execution framework doesn't know whether your code exists in an Escape project or anohter target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.</p>
-<p>
-					
-</p>
+<table id="N10CC3">
+<tr>
+						
+<td>Launching AMF and Escape models is easy. When an AMF file is selected -- in any of the perspectives -- the toolbar and Application menus are updated to reflect the file you've selected and provide convenient access to other functions. For example, when we click on a metaabm file in the package explorer, model execution buttons appear in the toolbar. If you right-click on a file a pop-up menu appears like the one to the far right -- in this case we're selecting the "Execute Headless" option. To launch a model, just select one of the options. (Note that the execution framework doesn't know whether your code exists in an Escape project or another target project. If you attempt to execute a .metaabm model in an Ascape project for example, you will get an error.)</td>
+						<td>
+							
 <div class="mediaobject">
 <img src="images/tools/EditorToolbar.png"></div>
-<p>
-				
-</p>
-<p>To launch a model, select one of the options.</p>
+						
+</td>
+						<td>
+							
+<div class="mediaobject">
+<img src="images/tools/EditorMenu.png"></div>
+						
+</td>
+					
+</tr>
+</table>
 <p>One a model has been launched, the Agent Execution Perspective automatically becomes active. The Provides a custom layout menus and tools specific to executing agent models.</p>
 <p>
 					
 </p>
 <div class="mediaobject">
-<img src="images/execution/EpidemicModelRunning.png"></div>
+<img src="images/execution/EpidemicExecNew.png"></div>
 <p>
 				
 </p>
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Introduction.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Introduction.html
index f0f3a9b..8052731 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Introduction.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Introduction.html
@@ -7,7 +7,7 @@
 <link rel="home" href="index.html" title="Agent Modeling Guide">
 <link rel="up" href="index.html" title="Agent Modeling Guide">
 <link rel="prev" href="index.html" title="Agent Modeling Guide">
-<link rel="next" href=".3DOther_Uses.html" title="=Other Uses">
+<link rel="next" href="Other_Uses.html" title="Other Uses">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
 <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Introduction</h1>
@@ -26,7 +26,7 @@
 <span class="section"><a href="Introduction.html#Agent-Based_Modeling">Agent-Based Modeling</a></span>
 </dt>
 <dt>
-<span class="section"><a href=".3DOther_Uses.html">=Other Uses</a></span>
+<span class="section"><a href="Other_Uses.html">Other Uses</a></span>
 </dt>
 <dt>
 <span class="section"><a href="Credits.html">Credits</a></span>
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Model_Implementation.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Model_Implementation.html
index 17f1bea..80ae722 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Model_Implementation.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Model_Implementation.html
@@ -150,7 +150,7 @@
 <div>
 <div>
 <h3 class="title">
-<a name="Structure_2"></a>Structure</h3>
+<a name="Structure_3"></a>Structure</h3>
 </div>
 </div>
 </div>
@@ -343,7 +343,7 @@
 <div>
 <div>
 <h3 class="title">
-<a name="Actions_3"></a>Actions</h3>
+<a name="Actions_4"></a>Actions</h3>
 </div>
 </div>
 </div>
@@ -583,12 +583,13 @@
 <div>
 <div>
 <h5 class="title">
-<a name="N10F52"></a>Create Select and Query Actions</h5>
+<a name="N10FD9"></a>Create Select and Query Actions</h5>
 </div>
 </div>
 </div>
 <p>The first part of the Bug Rule is exactly the same as the Initialize rule. Create a Selection Action. As before, we'll make the Select statement "Agent" property blank, as we want to move to a cell. As before, we want to make sure the Cell is free before we try to move in, so we'll select a "Spatial: Available" Query function.(By the way, to make scrolling through the list easier, you can type the first letters of the selection, in this case "SP".)</p>
-<p>But now, instead of moving <span style="color: red">&lt;i&gt;anywhere&lt;/i&gt;</span> we want to move nearby. So now, we create a 
+<p>But now, instead of moving 
+							<span class="italic">anywhere</span> we want to move nearby. So now, we create a 
 							<span class="italic">parallel</span> or "sibling" Query from the same Select root. Because this new Query Action is a child of the Select Action and not the "Space Available" Query we've just created, we'll right-click on the 
 							<span class="italic">Select</span> Action and choose 
 							<span class="bold"><strong>Create Target &gt; Select &gt; Query</strong></span>. Like so:
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Modeling.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Modeling.html
index de84f25..a519e08 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Modeling.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Modeling.html
@@ -188,7 +188,7 @@
 </div>
 </div>
 </div>
-<p>The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models incude textual languages and custom editors that are part of commercial offerings.</p>
+<p>The Eclipse Agent Modeling Framework includes a full-featured model editor based on the Eclipse Modeling Framework's Edit tools. All aspects of an AMF model can be managed from within this tool. Note that the tree editor is only one of many ways of editing a model. Other editors of AMF models include textual languages and custom editors that are part of commercial offerings.</p>
 <div class="section" title="Opening the Editor">
 <div class="titlepage">
 <div>
@@ -199,15 +199,15 @@
 </div>
 </div>
 <p>To open a model in the editor, simply double-click on it. If the model doesn't open in the model editor (if for example it had been previously opened using another editor), you can always access the editor using 
-						<span class="bold"><strong>Open With &gt; Other...</strong></span> and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll dicuss at the end of this section.
+						<span class="bold"><strong>Open With &gt; Other...</strong></span> and selecting "MetaABM Editor". The editor has two pages, an Editor page that we'll focus on first and a "description" page that we'll discuss at the end of this section.
 					</p>
 </div>
-<div class="section" title="Editing Structure">
+<div class="section" title="Structure">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
-<a name="Editing_Structure"></a>Editing Structure</h4>
+<a name="Structure_2"></a>Structure</h4>
 </div>
 </div>
 </div>
@@ -231,6 +231,25 @@
 						
 </p>
 </div>
+<div class="section" title="Creating Components">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Creating_Components"></a>Creating Components</h5>
+</div>
+</div>
+</div>
+<p>You add nodes by right-clicking on a node, like so:</p>
+<p>
+							
+</p>
+<div class="mediaobject">
+<img src="images/tools/EditorAdd.png"></div>
+<p>
+						
+</p>
+</div>
 <div class="section" title="Editing Components">
 <div class="titlepage">
 <div>
@@ -252,25 +271,6 @@
 						
 </p>
 </div>
-<div class="section" title="Adding Components">
-<div class="titlepage">
-<div>
-<div>
-<h5 class="title">
-<a name="Adding_Components"></a>Adding Components</h5>
-</div>
-</div>
-</div>
-<p>You add nodes by right-clicking on a node, like so:</p>
-<p>
-							
-</p>
-<div class="mediaobject">
-<img src="images/tools/EditorAdd.png"></div>
-<p>
-						
-</p>
-</div>
 <div class="section" title="Moving Components">
 <div class="titlepage">
 <div>
@@ -299,7 +299,7 @@
 </div>
 </div>
 </div>
-<p>You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entitiy still exist.</p>
+<p>You can remove actions by deleting or cutting them using the popup menu. When you delete an entity, all of its children are deleted as well, except in some special cases (such as with actions) where other paths to that entity still exist.</p>
 </div>
 <div class="section" title="Copying Components">
 <div class="titlepage">
@@ -351,17 +351,47 @@
 </p>
 </div>
 </div>
-<div class="section" title="Editing Actions">
+<div class="section" title="Actions">
 <div class="titlepage">
 <div>
 <div>
 <h4 class="title">
-<a name="Editing_Actions"></a>Editing Actions</h4>
+<a name="Actions_3"></a>Actions</h4>
 </div>
 </div>
 </div>
-<p>Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying strucuture of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.</p>
+<p>Actions are a key and relatively complex aspect of the model editor. Because actions are actually related in a graph structure, a tree-based editor will not be able to represent a the underlying structure of action relationships directly. (This is actually no different from most development environments -- for example, Java code is edited in a text based editor, but the call structure represents a complex graph. Advance tools developed by AMP contributors do support more sophisticated methods for action browsing and we'll have simple versions of them available in future releases of the AMF edit tools.) Therefore, it's helpful to take time to understand how action relationships appear in the editor.</p>
 <p>Like attributes and styles, every agent has a single Actions nodes which contains its Root Action(s).</p>
+<div class="section" title="Creating Actions">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Creating_Actions"></a>Creating Actions</h5>
+</div>
+</div>
+</div>
+<p>You create actions as with any other component, by right-clicking on the source action and choosing the new action. The menu is organized by usage.</p>
+<p>
+							
+</p>
+<div class="mediaobject">
+<img src="images/tools/EditorActionMenu.png"></div>
+<p>
+						
+</p>
+</div>
+<div class="section" title="Editing Actions">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Editing_Actions"></a>Editing Actions</h5>
+</div>
+</div>
+</div>
+<p>Actions and their inputs are edited just like any other model component. Click on the action or input you want to edit and then make changes to it in the properties editor.</p>
+</div>
 <div class="section" title="Order">
 <div class="titlepage">
 <div>
@@ -372,7 +402,7 @@
 </div>
 </div>
 <p>Generally, action sources will appear above their targets. In the case where there is only one source for a given target, and that target has no other sources, they will appear directly above one another. Its important to note however that 
-							<span class="italic">the order of the nodes does not indicate a specific source and target relationship</span>. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part .
+							<span class="italic">the order of the nodes does not indicate a specific source and target relationship</span>. For example, in the case where there are multiple targets for a source, they will typically follow that source immediately. To make the relationships clear, every action lists its source actions as part of the action label. Agent selections also appear as part of the label.
 						</p>
 <p>
 							
@@ -437,7 +467,7 @@
 </div>
 </div>
 </div>
-<p>You can remove actions in the same way as with strucutral model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from igh in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.</p>
+<p>You can remove actions in the same way as with structural model components. Note that just as when you delete an agent, all of that agent's attributes, actions and styles are also deleted form the model, when you delete an Action, any of its targets will also be removed, unless there is some other source action path that connects it to the root action. And of course, any targets of such targets will be affected in the same way and so on. If you remove a node from high in the action tree a lot of nodes could disappear at once! If you have actions that you want to retain as part of the flow, you should first make them targets of a new action before deleting their parent action.</p>
 </div>
 <div class="section" title="Copying Actions">
 <div class="titlepage">
@@ -464,7 +494,7 @@
 							
 </p>
 <div class="mediaobject">
-<img src="images/tools/ActionsExample.png"></div>
+<img src="images/tools/Inputs.png"></div>
 <p>
 						
 </p>
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Other_Uses.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Other_Uses.html
new file mode 100644
index 0000000..0f55f11
--- /dev/null
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Other_Uses.html
@@ -0,0 +1,26 @@
+<html>
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Other Uses</title>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Agent Modeling Guide">
+<link rel="up" href="Introduction.html" title="Introduction">
+<link rel="prev" href="Introduction.html" title="Introduction">
+<link rel="next" href="Credits.html" title="Credits">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Other Uses</h1>
+<div class="section" title="Other Uses">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Other_Uses"></a>Other Uses</h2>
+</div>
+</div>
+</div>
+<p>Many kinds of objects share characteristics of ABM agents -- after all, software agents are used in many other contexts. The Agent Modeling Framework meta-modeling support is potentially suitable (or extendible) for a number of approaches outside of ABM; for example business rules, object interactions, systems dynamics models and traditional discrete event models. Similarly, AMP execution and graphic support can be used for modeling natural systems but could also be used to manage other software agents -- for example independent reasoning tasks or dynamic visualization support.</p>
+</div>
+</body>
+</html>
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Resources.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Resources.html
index 53a7150..c7087a4 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Resources.html
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/Resources.html
@@ -50,7 +50,7 @@
 <div>
 <div>
 <h4 class="title">
-<a name="N11126"></a>Import from CVS</h4>
+<a name="N111AE"></a>Import from CVS</h4>
 </div>
 </div>
 </div>
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/actions/ActionsSelBoundarySimple.png b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/actions/ActionsSelBoundarySimple.png
index 72a1288..bafb515 100644
--- a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/actions/ActionsSelBoundarySimple.png
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/actions/ActionsSelBoundarySimple.png
Binary files differ
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/execution/EpidemicExecNew.png b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/execution/EpidemicExecNew.png
new file mode 100644
index 0000000..0dc133e
--- /dev/null
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/execution/EpidemicExecNew.png
Binary files differ
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/tools/EditorActionMenu.png b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/tools/EditorActionMenu.png
new file mode 100644
index 0000000..ab3b231
--- /dev/null
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/help/images/tools/EditorActionMenu.png
Binary files differ
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/html/Introduction.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/html/Introduction.html
new file mode 100644
index 0000000..73553f2
--- /dev/null
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/html/Introduction.html
@@ -0,0 +1,338 @@
+<html>
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter&nbsp;1.&nbsp;Introduction</title>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Agent Modeling Guide">
+<link rel="up" href="index.html" title="Agent Modeling Guide">
+<link rel="prev" href="index.html" title="Agent Modeling Guide">
+<link rel="next" href="Modeler_Guide.html" title="Chapter&nbsp;2.&nbsp;Modeler Guide">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table summary="Navigation header" width="100%">
+<tr>
+<th align="center" colspan="3">Chapter&nbsp;1.&nbsp;Introduction</th>
+</tr>
+<tr>
+<td align="left" width="20%"><a accesskey="p" href="index.html">Prev</a>&nbsp;</td><th align="center" width="60%">&nbsp;</th><td align="right" width="20%">&nbsp;<a accesskey="n" href="Modeler_Guide.html">Next</a></td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" title="Chapter&nbsp;1.&nbsp;Introduction">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title">
+<a name="Introduction"></a>Chapter&nbsp;1.&nbsp;Introduction</h2>
+</div>
+</div>
+</div>
+<div class="toc">
+<dl>
+<dt>
+<span class="section"><a href="Introduction.html#Agent-Based_Modeling">Agent-Based Modeling</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#Other_Uses">Other Uses</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#Credits">Credits</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#The_Agent_Modeling_Platform_.28AMP.29">The Agent Modeling Platform (AMP)</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Introduction.html#Agent_Modeling_Framework_.28AMF.29">Agent Modeling Framework (AMF)</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#Agent_Execution_Framework_.28AXF.29">Agent Execution Framework (AXF)</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#Agent_Graphics_Framework_.28AGF.29">Agent Graphics Framework (AGF)</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#Escape">Escape</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Introduction.html#Getting_Started">Getting Started</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Introduction.html#Setting_up_Eclipse">Setting up Eclipse</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#Get_the_Example_Projects">Get the Example Projects</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#ABM_Researchers">ABM Researchers</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#ABM_Modelers">ABM Modelers</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#ABM_Java_Developers">ABM Java Developers</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Introduction.html#Eclipse_Plugin_Developers">Eclipse Plugin Developers</a></span>
+</dt>
+</dl>
+</dd>
+</dl>
+</div>
+<p>In this manual we provide an in-depth understanding of what goes into an Agent Model, how you can use the Agent Modeling Framework and related tools to design one and present tutorials to get you started. But before going into details, let's take a quick overview at what agent-based modeling is is and how the Agent Modeling Framework can help you to develop models for ABM or other problem domains.</p>
+<p>We hope you enjoy using the tool, and we look forward to your comments and feedback and most of all participation!</p>
+<div class="section" title="Agent-Based Modeling">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Agent-Based_Modeling"></a>Agent-Based Modeling</h2>
+</div>
+</div>
+</div>
+<p>The primary focus of the Agent Modeling Platform tools is "Agent-Based Modeling" (ABM). ABM is an innovative technique used to explore complex phenomenon in many domains, including economics, social sciences, biomedicine, ecology and business operations. ABMs share characteristics with object models, but are:</p>
+<div class="variablelist">
+<dl>
+<dt>
+<span class="term">Spatial</span>
+</dt>
+<dd>
+<p>Models have explicit environment(s) in which agents interact. (An environment need not be a physical landscape; other examples of spatial relationships include social networks or positions within a logic system.)</p>
+</dd>
+<dt>
+<span class="term">Temporal</span>
+</dt>
+<dd>
+<p>Models change over discrete units of time.</p>
+</dd>
+<dt>
+<span class="term">Autonomous</span>
+</dt>
+<dd>
+<p>Agent behaviors are activated independently from other object requests.</p>
+</dd>
+<dt>
+<span class="term">Heterogeneous</span>
+</dt>
+<dd>
+<p>Agents may share behavior definitions but have apparent and distinct states and behaviors.</p>
+</dd>
+<dt>
+<span class="term">Collective</span>
+</dt>
+<dd>
+<p>Models contain large communities of agents which exhibit collaborative and competitive behaviors.</p>
+</dd>
+<dt>
+<span class="term">Emergent</span>
+</dt>
+<dd>
+<p>Agents have collective macro-behaviors that are non-obvious from agent micro-specifications.</p>
+</dd>
+</dl>
+</div>
+<p>Existing scientific models are very good at representing relatively simple systems, but generally speaking aren't very good at representing complex systems. The world is full of complex systems, and our misunderstanding of these systems has prevented us from addressing many of the key challenges facing the world, including the global financial crisis and climate change -- in fact once could argue that our misunderstanding of these systems has strongly contributed to these crises.</p>
+<p>Agent-Based Models (ABMs) seek to represent important real-world dynamics by designing communities of software agents that mimic real entities. Rather than make simplifying assumptions about such systems and then representing them in equation form or as off the shelf algorithmic constructs, the ABM researcher aims to identify key agent state, interaction spaces, and behaviors. Agents are then "let loose" on our computers and we explore what happens next. The computational horsepower exists today to simulate large numbers (e.g. &gt;&gt;10) of interacting, adaptive and autonomous agents but often desktop computers are all we need to explore significant domains. ABMs have been designed to represent all kinds of important natural systems, at scales reaching from cellular mechanics to international trade and are being used to solve truly hard problems in government, business, and academia. ABMs are not a solution to every problem, but they can help us to appreciate and gain unique insight into many systems, and often they can help us to come up with better practical decisions than we might using classic approaches.</p>
+</div>
+<div class="section" title="Other Uses">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Other_Uses"></a>Other Uses</h2>
+</div>
+</div>
+</div>
+<p>Many kinds of objects share characteristics of ABM agents -- after all, software agents are used in many other contexts. The Agent Modeling Framework meta-modeling support is potentially suitable (or extendible) for a number of approaches outside of ABM; for example business rules, object interactions, systems dynamics models and traditional discrete event models. Similarly, AMP execution and graphic support can be used for modeling natural systems but could also be used to manage other software agents -- for example independent reasoning tasks or dynamic visualization support.</p>
+</div>
+<div class="section" title="Credits">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Credits"></a>Credits</h2>
+</div>
+</div>
+</div>
+<p>Miles Parker is a consultant and software developer with over ten years of experience in the agent-based modeling field and twenty years developing object-oriented tools and frameworks and is the architect and project lead for the Eclipse Agent Modeling Platform (Incubation).</p>
+<p>Metascape, LLC is the primary contributor to AMP and provides Agent-Based Modeling tools, including sophisticated tools based on the AMF platform, and comprehensive consulting services. For more information on Metascape products and services visit 
+				<a class="ulink" href="http://metascapeabm.com" target="_new">http://metascapeabm.com</a>.
+			</p>
+<p>The AMF meta-model started life as 
+				<a class="ulink" href="/wiki/http://www.agent2005.anl.gov/2006procpdf/Parker_Agent_2006.pdf" target="_new">"score"</a>, a component of the Repast Simphony environment. Argonne National Labs supported the initial development in 2007 and agreed to contribute the relevant IP to the Eclipse project in 2009. It wasn't fully utilized within Simphony, and migrated from there to the MetaABM project supported by Metascape. The MetaABM project defined a complete editor, code-generation and model execution suite that formed the initial AMP AMF contribution. Metascape has sponsored the development of AMF from 2007 through the present.
+			</p>
+<p>The AMP logo was inspired by the 
+				<a class="ulink" href="/wiki/http://swarm.org_Swarm_logo" target="_new">http://swarm.org Swarm logo</a> with their kind permission.
+			</p>
+</div>
+<div class="section" title="The Agent Modeling Platform (AMP)">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="The_Agent_Modeling_Platform_.28AMP.29"></a>The Agent Modeling Platform (AMP)</h2>
+</div>
+</div>
+</div>
+<p>The Eclipse Agent Modeling Project (Incubation) or "AMP" provides extensible frameworks and exemplary tools for representing, editing, generating,
+				executing and visualizing agent-based models (ABMs) and any other domain requiring spatial, behavioral and functional features. AMP has two main themes that complement but don't depend on one another, modeling of agent systems (AMF) and execution and exploration of those systems (AXF, AGF and Escape).</p>
+<p>The overall AMP architecture and project dependencies are summarized in the architectural diagram below:</p>
+<p>
+				
+</p>
+<div class="mediaobject">
+<img src="images/AMPArchitectureDiagram.jpg"></div>
+<p>
+			
+</p>
+<div class="section" title="Agent Modeling Framework (AMF)">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Agent_Modeling_Framework_.28AMF.29"></a>Agent Modeling Framework (AMF)</h3>
+</div>
+</div>
+</div>
+<p>AMF provides an ABM meta-model representation, editor, generator and development environment. The AMF Acore meta-model is similar to EMF Ecore and defined in Ecore, but provides high-level support for complex agents.AMF generates complete executable models for Escape, Ascape and Repast Simphony, as well as Java Skeletons and Interfaces, JUnit test cases and documentation and is easily extensible to support additional targets. For more on AMF, see the Modeler Guide.</p>
+</div>
+<div class="section" title="Agent Execution Framework (AXF)">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Agent_Execution_Framework_.28AXF.29"></a>Agent Execution Framework (AXF)</h3>
+</div>
+</div>
+</div>
+<p>The execution framework provides services and UI for model management, execution, and views. Arbitrary toolkits can easily integrate with Eclipse and AXF by implementing pluggable providers like engines, agents and view parts. AXF is not just for ABM -- anyone who needs support for executing, managing and visualizing collections of objects may find it useful. AXF user tools are covered extensively in the User Guide, and the forthcoming Platform Developers Guide will provide information about integrating AXF in your own tools.</p>
+</div>
+<div class="section" title="Agent Graphics Framework (AGF)">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Agent_Graphics_Framework_.28AGF.29"></a>Agent Graphics Framework (AGF)</h3>
+</div>
+</div>
+</div>
+<p>The graphics framework extends GEF, GEF3D, Zest, and the BIRT charting engine to support real-time visualization of and interaction with agent models. AGF currently provides support for 2D, 2 1/2 D. and graph structures, and will be extended to 3-D, GIS and others. As with other AMP components, the AGF design focus is to provide an extensible infrastructure so that platform adopters can easily create their own view and editor parts. AGF user tools are covered extensively in the User Guide, and the forthcoming Platform Developers Guide will provide information about integrating and extending AGF in your own tools.</p>
+</div>
+<div class="section" title="Escape">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Escape"></a>Escape</h3>
+</div>
+</div>
+</div>
+<p>Escape is an exemplar ABM toolset. It's based on Ascape, which has been in use for more than 10 years. The core API is very stable, and that should give users a way to explore the features of AMP without concerns about keeping in synch with the rapidly evolving AXF /AGF API. It allows modelers to code in Java and/or generate models with AMF and then execute those models within the same development environment. Escape is the primary target for most of the models in this guide. Those users interested in writing code directly to the Escape API can refer to the Programmer Guide.</p>
+</div>
+</div>
+<div class="section" title="Getting Started">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Getting_Started"></a>Getting Started</h2>
+</div>
+</div>
+</div>
+<p>AMP has many potential facets and use cases.</p>
+<div class="section" title="Setting up Eclipse">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Setting_up_Eclipse"></a>Setting up Eclipse</h3>
+</div>
+</div>
+</div>
+<p>If you're reading this from the Eclipse help browser, you've already done this! Otherwise, if you aren't using a full download version of AMP, you'll need to 
+					<a class="ulink" href="http://eclipse.org/amp/installing/" target="_new">install it</a>. Once you've done that, select the 
+					<span class="bold"><strong>Help &gt; Help Contents</strong></span> menu, find the Agent Modeling Guide and open this overview page within that guide.
+				</p>
+<p>Some installations will also include a Welcome screen which will guide you through the same set of steps.</p>
+</div>
+<div class="section" title="Get the Example Projects">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Get_the_Example_Projects"></a>Get the Example Projects</h3>
+</div>
+</div>
+</div>
+<p>You can do that using a cheat sheet. Select 
+					<span class="bold"><strong>Help &gt; Cheat Sheets...</strong></span> and then under the "Agent Modeling" category, select "Load Sample Projects".
+				</p>
+<p>Then check out the following sections of the manual for more information about..</p>
+</div>
+<div class="section" title="ABM Researchers">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="ABM_Researchers"></a>ABM Researchers</h3>
+</div>
+</div>
+</div>
+<p>Run an example model using the "Run an Example Model" cheat sheet.</p>
+</div>
+<div class="section" title="ABM Modelers">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="ABM_Modelers"></a>ABM Modelers</h3>
+</div>
+</div>
+</div>
+<p>Create Agent-Based models using simple visual tools and deploy them to a number of popular ABM platforms, including Escape. Follow the tutorial section of the Modeler's guide.</p>
+</div>
+<div class="section" title="ABM Java Developers">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="ABM_Java_Developers"></a>ABM Java Developers</h3>
+</div>
+</div>
+</div>
+<p>Write "Plain Old Java" models within a full-featured agent-based modeling framework. Read Programmers Guide and then try the "Create an Escape Java Model" cheat sheet.</p>
+</div>
+<div class="section" title="Eclipse Plugin Developers">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Eclipse_Plugin_Developers"></a>Eclipse Plugin Developers</h3>
+</div>
+</div>
+</div>
+<p>AXF and AGF provide a number of features based around Eclipse technologies such as GEF, GEF3D, BIRT Charts and Zest. For example, AGF supports dynamic visualization of objects in space, and AXF supports managed UI and headless execution for models of any kind. There isn't currently any general documentation for these features, but we encourage you to look at the APIs and at Escape's implementation of them. They're straightforward and can be useful for a variety of general science platform needs.</p>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table summary="Navigation footer" width="100%">
+<tr>
+<td align="left" width="40%"><a accesskey="p" href="index.html">Prev</a>&nbsp;</td><td align="center" width="20%">&nbsp;</td><td align="right" width="40%">&nbsp;<a accesskey="n" href="Modeler_Guide.html">Next</a></td>
+</tr>
+<tr>
+<td valign="top" align="left" width="40%">Agent Modeling Guide&nbsp;</td><td align="center" width="20%"><a accesskey="h" href="index.html">Home</a></td><td valign="top" align="right" width="40%">&nbsp;Chapter&nbsp;2.&nbsp;Modeler Guide</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/org.eclipse.amp/doc/org.eclipse.amp.doc/html/Modeler_Guide.html b/org.eclipse.amp/doc/org.eclipse.amp.doc/html/Modeler_Guide.html
new file mode 100644
index 0000000..ef6b528
--- /dev/null
+++ b/org.eclipse.amp/doc/org.eclipse.amp.doc/html/Modeler_Guide.html
@@ -0,0 +1,4132 @@
+<html>
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter&nbsp;2.&nbsp;Modeler Guide</title>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Agent Modeling Guide">
+<link rel="up" href="index.html" title="Agent Modeling Guide">
+<link rel="prev" href="Introduction.html" title="Chapter&nbsp;1.&nbsp;Introduction">
+<link rel="next" href="User_Guide.html" title="Chapter&nbsp;3.&nbsp;User Guide">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table summary="Navigation header" width="100%">
+<tr>
+<th align="center" colspan="3">Chapter&nbsp;2.&nbsp;Modeler Guide</th>
+</tr>
+<tr>
+<td align="left" width="20%"><a accesskey="p" href="Introduction.html">Prev</a>&nbsp;</td><th align="center" width="60%">&nbsp;</th><td align="right" width="20%">&nbsp;<a accesskey="n" href="User_Guide.html">Next</a></td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" title="Chapter&nbsp;2.&nbsp;Modeler Guide">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title">
+<a name="Modeler_Guide"></a>Chapter&nbsp;2.&nbsp;Modeler Guide</h2>
+</div>
+</div>
+</div>
+<div class="toc">
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Overview">Overview</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Agent_Modeling_Framework">Agent Modeling Framework</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Structure">Structure</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Overview_2">Overview</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Details">Details</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#General">General</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Agents">Agents</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Attributes_2">Attributes</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Spaces_2">Spaces</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Reference">Reference</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Diagrams">Diagrams</a></span>
+</dt>
+</dl>
+</dd>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Actions_2">Actions</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Overview_3">Overview</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Concepts">Concepts</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Kinds_of_Actions">Kinds of Actions</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Flow">Flow</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Selections">Selections</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Weaving">Weaving</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Details_3">Details</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Selections_2">Selections</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Roots">Roots</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Builders">Builders</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Commands">Commands</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Other">Other</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Query_and_Evaluation_Inputs">Query and Evaluation Inputs</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Example">Example</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Reference_2">Reference</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Diagrams_2">Diagrams</a></span>
+</dt>
+</dl>
+</dd>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Functions">Functions</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Overview_4">Overview</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Details_5">Details</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#General_Functions">General Functions</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Random">Random</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Space_3">Space</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Time">Time</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Graphics">Graphics</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Lists">Lists</a></span>
+</dt>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Attribute_Distributions">Attribute Distributions</a></span>
+</dt>
+</dl>
+</dd>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Reference_3">Reference</a></span>
+</dt>
+<dd>
+<dl>
+<dt>
+<span class="section"><a href="Modeler_Guide.html#Diagrams_3">Diagrams</a></span>
+</dt>
+</dl>
+</dd>
+</dl>
+</dd>
+</dl>
+</div>
+<div class="section" title="Overview">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Overview"></a>Overview</h2>
+</div>
+</div>
+</div>
+<p>In this section we present the design of the Agent Modeling Framework and explain how it can be used to create models that are transparent, composable and adaptable. Fundamentally, an agent-based model, or "ABM", is composed of five pieces: Agents and Context Agents, Attributes, Spaces, and Actions. The first three refer to structural components, whereas Actions define behavior. Agent models also have styles, which are a special kind of Action used to determine how to portray an agent in a visualization. Finally Actions make use of Functions. We'll describe of these components in a separate section.</p>
+<div class="section" title="Agent Modeling Framework">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Agent_Modeling_Framework"></a>Agent Modeling Framework</h3>
+</div>
+</div>
+</div>
+<p>The Eclipse Platform provides many unique features that make it ideal for an ABM platform. AMF provides easy to use and powerful tools and techniques for designing Agent-Based Models, including a common representation, editors, generators and development environment.</p>
+<p>The Agent Modeling Framework (AMF) provides high level representations for common ABM constructs, and introduces novel ways of representing agents and their behaviors. As detailed in other documentation sections, the Agent Modeling Framework and related tools have been designed to allow researchers to explore complex models in an intuitive way. One of our major design goals has been to create tools that non-programmers can use to create sophisticated models. It has been our experience that using Model-Driven Software Development (MDSD) techniques increase productivity for all developers regardless of skill level. </p>
+<p>The foundation of the Agent Modeling Framework is "Acore". The current version uses an interim version of Acore called "MetaABM". We refer to the AMF models as "meta-models" because they are used to define 
+					<span class="italic">how</span> Agent-Based Models are themselves modeled. For those familiar with Eclipse Model-Driven Development tools, AMF is analogous to EMF but is targeted toward the design and execution of models composed of agents. Acore and MetaABM are defined in Ecore but provide a more direct and high-level ABM representation of agents, including spatial, behavioral and functional features sufficient to generate complete executable models for the target platforms. AMF is fully integrated with the Eclipse IDE platform, but Acore models themselves need have no dependencies on any particular technology beyond XML/XSD.
+				</p>
+<p>Models designed in AMF are transparently converted to Java code for leading Agent-Based Modeling tools, such as the Escape tools which are included in AMP and allow direct execution of models within the AMP environment, and Repast Simphony, another popular Java based ABM tool. These tools create Java code that can then be compiled, executed and event modified in these environments just as with any other Java program. AMF's generative capability is designed to be pluggable and modular so that other developers can create AMF generators for their own tools. In fact, targets can be designed that have no inherent dependencies on Eclipse or even on a traditional platform.</p>
+<p>The Acore / MetaABM meta-model is made up of three main packages. This is all based on MetaABM, and while names and important details will change for Acore, the core design should be quite similar.</p>
+</div>
+</div>
+<div class="section" title="Structure">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Structure"></a>Structure</h2>
+</div>
+</div>
+</div>
+<div class="section" title="Overview">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Overview_2"></a>Overview</h3>
+</div>
+</div>
+</div>
+<p>The basic structure of an agent-based model can be quite simple. While there are many subtle complexities  -- beyond the scope of this manual -- we can construct most models following some straightforward and elegant design principles. And in fact, one of the main goals of the Agent Modeling Framework is to provide a consistent framework that can support using those principles to support the creation of models that can be easily understood, shared, and that can be used interchangeably as components in other models.</p>
+<p>Unlike the approach of a traditional Object Oriented environment, the dominant organizing principal for agents within AMF follows a compositional hierarchical model, not an inheritance model. (Inheritance-like behavior will be supported in forthcoming versions of Acore, but in a more sophisticated, flexible and dynamic way than is supported by traditional programming languages such as Java.) Contexts -- also referred to as "Swarms" or "Scapes", are simply Agents that are capable of containing other agents. With this basic construct -- known as a Composition in design pattern language -- agents are able to contain other agents.</p>
+</div>
+<div class="section" title="Details">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Details"></a>Details</h3>
+</div>
+</div>
+</div>
+<div class="section" title="General">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="General"></a>General</h4>
+</div>
+</div>
+</div>
+<p>Everything represented in an Acore model needs to be referred to in some way. Just as software classes have names, Acore provides a way to label and describe every entity, but in a richer and more maintainable way. All entities in Acore -- including Actions and Functions which we describe in the next two sections -- have a number of shared values.</p>
+<div class="section" title="Named Entities">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Named_Entities"></a>Named Entities</h5>
+</div>
+</div>
+</div>
+<div class="section" title="Label">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Label"></a>Label</h6>
+</div>
+</div>
+</div>
+<p>A reasonably short, human readable name for the agent. For example, "Timber Wolf", "Exchange Trader" or "Movement Probability". These should be defined so that they fit in well with auto-generated documentation. Note that Labels must be unique throughout the model. (This may change in future releases for Action names.) If you try to provide an object with a name that is already in use, "Copy" will be appended to the end of the name. </p>
+</div>
+<div class="section" title="ID">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="ID"></a>ID</h6>
+</div>
+</div>
+</div>
+<p>An ID is an identifier that can be used to represent the object in a software program. This means that it must follow certain rules such as no-spaces or non alpha-numeric characters. The editing tools will help make sure that this value is legal. Note that when you enter a label, a legal ID is automatically created for you! Usually you won't need to change this, but you might if for example you want the value to match up with some database or other external representation. So reasonable values here might be "timberWolf" or perhaps "MVMNT_PRB" if say you're trying to match up to some old statistics records you have. (Note that currently IDs by default use "camel case", i.e. "thisIsAnExampleOfCamelCase" to match with Java variable naming conventions, but this is likely to change.) Like labels, IDs need to be unique across the model, and the editing tools will assign a different id if you attempt to give two entities the same id.</p>
+<p>And most entities also define:</p>
+</div>
+<div class="section" title="Description">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Description"></a>Description</h6>
+</div>
+</div>
+</div>
+<p>A complete textual description of the object. Don't overlook this -- it is the most important part of your model. The description will show up in your auto-generated html documentation, software documentation and even in your running model. You should include enough information that model users will understand what the entity is for and what it does without referring elsewhere. This is also where any attributions and references should go. You can put html tags in here -- such as href's to external papers, but keep those to a minimum as they won't be rendered as html in all contexts.</p>
+</div>
+<div class="section" title="Plural Label">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Plural_Label"></a>Plural Label</h6>
+</div>
+</div>
+</div>
+<p>The plural representation of an entity. This can be a surprisingly useful thing to have in generated documentation and software code, so it's worth maintaining. The editor will automatically add an "s" at the end of the label you've entered above, but you change it to whatever is appropriate. For example "Person", or "Timber Wolves".</p>
+</div>
+</div>
+</div>
+<div class="section" title="Agents">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Agents"></a>Agents</h4>
+</div>
+</div>
+</div>
+<div class="section" title="Simple Agents">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Simple_Agents"></a>Simple Agents</h5>
+</div>
+</div>
+</div>
+<p>An Agent is simply a software object that has autonomous behavior and (generally speaking) exists within some set of spaces. By autonomous, we mean that agents make the choice about when and how to execute a behavior, as opposed to have that controlled from "above", so to speak. Like any software objects, agents have attributes (fields) and actions (methods) associated with them.</p>
+<div class="section" title="Attributes">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Attributes"></a>Attributes</h6>
+</div>
+</div>
+</div>
+<p>As described in the attribute sections above.</p>
+</div>
+<div class="section" title="Actions">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Actions"></a>Actions</h6>
+</div>
+</div>
+</div>
+<p>Described in the "Actions" section.</p>
+</div>
+<div class="section" title="Styles">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Styles"></a>Styles</h6>
+</div>
+</div>
+</div>
+<p>Special actions that are used to define how to draw an agent graphically as also described in the "Actions" section and detailed in the "Functions" section.</p>
+</div>
+</div>
+<div class="section" title="Context Agents (Contexts)">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Context_Agents_.28Contexts.29"></a>Context Agents (Contexts)</h5>
+</div>
+</div>
+</div>
+<p>As detailed above, agents also form the basic structural component of an agent-based model. To get an idea for how this works, have a look at the "EpidemicRegional.metaabm" model. Note that in future releases, we will probably refer to Contexts as "Scapes".</p>
+<div class="section" title="Agents">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Agents_2"></a>Agents</h6>
+</div>
+</div>
+</div>
+<p>The agents that are contained within this context. For example, a context representing a city might contain an Individual Agent for defining all individuals in the model, and a Vehicle agent defining all vehicles. Note that when we refer to an agent in this context, we mean a general type or class of agent, not the agent itself.</p>
+</div>
+<div class="section" title="Spaces">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Spaces"></a>Spaces</h6>
+</div>
+</div>
+</div>
+<p>The set of all spaces contained or subsumed by the agent. For example, a context representing a city might contain a geographical space and a transportation network space.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Attributes">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Attributes_2"></a>Attributes</h4>
+</div>
+</div>
+</div>
+<p>Agents need some way to represent their internal state. For example, an agent in an economic model might have a wealth attribute, and an agent in an ecology model might have a quantity of food and a particular vision range. These states are represented as attributes just as all software objects do. In an agent model, we keep richer information about these attributes and generally represent them at a higher level. For example, rather than specify that a real value is a "double", a "float" or a "big number", we represent them as "Reals" so that they can be implemented and tested in different environments. This might allow us for instance to ensure that a model's behavior is not dependent on a particular machine implementation of floating point arithmetic. Also, note that attributes only represent so-called "primitive" values -- that is, actual measurable features of a particular agent but not an agent's relationship to other agents or objects. See the discussion about networks for more on this key topic.</p>
+<p>Here are the basic types of attributes available in Acore models:</p>
+<div class="section" title="Basic Attributes">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Basic_Attributes"></a>Basic Attributes</h5>
+</div>
+</div>
+</div>
+<p>Attributes are single values that a given agent contains. For example, an agent might have an "Age" attribute. In this section we go over the values you can set for the attributes. For those with a tecnical bent, note that we are technically describing the meta-attributes for the meta-class "SAttribute". But it is far too confusing to refer to the attributes of attributes! So we'll just refer to the attributes that any of our model components as "values".</p>
+<div class="section" title="Type">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Type"></a>Type</h6>
+</div>
+</div>
+</div>
+<p>These can be anyone of the following: </p>
+<table id="N1014D">
+<tr>
+									
+<td>Boolean</td>
+									<td>A value that is simply true or false. Note that unless this value really is a simple binary value, you should consider using state instead. (See details below.) For example, rather than representing gender as a 'Female' boolean value, define a 'Gender' state with values 'Male' and "Female'. Generated artifacts and documentation will be much clearer, and you'll be able to easily modify the model later if for example you discover that there are more than two potential gender categories that are relevant to your model.</td>
+								
+</tr>
+<tr>
+									
+<td>Integer</td>
+									<td>A discrete whole number value, such as "100", "-1", "10029920". It's generally a good idea to represent any value that can never have a decimal value as an integer.</td>
+								
+</tr>
+<tr>
+									
+<td>Real</td>
+									<td>A continuous number value. While these are typically represented in software as floating point numbers, they can conceivably represent numbers at any arbitrary precision and in any scheme. Note that while technically speaking we should be representing irrational numbers, this is not currently supported for default values and users should simply use the closest decimal approximation.</td>
+								
+</tr>
+<tr>
+									
+<td>Symbol</td>
+									<td>A string representing some state. More precisely, a computationally arbitrary value with contextual meaning. This could be any kind of identifier. For example, you might use it to store some kind of input coding from data that is then converted into an object state. Or it could simply be an agent's name. But theoretically (though this is not currently supported) one could imagine a symbol using an idiogram, an icon or even a sound that identifies or represents the agent in question.</td>
+								
+</tr>
+</table>
+<p>(Undefined and Numeric types should not be used within a well-defined model.)</p>
+</div>
+<div class="section" title="Default Value">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Default_Value"></a>Default Value</h6>
+</div>
+</div>
+</div>
+<p>The value that should be assigned to the attribute at the beginning of any model run. The attribute may of course be assigned a different value in an Initialize rule, but its a good idea to specify one here. It's OK to leave it blank, in which case a sensible 'empty' value will be assigned, i.e. false for Boolean, 0 for Integers and Reals, and an empty string for Symbol.</p>
+</div>
+<div class="section" title="Gather Data">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Gather_Data"></a>Gather Data</h6>
+</div>
+</div>
+</div>
+<p>Here you can specify whether executing models should collect aggregate values for the data. For example, if you select this value as true for a 'Wealth' attribute, Escape will automatically keep track of minimum, maximum, average, sum and optionally standard deviation and variance across all agents for each model execution period. All of these statistics will then be selectable with a mouse click to appear in your model charts at runtime.</p>
+</div>
+<div class="section" title="Immutable">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Immutable"></a>Immutable</h6>
+</div>
+</div>
+</div>
+<p>This value indicates whether you expect the model value to change. If you know that it won't or shouldn't, this value should be true.</p>
+</div>
+<div class="section" title="Units">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Units"></a>Units</h6>
+</div>
+</div>
+</div>
+<p>Specifies what the attribute is actually measuring. For example, if you're defining an attribute for "Wealth" in the context of a model of the world economy, you might specify "USD". If you're defining "Age", you might specify "Years", for "Mass" "Kg". Like description, this value is often overlooked, but can be critically important to allowing yourself and others to understand and correctly calibrate a model. Note that this will also allow you to simplify variable names -- instead of using "Age in Years", you can simply specify "Age" and the appropriate unit. It may be obvious to you that your model is concerned with age in years, but a user who needs to specify a different granularity will be grateful for more clarity.</p>
+</div>
+</div>
+<div class="section" title="Arrays">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Arrays"></a>Arrays</h5>
+</div>
+</div>
+</div>
+<p>Arrays are simply attributes with zero or more entries. For example, you might have an array of three Real numbers representing the Red Green and Blue color components for an object. Note that if you find yourself defining very complex sets of arrays, its likely that what you really want to define is a new agent with attributes for each array. In addition to what is defined above, arrays specify:</p>
+<div class="section" title="Size">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Size"></a>Size</h6>
+</div>
+</div>
+</div>
+<p>The number of values that the array attribute will contain.</p>
+</div>
+</div>
+<div class="section" title="States">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="States"></a>States</h5>
+</div>
+</div>
+</div>
+<p>States represent any agent quality that may take on one of a number of well defined values. For example, an "Ice Cream Consumer" Agent might contain a state of "Ice Cream Preference" with options of "Chocolate", "Vanilla" and "Ginger".</p>
+<div class="section" title="State Options">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="State_Options"></a>State Options</h6>
+</div>
+</div>
+</div>
+<p>Create new options for states by adding them to the state node. States are simple described items. Don't forget to provide a description! States also have</p>
+</div>
+<div class="section" title="Default Option">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Default_Option"></a>Default Option</h6>
+</div>
+</div>
+</div>
+<p>unlike for regular attributes, this option is not optional! Simply pick a state option to be assigned that the agent will take if no other option has been assigned.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Spaces">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Spaces_2"></a>Spaces</h4>
+</div>
+</div>
+</div>
+<p>All contexts can contain spaces. Spaces provide an environment in which agents can have a physical or notional location and upon which they can interact with one another and their environment. Agents can exist in more than one space at a time, and a given agent need not exist in every space. (Note that this is different from the Repast Simphony notion of projections, though the two representational approaches are generally compatible.) Agents need not represent explicit, "real" spatial structures such as a landscape, though this is of course the most common use. They can also represent relational and state information, such as a belief space or a social network. There are four kinds of space represented:</p>
+<div class="section" title="Space (Continuous)">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Space_.28Continuous.29"></a>Space (Continuous)</h5>
+</div>
+</div>
+</div>
+<p>In the modeling tools, we simply refer to this as a "Space" as it is represents the general concept of a space. A space is simply something that contains objects with certain locations and extents and has a certain number of dimensions. The space is continuous, in the sense that objects can be placed anywhere with arbitrary position. Spaces hold attributes, which simply define their dimensions-- see below.</p>
+<div class="section" title="Border Rule">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Border_Rule"></a>Border Rule</h6>
+</div>
+</div>
+</div>
+<p>A value representing what happens to an agent when that agent is asked to move beyond its extent.</p>
+<div class="variablelist">
+<dl>
+<dt>
+<span class="term">Periodic</span>
+</dt>
+<dd>
+<p>When encountering an edge, the agent will treat the space as wrapping around to the other side of the space. For example, if the agent at location {1,2} (0-based) within a Moore space (see grid discussion below) of size {10,10} is asked to find some other agent within distance 3, the agent look in the square defined between {8,9} and {4,5}. An agent asked to move beyond the confines of the space will simply stop when it reaches the edge. You can imagine this as taking a piece of graph paper and connecting the opposite edges. You can't actually do that with paper, but if you could you would have a toroidal (donut) shape in three dimensions defining the shape in two.</p>
+</dd>
+<dt>
+<span class="term">APeriodic</span>
+</dt>
+<dd>
+<p>When encountering an edge, the agent treats it as the edge of the space. For example, if the agent at location {1,2} is asked to find some other agent within distance 3, the agent look between {0,0} and {4,5}. An agent asked to move beyond the confines of the space will simply stop when it reaches the edge.</p>
+</dd>
+</dl>
+</div>
+<p>The "Strict" and "Bouncy" values are obsolete and should not be used.</p>
+</div>
+<div class="section" title="Dimensionality">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Dimensionality"></a>Dimensionality</h6>
+</div>
+</div>
+</div>
+<p>The number of dimensions that the space has. After selecting a dimensionality, attributes will be added to represent each dimension. For example, if you enter 3 here, you will have an attribute for X, Y, and Z. Be sure to enter default values here, as they will be used to specify the actual size of the space.</p>
+</div>
+</div>
+<div class="section" title="Grid">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Grid"></a>Grid</h5>
+</div>
+</div>
+</div>
+<p>A grid is technically a regular lattice structure. Currently, only rectilinear structures are supported, i.e. a One-dimensional vector, a two-dimensional grid, a three-dimensional cube and so on. (Though none of the current target platforms support n-d spaces yet.) </p>
+<p>Like continuous spaces, a grid has a border rule and dimensionality. A grid has a couple of other important values:</p>
+<div class="section" title="Multi-Occupant">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Multi-Occupant"></a>Multi-Occupant</h6>
+</div>
+</div>
+</div>
+<p>Does the grid allow more than one agent to occupy it at a time? This value may be replaced with another mechanism in future releases.</p>
+</div>
+<div class="section" title="Neighborhood">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Neighborhood"></a>Neighborhood</h6>
+</div>
+</div>
+</div>
+<p>This value determines what constitutes a region within a particular distance from the agent. The value for this is often critical in obtaining particular behavior from a model, and shouldn't be overlooked. There are three possible values:</p>
+<div class="variablelist">
+<dl>
+<dt>
+<span class="term">Euclidean</span>
+</dt>
+<dd>
+<p>The distance between any two cells is taken to be the "real" distance. For example, if an agent was within a chess board, and we wanted to find all agents within distance three of it, we could determine that by taking a string of length 3, tacking it to the center of the source square, and including all cells whose centers we can reach with the other string end. Note that although Euclidean space may seem the most reasonable neighborhood configuration to choose, this really isn't the case. Euclidean space is continuous whereas grid space is discrete, and mapping the two to each other can create unexpected issues. Still, this is a good choice for models representing notional real spaces.</p>
+</dd>
+<dt>
+<span class="term">Moore</span>
+</dt>
+<dd>
+<p>Here, the distance between any two cells is defined by the number of edge 
+											<span class="italic">or</span> corner adjacent cells crossed to get between them. To continue the chess board analogy, this is the set of moves that a king can make. Note that this does not map well to real space at all, as a cell at distance 1 in a moore space is at distance sqrt(2) in "real" space.
+										</p>
+</dd>
+<dt>
+<span class="term">Von-Neumann</span>
+</dt>
+<dd>
+<p>Here, the distance between any two cells is defined by the number of edge adjacent cells crossed to get between them. This is the set of moves that a rook might make on a chess board -- if a rook could only move one square at a time. It is also often referred to as a Manhattan distance for the self-evident reason.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+<div class="section" title="Network">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Network"></a>Network</h5>
+</div>
+</div>
+</div>
+<p>A network represents a set of relationships between agents, in a graph structure. The concept is pretty simple, but note that a network is actually a critical part of many AMF models. This is because we use networks to represent any kind of references between agents. You may have noticed in the discussion about attributes that there is no generic "object" type for an attribute. In fact, attributes only contain primitive values. So we will use networks to do the kinds of things that we would often use object references for in a traditional Object-Oriented model. For example, if an agent is a member of a family, rather than have that agent have a member attribute of "family" with a reference to the "Family" object, the modeler would create a "Family Members" network and connect agent's to their families as appropriate. This implies that network members can contain members of many different types.</p>
+<p>A network has only one value to specify:</p>
+<div class="section" title="Directed">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Directed"></a>Directed</h6>
+</div>
+</div>
+</div>
+<p>This indicates whether connections between agents are one-way or two-way. If this value is false, then if a connection is made between an agent A and an agent B, and agent B searches within distance 1, agent B will find agent A. If this value is true, agent A can find agent B, but agent B can not find agent A. (Unless of course some other path leads B to A.)</p>
+</div>
+</div>
+<div class="section" title="Geography">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Geography"></a>Geography</h5>
+</div>
+</div>
+</div>
+<p>A geography represents a physical landscape. Here we assume that that landscape is going to be defined by an external data source and representational scheme -- typically a Geographical Information System. We'll describe how to work with GIS in more detail when we discuss builder actions.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Reference">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Reference"></a>Reference</h3>
+</div>
+</div>
+</div>
+<div class="section" title="Diagrams">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Diagrams"></a>Diagrams</h4>
+</div>
+</div>
+</div>
+<p>For readers familiar with UML and meta-modeling, the following diagrams give more detail on the structural design.</p>
+<div class="section" title="Meta-Classes">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Meta-Classes"></a>Meta-Classes</h5>
+</div>
+</div>
+</div>
+<p>Our first diagram depicts the core structural design of the model. </p>
+<p>
+							
+</p>
+<div class="mediaobject">
+<img src="images/structure/StructureComplexDiagram.png"></div>
+<p> 
+						
+</p>
+<div class="literallayout">
+<p>There&nbsp;seems&nbsp;to&nbsp;be&nbsp;a&nbsp;lot&nbsp;going&nbsp;on&nbsp;here,&nbsp;but&nbsp;the&nbsp;basic&nbsp;components&nbsp;are&nbsp;pretty&nbsp;straightforward&nbsp;as&nbsp;we&nbsp;can&nbsp;see&nbsp;in&nbsp;the&nbsp;next&nbsp;diagram.<br>
+
+</p>
+</div>
+</div>
+<div class="section" title="Key Collaborations">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Key_Collaborations"></a>Key Collaborations</h5>
+</div>
+</div>
+</div>
+<p>
+							
+</p>
+<div class="mediaobject">
+<img src="images/structure/StructureSimpleDiagram.png"></div>
+<p>
+						
+</p>
+<div class="literallayout">
+<p>Core&nbsp;interactions&nbsp;are&nbsp;in&nbsp;Red.&nbsp;The&nbsp;meta-model&nbsp;structure&nbsp;is&nbsp;essentially&nbsp;a&nbsp;Composite&nbsp;pattern.&nbsp;<br>
+
+</p>
+</div>
+</div>
+<div class="section" title="Details">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Details_2"></a>Details</h5>
+</div>
+</div>
+</div>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Every model has at its root a Context (Scape). Contexts are Agents that are capable of containing other Agents (including other contexts, naturally). </p>
+</li>
+<li class="listitem">
+<p>(Meta-level) Contexts contain (meta-level) Agents at the model (design-time) level.  At runtime, (model-level) Context instances defined in a (meta-level) SContext will contain (model-level) agent instances of the defined (meta-level) SAgent. This sounds more complicated than it is, so let's look at a simple example. Suppose we create a new Context, and give it a label of "Wiki Example". Within that Context, we create an Agent and give it a label of "Individual" and another Agent with the label "Block". At runtime when we are actually executing the model we will have one WikiExample model instance  which contains a number of Individuals.</p>
+</li>
+<li class="listitem">
+<p>Agents contain Attributes, such as Vision and Age. Context attributes often represent input parameters for contained agents. For example, our Wiki Agent Context might contain an Individual Count as well as a Minimum Age and Maximum Age.</p>
+</li>
+<li class="listitem">
+<p>Contexts can contain Projections (Spaces), which represent some kind of spatial or structural interaction space for the agents; either a grid, a continuous (euclidean) space, or a network (graph) or geographic space of some kind. For example, we might want to have a City that contains Blocks and that an Individual can move around within.</p>
+</li>
+<li class="listitem">
+<p>Agents are Actable and thus can contain any number of behaviors called "Actions", described in detail in the next section. Actions can describe individual behavior, and at the Context (Scape) level can define how member Agents and Projections are created.</p>
+</li>
+<li class="listitem">
+<p>Styles provide a mechanism for defining generic visualization behavior for Agents and so are also Actable. For example, an Agent might have an Action that says effectively "draw a red circle shaded red for the wealth of the agent".</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="section" title="Actions">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Actions_2"></a>Actions</h2>
+</div>
+</div>
+</div>
+<p>Actions are the most important part of an agent model. While Agents, Attributes and Spaces define what we're modeling, it is Actions that give the models life.</p>
+<div class="section" title="Overview">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Overview_3"></a>Overview</h3>
+</div>
+</div>
+</div>
+<p>Actions allow the definition of behavior for agents at a very high level. You can think of actions as being analogous to methods in a traditional object-oriented model but that analogy only goes so far. In the same way that methods are defined as part of objects, actions belong to particular agents. (Though even more expressive ways of defining actions are contemplated in future releases.) In the next section we go into detail about what Actions are and how they can be used to define all agent behavior. They are also conceptually more challenging as unlike with structure they have no direct analogies to past agent representations.</p>
+<p>An action provides simple, well-defined details that a model can use to determine what steps to take in model execution. That definition seems general enough to be almost useless, but its important to understand that an action is not equivalent to an instruction, a method or a query. In fact, actions can have aspects of all of these. But an action is not in itself an instruction specifying exactly 
+					<span class="italic">how</span> the modeling engine should do something -- instead an action represents 
+					<span class="italic">what</span> the modeler intends for the agents to do. (Technically, we might say that Actions takes a "declarative" approach instead of an 'imperative' approach, but that's not quite true, because actions do allow us to define behavior in a richer way than most declarative approaches, and many action constructs map directly to imperative approaches.)
+				</p>
+<p>Actions are connected together in a series of sources and targets. (Technically, an acyclic directed graph.) In an abstract sense that is similar to the way any programming language is defined although that structure isn't usually obvious because of the constraints of textual representations. But unlike a typical programming language, in Actions it is not the execution thread (the processor) that moves from one instruction to the next, but the result of the previous action. In this way, action results "flow" from the output of one action into the next action.</p>
+<p>Why are these distinctions between traditional Object-Oriented and the Action approaches important? They give us the advantages of simplicity, clarity and flexibility that 
+					<a class="ulink" href="/wiki/http://en.wikipedia.org/wiki/Dataflow_programming" target="_new">data-flow approaches</a> like spreadsheets and some query languages have, but with less restrictions. At the same time, they can bring us much of the power and expressiveness of 
+					<a class="ulink" href="/wiki/http://en.wikipedia.org/wiki/Functional_programming" target="_new">functional languages</a> like Lisp or 
+					<a class="ulink" href="/wiki/http://en.wikipedia.org/wiki/Logical_programming" target="_new">logical languages</a> like Prolog, but without the level of complexity and obscurity that such languages can have.
+				</p>
+<p>We can get a better idea for how Actions work by thinking about how a spreadsheet works. In a spreadsheet, we might define a cell A that adds up a row of data, say "Income". We might define another cell C ("Profit") that takes A and adds it to another cell B that adds up another row of data ("Expenses"). Now, if we change a value in any of the rows, all of the other rows are added up and we get the results in A and B updated automatically. We never had to write code that said something like "for each cell in row X, where...". In fact, we don't really care 
+					<span class="italic">how</span> our Spreadsheet program adds up the numbers -- it could have added them all up at once but in backward order, or stored a running total somewhere and updated just the difference in value for the cell we changed -- what we care about is 
+					<span class="italic">what</span> the result is, and whether it is correct.
+				</p>
+<p>But Actions are much more powerful than a spreadsheet, because what is flowing from Action A to Action B is not just a number, but any model component such as a space or a set of agents that we need to use in target actions.</p>
+</div>
+<div class="section" title="Concepts">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Concepts"></a>Concepts</h3>
+</div>
+</div>
+</div>
+<p>In this section, we'll describe how modelers can assemble actions into sets of behavior that accomplish complex tasks on interrelated agents and spaces over time.</p>
+<div class="section" title="Kinds of Actions">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Kinds_of_Actions"></a>Kinds of Actions</h4>
+</div>
+</div>
+</div>
+<table id="N1029B">
+<tr>
+							
+<td>Before getting into the details of how each Actions work together, or the various kinds of Actions, it will be helpful to take a broad overview of how they all fit together. As discussed above, actions are strung together in a sequence or flow. They're always composed of two parts, though those parts can be assembled and intermixed in many different ways. First, we search for a collection of agents, and then we do something with that selection. We refer to these two parts as Selections and Commands. (For the technically minded, another useful way of looking at the Actions approach is as a Query Transformation language, as with SQL and Stored Procedures.  Except again, the results of the queries along with the transformations flow through from one query to the next.) Selections find the agents we want to do something with, and the commands do it. We need some way to start the whole chain of actions off, and so we have a kind of Selection called a Root Selection, or simply a Root. Secondly, we need some way to actually make the agents exist in the model in the first place, so we have a Create Agents action. Finally, we have special commands called builders that allow us to create the spaces that the agents will occupy. The various actions are discussed in depth in the Details section.</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsBlocks.png"></div> 
+							
+</td>
+						
+</tr>
+</table>
+</div>
+<div class="section" title="Flow">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Flow"></a>Flow</h4>
+</div>
+</div>
+</div>
+<p>First, let's look at how actions define the basic path that agents take during a model run. As with any programming language, the path we take through the program specification is what determines our state when we get there. In a pure object oriented program, the path just defines the control flow -- what we are doing. The actual state of our model is defined within the object itself. If we call a method B from another method A, we'll be relying on method A to set the values that we need into the object state itself. In a purely functional program the path defines how we are going to deal with whatever has been explicitly passed in to a function that has been called, that is the function parameters. In fact, most languages such as Java combine aspects of both approaches.</p>
+<p>In Actions, the path itself implicitly carries all of the context of prior execution with it. This means that we don't have to worry about storing context in the object -- as we would in an object-oriented language -- or passing the correct values from one method call to the next as we would in a functional language. Instead, Actions can use the implicit context of the path of flow to determine what the current state of execution is.
+						An important aspect of the Actions design is that loop structures are not allowed -- that is, flows are acyclic. An action can never have an ancestor target (that is targets, targets of targets, etc..) that has as one of its ancestors that same action. As you'll see, actions don't typically 
+						<span class="italic">need</span> loop structures. By far the most common use of loops in conventional programming langauges is to loop through collections of objects. As selections (see below) refer to the entire collection of agents, any actions on a selection apply to all members of that collection. Recursive structures are needed for some particular usages and will be supported in future releases, but not through an explicit looping construct.
+					</p>
+<table id="N102B9">
+<tr>
+							
+<td>Again, behaviors in Actions are always defined by a set of 
+								<span class="italic">selections</span> and 
+								<span class="italic">queries</span>. In the diagram to the right, we can see the pattern. First, we define a Root Selection for a Rule, Schedule or other triggering event. Then, we might add a series of Query and Logic Actions to define the specific agents that we are interested in. These are all part of the Selection. Next, we might define a series of Commands to determine what to do with those agents. Or, we could use the result of that selection to immediately define another selection, for example if we are searching for an agent that is near another agent.
+							</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsSequence.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<table id="N102D3">
+<tr>
+							
+<td>The diagram to the right depicts a simple example. Here, we create a rule, and then check the results of two queries. For any agents that meet those criteria, we'll evaluate some function based on their state, and then set some value on them.</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsSimpleSequence.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<table id="N102E5">
+<tr>
+							
+<td>In this next example, we'll first create the rule, and then create a new selection with a set of criteria. Finally, we'll do a move based on those queries.</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsSimpleSequence2.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<p>In the following example, we've defined a set of actions and their relationships. We have a selection, a few queries and a couple of logic operators leading to a Set Action. We'll describe in detail below how Logic Actions are used in conjunction with other actions to assemble any kind of query structure needed. But for now, we'll focus on the control flow itself.</p>
+<p>
+						
+</p>
+<div class="mediaobject">
+<img src="images/actions/ActionsFlowSimple.png"></div>
+<p>
+					
+</p>
+<p>As you have probably already guessed, the agents that have the Set Action applied to them could take one of two paths through the Action flow. Readers with experience with programming or formal logic will note that this looks just like a parse tree, and while that's basically what it is, there are important differences. For example, if we looked at the following structure as a definition of control flow for a single agent we'd take them to be equivalent. Both would evaluate the statement (Query 1 AND Query 2) OR Query 3 for each agent.</p>
+<p>
+						
+</p>
+<div class="mediaobject">
+<img src="images/actions/ActionsFlowUnion.png"></div>
+<p>
+					
+</p>
+<p>Within Actions in many cases these two approaches will also act equivalently. If we are simply setting a value, it doesn't matter how an agent gets to that Set Action, as long as it gets there. All sources that flow into a given target Action act like a logical union since any of the paths might reach that target. But note that we have two flows moving in parallel in the flow on the right. What happens when the conditions for 
+						<span class="italic">both</span> branches are true? As the set of agents flow through each branch the Set Action on the left will be evaluated once, while the one on the right will be evaluated twice. Again, this often ends up with the same behavior, but not always. If for example, the evaluate Action uses the value of the attribute that we are setting as input, we can get different results. Of course, you can write code in any language that accomplishes the same thing, but the code will look quite different. For example, if we wrote the same basic logic in Java, in the first case we'd have something like:
+					</p>
+<div class="literallayout">
+<p>if&nbsp;((query1.evaluate()&nbsp;&amp;&amp;&nbsp;query2.evaluate())&nbsp;||&nbsp;query3.evaluate())&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;doSomething();<br>
+}<br>
+
+</p>
+</div>
+<p>In the second we'd have:</p>
+<div class="literallayout">
+<p>if&nbsp;(query1.evaluate()&nbsp;&amp;&amp;&nbsp;query2.evaluate())&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;doSomething();<br>
+}<br>
+if&nbsp;(query3.evaluate())&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;doSomething();<br>
+}<br>
+
+</p>
+</div>
+<p>This is a simple example, but with multiple branches such code design issues can quickly grow complex. The flow approach allows us to express things in a way that is often more natural and expressive. The important thing to keep in mind when desiging action flows is to see the flow as representing a selection of agents moving through streams independently. In the Actions example we expressed both approaches in nearly the same way, except in the case on the left we used a Union Action to bring the two branches of flow back together.</p>
+</div>
+<div class="section" title="Selections">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Selections"></a>Selections</h4>
+</div>
+</div>
+</div>
+<p>Selections are a key concept in Actions. Put simply, selections define what we are searching for and where. They are defined by a combination of Select, Query and Logic Actions. Each time we create a new Select Action, we define a new selection. Queries can be used to further refine selections either immediately after or later in the Action flow, as described in the next section. Logic Actions are used to combine and organize the Action flow defined by Query Actions. In order to understand how these three pieces work together, we need to understand the idea of selection boundaries.</p>
+<table id="N10321">
+<tr>
+							
+<td>A selection boundary determines the set of selection actions that are used to determine what agents to apply target actions to. For example, in the following diagram, we can see the extent of the boundary for a straightforward selection.</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsSelBoundarySimple.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<table id="N10333">
+<tr>
+							
+<td>Each time we create a new selection, we define a new set of boundaries. In the diagram to the right, Selection 1 and Selection 2 eaach start with a new Select Action. </td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsSelBoundary2Parts.png"></div> 
+							
+</td>
+						
+</tr>
+</table>
+<p>But boundaries can be defined for a group of actions by a Query Actions as well. This is because Query Actions can be directly part of a selection definition, but they can also refine selections. We'll see how that works below. So where does one selection boundary end and the next one begin? The simple rule is that the end of the boundary is defined for a given Action by the place where:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>A Query Action is not followed by a Logic Action, or</p>
+</li>
+<li class="listitem">
+<p>A Logic Action is not followed by another Logic Action</p>
+</li>
+</ol>
+</div>
+<table id="N10350">
+<tr>
+							
+<td>In other words, as soon as a Logic Action occurs in a path leading to an Action, any following Query will define a new boundary, as shown in the example to the right. </td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsSelBoundary11A.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<p>Note that we refer to "Selection 1" and Selection 1A". This is because Selection 1A is a refinement of Selection 1 along its particular path of flow. When a query appears for the same selection but past a particular boundary, you can think of it as a sort of filter on the selection contents. We don't have a "Selection 2" here because any Actions that refer to "Selection 1" along the current path of flow will be acting on the selection defined by Selection 1 and Selection 1A.</p>
+<p>These rules allow actions to be defined in the simplest possible way, but it is important to understand their implication as they result in behavior that can be different from what someone used to and imperative programming environment such as Java might expect. In a simple case the distinction might not matter. For example, if we are using a Query 1 to test whether an agent's attribute a == x and attribute b == y, we would get the same outcome if we placed intersected the queries as if we simply put them in sequence. Internally we would actually be searching for agents with a == x, and 
+						<span class="italic">then</span> taking those agents and choosing those agents with b==y, but the outcome would be the same. But consider a more sophisticated case, where we are searching for neighboring available cells.
+					</p>
+<p>
+						
+</p>
+<div class="mediaobject">
+<img src="images/actions/ActionsSelBoundaryComplex.png"></div>
+<p>
+					
+</p>
+<p>In the first case, we execute a search for all agents that meet the two criteria. This means that if there are 
+						<span class="italic">any</span> neighboring cells which are available, we're guaranteed to find one (random) cell. In the second case, we first search for all cells that are neighbors. This will match any agents that include both available and non available agents. Now, at this point since our search returns one agent (in the current AMF design -- richer behavior will be supported in the future) the randomly selected agent could be either available or not. So in the second case, we might end up with no cell to move to, and thus make no move at all. This then becomes an important aspect of model design. For example, if one were defining a model where neighbors played a game with each other, one might want to instruct agents to play the game only with neighbors that have a certain wealth threshold. In the real-world situation that we are modeling, we might simply search for neighbors who are over a given wealth threshold and then play the game with them. This would imply that information about other agent's wealth is open knowledge. Or, we might simply select a random neighbor, and ask that neighbor to play a game with us. Upon discovering that our neighbor does not meet our wealth criteria, we would then choose not to play with them. Here we are modeling a cost in time to obtain information about another agent's wealth, because we might miss an opportunity to play the game with another agent on that round.
+					</p>
+</div>
+<div class="section" title="Weaving">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Weaving"></a>Weaving</h4>
+</div>
+</div>
+</div>
+<table id="N1037B">
+<tr>
+							
+<td>Now, let's put the concepts of Actions sequences and boundaries together to see how we can easily define complex interactions between multiple selections. When we define a Select, the state of its selection flows through and with any subsequent selections. So for example, if we have a Root Action rule, and then do a selection based on it, we'll have access to the agent from the original context as well as all of the subsequent selections. We can refer to any previous selection for any subsequent action. For example, instead of setting the value for the rule agent, we might instead set a value for an agent we've found in a target selection.</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsWeavingSetAnother.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<table id="N1038D">
+<tr>
+							
+<td>Inputs to functions also use selections. (We'll discuss more details in the functions section.) In the following example, we're adding the wealth of the Selection 1 agent to the wealth of the Selection 2 agent and using that value to set some other value. (Here, perhaps we are modeling an agent in a winner takes all game, in which case we'd also add a Set Action on Selection 2 and set the second agent's wealth to 0.)</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsWeavingEvaluate.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<table id="N1039F">
+<tr>
+							
+<td>But we can also use selections in defining Query Actions themselves. So in the following example, we select a neighbor agent and then compare the age of our Rule agent with the age of the Selection 2 agent. If and only if those ages are the same will we execute the target Set Action. This example also demonstrates why we refer to the data flow as weaving. Query Actions can be used to refine selections at any point in the data flow. Selections and their uses are interwoven throughout an action sequence.</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsWeaving1A.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+<table id="N103B1">
+<tr>
+							
+<td>Finally, we can put all of these concepts together by weaving selections together with flows. As we discussed in the flow section, if we use multiple paths in the Query, the agents that flow through from any prior Query can follow multiple paths at once. And as we discussed in the selection section, the selection and its boundaries determine what agents we will be working with at any given evaluation point in the flow. Consider the example to the right. As we'll see in the detailed explanation of each Action below, Transformation Actions such as Move or Connect take multiple selections. The first selection defines the set of agents that will be performing the action. In the case of a Move agent, this refers to the mover. The second selection, which for Move we call "destination", refers to the selection that will be receiving the action. In the case of movement this is the agent or location that the Rule agent will be moving to. If we follow the flows through, we can note two important outcomes of our model design -- a Rule agent might move twice if it meets the criteria for both the blue path and the red path and that it might move to a different location each time.</td>
+							<td>
+								
+<div class="mediaobject">
+<img src="images/actions/ActionsWeaving2.png"></div>
+							
+</td>
+						
+</tr>
+</table>
+</div>
+</div>
+<div class="section" title="Details">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Details_3"></a>Details</h3>
+</div>
+</div>
+</div>
+<table id="N103C7">
+<tr>
+						
+<td>In this section, we'll dig into the specific role of each of the Actions. From the design discussion we hopefully have some sense of how these all fit together in general. Again, the block diagram to the right provides an overview of how the various actions are related. You might want to take a look at the meta-class diagrams in the referernce section as well.</td>
+						<td>
+							
+<div class="mediaobject">
+<img src="images/actions/ActionsBlocks.png"></div> 
+						
+</td>
+					
+</tr>
+</table>
+<div class="section" title="Selections">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Selections_2"></a>Selections</h4>
+</div>
+</div>
+</div>
+<p>A selection defines a particular set of agents that we want to do something with. Selections are made up of the Select action itself, along with Query and Logic actions. When we refer to a selection in any target command, we are referring to the selection in the context of where we have defined the behavior.</p>
+<div class="section" title="Select">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Select"></a>Select</h5>
+</div>
+</div>
+</div>
+<p>As we discussed above, when we refer to a Select, we're actually referring to the selection as a whole leading up to the current action. The Select Action itself is used to define what we are searching for (Agent), where we are searching for it (Space), and from whose perspective we are doing it (Selection). Create Actions are a sepecial kind of Select Action that are used to create agents. See the decription in the Builders section below for more information.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection that we are searching "from". This seems to be the concept that new users have the most difficulty with, but it is key to understanding how Actions works. Just as with any other Action -- a Move command for example -- a selection needs to know what set of agents that it is working with. For example, if we want to define a selection B that finds the cells neighboring a rule B's agent, we would set selection B's selection to A.</p>
+</div>
+<div class="section" title="Agent">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Agent"></a>Agent</h6>
+</div>
+</div>
+</div>
+<p>Here we define what agent we will be looking for. In order for this to make sense, the agent has to be related in some meaningful way to the agent whose behavior we are defining. For example, it might be a partner agent or a location that we might want to move to. An agent must be specified unless we are searching within a continuous space, in which case this value should be empty, and the result of the selection will represent some location in that space. In the current version of the framework, we treat destination cell locations as agents, and require that location to be specified as a target agent, but in a future version we'll allow searches without defining an agent within grid spaces as well.</p>
+</div>
+<div class="section" title="Space">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Space"></a>Space</h6>
+</div>
+</div>
+</div>
+<p>The space that we want to search within. Of course, this must be specified if we use any spatial query terms (see below), but if we simply want to search across all agents it should not be specified.</p>
+<p>Represent Queries (Controls) on agents and Transformations, or Commands, on the result of those queries. Queries, Transformations and other  in which each child target carries the execution and data context for it's particular path.</p>
+</div>
+<div class="section" title="For">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="For"></a>For</h6>
+</div>
+</div>
+</div>
+<p>This value is obsolete and will be replaced with a different mechanism in the next version of the modeling environment.</p>
+</div>
+</div>
+<div class="section" title="Query">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Query"></a>Query</h5>
+</div>
+</div>
+</div>
+<p>A Query represents a concrete criteria for our search. The name is a bit confusing because of potential for confusion with a generic query. Queries -- along with their cousin Evaluators -- define a function that is evaluated and that can take Agent attributes and the results of other Actions as input. Queries are combined with each other and with the logic actions to determine the results of a selection for their direct target actions. </p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_2"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>As with all other actions, evaluations specify a selection, and just as with the other actions, this determines the set of agents that the evaluation occurs for, but the input selections determine what agent is used for the calculation itself.</p>
+</div>
+<div class="section" title="Function">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Function"></a>Function</h6>
+</div>
+</div>
+</div>
+<p>A query function is evaluated to determine the results of a particular selection. Functions can represent very simple search criteria such as "My Age == Your Age", but they can also represent complex and inter-related concepts such as spatial relationships. They must return logical values. See the functions section for more information on specific functions.</p>
+</div>
+<div class="section" title="Inputs">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Inputs"></a>Inputs</h6>
+</div>
+</div>
+</div>
+<p>The set of values that will be used to determine the result, in the order specified by the function prototype. Inputs can specify any source evaluation and any agent state or agent parent context state. They can also be literal values -- see the section on literals below. The selection determines which agent's will be used to determine the value, and different inputs can specify different selections.</p>
+</div>
+</div>
+<div class="section" title="Logic">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Logic"></a>Logic</h5>
+</div>
+</div>
+</div>
+<p>These Actions provide us with the ability to combine queries with one another, and follow the basic rules of set logic. But as we've seen above, it is important to understand that there are important differences between Logic Actions and typical programming logic. Most importantly, they apply not to individual agents per se, but to the set of agents that move through them. Also, there is not neccesarily short circuit execution (it's not needed) and much richer criteria can be joined together because of the action flow design.</p>
+</div>
+<div class="section" title="Intersection">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Intersection"></a>Intersection</h5>
+</div>
+</div>
+</div>
+<p>An intersection contains only those agents that match all of its source actions. This is essentially equivalent to a logical AND statement and has similarities to an &amp;&amp; operator in a java "if" statement. An agent must be able to flow through all incoming actions in order to flow out of an Intersection Action.</p>
+</div>
+<div class="section" title="Union">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Union"></a>Union</h5>
+</div>
+</div>
+</div>
+<p>A union contains all agents that match any of its source actions. This shares similiarities to a logical OR statement and the || operator in a java "if" statement. It does mroe than that however, as it acts to join multiple flows of action. That is, as set logic implies, an agent will never appear in the result of a union more than once.</p>
+</div>
+<div class="section" title="Difference">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Difference"></a>Difference</h5>
+</div>
+</div>
+</div>
+<p>A difference contains all agents that do not match any of its source actions. This essentially equivalent to a logical NOT statement, and has similarities to the Java else statement. Like the Union Action, difference implies that a given agent will only appear once in any subsequent targets. No agents that reach a Difference Action will flow through to the next action(s), and all agents (that meet the definition of the Select Action) that cannot reach that action will.</p>
+</div>
+</div>
+<div class="section" title="Roots">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Roots"></a>Roots</h4>
+</div>
+</div>
+</div>
+<p>Root actions are a special case of a selection. These represent behaviors that are defined for all members of agents; these are the highest granularity of an agent's behavior, such as "Find Partners" or "Eat" or "Reproduce". When you want to create a new set of Actions, you have the following choices.</p>
+<div class="section" title="Build">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Build"></a>Build</h5>
+</div>
+</div>
+</div>
+<p>The Build Action is a specialized action that allow the construction of member agents and spaces within a parent context. A Build Action executes once for each context before any initialization actions occur for any children agents of that context. Currently it is undefined whether a context's own Initialize Action is executed before the Build Action occurs, so implementors should not rely on any initialized values being available at build time.</p>
+</div>
+<div class="section" title="Initialize">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Initialize"></a>Initialize</h5>
+</div>
+</div>
+</div>
+<p>An Initialize action is executed once and only once for every agent when the model is first started -- at time 0. Initialize Actions are guaranteed to execute before any other non-builder action occurs.</p>
+</div>
+<div class="section" title="Rule">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Rule"></a>Rule</h5>
+</div>
+</div>
+</div>
+<p>A Rule executes once for every agent for every iteration of the model. An important note is that the actual sequence of rules is technically undefined. An implementor should not rely on the fact that a rule occurs before another rule in the list of agent actions though typically the order in which the rules were actually created is respected.</p>
+</div>
+<div class="section" title="Schedule">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Schedule"></a>Schedule</h5>
+</div>
+</div>
+</div>
+<p>A schedule is executed on a recurring basis, according to the values detailed below. Note that schedules are often overused. In most agent-based models it makes sense to have any behaviors occur at the same granularity using a Rule. Please note that Schedules are not currently supported in the Escap target, but that support should be available soon. In the following descriptions we refer to period as the current iteration of the model, that is where time == t.</p>
+<div class="section" title="Start">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Start"></a>Start</h6>
+</div>
+</div>
+</div>
+<p>The period that the schedule will first be invoked. For example, if this value is 100, and interval is 1, the schedue will be executed at times 100,101,102..</p>
+</div>
+<div class="section" title="Interval">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Interval"></a>Interval</h6>
+</div>
+</div>
+</div>
+<p>How often the schedule is invoked. For example, if this value is 3 and start is 1, the schedule will be executed at times 1,4,7..</p>
+</div>
+<div class="section" title="Priority">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Priority"></a>Priority</h6>
+</div>
+</div>
+</div>
+<p>Where the rule will be placed in the execution queue for a given time period. For example, if Schedule A's priority is set to 3 and Schedule B's is set to 2, Schedule B will be executed for all agents before Schedule B is executed for any agents.</p>
+</div>
+<div class="section" title="Pick">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Pick"></a>Pick</h6>
+</div>
+</div>
+</div>
+<p>Controls how many agents to execute the schedule against. While this value will have an effect on the Repast target, it is not recommended to be used for general models and is likely to be replaced by another approach.</p>
+</div>
+</div>
+<div class="section" title="Watch">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Watch"></a>Watch</h5>
+</div>
+</div>
+</div>
+<p>A Watch action is executed any time the watched value is set for any agent. Note that the Action will be triggerred even if the state is simply set back to the value that it already has. It is important to be careful about creating Watches that might set the values of other Watch actions which might in turn trigger this watch. To clarify, if a modeler creates a Watch A for attribute a, and creates a target Set for it for attribute b, and Watch B is watching attribute b, then if Watch B has a target Set for attribute A, a circular execution could occur. This would cause the model to get stuck in its current iteration. To help model developers avoid this case, a warning will be provided if such a set of circular watch dependencies is created.</p>
+<div class="section" title="Attribute">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Attribute"></a>Attribute</h6>
+</div>
+</div>
+</div>
+<p>The attribute that will be monitored for change.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Builders">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Builders"></a>Builders</h4>
+</div>
+</div>
+</div>
+<p>Builders are a special category of actions that are used to create spaces. They should not be confused with the Build Action itself which is a root selection that defines the time at which builder actions should occur. Generally speaking, specific Builder Actions for spaces and Create Actions for agents are targets of Build Actions.</p>
+<div class="section" title="Create Agents">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Create_Agents"></a>Create Agents</h5>
+</div>
+</div>
+</div>
+<p>Agents are crete using the Create Agent action. The Create Agent Action is actually a special kind of Select Action that is used to actually create agents rather than simply search for them. Other than this capability, a Create Agent action can be used just like any other action except that Query and Logic actions aren't needed or genrally appropriate as this action defines a set number of agents to perform an action against. Create Agent actions have the special feature of being usable from the containing context, so that contexts can create initial agent populations before any agents exist within the context to perform actions against. But they can also be used directly within agent rules, for example to create a child agent as the result of a reproducation rule. Note that Initialize Actions are 
+							<span class="italic">not</span> performed on agents that have been created within a model during regular (non-initialization time) execution. If the model creates actions during the regular model run, any state initialization should be handled by the targets of this action directly. (Naturally, if the enclosing context is used to create agents at the beginning of a model run, then the Initialize action is used as part of the normal model life-cycle.)
+						</p>
+<div class="section" title="Agent">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Agent_2"></a>Agent</h6>
+</div>
+</div>
+</div>
+<p>The kind of agent to create.</p>
+</div>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_3"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection to use as the basic for this selection. This is generally not important except to define control flow.</p>
+</div>
+<div class="section" title="Space">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Space_2"></a>Space</h6>
+</div>
+</div>
+</div>
+<p>Not generally relevant for agent actions, as agents are not placed into a space unless explicitly moved to that space. Potential associations between agents and spaces are defined by the space building actions.</p>
+</div>
+<div class="section" title="Agent Count">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Agent_Count"></a>Agent Count</h6>
+</div>
+</div>
+</div>
+<p>The number of agents to create. If used as part of an enclosing context's Initialize Action(s) an Attribute parameter will automatically be created. If not, then an evaluation or agent attribute should be used to define this number.</p>
+</div>
+<div class="section" title="For">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="For_2"></a>For</h6>
+</div>
+</div>
+</div>
+<p>Deprected. Should not be used.</p>
+</div>
+</div>
+<div class="section" title="Create Shaped Agent">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Create_Shaped_Agent"></a>Create Shaped Agent</h5>
+</div>
+</div>
+</div>
+<p>Creates an agent that has a particular shape extent within some continuous (i.e. vector as opposed to raster) space. This action performs just like a Create Action except for the following attribute:</p>
+<div class="section" title="Shape">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Shape"></a>Shape</h6>
+</div>
+</div>
+</div>
+<p>Determines how each agent's spatial extent will be defined. The actual form of that shape is implementation specific. For example, in a GIS space (the immediate rationale for this Action) a polygon represents a region on a map and the extent of that shape might be determined by a .shape file. The available shape types are:</p>
+<div class="variablelist">
+<dl>
+<dt>
+<span class="term">Point</span>
+</dt>
+<dd>
+<p>A simple point in space, fully equivalent to a standard continuous space location.</p>
+</dd>
+<dt>
+<span class="term">Line</span>
+</dt>
+<dd>
+<p>A single line within a continuous space. Technically this represents a line segment as it is expected to have a beginning and ending point. In the future, this might refer more generically to planes in three dimensional space and hypersurfaces in n-dimensional spaces, but this is currently not supported by any AMF target implementations.</p>
+</dd>
+<dt>
+<span class="term">Polygon</span>
+</dt>
+<dd>
+<p>A region within a space defined by an arbitrarily large set of line segments. Potentially this could be used to refer to polyhedrons in three-dimeensional space, or even more genrally as polytopes, but this is currently not supported by any AMF target implementations.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+<div class="section" title="Load Agents">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Load_Agents"></a>Load Agents</h5>
+</div>
+</div>
+</div>
+<p>Imports and creates a set of agents from some input file. The actual form and manner of the import is implementation specific but should be inferrable from any source file based on the URL provided, assuming that the target platform or the AMF platform supports the appropriate imput type. For example, a Tab-CR delimited file might be used to populate a set of agents with various attributes. Additional meta-data could be provided by the URL, but we will likely add additional extensible meta-data to this action to better support the definition of expected input types and routines from within an AMF model itself. This action is equivalent to the Create Agents action except for:</p>
+<div class="section" title="Source URL">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Source_URL"></a>Source URL</h6>
+</div>
+</div>
+</div>
+<p>The location of the input file or set of meta-data used to determine the location and type of the input file.</p>
+</div>
+</div>
+<div class="section" title="Load Shaped Agents">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Load_Shaped_Agents"></a>Load Shaped Agents</h5>
+</div>
+</div>
+</div>
+<p>Combines the properties of the Create Shaped Agent and Load Agent Actions. The source url should of course specify an input format that supports the shape type specified. See the descriptions of the related actions for more details.</p>
+</div>
+<div class="section" title="Build Network">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Build_Network"></a>Build Network</h5>
+</div>
+</div>
+</div>
+<p>Creates a network, i.e. a graph structure, supporting the establishment of edges between arbitrary nodes.</p>
+<div class="section" title="Agents">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Agents_3"></a>Agents</h6>
+</div>
+</div>
+</div>
+<p>Specifies the set of agents that can exist within this network. Agents must be included here in order for them to make connections within the network but agents included here are not required to have connections within the network, nor are such connections created for them. (See important note regarding network types below.)</p>
+</div>
+<div class="section" title="Attributes">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Attributes_3"></a>Attributes</h6>
+</div>
+</div>
+</div>
+<p>Not currently used for networks.</p>
+</div>
+<div class="section" title="Network Type">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Network_Type"></a>Network Type</h6>
+</div>
+</div>
+</div>
+<p>Deprecated. This feature is only currently supported for Repast targets and is likely to be removed from future versions of the AMF meta-model. Future AMF implementations are likely will provide a different mechanism for instantiating and importing network structures either within the network defintion or through other Action definitions. Instead of using this feature, modelers should create specific networks by building them up with Connect Actions for indivdual agents. For example to create a small world netowrk, a modeler might create random links between agents and then replace or augment those connections.</p>
+</div>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_4"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>Not relevant for network builders except as part of normal control flow.</p>
+</div>
+</div>
+<div class="section" title="Build Grid">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Build_Grid"></a>Build Grid</h5>
+</div>
+</div>
+</div>
+<p>Creates a grid space.</p>
+<div class="section" title="Agents">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Agents_4"></a>Agents</h6>
+</div>
+</div>
+</div>
+<p>The set of agents that might exist as occupants of this grid; that is, members of individual cells within a given grid. Agents must be included here in order for instances to exist within the space, but agents included here do not actually have to exist within the space. (In the Repast implementation, all agents technically are memebers of the spatial projection, but are not required to have valid coordinates within that space.) For example, in an agriculture model these might represent agents moving about and harvesting plots of land.</p>
+</div>
+<div class="section" title="Fill Agent">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Fill_Agent"></a>Fill Agent</h6>
+</div>
+</div>
+</div>
+<p>The agent that will be used to populate the grid itself. A gird is guranteed to contain one and only one fill agent within each grid locaiton. The grid will be populated with instances of the specified agent and these agents cannot move, leave or die within this space. This value need not be specified -- if left blank a default cell without any state will be used. For example, in an agriculture model, this agent might represent a single plot of land.</p>
+</div>
+<div class="section" title="Space Type">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Space_Type"></a>Space Type</h6>
+</div>
+</div>
+</div>
+<p>Deprecated. Should not be used.</p>
+</div>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_5"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>Not relevant for builders except as part of normal control flow.</p>
+</div>
+<div class="section" title="Attributes">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Attributes_4"></a>Attributes</h6>
+</div>
+</div>
+</div>
+<p>Not currently used for spaces.</p>
+</div>
+</div>
+<div class="section" title="Build Space">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Build_Space"></a>Build Space</h5>
+</div>
+</div>
+</div>
+<p>Creates a continous space. The actual dimensionality and other qualities of the space are currently defined in the space itself though this might change in future versions. All other values are used in the same way as for the gird and other builder actions.</p>
+<div class="section" title="Agents">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Agents_5"></a>Agents</h6>
+</div>
+</div>
+</div>
+<p>The set of agents that might be a part of this space. Agents must be included here in order for instances to exist within the space, but agents included here do not actually have to exist within the space. (In the Repast implementation, all agents technically are memebers of the spatial projection, but are not required to have valid coordinates within that space.)</p>
+</div>
+</div>
+<div class="section" title="Build Geography">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Build_Geography"></a>Build Geography</h5>
+</div>
+</div>
+</div>
+<p>Constructs a geographical space. All details of this space are specfied by the implementation, i.e. a specific geographical imported space. Generally these would be defined by a Create Agents action; that is a set of imported agents representing US states would also represent the overall space of interest.</p>
+</div>
+</div>
+<div class="section" title="Commands">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Commands"></a>Commands</h4>
+</div>
+</div>
+</div>
+<div class="section" title="Evaluate">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Evaluate"></a>Evaluate</h5>
+</div>
+</div>
+</div>
+<p>Evaluate Actions define some calculation on a function based on the model state and a set of input(s). The inputs that an Evaluate Action can take is determined by its functions and can be either agent attributes, prior evaluations or literals. The result is then determined based on those inputs. In some cases Evaluate functions can be used to determine some action indirectly, such as with a graphics fill, but they can never be used to directly change model state.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_6"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>As with all other actions, evaluations specify a selection, and just as with the other actions, this determines the set of agents that the evaluation occurs for, but the input selections determine what agent is used for the calculation itself.</p>
+</div>
+<div class="section" title="Function">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Function_2"></a>Function</h6>
+</div>
+</div>
+</div>
+<p>A with queries, a function is evaluated against its input set. Functions can represent simple operators as well as complex functions. See the functions section for more information on specific functions.</p>
+</div>
+<div class="section" title="Inputs">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Inputs_2"></a>Inputs</h6>
+</div>
+</div>
+</div>
+<p>The set of values that will be used to determine the result, in the order of the function prototype. Inputs can specify any source evaluation and any agent state or agent parent context state. They can also be literal values -- see the discussion in the Tools section. The selection determines which agent's will be used to determine the value, and different inputs can specify different selections.</p>
+</div>
+</div>
+<div class="section" title="Set">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Set"></a>Set</h5>
+</div>
+</div>
+</div>
+<p>The Set Action assigns some value to another value.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_7"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>Here the selection refers to the agent that we want to change. This does not have to be the immediatily preceeding selection but can be any accessible selection.</p>
+</div>
+<div class="section" title="Attribute">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Attribute_2"></a>Attribute</h6>
+</div>
+</div>
+</div>
+<p>The attribute to modify. It must be a member of this action's agent or of that agent's parent context.</p>
+</div>
+<div class="section" title="Parameter">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Parameter"></a>Parameter</h6>
+</div>
+</div>
+</div>
+<p>The value to assign to the attribute. Here, we can use either another agent attribute, or the results of a source evaluation. </p>
+</div>
+</div>
+<div class="section" title="Move">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Move"></a>Move</h5>
+</div>
+</div>
+</div>
+<p>The Move Action causes an agent to change its location in some space or network. The agent will leave whatever location it was in before within the selection space, and move to its new destination.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_8"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>As in any other action, the selection determines what agent is affected -- in this case the agent that is being moved.</p>
+</div>
+<div class="section" title="Destination">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Destination"></a>Destination</h6>
+</div>
+</div>
+</div>
+<p>Specifies the target agent or location for the movement.</p>
+</div>
+</div>
+<div class="section" title="Leave">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Leave"></a>Leave</h5>
+</div>
+</div>
+</div>
+<p>Causes the agent to leave a particular space.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_9"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection determines what agent will be leaving and what space the agent will be leaving. If the agent doesn't exist in that space nothing will happen.</p>
+</div>
+<div class="section" title="Destination">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Destination_2"></a>Destination</h6>
+</div>
+</div>
+</div>
+<p>The destination is irrelevant for a leave action and should not be specified.</p>
+</div>
+</div>
+<div class="section" title="Die">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Die"></a>Die</h5>
+</div>
+</div>
+</div>
+<p>Causes the agent to cease to exist within the model as a whole.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_10"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection determines what space the agent to remove.</p>
+</div>
+<div class="section" title="=Destination">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name=".3DDestination"></a>=Destination</h6>
+</div>
+</div>
+</div>
+<p>The destination is irrelevant in this case and will probably be removed.</p>
+</div>
+</div>
+<div class="section" title="Connect">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Connect"></a>Connect</h5>
+</div>
+</div>
+</div>
+<p>Connects two agents within a network space. This Action is not applicable for any other kinds of spaces. Note that unlike with other transformational commands, we do not use the destination space to determine the space that will be impacted by the Action. This provides a more efficient representation without any loss in generality, because it allows us to search for a source and target agent within other spaces and then create a connection without creating a separate selection. As the important structural feature of networks are the relationships themselves, not the nodes this provides a more direct way to specify these relationships.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_11"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection determines the agent that will be connected to another agent. In the case of a directed graph, this is the source node.</p>
+</div>
+<div class="section" title="=Destination">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name=".3DDestination_2"></a>=Destination</h6>
+</div>
+</div>
+</div>
+<p>The destination determines the agent that the selection agent will be connected to. In the case of a directed graph, this is the target node.</p>
+</div>
+<div class="section" title="Within">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Within"></a>Within</h6>
+</div>
+</div>
+</div>
+<p>Specifies the network that the connection will be created within.</p>
+</div>
+</div>
+<div class="section" title="Directed">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Directed_2"></a>Directed</h5>
+</div>
+</div>
+</div>
+<p>Determines whether the connection made is directed or not. If true, selections from source agents will include the target, but target agent selections will not include the source agents (unless they are connected through some other path).</p>
+</div>
+<div class="section" title="Disconnect">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Disconnect"></a>Disconnect</h5>
+</div>
+</div>
+</div>
+<p>Removes the connection between agents within a network space. See the description of the Connect Action for important details.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_12"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection determines one side of the agent relationship that will be disconnected.</p>
+</div>
+<div class="section" title="Destination">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Destination_3"></a>Destination</h6>
+</div>
+</div>
+</div>
+<p>The selection determines one other side of the agent relationship that will be disconnected.</p>
+</div>
+<div class="section" title="Within">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Within_2"></a>Within</h6>
+</div>
+</div>
+</div>
+<p>Specifies the network that the connection will be created within.</p>
+</div>
+</div>
+<div class="section" title="Replace">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Replace"></a>Replace</h5>
+</div>
+</div>
+</div>
+<p>Functions in the same way as a Connect Action excepth that all other connections to other agents will first be removed.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_13"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection determines the agent that will be connected to another agent. In the case of a directed graph, this is the source node.</p>
+</div>
+<div class="section" title="Destination">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Destination_4"></a>Destination</h6>
+</div>
+</div>
+</div>
+<p>The destination determines the agent that the selection agent will be connected to. In the case of a directed graph, this is the target node.</p>
+</div>
+<div class="section" title="Within">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Within_3"></a>Within</h6>
+</div>
+</div>
+</div>
+<p>Specifies the network that the connection will be created within.</p>
+</div>
+</div>
+<div class="section" title="Directed">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Directed_3"></a>Directed</h5>
+</div>
+</div>
+</div>
+<p>Determines whether the connection made is directed or not. See the Connect description for more details.</p>
+</div>
+</div>
+<div class="section" title="Other">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Other"></a>Other</h4>
+</div>
+</div>
+</div>
+<div class="section" title="Method">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Method"></a>Method</h5>
+</div>
+</div>
+</div>
+<p>The Method action supports inclusion of arbitrary code within a generated method. Generally, this will be Java code as all of the current target platforms are Java-based but there is no technical requirement that it must be. For example, if a target has been developed to produce code for Swarm running on an iPad (and no, there are no current plans to support such a thing, though it would certainly be cool!) then the modeler could define Objective C code for the method.</p>
+<p>Please note that the Method Action should be avoided whenever possible. You should consider using it only in the case where there doesn't appear to be a way to construct equivalent functionality using the native Actions framework, such as when interfacing with third party APIs.  The aim of Actions is to provide the most general support for Agent Modeling possible without compromising the core design. Any use of native Java code strongly limits the set of platforms that your model will be able to generate code for and prevents you from using the AMF edit tools to explore the model behavior. In the case where you wish to construct a model feature and believe that it isn't possible or practical to do it with Actions, please contact us (see support section) so that we can suggest how you can accomplish what you want within Actions. If that is not possible, we'll consider developing new features that will support what you want to do.</p>
+<p>On the other hand, you may simply wish to use the Agent Modeling Framework to build a scaffolding for your model -- perhaps using your own custom Java framework for example -- and Method would be a good way to accomplish that. Also, note there are a number of other approaches to mixing hand-crafted Java together with AMF generated code. Please see the Programmer's Guide section "Integrating Java and AMF Models" for more on that.</p>
+<p>If you do decide to use the Method Action, keep in mind the following design practice recommendations:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Keep your usage of external API references to a minimum. If you can use only code provied by the core Java classes as well as the Apache Collections library, your code should work on every current Java target. On the other hand, if you make use of a specific ABM platform APIs your code will obviously only compile and run against that target.</p>
+</li>
+<li class="listitem">
+<p>Code should be in the form of a method body, excluding the signature. A single Java method is created using this code body. There is no support for input parameters -- if you need access to evaluated values from source actions, create agent attributes for them, set their values for the selected agents, and use them as sources for your Method Action.</p>
+</li>
+<li class="listitem">
+<p>All Java class references should be fully qualified. For example, if you wish to use the eclipse Draw2D Graphics class, you should refer to "org.eclipse.draw2d.Graphics", not simply "Graphics". If classes are not fully qualified, you will recieve compile errors. You can usually easily fix these by selecting your source code directory and choosing 
+									<span class="bold"><strong>Source &gt; Organize Imports..</strong></span> but it prevents automatic code generation.
+								</p>
+</li>
+<li class="listitem">
+<p>The method interface has no support for code completion, syntax checking or other common Java development environment features. You can avoid code maintenance and even support targetting multiple APIs by using the following technique. From your method body, call a helper method in a seperate class. The referred class could use a static method call, or you could instantiate the class and call a method against it, passing in the agent class so that the helper class can reference the agent's state. For example, if you wanted to use some custom java code to import agents from a specialized input file, you could put the following code in the Method Action body for the root Context:</p>
+</li>
+</ol>
+</div>
+<div class="literallayout">
+<p>(new&nbsp;org.me.SpecialFileLoader()).load(this);<br>
+
+</p>
+</div>
+<p>Then create a new source directory in your project called "src" (
+							<span class="bold"><strong>New &gt; Source Folder...</strong></span>) and create the class for the specialized file loader including the following method:
+						</p>
+<div class="literallayout">
+<p>public&nbsp;void&nbsp;load(MyRootModel&nbsp;model)&nbsp;{...}<br>
+
+</p>
+</div>
+<p>This approach allows you to a) maintain the working code using the Java Development Environment, b) avoid changes to the Method Action within the model, and most importantly, c) allow other implementations of the code using multiple APIs. For example, if you need to create a specialized graphics routine, you could create seperate implementations for your Escape (Eclipse Draw 2D), Ascape (Java Swing), and Repast (Simphony API) and place them in the appropriate projects. As long as the different Java source files have the same names and signatures, they will all compile correctly and execute the appropriate behavior.</p>
+<div class="section" title="Selection">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Selection_14"></a>Selection</h6>
+</div>
+</div>
+</div>
+<p>The selection determines what Agent class the code will be created within and the set of agents the method will be called upon.</p>
+</div>
+<div class="section" title="Body">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Body"></a>Body</h6>
+</div>
+</div>
+</div>
+<p>The actual code to insert in the method body. See the detailed recommendations for code use above.</p>
+</div>
+<div class="section" title="Generate">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Generate"></a>Generate</h6>
+</div>
+</div>
+</div>
+<p>Determines wether the code is actually inserted. If this is false, a bare method body will be constructed instead. This can be useful if you wish to turn off method generation in certain model implementaitons without removing the actual code.</p>
+</div>
+</div>
+</div>
+<div class="section" title="Query and Evaluation Inputs">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Query_and_Evaluation_Inputs"></a>Query and Evaluation Inputs</h4>
+</div>
+</div>
+</div>
+<p>Query and Evaluation Actions are both "Sinks" which means that they are capable of containing inputs. When you select a function, the appropriate number of inputs will be created. After selecting a function, you can view and select the inputs. The choices for the inputs will be constrained by the type of the function and the other operands you've selected.</p>
+<div class="section">
+<div class="titlepage"></div>
+<div class="section" title="Input Literals">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="N1062F"></a>Input Literals</h6>
+</div>
+</div>
+</div>
+<p>Inputs can take literal values; that is values that you specify simply by entering them directly into the query. In general it is useful to think of literals as similar to local variables in a conventional programming language, whereas attributes are analogous to member variables. (And this is how they are represented in the generated Java code.) As with local variables in model code, literals are not recommended for any values that can change model behavior. The value cannot be easily accessed or changed by other model users. For greater transparency, you should instead create an Attribute with an appropriate default value, setting the "immutable" value to true. Still, literals can be useful for values that are special cases related to the evaluation or query, such as an input code, and for quickly prototyping functionality.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="section" title="Example">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Example"></a>Example</h3>
+</div>
+</div>
+</div>
+<p>In this section, we'll look at an example that should make clear how the basic Actions approach works in a model. Say we want to define a behavior like:</p>
+<div class="literallayout">
+<p>"Search&nbsp;for&nbsp;a&nbsp;random&nbsp;agent&nbsp;within&nbsp;my&nbsp;vision&nbsp;that&nbsp;is&nbsp;the&nbsp;same&nbsp;age&nbsp;as&nbsp;I&nbsp;am.&nbsp;Find&nbsp;a&nbsp;location&nbsp;next&nbsp;to&nbsp;that&nbsp;agent&nbsp;that&nbsp;is&nbsp;not&nbsp;already&nbsp;occupied&nbsp;and&nbsp;move&nbsp;to&nbsp;it."<br>
+
+</p>
+</div>
+<p>Here, we create a sequence of actions like so:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Select every agent for every period of the model. ("Find Partner" Rule)</p>
+</li>
+<li class="listitem">
+<p>For every member of that selection, search for other agents of the same age within vision distance. ("Partner" selection.)</p>
+</li>
+<li class="listitem">
+<p>From "Partners" find a random member and search for a neighboring locations. ("Partner Neighbor" selection.)</p>
+</li>
+<li class="listitem">
+<p>Finally, move the agent in "Find Partner" to the "Partner Neighbor" location.</p>
+</li>
+</ol>
+</div>
+<p>Now, notice that although it's convenient to speak as if there is only one "Find Partner" and one "Partner Neighbor" in step 4 above, in fact selections are flowing through for each of the results of each of the previous action sequences, and we can refer to each of the directly. We could represent these behaviors in many different ways. For example, we might want to specify the model in a (hand-drawn) graphical language or in a (made-up) textual language:</p>
+<p>
+					
+</p>
+<div class="mediaobject">
+<img src="images/actions/ActionsExample.png"></div>
+<p>
+				
+</p>
+<p>This is how it looks in an actual model:</p>
+<p>
+					
+</p>
+<div class="mediaobject">
+<img src="images/actions/ActionsExampleNew.png"></div>
+<p>
+				
+</p>
+<p>And here is how this works in detail:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Create a Rule that will trigger the behavior. In this case, we want this rule to apply to all "Individual" agents within the model. (Space isn't relevant in this case.</p>
+</li>
+<li class="listitem">
+<p>Create a child Select Action that will find our partner. Two important things to note here:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>The selection occurs based on the "Find Partner" selection. This means that for each Individual in the model, we'll be searching from the point of view of that agent to some other selection of agents.</p>
+</li>
+<li class="listitem">
+<p>We also need to define what type of agent we want and in this case the space does matter. We want to find an agent that is nearby within the City space. If instead we wanted to find a partner in a social network, we'd specify that instead.</p>
+</li>
+</ol>
+</div>
+</li>
+<li class="listitem">
+<p>Create two child Query Actions:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>We want to search for someone who is the same age as us. This highlights the importance of the idea of the Selection in the Actions design. We're qualifying Age by the rule agent's partner for the first input and by the rule agent for the second. The selection carries throughout the flow of execution and this context is an explicit part of the entire structure. Note that this is very different from the way control flow works in a traditional imperative language such as Java.</p>
+</li>
+<li class="listitem">
+<p>We also want to search using a function for nearness, "within", which takes a parameter of vision. Note that the spatial functions are all polymorphic -- if we decided later on that we would rather search within say "Kevin Bacon space", that is a graph structure representation of space, we would only need to change the space we've defined in Select Partner.</p>
+</li>
+</ol>
+</div>
+</li>
+<li class="listitem">
+<p>Intersect the results of these two query components. This delineates the end of the selection definition for any target Actions.</p>
+</li>
+<li class="listitem">
+<p>Select a neighbor. Again, we can see the importance of Selections. Here, we are selecting from the point of view of the partner, not the initial agent that the current Rule is being executed for. Note that this time our target agent is a "Block", that is, a location within the city.</p>
+</li>
+<li class="listitem">
+<p>As above, define some queries. This time we want only those agents that are:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>available, and</p>
+</li>
+<li class="listitem">
+<p>neighbors of our partner.</p>
+</li>
+</ol>
+</div>
+</li>
+<li class="listitem">
+<p>And another intersection..</p>
+</li>
+<li class="listitem">
+<p>Finally, we move to the location we've found. All that's required at this point is to specify:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="a">
+<li class="listitem">
+<p>The movement selection, or those agents that are moving, which in this case is the original agent we're executing the rule for, and</p>
+</li>
+<li class="listitem">
+<p>The destination, which is the cell that we've found. Note that the framework infers from the space definition that the Block agent is capable of hosting the Individual.</p>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="section" title="Reference">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Reference_2"></a>Reference</h3>
+</div>
+</div>
+</div>
+<div class="section" title="Diagrams">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="Diagrams_2"></a>Diagrams</h4>
+</div>
+</div>
+</div>
+<p>The following diagram may be helpful to readers familiar with UML and Meta-modeling:</p>
+<div class="section" title="Meta-Classes">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Meta-Classes_2"></a>Meta-Classes</h5>
+</div>
+</div>
+</div>
+<p>
+							
+</p>
+<div class="mediaobject">
+<img src="images/actions/ActionsDiagram.png"></div>
+<p>
+						
+</p>
+</div>
+<div class="section" title="Details">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Details_4"></a>Details</h5>
+</div>
+</div>
+</div>
+<p>In the diagram above, all meta-objects except for Input, Literal, and the enumerators (lists of options) are Actions. Blue meta-classes are concrete (you can create and use them directly). Red meta-classes are key collaborations.</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>An Act is anything that might happen during the execution of an Agent-Based Model.</p>
+</li>
+<li class="listitem">
+<p>All Actions have as their root-most source action a Root. These are added first to any agent behavior and act as triggers for all target behavior. For example, a Watch will execute any time the watched attribute is modified. (As the diagrams do not refer to elements outside of the current package, we cannot see here that Accessor includes a reference to some Attribute, but it does. To see these kinds of relationships you will want to refer to the metaabm.ecore file itself.)#Actions are targets and sources of one another, but an Act can never have itself as a source. (That is, Actions are acyclic, but branches can re-converge. When we refer to an Act source or target, we typically mean to include all ancestors or descendants, not just the immediately connected Act.)</p>
+</li>
+<li class="listitem">
+<p>All Actions (except for root Actions) reference a Select, referred to as the "selected" relation. An ASelect represents the model aspects that the Act is working within; that is, the spatial, temporal and type (agent) "world" that is currently being selected.</p>
+</li>
+<li class="listitem">
+<p>Commands trigger some model state change (Set) or spatial transformation (Transform).</p>
+</li>
+<li class="listitem">
+<p>Controls determine whether target Actions are executed and against what agents. They are in some sense query terms and include Query actions and Logic Actions.</p>
+</li>
+<li class="listitem">
+<p>Transforms also specify a "destination" Select. This represents aspects that the selected agent(s) will transform to. For example, a Move may use a Rule to select all SugarAgents (type) in the SugarGrid (space) every period (time) and move them to a destination of a neighboring SugarCell (type) in the SugarGrid (space, with time implicit).</p>
+</li>
+<li class="listitem">
+<p>Sinks are Actions which use some Function (see next section) to interpret state in the form of Inputs. Inputs can come from selected agent attributes, other Actions, or literal values.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="section" title="Functions">
+<div class="titlepage">
+<div>
+<div>
+<h2 class="title" style="clear: both">
+<a name="Functions"></a>Functions</h2>
+</div>
+</div>
+</div>
+<div class="section" title="Overview">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Overview_4"></a>Overview</h3>
+</div>
+</div>
+</div>
+<p>Functions are relatively simple in terms of model design, but we need to understand how particular functions work in order to develop models. Functions are divided in two ways. By type:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Operators are simple calculations sharing the same type.</p>
+</li>
+<li class="listitem">
+<p>Functions that can represent any general function that takes some well-defined input(s) and returns some well-defined output(s).</p>
+</li>
+</ol>
+</div>
+<p>And by usage:</p>
+<div class="orderedlist">
+<ol class="orderedlist" type="1">
+<li class="listitem">
+<p>Generics can return any value and are used in Evaluate actions.</p>
+</li>
+<li class="listitem">
+<p>Logicals return some boolean result and are used by Query actions to decide whether target Actions apply to a particular selection, and by Evaluate actions just as with any other functions. Input types should be defined as generally as possible.</p>
+</li>
+</ol>
+</div>
+<p>These overlap, so we have operators, logical operators, functions and logical functions. Functions are also divided into categories. We'll go through each of these in depth below.</p>
+<p>The most important thing to point out about functions is that - as we've seen with other Acore concepts -- they provide richer sets of functionality than traditional approaches. Many functions are designed to collaborate with one another as we'll see when looking at Spatial and Graphical functions. Functions can also trigger the creation of related model artifacts as we'll see with the Distribution functions.</p>
+<p>A technical note: conceptually, functions can return multi-values, but that is not currently implemented in the reference targets because of limitations of the target language Java.</p>
+</div>
+<div class="section" title="Details">
+<div class="titlepage">
+<div>
+<div>
+<h3 class="title">
+<a name="Details_5"></a>Details</h3>
+</div>
+</div>
+</div>
+<div class="section" title="General Functions">
+<div class="titlepage">
+<div>
+<div>
+<h4 class="title">
+<a name="General_Functions"></a>General Functions</h4>
+</div>
+</div>
+</div>
+<p>Naturally, the Modeling tools provide general functions for performing calculations, comparisons and more complex mathematical expressions. The function library can be easily extended, and we'll be adding additional capabilities over time. As always, we welcome feedback and we'd like to hear what functions you need that aren't covered here.</p>
+<div class="section" title="Logical Operators">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Logical_Operators"></a>Logical Operators</h5>
+</div>
+</div>
+</div>
+<div class="section" title="Not">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Not"></a>Not</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression !X.</p>
+</div>
+<div class="section" title="Equal">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Equal"></a>Equal</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X==Y.</p>
+</div>
+<div class="section" title="Identical">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Identical"></a>Identical</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X==Y.</p>
+</div>
+<div class="section" title="Greater">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Greater"></a>Greater</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X&gt;Y.</p>
+</div>
+<div class="section" title="Lesser">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Lesser"></a>Lesser</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X&lt;Y.</p>
+</div>
+<div class="section" title="Greater or Equal">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Greater_or_Equal"></a>Greater or Equal</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X&gt;=Y.</p>
+</div>
+<div class="section" title="Lesser or Equal">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Lesser_or_Equal"></a>Lesser or Equal</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X&lt;=Y.</p>
+</div>
+<div class="section" title="True">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="True"></a>True</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression true.</p>
+</div>
+<div class="section" title="False">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="False"></a>False</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression false.</p>
+</div>
+<div class="section" title="Identity">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Identity"></a>Identity</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X.</p>
+</div>
+<div class="section" title="Different">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Different"></a>Different</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X!=Y.</p>
+</div>
+</div>
+<div class="section" title="Numeric Operators">
+<div class="titlepage">
+<div>
+<div>
+<h5 class="title">
+<a name="Numeric_Operators"></a>Numeric Operators</h5>
+</div>
+</div>
+</div>
+<div class="section" title="Negative Value">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Negative_Value"></a>Negative Value</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression -X.</p>
+</div>
+<div class="section" title="Add">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Add"></a>Add</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X+Y.</p>
+</div>
+<div class="section" title="Subtract">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Subtract"></a>Subtract</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X-Y.</p>
+</div>
+<div class="section" title="Multiply">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Multiply"></a>Multiply</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X*Y.</p>
+</div>
+<div class="section" title="Divide">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Divide"></a>Divide</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X/Y.</p>
+</div>
+<div class="section" title="Power">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Power"></a>Power</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X^Y.</p>
+</div>
+<div class="section" title="Modulo">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Modulo"></a>Modulo</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression X%Y.</p>
+</div>
+<div class="section" title="Increment">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Increment"></a>Increment</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression ++X.</p>
+</div>
+<div class="section" title="Decrement">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Decrement"></a>Decrement</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression --X.</p>
+</div>
+<div class="section" title="Unit Value">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Unit_Value"></a>Unit Value</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression 1.</p>
+</div>
+<div class="section" title="Zero Value">
+<div class="titlepage">
+<div>
+<div>
+<h6 class="title">
+<a name="Zero_Value"></a>Zero Value</h6>
+</div>
+</div>
+</div>
+<p>The result of the expression 0.</p>
+</div><