KCAuto not handling heavily damaged flagship

[Danielosama]

Environment details

• kcauto version (version on first line of CHANGELOG.md): v8.1.0
• Operating system and/or VM: Windows 10

Issue variability

Consistent

Issue

After the flagship gets heavily damaged and the fleet is forced to retreat, KCAuto will stop, seemingly not realising that the fleet has retreated and waiting.

Log

All best,

[XVs32]

Hello,

This is probably because the push node logic is overriding everything.

I will upload a git diff to fix this(am kinda busy at the moment).

Sincerely, XVs32

[XVs32]

After a quick run, my local version works just fine handling flagship heavily damaged case.

Plus I don't see Continuing sortie. or Retreating from sortie. in your log message. Which means the push node function did not take over the control.

I suspect kcauto_custom couldn't find the "combat_flagship_dmg.png". Could you run it again with addition --debug-output flag? We would need more info to solve this.

Sincerely, XVs32

[Danielosama]

After a quick run, my local version works just fine handling flagship heavily damaged case.

Plus I don't see Continuing sortie. or Retreating from sortie. in your log message. Which means the push node function did not take over the control.

I suspect kcauto_custom couldn't find the "combat_flagship_dmg.png". Could you run it again with addition --debug-output flag? We would need more info to solve this.

Sincerely, XVs32

Hello,

Sure, no problem.

Where exactly do I add --debug-output ? At the end of the python command?

It would look like this cd C:/kcauto_custom && python kcauto --cfg 3-2 --debug-output

EDIT: nevermind, I figured it out (it was correct to put it a the end). I have launched the script, let's see if it happens again.

[Danielosama]

Well, it happened again:

Here is the log:

(Thanks, I downloaded and delete the log, cause a full log could leak a lot of user info. XVs32) EDIT: oh right, should have thought about that. Thanks.

Happened around [2023-08-31 18:34:35]

All best,

[XVs32]

Hi Danielosama,

You issue is very likely due to network delay.

Every time kcauto navigate back to home page, the kancolle server will send a port api updated to us, this is one of the info which shows that you are currently at home page.

In this case, the time out is 3 sec. Which means, after kcauto press the last mouse click that send you back to home page, if kcauto doesn't receive the api update from kancolle server in 3 sec, we are in trouble.

Here is my log:

 Fleet 1 / Heavy fleet damage / No Fatigue
 Akigumo (Heavy damage)
 Check for Port API.                                                                                                           
 Begin waiting for API payload(s).
 Check for Port API. 
 Begin waiting for API payload(s).
 Check for Port API.
 Begin waiting for API payload(s).                                                  <= back to home page at this point
 Waiting for request ******.****** (http://***.***.***.***/kcsapi/api_port/port)    <= port api update
 Request ******.****** received
 ...
 ...
 At home

And here is your's:

Fleet 1 / Heavy fleet damage / Heavy Fatigue
伊203 改 (Heavy damage) : I-14 Kai (No Damage damage) : 伊504 (Scratch damage) : I-13 Kai (No Damage damage)
Check for Port API.
Begin waiting for API payload(s).
Check for Port API.
Begin waiting for API payload(s).
Check for Port API.
Begin waiting for API payload(s).          <= back to home page at this point
Between nodes.                             <= no port api is found, kcauto thinks it is still in sortie
Wait for combat API.

Sure I can increase the time out to more than 3 sec but kcauto is run upon all these APIs listening, I am sure you will run into another similar problem if your network stays the same. (Actually I've hit a similar problem another day due to I underclocked my cpu, as a result it couldn't handle the api in time)

Sadly I don't have a good solution here...

1. A combat logic rework could potentially solve the problem but 99% of those code comes from the original kcauto. And any logic bug in the combat module could cause lose ships so I am not planning to do this in the near future.
2. Upgrade/stabilize your network could help but after all the server is far in Japan so there is not much we can do....

Sincerely, XVs32

[Danielosama]

Hello @XVs32 ,

Thank you very much for everything.

Funnily enough, this used to happen in the original KCAuto too; I sent some messages to Perry back in November 2021, saying how KCAutoKai would get stuck if the Flagship got heavily damaged in the last combat node, or at the node you specified to retreat (all those messages can still be found on the Discord server).

Another user found a solution to it, here it is:

(this always worked without any issue btw)

Maybe it helps you.

All best,

[XVs32]

Hi Danielosama,

Thank you for your effort. That user did a great job debugging this, https://github.com/perryhuynh/kcauto/blob/master/kcauto/combat/combat_core.py#L326

That timeout=3 on line 328 is exactly the 3 sec I was talking about.

His code looks just fine and I believe it could work in kcauto_custom too, although on project management fount, this has to be defined as a temporary fix. (It adds logics but doesn't remove those redundant, this could damage readability, and the combat module is already a spaghetti...T_T)

But... As I said in the previous post, I am not going to redo the combat logic in near feature, so I might include this fix for now, maybe you will see this in the next update.

Sincerely, XVs32

[Danielosama]

Fyi, I tried the above fix in KCAuto-custom, and it works fine.