Tactical Combat AI Mod

[harpy eagle]

For the project of breaking up CloseAndAttack.lua, you probably want to create a couple new lua files, and then mark all of those files as dependencies of CloseAndAttack.lua by including the appropriate depends calls in CloseAndAttack.lua.

Cool, I'll definitely try that out.

[sven]

For the project of breaking up CloseAndAttack.lua, you probably want to create a couple new lua files, and then mark all of those files as dependencies of CloseAndAttack.lua by including the appropriate depends calls in CloseAndAttack.lua.

That said, there's a bit of a bug here, because if you're working inside a Mods/ subdirectory, the game is potentially going to get a bit confused by the fact that there are now 2 different CloseAndAttack.lua files that it knows about.

Given the way I set things up; *distributing* mods via the Mods/ subdirectory ought to more or less work; but, *developing* mods is almost certainly more comfortably done by editing the core game files in Lua state\.

As I said in my post on git, in theory, it would be pretty straightforward to write a perl script or something that would automatically export a modder's work into a sharable Mod directory, if we assume that you've been storing your work in git as a 'branch' off the official vanilla version of Lua state.

Unfortunately, this strategy would require that modders get used to using git; and git's a bit of a beast, so perhaps that's a bit much to ask

edit: Though, from your Mod naming convention, I suspect you may already be using git, in some capacity, to manage your own diffs? So maybe it /would/ be useful to write up that export script?

[sven]

That said, there's a bit of a bug here, because if you're working inside a Mods/ subdirectory, the game is potentially going to get a bit confused by the fact that there are now 2 different CloseAndAttack.lua files that it knows about.

Um, it's awkward, but there is potentially a simple fix for this, if you do want to work inside a Mods/ subdir... Just rename your modded CloseAndAttack.lua file to something else

[harpy eagle]

Well, I broke up the file while working inside the mod directory, and nothing bad happened. I guess my copy of CloseAndAttack.lua took precedence? When you say the game becomes 'confused' what is it that can go wrong, exactly?

I prefer to write my mods in a way that I only include the actual functions that are changed, so I don't usually work from the Lua State folder other than to look at things.

[harpy eagle]

An update to the indev version: I've made a whole lot of changes under the hood, split the mod into multiple files, plus some code cleanup.

Also found and fixed an important bug that was preventing carriers from launching craft except at point blank range in most cases (it was introduced in 1.1, so 1.0 is still fine for everyone not on the in-development branch).

[zolobolo]

Error in DEV track in interceptor priority evaluation

Save is located here: https://www.dropbox.com/s/g6iudf9oxylls ... 2.rar?dl=0

[zolobolo]

Sub-optimal behaviour: Yoral Destroyer moves too close and gets destroyed by reaction fire before being able to deal any damage itself

Save is here: https://www.dropbox.com/s/0yy7kfjrc6dzn ... 3.rar?dl=0

[zolobolo]

Assault Shuttles do not engage (Raid or Board) after the first attack.
Behavior seems to be blocked afterwards independently if the first action was Boarding or Raiding

Save for this (cannot be reproduced in all cases): https://www.dropbox.com/s/34d7fa9rctzud ... 4.rar?dl=0

[harpy eagle]

bugs

Fixed the first one, couldn't reproduce the second. I've been fixing a few other issues I found since my last upload, it's possible that whatever was causing the transport to misbehave has been fixed as well.

There are a few things that will cause a transport to not attempt to board:

• If the assault shuttle module is destroyed.
• If the transport is retreating.
• If the transport has less than 15-30 crew left.

Sub-optimal behaviour: Yoral Destroyer moves too close and gets destroyed by reaction fire before being able to deal any damage itself

I'm not sure if there's any good way to get the AI to evaluate hostile autofire, so I'm going to call that out of scope for this mod.

[zolobolo]

Bug and Transport issue resolved with 1.1

Below shows that Strike Fighters are not prioritized against the Fleet Carrier
Might be because they are considered as interceptors rather then bombers? Even if so, if both squadrons and carrier are in range, the squadrons out in the open should usually be prioritized (unless they cannot cause damage) due to the carriers think shield correct?

Currently, the de-priorization of the squadrons is the reason the attackers loose the fight (if shield regen mod is also applied, else the shield just keeps on ticking forever)

Save is the classical:
https://www.dropbox.com/s/34d7fa9rctzud ... 4.rar?dl=0

[zolobolo]

Would it be possible to limit the tactical speed of the weakest ships to that of the slowest vessel (usually the capital ship) so that they do not rush ahead without covering fire?

This would of course best work with proper formations best but the above in itself should reduce unnecessary losses to destroyers, frigates and military transport ships

[harpy eagle]

Below shows that Strike Fighters are not prioritized against the Fleet Carrier
Might be because they are considered as interceptors rather then bombers? Even if so, if both squadrons and carrier are in range, the squadrons out in the open should usually be prioritized (unless they cannot cause damage) due to the carriers think shield correct?

Looks like it was an issue with an iterator that I wrote, that was causing the choose move target function to fall back to vanilla behaviour of choosing the closest enemy ship.

[zolobolo]

Looks like it was an issue with an iterator that I wrote, that was causing the choose move target function to fall back to vanilla behaviour of choosing the closest enemy ship.

Works like a charm again thanks

This case is usefully for testing behaviour of carrier + Planetary defense vs small group of ships with military transport
Hard criteria is that the attacker wins, and optimized in way that their losses by doing so is minimal

For comparison:
Vanilla result: Attacker looses the battle and looses all ships
Current result: Attacker wins the battle via loosing 3 Destroyers and 2 Light Cruisers. Defending Fleet carrier survives the battle by retreating damaged

When translating the current losses into resources, it costs the attacker 60% Mineral of a Fleet Carrier and round 80% production of a Fleet carrier

A player could realistically not win the battle without loosing 3 Destroyers and at least 1 Light Cruiser

[harpy eagle]

For comparison:
Vanilla result: Attacker looses the battle and looses all ships
Current result: Attacker wins the battle via loosing 3 Destroyers and 2 Light Cruisers. Defending Fleet carrier survives the battle by retreating damaged

Yeah, simply including craft in the list of things the AI might want to move it's towards really makes a huge difference in the ability of the AI to shoot down bombers. Same thing for torpedoes as well.

It's actually to the point where the code that I have for the retreating logic, which uses the raw damage output of weapons in it's assessment of the relative fleet power, seems to massively overvalue bombers and especially torpedoes.

[harpy eagle]

Would it be possible to limit the tactical speed of the weakest ships to that of the slowest vessel (usually the capital ship) so that they do not rush ahead without covering fire?

This would of course best work with proper formations best but the above in itself should reduce unnecessary losses to destroyers, frigates and military transport ships

I actually just got some ideas for how this might be done, to help the AI to keep it's ships together. It kind of relies on the AI's ships already being in a good formation to begin with though.

Another thing to try would be to decouple the AI's move order for it's ships from it's shoot order. So tougher ships move first while without affecting when the more damaging ships shoot.

I kind of want to avoid making such a big change at this point but it might be worth it...