Security change for AIs

Screet · Post by **Screet** » Mon Oct 12, 2009 1:36 pm

Hi,

I've found some troubles with oxp's that did use setAI recently. It's easy to make a subtle mistake and not be aware of it, thus I'd like some security change in oolite to prevent problems:

1) When a request is made to switch/set AI from AI A to AI A then simply change that AI state and probably also add a warning message to the log.
2) When circular AI requests are made (like AI A to AI B to AI A) then fall back to the requested AI which was suspended and exit the others. Also change that targets AI state and probably also add a warning message to the log.

I guess both cases can even be handled by one check if the check keeps both cases in mind. Furthermore, for case 2 it would be very difficult to prevent this from inside an oxp.

That would prevent unnecessarily growing AI stacks and AI overflow problems. Maybe that way the current AI limit could even be drastically reduced (if that helps in some way).

Screet

JensAyton · Post by **JensAyton** » Sat Oct 24, 2009 1:09 pm

I’m not clear on what problem you want to solve.

Screet · Post by **Screet** » Sat Oct 24, 2009 1:17 pm

Ahruman wrote:
I’m not clear on what problem you want to solve.[/list]

The AI overflow problem. Some missiles do change the AI - and previously this did cause trouble when too many missiles did hit the same target. I've fixed that oxp by checking if that AI is already active - then nothing happens. However, this is no good fix: Multiple hits by different missiles cannot be detected this way. Other scripts also do change the AI, adding up to the AI stack.

Furthermore, if an AI itself does call another AI and that again calls another AI, it's also not possible to stay safe in a proper way, as it's difficult from outside oolite to determine wether the AI to change to is already somewhere further down in the stack.

That's why I asked to add a safety check to that functionality within the Oolite code: if the requested AI is already on the stack somewhere, simply go back to that one.

Screet

Wiki pages · Post by **Thargoid** » Sat Oct 24, 2009 1:39 pm

Or just set a maximum size to the AI stack, and report an error if it's exceeded? Or simply teach people better the difference between setAI and switchAI?

JensAyton · Post by **JensAyton** » Sat Oct 24, 2009 1:49 pm

Thargoid wrote:
Or just set a maximum size to the AI stack, and report an error if it's exceeded?

Oolite already does this.

Screet · Post by **Screet** » Sat Oct 24, 2009 2:18 pm

Ahruman wrote:
Thargoid wrote:
Or just set a maximum size to the AI stack, and report an error if it's exceeded?
Oolite already does this.

But that won't help to avoid the situation. IIRC L once got that error and had a massively spammed log.

Screet

Post by **Eric Walch** » Sat Oct 24, 2009 3:26 pm

Screet wrote:
Ahruman wrote:
Thargoid wrote:
Or just set a maximum size to the AI stack, and report an error if it's exceeded?
Oolite already does this.
But that won't help to avoid the situation. IIRC L once got that error and had a massively spammed log.

Screet

But it is logged, so the scripter knows there is probably something wrong and he can correct it. I think the maximum stack size is about 32. Sounds high enough for me as a normal script would never put that many AIs on stack.

Post by **Kaks** » Sat Oct 24, 2009 4:21 pm

To reiterate, the spammed log is due to some logic fault within the OXP code.
Once that OXP code is fixed, you'd get no more spamming & no more potential overflow.

As if by magic!