Clock problems_fixed

Discussion: These are examples of the consequence of having multiple timers with the same timer frequency. It helps to understand how timer events work. A “once every” condition can be interpreted like this: “Has this amount of time since the last time this condition was true?” Once the appropriate amount of time has elapsed, the condition remains true until the “once every” condition in that agent’s “While running” method is evaluated. Once that happens, the condition is no longer true. Thus, if the condition is evaluated, regardless of whether any other conditions in that same rule are true, the condition is now false for other rules below that rule. In the above example, therefore, every 0.5 second, the timer event will be true and the first rule’s condition will be satisfied, so the agent’s depiction will change to the green square. The second rule will never be reached. There are multiple ways to address this situation. One way is to insert a condition BEFORE the “once every” condition to create the decision of which change should occur. The probable intent of this agent behavior was for the agent to move back and forth like a clock pendulum. However, because the same time interval is used for both rules, the second rule will never have its action invoked, and the agent will move to the left every second. How can this be changed? In this case, since the agent does not change appearance, it is not possible to use that as a decision-making tool. Different agent shapes essentially carry “state” information about the agent; that is, the state of the agent is to have one shape or another. This means that the shape information can be used for decision making. In this current example, however, there is only one shape. In some project designs, there might be some other adjacent agent that can help discriminate between the two rules. However, in this example, there is no other information for such a determination. One way to resolve this is to use an agent attribute, which serves as the information bearer about the state of the agent. When the desired direction is to the left, for example, the attribute will have one value; it will have another value for the opposite direction. The default for an agent attribute before it is ever referenced or changed is zero. Below are two ways to use an agent attribute to effect the pendulum-like behavior for the “Mover” agent. The first technique uses the agent attribute as the condition preceding the “once every” timer event in the same way as the agent color was used in the preceding example:
Data
Created:May 28, 2015
Played:112
Agent:5
Rules:11
Methods:7
false
Settings
New Project Name
Rename
Copy
Download
Show Project Report
Flag Project
Delete
Discussion: These are examples of the consequence of having multiple timers with the same timer frequency. It helps to understand how timer events work. A “once every” condition can be interpreted like this: “Has this amount of time since the last time this condition was true?” Once the appropriate amount of time has elapsed, the condition remains true until the “once every” condition in that agent’s “While running” method is evaluated. Once that happens, the condition is no longer true. Thus, if the condition is evaluated, regardless of whether any other conditions in that same rule are true, the condition is now false for other rules below that rule. In the above example, therefore, every 0.5 second, the timer event will be true and the first rule’s condition will be satisfied, so the agent’s depiction will change to the green square. The second rule will never be reached. There are multiple ways to address this situation. One way is to insert a condition BEFORE the “once every” condition to create the decision of which change should occur. The probable intent of this agent behavior was for the agent to move back and forth like a clock pendulum. However, because the same time interval is used for both rules, the second rule will never have its action invoked, and the agent will move to the left every second. How can this be changed? In this case, since the agent does not change appearance, it is not possible to use that as a decision-making tool. Different agent shapes essentially carry “state” information about the agent; that is, the state of the agent is to have one shape or another. This means that the shape information can be used for decision making. In this current example, however, there is only one shape. In some project designs, there might be some other adjacent agent that can help discriminate between the two rules. However, in this example, there is no other information for such a determination. One way to resolve this is to use an agent attribute, which serves as the information bearer about the state of the agent. When the desired direction is to the left, for example, the attribute will have one value; it will have another value for the opposite direction. The default for an agent attribute before it is ever referenced or changed is zero. Below are two ways to use an agent attribute to effect the pendulum-like behavior for the “Mover” agent. The first technique uses the agent attribute as the condition preceding the “once every” timer event in the same way as the agent color was used in the preceding example:
Edit Description
Design