Oolite Bulletins

Request to the code wizards: Would one of you have the kindness to explain to me (once more, as parts of it have been explained in various contexts), how pauseAI: is exactly working?

As far as I have understood so far, it is like this: pauseAI: is only executed in the UPDATE-part of every AI-state. Therefore, if inserted into any other part, it won't behave as expected.

What I haven't yet understood is this:

1. If there are other appearences of pauseAI: in other parts of an AI-state, will the engine remember them? And execute them as soon as it reaches the UPDATE-part?
2. Will this be done cumulative? If e.g. the AI searches for the closest ship in range, and there is a pauseAI: 5.0 in the TARGET_FOUND-part, then tests for the found ship's legal status, and there is another pauseAI: 5.0 in the TARGET_OFFENDER-part, will the AI pause 10 seconds during the next UPDATE?
3. What if the TARGET_OFFENDER-part sets the AI to another state, like ("pauseAI: 5.0", "setAITo: ATTACK_SHIP"). Will the 10-seconds-pause be transferred and executed in the UPDATE-part of the ATTACK_SHIP-state?
4. What exactly does "pause" mean? Does the AI really pause, i.e. don't do anything, don't react to messages during that time? So what happens if I attack a NPC that just has entered into a pauseAI: 20.0-method? Will it defend itself only after 20 seconds?
5. If this is not the case, and I assume it to be not the case, or else most of the NPCs would be lame ducks most of the time: which AI-messages do reach the AI during a pauseAI: and will therefore trigger an immediate response? Which AI-messages will not?
6. In case of triggering an immediate response and therefore "waking up" the AI from its current pausing: What happens to the pausing time that is left at this very moment? Is it reset? Or is it somehow stored, so that (in the example above) the AI will pause for the remaining 18 or so seconds as soon as it reaches another UPDATE (or at any later time)?

Answers to these questions would help me improving the AIs I have written so far. E.g. I have just encountered a situation where I attacked a Renegade Station. Its defense ships were launched as expected, but only after more than a minute. So I am wondering whether this could be caused by accumulated pauseAI:-methods.

The pauseAI: interval method sets the “next think time” of the AI to now + interval. This effect is not cumulative.

The “next think time” defines when the AI will next “think”. “Thinking” involves reacting to the UPDATE message, then reacting to any queued messages.

Reacting to a message is always instantaneous. Urgent messages, like ATTACKED, are reacted to, i.e. handled instantly. Less urgent messages, like TARGET_FOUND, are queued, i.e. handled immediately after the next UPDATE.

In effect, the AI’s “thinking” can be thought of as an idle activity timer, and pauseAI: specifies when that timer will fire. It has no effect on urgent messages. Note in particular that pauseAI: does not suspend execution of the current message handler, nor does it stop handlers other than UPDATE from being executed before the timer fires.

Thanks!

I think this may cause lot of OXPers to re-think their current AI programming. At least it does, as far as I am concerned.

I noticed that I also put it wrong in the description of the state-machine:

http://wiki.alioth.net/index.php/State_machine

Pause is not added to the update-time, but as Ahruman says: the new update time is the current time plus the pauseAI time.

In the statemachine description I had also put an example to demonstrate an other unexpected behaviour. The line: looks strange as most people will think that nothing will be read in after a switching states command. But just as with the pauseAI, the whole line is always executed. Even the commands after a "setStateTo:". The new state is only used on the NEXT update moment. Except the ENTER line which is executed immediately. Read and try to understand the example that I only created for educative purposes as it has no practical use.

so...the timer works similar to SetDesiredRange (or whatever) in that it has only a single value, namely the last mentioned before it is executed?

ie
"pauseAI: 1", "pauseAI: 2"

Gives a wait of 2 seconds in UPDATE, not 3 seconds.

Arexack_Heretic wrote:

so...the timer works similar to SetDesiredRange (or whatever) in that it has only a single value, namely the last mentioned before it is executed?

ie
"pauseAI: 1", "pauseAI: 2"

Gives a wait of 2 seconds in UPDATE, not 3 seconds.

Exactly!!