Oolite Bulletins

I never thought of using launch_actions to change the AI...interesting.
setup_actions could be used for more general, non-escort applications.

-
group defence question:
yeah, getting ships to behave as a coherent group is a problem.
I asked about adding methods and handles to manually assign ships to custom groups. IIRC in the code requests thread.

have you tried using scanForHostiles iso scanForOffender, this may work, but just as easilly could just scan only for ships agressive towards the scanning.object.

Today I looked at AI the scripts of transports transports v2.1 and Executive Spaceways v2.1.oxp

Both OXP's add escorted ships that don't work. i can shoot at them but the escorts don't react. When I made an objectdump I saw that the AI of the mainship stayed in the "HEAD_FOR_PLANET" state and never left it when I fired at them.

Looking at the script I saw that it was almost a copy of the route1TraderAI.plist But nor quite the same. For some reason the used the line:

ATTACKED = (broadcastDistressMessage, fightOrFleeHostiles);

And in the route1TraderAI.plist the line

ATTACKED = (fightOrFleeHostiles);

is used. So I removed the "broadcastDistressMessage" from that line and restarted Oolite. When I found the ships, the escorts became orange on my first laserbeam .

Somehow the command "broadcastDistressMessage" resets the target so it sees no hostiles in the second command. Very strange that the authors never saw this. But there are more changes with the route1TraderAI.plist that are not logical.

The most likely thing I can come up with is that they copied the route1TraderAI.plist from an old oolite version were it worked. Oolite evolved and the old route1TraderAI.plist didn't work anymore. The one within oolite was adapted so it still worked but the old copies stopped working. That is the risk of writing your own AI instead of pointing to an existing one that always will be updated with the program.

EDIT: I tested this with oolite 1.65

here's the AI from the santa v2 oxp, it might be one you've missed as it's not an obvious oxp to check for escorts. It seems to work ok as long as you've given santa and the reindeer enough time to sort out their formation before you wade in with all lasers blasting!

I've got a vague memory that the line

UPDATE = (groupAttackTarget, performAttack);

was the key to getting all the escorts to attack you if you attacked santa or one of the other escorts, not sure who worked that out, A_H or LB possibly, i'm pretty sure it wasn't me! Either way what's cool is that santa makes make a run for it leaving the escorts to battle you whether you attack him directly or not.

I've got a vague memory that the line

UPDATE = (groupAttackTarget, performAttack);

was the key to getting all the escorts to attack you if you attacked santa or one of the other escorts,

The scrips will also run without the "groupAttackTarget" command. All the scripts for ships with escort I studied the last day work without it. I think the escort automatical attack as the mother performs a "performAttack" or a "performFlee".

here's the AI from the santa v2 oxp, it might be one you've missed as it's not an obvious oxp to check for escorts. it seems to work ok as long as you've given santa and the reindeer enough time to sort out their formation before you wade in with all lasers lasers blasting!

I just downloaded the Santa OXP v2 you mentioned. However it refused to start up. I looked in it with the plist editor and it showed that the shipData.plist had errors. Looking through the listing I found with the last ship:

<key>has_escape_pod</key>
<real>false</real>
<key>has_scoop</key>
<real>false</real>
<key>has_shield_booster</key>
<real>false</real>

That is wrong syntax. It must be:

<key>has_escape_pod</key>
<false/>
<key>has_scoop</key>
<false/>
<key>has_shield_booster</key>
<false/>

Maybe it works under windows, but the mac-version of oolite also checks the .plist syntax and refuses to start scripts with wrong syntax in it. Probably to prevent crashes as result of a wrong syntax. So any file I can not open with the plist-editor will never work on a mac-oolite.

Not strictly true. If the normal plist parser fails, Oolite tries its own hacked-together one (known as the ad-hoc parser). The ad-hoc parser will be going away after the next stable release, though, and the test releases make a point of logging noisily about files that rely on the ad-hoc parser.

The next stable version will possibly also refuse to load property lists which parse but have values of the wrong type (schema validation, a feature developed as part of the OXP validation support I’ve been working on).

Cheers Eric, i must have been on the Christmas Sherry or something whilst copying out that .plist! I've fixed those problematic <key>'s now and added your fix for the mission offering screen conflict that can occur.
I've re-uploaded the .oxp here http://www.box.net/shared/mcmeur2axl

<real>false</real> ...'real' values should be a logic number I think, 0 or 1.

Not strictly true. If the normal plist parser fails, Oolite tries its own hacked-together one (known as the ad-hoc parser). The ad-hoc parser will be going away after the next stable release

Maybe not strictly true and also depending on version number I asume, but I only did oolite programming with the mac version 1.65. And if I see a ship I am working on hanging still in space it is always that I made a typo in the script that prevent the AI to be loaded. And sometimes the normal script didn't do anything when it should do something. When I then looked in it with the plist-editor it refused to open and I had to look with a normal text-editor for the typo's that then were present.

That is a big advantage of the plist editor. You can not make structure typos. But I miss the quick overview so I also do a lot of writing in a normal editor. I use the plist-editor that came with the mac installation disk for syntax check.

Arexack_Heretic wrote:

I never thought of using launch_actions to change the AI...interesting.
setup_actions could be used for more general, non-escort applications.

If you have a kind look to the third link I posted above, namely this one, you will see that even back then Ahruman answered to your idea of using setup_actions. To quote him again right here:

Ahruman wrote:

Arexack_Heretic wrote:

or use "setup_actions" to script "setAITo: myAI.plist"

No. setup_actions are executed too early.

Ah insightfull.

I missed that comment.

You're welcome. After all, this kind of collective memory is what fellow boardmembers are for, isn't it?

indeed!

And setup_actions are still usefull for forcing co-spawns and such.

And still, launch_actions for some reason don't work with turrets. (I've never actually tested other types of sub-entities, so I can't honestly say anything in general about that, but turrets definitively don't work.).

How exactly does it not work?

-turrets won't appear or function if object is called by launch_actions.
-turret initialisation of an object does not work if it is done in launch_actions.
-ect.

In the second case, small wonder, and no problem, you just need to put the initialisation in the setup_actions.

In the first case, I theorise it is a similar problem as with subentities/ flashers on missiles.