escort-role is not working.

[Eric Walch]

The last week I have been busy in understanding how the escort functions work in detail. (By browsing through the source code). This leaded to a preliminary manual for users:

Escort Instructions

It is still preliminary and if someone thinks I should improve it at some point by adding things, please say so.

By looking at the code I stumbled over two bugs. First of all: escort-role could never have worked. All escorts have a role of "escort". Even ships added with escort-ship get the role of "escort" by the system. Only escort-role ships keep their original role.

But the commands escortCheckMother and suggestEscort only accepts escorts with role escort. This means other escorts will be rejected as escort. I couldn't believe it, but I checked it by creating such an escort. Escort-role escorts immediately jump out of the "FLYING_ESCORT" state and into the "LOOK_FOR_BUSINESS" state. And a few seconds later they have a route1PatrolAI.plist. because they don't find the mother.

This bug must always have been there and strange nobody noticed it as these escorts could never have been working. The 1.65 sourcecode has the same bug. By looking at several escort OXP I couldn't find one that used this way of adding an escort by role but a lotof people must have been trying.

There is a easy solution for the problem:

In the sourcefile SchipEntity.m in the function setUpEscorts just before the command:

[escorter setRoles:escortRole];

it needs a check: if( mother is police) then (escortrole="wingman") else (escortrole="escort")

------

I'll put it also on berlios. The second bug I already added there yesterday.

[Commander McLane]

I have struggled very much with escorts myself, and I think posted here several times that they are not working as I would expect (e.g. here, here, and I think I have posted a lengthy explanation of the problem somewhere, but I don't find it now). So I did notice that my escorts are never working. This is one of the main reasons why I couldn't yet release Anarchies.oxp 1.0.

Of course I could never identify the source of all my trouble, as I am not a coder. So I am very thankful for your hints.

May I send you my AIs and shipdata, so you can look whether my specific problem can be solved within the existing framework or not?

[Eric Walch]

I have struggled very much with escorts myself, and I think posted here several times that they are not working as I would expect (e.g. here, here, and I think I have posted a lengthy explanation of the problem somewhere, but I don't find it now). So I did notice that my escorts are never working. This is one of the main reasons why I couldn't yet release Anarchies.oxp 1.0.

I had read them in the past and was aware of it's existense. At that time however I hadn't a clue how escorts worked. Just past week I looked into it and discovered some strange things. One of them is that the AI stack must be <2 for escorts to proper work. On initial adding the AI stack size is 0. When you do a setAITo: the stack is raised to 1. Just enough. But with an other setAITo: the escorts wont work anymore.

But using setAITo: in launch_actions is wrong. But setAITo: is equivalent with a jumpSubRoutine. And when there is no return it makes no sense although it will work. the AI stack size has a maximum of 32. So after 32 times using a setAITo: for an AI you get a bug.

In launch_actions you should use switchAITo: This does the same as setAITo: but also resets the return stack to zero. Now you can't return to the previous AI, but that was never intended. Both commands were always explained correct in the wiki. In my launch_action example I also used the wrong command as example. I've corrected this last week.

May I send you my AIs and shipdata, so you can look whether my specific problem can be solved within the existing framework or not?

Put it in my mailbox as text.

[matt634]

From the Oolite-PC board -

I frequently observe 4 escorts in formation (leader missing) heading for the WP

I encountered this same problem while play testing my OXP in Version 1.65 on a Mac. I would script a medical transport or frigate to appear in the space lane, and on my way to meet it, I would encounter the escorts, flying in formation towards the witchpoint. After an entire, frustrating, afternoon of trying to locate the source of the problem I gave up and moved on to other things.

Then, while working on my shipdata.plist, I noticed that some times I had used <key>escort-ship</key> and other times I had used <key>escort-role</key>. The escort-role key turned out to be the problem. Ships using the key escort-ship had no problems, where as ships using the key escort-role experienced the problem quoted above - switching them fixed the problem.

[Commander McLane]

One of the sources of the "lonely escorts" problem can be that in some OXPs escort-cascades are used: A capital ship is given some escorts, and those are spawned with escorts again. An example for that is the ixianships.oxp, where the ixian_battle_cruiser has 2 ixian_escort as escort_ship (working key). The ixian_escort itself has again 2 ixian_bezerka as escort_ship. The result are 4 lonely Ixian Bezerkas, because escorts can't have escorts, if I'm correctly informed here. (Another OXP that makes heavy use of these cascading escorts is orb.oxp. Of course also this doesn't work.)

I am not sure, however, why cascading escorts don't work. It could be (1) hard-coded, as some kind of limitation, or it could simply be (2) that all escorts are given escortAI, which has no methods to work as a mother and lead other escorts. If it's the latter, a switchAIto in the first escort's launch_actions could give it a custom AI that has methods for both escorting and mothering.

[Eric Walch]

I am not sure, however, why cascading escorts don't work. It could be (1) hard-coded, as some kind of limitation, or it could simply be (2) that all escorts are given escortAI, which has no methods to work as a mother and lead other escorts.

It is a combination of 1 and 2. The commands escortCheckMother and suggestEscort both call a pairing function that explicit checks that the mother has not a role of escort.

But by starting with a ship with escorts they have already a mother and writing an escort script without those two functions one must be able to let escorts follow other escorts. But the original escortAI must be bypassed with a switchAITo: (Never tested it, but I think it could work. I the past have created normal escorts without using those two functions escortCheckMother and suggestEscort.)

[matt634]

I think that the key defense_ship_role is suffering from the same problem as escort_ship_role.

When I use the defense_ship_role key for my SecCom Stations the defense ships will launch, perform a 180 and redock. But, when I use the defense_ship key, the defense ships launch and attack as usual.

[Eric Walch]

When I use the defense_ship_role key for my SecCom Stations the defense ships will launch, perform a 180 and redock. But, when I use the defense_ship key, the defense ships launch and attack as usual.

I see no bug in the code at this point. It must be something in your AI, I am pretty sure. Probably you are somehow throwing away the target it got from the SecCom on launching.

The problem with escort_role is that throughout the code the system always assumes escorts have role escort. To get accepted as escort the role must be escort and attacking an escort is only sets the ATTACKED with the mother when it has role of escort.

[matt634]

You're right as usual. And, as usual my AI skills (if you can call mindless trial and error a skill) are found to be lacking.