Changing to different agent doesn't work_fixed

Discussion: This example illustrates what the “Change” action does: it changes the way an agent looks; it does NOT change one agent to another agent. It is a very common mistake that beginning students make when they want an agent to “morph” into another agent. One way to help students understand this is to use the analogy of a mask: does donning a mask of a famous person transform someone into that person? Obviously not. It only gives the appearance of that other person. The person wearing the mask still has all of the internal characteristics he/she possessed before donning the mask. So it is if an agent takes on the appearance, or shape of another agent. In this example, although the frog now looks like the superfrog, the frog is still just a frog, vulnerable to all the hazards as a normally appearing frog agent. In order to accomplish the desired transformation, it is necessary to actually create a new superfrog agent and remove (erase) the original agent. 'New agent ‘remembers’ key strokes: As an aside, when testing this, you might notice that if you press quickly on the right arrow key, the newly created superfrog continues to move onto the pellet, even though the original frog is supposed to simply be erased and replaced by the new superfrog at the same position. If the pellet is at the edge of the world, this might not be noticeable. Try moving the pellet to the left a few columns and then quickly tap the right arrow key. The new superfrog will usually move a few cells to the right of the pellet after it is created. Why is this? 'The explanation requires understanding how AgentCubes handles keyboard input. Because AgentCubes does not know a priori which agents respond to a specific keyboard input, the simulation processor retains the keyboard input long enough to allow each agent in the world to examine each keystroke. If the user presses keys quickly, it is possible for a newly created agent (as a result of keyboard-directed activity) to be presented with the keyboard input. If avoiding this “key queuing” phenomenon is important to the operation of the simulation, it may require some additional programming, as well as careful attention to world construction to minimize the effect. 'One technique is to construct the world like that in the example above, so that even though there are residual keystrokes, they do not have a noticeable effect on the behavior. 'Another technique is to “throttle” the rate at which an agent is permitted to respond to keystrokes. In the example below, a timing condition (once every 0.2 second) is inserted in the rule that responds to the right arrow key. This limits how often the frog agent can receive the right arrow key. With this behavior (in both the frog and superfrog agents), the extra keystrokes that are entered very quickly will be ignored. Summary: The “Change” action merely changes the way an agent appears, not the way it behaves. If the simulation requires that an agent assume the behavior of a different agent, then the original agent must be removed (“erase” action) and a new instance of the desired agent be created (“new” action). If the original and/or newly created agent responds to keyboard input, then attention must be paid to prevent unwanted movement of the newly created agent, such as by using a timer condition in the rules that respond to keyboard input.

By kyuhan