AI invasion problems

Describe your experience with the latest version of FreeOrion to help us improve it.
Forum rules
Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
Post Reply
Message
Author
User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

AI invasion problems

#1 Post by mem359 » Mon Mar 27, 2017 6:53 pm

EDIT by Vezzra: split thread from here.
Dilvish wrote:it will help if we can get some more experienced players helping playtest Morlic's Fighters vs Planets PR and giving feedback on it.
I made a note on the Morlic's PR, based on 1 game. (Looks okay to me.)

I did notice one thing (spying with the Super-Tester and looking through the AI_log).
It is probably unrelated to those changes, but it does concern the AI decision making

A Chato_AI decided it wanted a Mu Ursh system near its homeworld. (Right choice!)
The Mu Ursh system had 26 defending troops. The Chato_AI created a goal of having 26 troops. (Seemed to be procrastinating on building them, long after the warships beat down the defenses, but maybe the AI had other concerns.) It then eventually sent those 26 troops to invade, got the Mu Ursh to 0 defending troops, then started building ships for 10 more troops. After those were built, it then invaded with all of them (overkill). I'd think that the AI should have requested more than 26 troops to start with, and/or not use so much troop overkill.

Edit: This is the sort of line I noticed in the AI log:

Code: Select all

2017-03-27 14:17:27.692831 [debug] AI : LoggingWrapper.cpp:23 : Insufficient invasion troop allocation for system 19 ( Stern β ) -- requested {'rating': 0, 'troopCapacity': 26.0} , found {'rating': 0.0, 'troopCapacity': 22.0}
Last edited by mem359 on Mon Mar 27, 2017 7:03 pm, edited 1 time in total.

Morlic
AI Contributor
Posts: 238
Joined: Tue Feb 17, 2015 11:54 am

Re: 0.4.7 preparations

#2 Post by Morlic » Mon Mar 27, 2017 7:02 pm

Thanks for the report. Again, a log would be helpful to identify the issue.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

Re: 0.4.7 preparations

#3 Post by mem359 » Mon Mar 27, 2017 7:14 pm

Morlic wrote:Thanks for the report. Again, a log would be helpful to identify the issue.
Attached a log.
This is the same seed game I've been using the past 2 weeks:
cluster, 180 stars, seed: Vuu18W41, Gysache species

If you use the Supertesters, the Chato is the first AI to be encountered, due "East" (homeworld Kephra).
Attachments
ai_log.tar.gz
Chato AI log, gzipped and tarred
(1.01 MiB) Downloaded 23 times

Morlic
AI Contributor
Posts: 238
Joined: Tue Feb 17, 2015 11:54 am

Re: 0.4.7 preparations

#4 Post by Morlic » Mon Mar 27, 2017 7:20 pm

This PR may fix the issue but it is hard to test.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

Re: 0.4.7 preparations

#5 Post by mem359 » Mon Mar 27, 2017 10:10 pm

Morlic wrote:This PR may fix the issue but it is hard to test.
This is getting real interesting.
Or real ugly, if it has to be tracked down.
I still think the AI is playing better now, compared to a week ago, so hopefully this won't slow down the 0.4.7 plans.

Same seed game.
Similar compiled game as earlier ("master" from today, plus Morlic's fighter-v-planets PR #1434).
Made the 2-line change to the AI invasion python code (PR #1444), which does not require rebuilding the rest of the code.

Attached is the save game at Turn 65, and the AI log for turns 65-75.
Ignore the SuperTester (home) empire. Just focus on the Chato around Kephra.
The spawned monsters might be different, but the Chato has been behaving the same for 3 retries, so hopefully others will see this too.
state_turn71.jpg
Turn 71
state_turn71.jpg (212.78 KiB) Viewed 431 times
What's going on here... Stern Beta 3 has the Mu Ursh planet with 26 troops. The Chato have a 20 troop fleet in orbit, along with warships.
Adhil Beta has a Hhhoh planet (troops but no defense), while Sunna Alpha has defense and troops (Tae Ghirus?). There used to be a 20 troop fleet sitting at Sunna Beta (??), but now it is circling south from Adhil Alpha. There is also a fleet with 8 troops at Kephra.
state_turn74.jpg
Turn 74
state_turn74.jpg (60.04 KiB) Viewed 431 times
By turn 74, the 20 troop fleet (that started at Sunna Beta) decided to not join Stern Beta, and instead went straight west, got hammered by Sentinels at Procyon, before circling back north to return to Sunna Beta (??). It never makes it, as there are more monsters waiting to destroy it. The 8 troop fleet from Kephra is heading up, instead of helping subjugate the Mu Ursh.

Looks like the AI is getting a bit confused about which troop ships are going where.
Attachments
chato_choices.tar.gz
gzip-tar of save game (turn 65) and AI log
(888.66 KiB) Downloaded 25 times

Morlic
AI Contributor
Posts: 238
Joined: Tue Feb 17, 2015 11:54 am

Re: 0.4.7 preparations

#6 Post by Morlic » Mon Mar 27, 2017 11:37 pm

Great setup to test stuff on.

There definitely are quite some issues here. Not sure when I find the time to fix them, probably will try this weekend.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Morlic
AI Contributor
Posts: 238
Joined: Tue Feb 17, 2015 11:54 am

Re: AI invasion problems

#7 Post by Morlic » Tue Mar 28, 2017 7:07 pm

Another 1-line change seems to fix the issue for me.

After loading the save with the changes applied, the AI invades Stern Beta successfully and leaves the other invasion fleet at Sunna Alpha.
Can't thoroughly test it at the moment due to lack of time. There may be side effects, I am not too confident with all the fleet mission related code.

Basically, the AI rightfully realized that it can't move through the monster system (yay!)... and then proceeds to issue the movement order to the next system obviously having to move through the system guarded by the monster... Yeah, that's not going to work too great.

Code: Select all

2017-03-28 01:34:36.831951 [debug] AI : LoggingWrapper.cpp:23 : Checking order: [move] of F_1410<Fleet 1410> to S_312<Procyon> in progress
2017-03-28 01:34:36.834951 [debug] AI : LoggingWrapper.cpp:23 : CAN'T issue fleet order [move] of F_1410<Fleet 1410> to S_312<Procyon> in progress
2017-03-28 01:34:36.834951 [debug] AI : LoggingWrapper.cpp:23 : Checking order: [move] of F_1410<Fleet 1410> to S_101<Menkib> in progress
2017-03-28 01:34:36.836951 [debug] AI : LoggingWrapper.cpp:23 : Issuing fleet order [move] of F_1410<Fleet 1410> to S_101<Menkib> in progress
2017-03-28 01:34:36.837951 [debug] AI : Order.cpp:374 : FleetMoveOrder::ExecuteImpl Setting route of fleet 1410 to  19 312 101
So, this fixes the suicide intentions of the AI... I have absolutely no idea why this appears to also fix the other fleet's movement. Isn't programming fun?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply