ВЕРНЫЙ IS DEAD

[stackhanovets]

It was quite nice tool, btw. But there was a bug with Taiha detection on Verniy. I've just left the script overnight, and I was shocked. But I was ready for something like that. Lv. 2 for retreat, lv. 2 for repair. Be careful with that, so I'm kuso now.

Looks like there's sort of recognition issue on some iterations for ships with light templates. Or it may be caused by the multi-repairing loop issue, so that's worse.

[stackhanovets]

Nice pic comes here:

Ну, что. Был Верный и нету Верного.

[mrmin123]

@stackhanovets Sorry to hear that :( I thought the damage tally system was functioning pretty well but apparently there were gaps. I'll have to do some testing to figure out if I can figure out a fix... It clearly failed on both the post-combat result screen as well as the pre-sortie check (both use the same checks, just on different locations) so it's clearly not a one-off issue. Being in the last location clearly did not help Verniy either, despite it being probably the best position to the damage checks in because you don't have damaged ships from below billowing smoke into your icon.

Again, sorry for your loss, and thanks for reporting it.

[mrmin123]

I dunno what to say. I deliberately damaged Verniy then ran a debug function against it in both the post-combat results screen and the pre-sortie screen. dmg_critical.png matched with a score of ~100% almost every time I tried. Maybe just a really unlucky match % there...

I did lower the the dmg_similarity to 0.65 from 0.75 and increase the area searched by tally_damages, however, to hopefully reduce the chances of this happening in the future.

[AppleBoi86]

@stackhanovets Sorry for your loss.
Hopefully mrmin123 is able to locate this problem to avoid future similar case.

[stackhanovets]

Thank you guys. I'm fine. But these things must not happen again. Sounds good @mrmin123 has debugged Sikuli, so the recognition wasn't a problem. But it means also there's a bug in the algorithm. Please take a look:

Looks like Верный has sunk on the I node, I cannot make a connection between the score and sinking. Unfortunately, I haven't specified any output logging. But the script hasn't crashed, it just stuck on the C node. Nevermind.

So I've noticed some strange things. At large iterations (15+) the script's behavior has becomed weird. Pre-sortie check was organized pretty good, so the Taiha detection was strong. But the after-combat condition check was performed ON the results screen with laaarge score letter, NOT at a click after, just as a human will do. So the results were like "Undamaged" for all ships and the repair queue was empty before the pre-sortie check. You know, I've used the dummy for grinding 1-5 w/ 4 ships, 2-3 w/ 1 SS, 3-2A leveling, so that was sort of the first real testing in an "aggressive" mode.

I have an another pic:

I didn't even touch this fleet since then. 4 ships with full HP. Looks like @mrmin123 has to test the multi-repair algorithm for heavily damaged fleets, just to avoid the situation like this (warning, shock-content is related): https://youtu.be/yx6TVJBahBU

Will keep reporting.

P.S. Я угробил единственную русскоговорящую посудину в игре. Конечно, ощущения не самые приятные. Я знал, на что иду.

[mrmin123]

OK, so I think I have an idea of what happened now thanks to this line:

But the after-combat condition check was performed ON the results screen with laaarge score letter, NOT at a click after, just as a human will do.

Image recognition was always working fine, but kancolle-auto ran tally_damages mid-sortie at the wrong time.

For a background, this is what kancolle_auto does for combat and mid-sortie damage checks: loop_post_combat() is looped through until combat is over, which is ascertained by the presence of the retreat button, the next button in lower right, or the alternative next button in lower right. Let's assume, for simplicity, that the enemy fleet was wiped out and the script saw the next button, which would indicate that it's at the big Score screen you mentioned. At this point, the script clicks the screen to get away (wait_and_click(global_regions['next'], 'next.png', 30, expand_areas('next')), waits for ~3 seconds (sleep(3)), then tallies the damages (self.tally_damages(combat=True)). There's no check to see if whether or the click to get past the score screen is successful (I figured there was never a need for this since I never experienced a delay at this point)

If, for some reason, kancolle_auto clicks the score screen, and the subsequent damaged ships do not show up OR the click is not recognized and the score screen persists, the script will not be aware of this and simply do a tally_damages, which obviously results in 0 damaged ships since none of the damage icons are on the screen. Even in case of a click failure/click recognition failure, the script is robust enough to deal with any number of next buttons so it can click through everything and continue.

I do have a proposed fix for this (check for a fixed element only visible after clearing the score screen before running tally_damages), but it's still not a guarantee for the second fleet in combined fleets because there is no consistent change between the two screens.

To address some of your other points:

• The script being stuck at node C is expected, since node C is a node selection map, and I'm guessing that you did not have a node selection image specified in the config
• The repair issue of kancolle-auto sometimes fixing the incorrect ships is a known and will-not-fix behavior.. it's also considered ok because the pre-sortie tally_damages is expected to find if a ship is still damaged, and the script will automatically loop back and fix ships under the threshold until it can sortie (again, this is expected and desired behavior as far as I'm concerned). It's certainly an issue if the pre-sortie tally_damages fails, but I see no indication of that happening here
• Not sure what would be causing the 'weirdness' after large iterations. I've personally run this script for over 3 days without stopping it in the past with no issues.

[mrmin123]

I just realized that if you're using KC3Kai with subtitles, the subtitles can cover up the last ship in the post-combat results screen, rendering image recognition useless. I strongly recommend that subtitles be disabled or the subtitle size lowered 13px or lower (found in KC3Kai Settings, Game Window section).

[lainconnue]

Sorry for your loss man, don't know how i would have reacted (being a newbie ttk had never suffered a sunken ship). Thanks mrmin for the swift response and fix.

[stackhanovets]

Верный is dead. Long live Верный!

@lainconnue Thank you for a compassion, but it's still a game after all.

@mrmin123 tl:dr: I think there was an algorithm error though. There wasn't the subtitle issue you're talking about, here come some of my KC3Kai settings:

Let me explain. I've got a catbomb just before the KanColle's update and I got rid of that only by F5 when the maintenance has ended, nothing special as you see, But when you're refreshing the browser without the KC3Kai restart, the subs engine crashes. No engine, no subs, no possible interference w/ Sikuli's recognition. I have restarted Chrome just when the subj happened, so the subtitles engine worked fine for a while. After some time there was sort of a bug at the pvp script conduction, so I've decided to refresh the page w/out closing the tab/browser, the voiceline and quest translation were disabled just as I said. I haven't updated/changed anything yet and it just works with some mess in KC3Kai tracking.

I think there is should be a point about the last ship's Taiha/KC3Kai subtitles interference in wiki after all.

[mrmin123]

If subtitles weren't active, the only thing I can assume is that tally_damages was run before the results had loaded. I've already patched in a fix for this, but beyond that, there isn't much more I can do. You speak of 'algorithm error's but provide no proposed fix or actual identification for the cause of failure. I can't fix undesired behavior I've never seen, and even if I have seen it, if it's an incredible edge-case that requires a fair amount of processing to check for, I'd hesitate incorporating it.

For the record, I did lose a ship when I first implemented the combat module. I've not lost a ship since then, however, nor have I heard any other reports of ships being sunk until this one. kancolle-auto is not foolproof, but it's pretty good at making sure your ships don't sink. Other external factors might screw this up, but that is beyond the control of kancolle-auto and no amount of coding can account for everything ahead of time, and even if an issue is known there might be no viable solution given the constraints we're working with. You take a risk of getting banned by using this tool, and you also take the risk of losing ships by using this tool.

The README has already been revised to include information regarding the subtitles.