search

mrmin123 / kancolle-auto

Kantai Collection (Kancolle) bot/automation tool - DEPERECATED - see kcauto-kai:
https://github.com/mrmin123/kcauto-kai
54 stars 22 forks source link

Submarine switching going overboard #346

Closed R-Jimenez closed 7 years ago

R-Jimenez commented 7 years ago

Please read the FAQ/Common Issues section of the README before opening a ticket. Please remove sections of this template you do not find relevant when creating your ticket.

Environment details

Issue

Is the issue consistent (can be reproduced consistently) or is it transient (only happens sometimes)?: Consistent.

Despite not being assigned to the submarine switching list, I have witnessed both I-13 and I-14 being switched in to fill out sub slots.

Relevant config snippet (if applicable)

[SubmarineSwitch]
Enabled = true
EnabledSubs = ss, i-19-kai, i-26-kai, i-58-kai, i-8-kai
ReplaceLimit = 
FatigueSwitch = true
mrmin123 commented 7 years ago

I actually can't reproduce this... The above settings works fine in only swapping out those specific subs on my end.

R-Jimenez commented 7 years ago

It's definitely still happening on my end. I'll throw some planes back on them and see if that might shake things up.

mrmin123 commented 7 years ago

Just so you know, stats no longer play a role in identifying subs. It IDs off of the ship's names.

R-Jimenez commented 7 years ago

I see. Hrm. Will keep monitoring and see if I can't get a first-hand view of it happening. Right now I have only my two main subs and the I- twins in my active fleet. Rest on expedition.

mrmin123 commented 7 years ago

I should note that if it does look at ship stats to try and ascertain whether they're subs or not, that's old code behavior... It's entirely possible that even though the codebase was updated, the compiled *.pyc files are of the old code, although arguably that still shouldn't work because I'm pretty sure I removed the defunct assets.

R-Jimenez commented 7 years ago

I may have stumbled upon another bug while trying to force a sub switch.

If you start the script with a sub (or presumably any ship) in the docks, it will attempt to launch the sortie, run the fleet condition check, and only read the damage for ships not under repair. Then it'll head back to home after realizing it can't launch, and start the regular loop, until returning back to the sortie menu. Repeat ad infinitum. Perhaps before the first loop there should be a stop at the repair docks during initialization, or include "under repair" as a fleet condition enum?

Going to just bucket her up and change the repair limit to see if I can't force the original issue in front of me.

R-Jimenez commented 7 years ago

Yep, issue is still present. Script goes to top free sub (I-13) and clicks away. Configuration is as listed above.


←[94m[2017-03-26 19:08:29] Found ship that is under repair!←[0m
←[94m[2017-03-26 19:08:32] Ship is a submarine!←[0m
[log] CLICK on L(419,338)@S(0)[0,0 1920x1080] (521 msec)
←[94m[2017-03-26 19:08:33] Checking shiplist sort order and moving to first page
 if necessary!←[0m
[log] CLICK on L(770,227)@S(0)[0,0 1920x1080] (520 msec)
[log] CLICK on L(435,567)@S(0)[0,0 1920x1080] (521 msec)
[log] CLICK on L(456,457)@S(0)[0,0 1920x1080] (524 msec)
←[94m[2017-03-26 19:08:48] Swapping submarines!←[0m
[log] CLICK on L(711,575)@S(0)[0,0 1920x1080] (521 msec)
←[92m[2017-03-26 19:08:59] All submarines (under repair) successfully swapped ou
t! Continuing!←[0m```
mrmin123 commented 7 years ago

Enter a console message into the code to identify which sub is being identified as a match. Line ~614 in combat.py, after 

                        for enabled_sub in self.submarine_switch_subs:

Put in 

print enabled_sub

Run again, and check the console for when it swaps to i-13/i-14. It should tell you what it was looking for. Then match that image against the shiplist using the debug mode using 0.95 similarity and report back..

As for the other looping issue, that's old behavior from before recovery and such were implemented... back then you as the user had to make sure that your fleets were set up properly before running. This is still the case, although problematic now because of automatic recovery. Dunno when I'll get to addressing this.

mrmin123 commented 7 years ago

Better yet, make it print out fleetcomp_shiplist_submarine_img after it gets set

R-Jimenez commented 7 years ago

Roger. I'll get some more logging for you after dinner and groceries. o7

waicool20 commented 7 years ago

Also a suggestion for the sub switch module while you're at it is to save which slots (1..6) are SS(V) on the first scan, then just use the cache to switch subs. Just for a potential speed up. Clear cache when switching fleetcomps. Or a less automagical way is to just set all of ship types in the slots in the config.

R-Jimenez commented 7 years ago 
fleetcomp_shiplist_submarine_i-8.png
i-58
fleetcomp_shiplist_submarine_i-58.png
i-19-kai
fleetcomp_shiplist_submarine_i-19-kai.png
[log] CLICK on L(455,457)@S(0)[0,0 1920x1080] (520 msec)
←[94m[2017-03-26 22:40:08] Submarine not available, moving on!←[0m
[log] CLICK on L(460,577)@S(0)[0,0 1920x1080] (521 msec)
i-26
fleetcomp_shiplist_submarine_i-26.png

Unless I'm reading the log wrong, seems like it clicks on I-13 as a match for I-19-kai? Print statements are placed at the beginning of the sub switch loop as requested. I-14 was not matched by any of the enabled subs, so it seems like it might just be her sister.

muromachi commented 7 years ago

Since my issue is similar, I thought I would add on to this rather than making an entirely new ticket. The gist is that Mizuho Kai is being switched out for a sub at red morale.

Environment details

kancolle-auto version (date on first line of your CHANGELOG.md): 2017-03-17 Viewer/browser: Chrome / KC3Kai Operating system: Windows 10 Issue With Mizuho Kai in the 5th position, undamaged, kcauto attempts to switch it out at red morale as it thinks it's a submarine.

Code snippet: [2017-03-28 23:37:30] Found ship that is highly fatigued! [2017-03-28 23:37:34] Ship is a submarine! [log] CLICK on L(681,586)@S(0)[0,0 1366x768] (525 msec) [2017-03-28 23:37:35] Checking shiplist sort order and moving to first page if necessary! [log] CLICK on L(716,589)@S(0)[0,0 1366x768] (521 msec) [log] CLICK on L(827,589)@S(0)[0,0 1366x768] (526 msec) [2017-03-28 23:37:47] We are seeing available submarines! [log] CLICK on L(705,423)@S(0)[0,0 1366x768] (520 msec) [2017-03-28 23:37:50] Can't replace with this sub type! [log] CLICK on L(702,599)@S(0)[0,0 1366x768] (521 msec) [log] CLICK on L(718,563)@S(0)[0,0 1366x768] (520 msec) [2017-03-28 23:37:57] Swapping submarines!

The "ship that is highly fatigued" is Mizuho Kai. The "can't replace with this sub type" is because it attempted to switch Mizuho Kai out for an I-168 which was already in the fleet at the 2nd position. Kcauto then switched out Mizuho for a I-58 which was the next sub on the list.

Is the issue consistent (can be reproduced consistently) or is it transient (only happens sometimes)?: Consistent. This happened each time the program was run until FatigueSwitch was set to False. It was specific to Mizuho Kai, the other ships (Akagi Kai, Teruzuki Kai, Haruna Kai, Chiyoda Kou K2) were not affected. I don't have a MIzuho dupe so I cannot confirm if this applies to Mizuho non-kai as well.

Relevant config snippet (if applicable)

[SubmarineSwitch] Enabled = True EnabledSubs = ss ReplaceLimit = FatigueSwitch = True

Btw, since it's my first time reporting an issue, just want to thank you very much for all the work you put into kcauto - I have benefited a lot from it (:

waicool20 commented 7 years ago

@muromachi You can up the number on this line (13): CLASS_SIMILARITY = 0.7 # Ship class icons in combat.py to prevent class misidentification, I find a value of 0.76 works most reliable for me, give or take.

mrmin123 commented 7 years ago

@muromachi you can use the debug function to figure out the threshold you need to set. I tested it on my end with 2 SSVs (1 sparkled, 1 normal) and 2 AVs (1 sparkled, 1 normal) and got the following results, with the sparkled AV and non-sparkled AV being matches 3 and 4, respectively, both below the default value for CLASS_SIMILARITY of 0.7:

+  Sikuli match object for 'ship_class_ssv.png' in window 'Chrome'
+    with minimum similarity of 0.6:
M[644,261 26x26]@S(S(0)[0,0 1600x900]) S:0.79 C:657,274 [-1 msec]
M[644,374 26x26]@S(S(0)[0,0 1600x900]) S:0.76 C:657,387 [-1 msec]
M[303,261 26x26]@S(S(0)[0,0 1600x900]) S:0.66 C:316,274 [-1 msec]
M[303,487 26x26]@S(S(0)[0,0 1600x900]) S:0.64 C:316,500 [-1 msec]

If your results are different, you should run the same test and set a threshold as recommended.

This is the command I used btw:

debug_find('ship_class_ssv.png', 'Chrome', 0.6)  # For debugging purposes only!

@R-Jimenez you'll have to do something similar. Use this debug command:

debug_find('fleetcomp_shiplist_submarine_i-19-kai.png', 'Chrome', 0.7)

and figure out what the needed cutoff is. The cutoff is defined on line 616 of combat.py. I personally got the following results:

+  Sikuli match object for 'fleetcomp_shiplist_submarine_i-19-kai.png' in window 'Chrome'
+    with minimum similarity of 0.7:
M[376,438 155x14]@S(S(0)[0,0 1600x900]) S:1.00 C:453,445 [-1 msec]
M[376,298 155x14]@S(S(0)[0,0 1600x900]) S:0.86 C:453,305 [-1 msec]
M[376,354 155x14]@S(S(0)[0,0 1600x900]) S:0.83 C:453,361 [-1 msec]
M[376,326 155x14]@S(S(0)[0,0 1600x900]) S:0.81 C:453,333 [-1 msec]
M[376,270 155x14]@S(S(0)[0,0 1600x900]) S:0.80 C:453,277 [-1 msec]
M[376,382 155x14]@S(S(0)[0,0 1600x900]) S:0.80 C:453,389 [-1 msec]

with the first 1.00 match being for my actual i-19-kai, showing that the other subs would be correctly excluded at 0.95.

R-Jimenez commented 7 years ago

So, changing the similarity seems to have taken care of the problem. .7 seems a bit low, so I'm curious if there's a reason it's that low by default? Is it just to safeguard against sikulix not OCR'ing right now and then? What kind of circumstances might arise if I keep it above .9?

muromachi commented 7 years ago

Thanks! I ran the test, Mizuho Kai is right on the dot at 0.7. Chiyoda Kou K2 is the 0.69, I think. It didn't pick up my I-58, but I noticed you looked for ssv, not ss.

If I set it to look for ss:

The only similarity is I-58. MIzuho Kai is ignored.

Thanks! I will play around with the similarity if I need to.

R-Jimenez commented 7 years ago

One thing I noticed however when playing with the class similarity is that if I pushed it higher to .9 or .95, it for whatever reason stops recognizing the SSV icon in the fleet comp screen. It sees an SSV is under repair, but then says it's not a submarine (This is with "all" enabled in sub switching config).

mrmin123 commented 7 years ago

@R-Jimenez the default similarity for the shiplist is 0.95, not 0.7. The only things at 0.7 damage and ship class images. kancolle-auto's default is 0.8. You don't want to match everything by 0.9~1.00(exact) because some assets cannot be matched exactly. Sparkling and fatigue affect fatigue/damage/ship class matches. The background of the shiplist and where your ship is relative to that list affect ship class matches. Apparently exact match %s differ from machine to machine, as well, which makes this even more difficult to pin down.

If you push the class similarity threshold 0.9 or 0.95, when even if your true positives only hit ~0.7 (which is what people seem to be getting), you're basically excluding all your true positives, so you are never going to have a matched sub. Your threshold is simply set too high.

mrmin123 commented 7 years ago

Also @R-Jimenez you shouldn't need to modify CLASS_SIMILARITY if your issue was on the shiplist. CLASS_SIMILARITY is only for ID-ing whether or not a ship is a SS or SSV in the context of the fleetcomp screen and PvP screen. You were having issues at the shiplist stage, which, as I mentioned previously, is defined on line 616:

                            fleetcomp_shiplist_submarine_img_matches = findAll_wrapper(self.kc_region, Pattern(fleetcomp_shiplist_submarine_img).similar(0.95))

(note the 0.95)

mrmin123 commented 7 years ago

Since this will not result in any changes to master I am closing this.