UPDATED OXPS: Lave 1.70 & transports 2.45(new)

[Kaks]

@Commander MacLane: I'll see if I can figure it out, that auto_ai business is fairly tricky... good to know there's a shipdata solution for that!

@all: just tested transport.oxp with the ai changes: I attacked a woma, then ran away towards a nearby coral starliner - the woma's escorts hit the coral by mistake then both woma, coral, and all escorts had a battle between them while I discreetly turned back to watch. Well worth getting an offender status for!

Transports.oxp v2.44, compatible with 1.70 coming up!. Available in the usual places (top of this thread, and inside the wiki) real soon now.

Edit: I re-read Comander MacLane's post and yes, the non-bugfix I suggested disables auto_ai only for escorts. It would make sense if auto_ai was fully switchable, though. I doubt my non-bugfix will be added to Oolite as it is!

[Eric Walch]

Or get your solution of making autoAI a default false for escorts (but for escorts only!) working. That would spare us the workarounds (and my Sentinel Asteroids would probably the daylight once...).

Things have nothing to do with auto_ai. Auto_ai was introduced in version 1.69. The described behaviour was also happening before and escorts have always been forced into an escortAI. I even think the code is now overwriting the autoAI settings later on in the code. Better remove it there and let the auto AI do its work. And default to yes so old escorts work as they always have done. Now there are a lot of escorts with buggy AI codes in place. But the bugs never occurred because the custom escort script was never used.

[JensAyton]

auto_ai, in its current form, is only intended to apply to ships generated with addShip: and related methods. But since the default is now auto_ai=yes, it would probably make sense to apply it to the various hard-coded AI settings as well.

[Eric Walch]

auto_ai, in its current form, is only intended to apply to ships generated with addShip: and related methods. But since the default is now auto_ai=yes, it would probably make sense to apply it to the various hard-coded AI settings as well.

I don't see any harm but only good things in doing so. But some AI settings still need to be hard coded. I experimented a lot with traders with custom AI. I added the switchAI: command in the launch_actions. Now the populater adds them to the system and I switch it back to my custom AI. (there defined two in UPS) Most custom AI's have a destination to the station because they are traders. But sometimes the populater launches traders from the station itself and gives them a special AI of leaving the station.
Problem with switchAI: and traders is that also this AI is overwritten by the custom AI and the just launched trader turns and re-docks. I tried to check for the "LAUNCHED_OK" message but that one reaches the old AI and launch_actions happen after this message.
This problem is cosmetic only, but just an example of that this launchingTraderAI should stay hardcoded.

[Kaks]

I got it kind of working on my homebrew version of Oolite:

On my computer, if you add auto_ai=NO; (or <key>auto_ai</key><false />) to an escort definition, the escort's ai starts up with whatever you've defined in ai_type. If you haven't defined ai_type - or you haven't added any auto_ai to the ship's definition - the escort starts with the standard escortAI.

It works very well if the escorts are chosen with escort-ship, but there's a couple of bugs still there if you choose the escorts with escort-role.

Would such a system be genuinely useful for OXPs, or is it something just a minority (me & Commander McLane) feel the need for?

[Commander McLane]

It would be genuinely useful for all OXPs which feature escorts with custom AIs. And that's quite a lot of OXPs.

auto_ai, in its current form, is only intended to apply to ships generated with addShip: and related methods.

But even this is fine, because in most cases ships with escorts that have a special AI are added via addShips: and related methods. So e.g. for my Sentinel Asteroid it would be a good solution instead of the launch_actions thing. I should try to set its autoAI to false and see what happens.

@Kaks: Can I do this in vanilla 1.70, or is the problem that for any escorts the autoAI-value specified in shipdata is overridden and set to true by the engine?

[Eric Walch]

It works very well if the escorts are chosen with escort-ship, but there's a couple of bugs still there if you choose the escorts with escort-role.

This is a bug I reported else where. The role of all type of escorts is set to escort after addition. Only ships with escort-role keep their role. But within the escorting function there is an explicit check that escorts must have a role of escorts or they are not accepted.

This is why I used tricks in the new Leviathan.oxp to force his escorts back to role escorts to get them working.

[Kaks]

Hi, I'm a bit in a hurry atm(RL), so I might forget a word or two as I write. Apoligies in advance!


in vanilla 1.70 it works differently depending on what you use in the mothership definition:

escort-role (via addShips) checks autoAI of the escorts. sets AI up accordingly, and then kills that ai & replaces it with the standard escortAI

escort-ship doesn't check autoAI, sets the AI according to ai_type then sets the AI to escortAI

So adding auto_ai false to vanilla 1.70 doesn't do anything to the escorts.

Got to rush! Won't be around the board for a little while - about 2 days, but see you all soon!

Edit: @eric yes, my homebrew for escort-role, after doing its thinking, sets the main role to escort or the equivalent police role. So they get accepted by Mum! The moral of the story? Always put escort(0.00001) in any escort ship's role!

Cheers,

Kaks

[JensAyton]

Kaks’s patch for auto_ai support for escorts will be in 1.71. Starting with 1.71, it will thus be possible to give an escort a custom AI by setting auto_ai to false. Additionally, the custom AI will immediately be set to its FLYING_ESCORT state, if it has one.

dit: @eric yes, my homebrew for escort-role, after doing its thinking, sets the main role to escort or the equivalent police role. So they get accepted by Mum! The moral of the story? Always put escort(0.00001) in any escort ship's role!

This shouldn’t be necessary, since it’s valid to set the primary role to a role that’s not in the ship’s predefined role set. It will be considered to be part of the role set until the primary role is changed.

For example, if a ship whose role shipData.plist entry is "trader" is generated as an escort, its effective role set will automatically change to ["escort", "trader"]. If the role is subsequently changed to "trader" (for instance, via JavaScript), the effective role set will become ["trader"].

Edit: clarification.

[Kaks]

Thanks for clarifying that point. I wasn't 100% sure about a couple of things, so I tried to err on the side of caution.

And thanks for sorting out my patch properly!

[Ark]

Today I saw something strange and I want to mention it.

There was a woma convoy with a fuel transport and 4 escorts but it was something strange so I move closer to observe. The transport was moving forward normally but the 4 escorts were immobile, spinning around their axis (like in the demo screen) and did not follow the transport (not much of an escort I guess )

[Captain Hesperus]

Today I saw something strange and I want to mention it.

There was a woma convoy with a fuel transport and 4 escorts but it was something strange so I move closer to observe. The transport was moving forward normally but the 4 escorts were immobile, spinning around their axis (like in the demo screen) and did not follow the transport (not much of an escort I guess )

Sounds like their AI was stuck in 'frustrated' mode. Like when they attack you and you hit the Cloak.

Captain Hesperus

[Kaks]

Hmmm, interesting... I wonder if the escorts were going too fast & spun around while waiting for the woma to catch up...

Did you try to attack the woma? What happens when you do?
If you see that again, could you log their ai state (target one of them then shift+h)?

Cheers,

Kaks

[Eric Walch]

Sounds like their AI was stuck in 'frustrated' mode. Like when they attack you and you hit the Cloak.

There is a bug in the AI scripting of default escorts. After the second attack round they end up in a AI-state without update state. I send this bug already some time ago to the Berlios bug site.

[Ark]

Hmmm, interesting... I wonder if the escorts were going too fast & spun around while waiting for the woma to catch up...

No the oposite. the woma was in his course to the station and its escort were left behind .... dancing !!!!!

Did you try to attack the woma? What happens when you do?
If you see that again, could you log their ai state (target one of them then shift+h)?

I am afraid that i didn't do anything of the above. I was stunned from the spectacle . But if i am to see that again i will