Fix: refactor reward mail support

[nEEtdo0d]

Issue with collecting multiple merit type items / mails in the same screen since objects were classified as the same according to the Filter module. Hadn't encountered this with my prior testing as my sample images only had one merit or one of each type displayed.

Refactored to scan, collect one, and then repeat until all collected or exhausted 5 tries.

Takes extra screenshot on 2nd iteration onwards as picture on exit in _reward_mail_collect_one provides an image that cannot successfully predict. Seemingly, the next screenshot is sufficient though.

[LmeSzinc]

Late for reply, there is something about the first PR.

1. Do not delete viewed mails.
2. Split out mail to a its own file.
3. Check mails once a day is enough, so mail should be a standalone module or a part of exercise task

[nEEtdo0d]

1. Do not delete viewed mails.

Okay, mind if I make this a configurable to turn on and off? Default will be off.

2. Split out mail to a its own file.

Had debated on this, seemed more like reward routine with it collecting stuff and all. But should be straight forward to adjust, I'll use an IDE to clean out unused imports

3. Check mails once a day is enough, so mail should be a standalone module or a part of exercise task

Noted, probably go with the once a day. Maybe at end of day after last exercise task run. Can either make it a standalone task or just have exercise module import it to execute in its run method.

Although I think I've more or less tested this stably with that last force push, I might not get around to doing these new updates super soon. Would you like me to revert and remove the commits from the first PR from dev branch?

[LmeSzinc]

Okay, mind if I make this a configurable to turn on and off? Default will be off.

Default to OFF then.

Although I think I've more or less tested this stably with that last force push, I might not get around to doing these new updates super soon. Would you like me to revert and remove the commits from the first PR from dev branch?

Keep the current commits.

The amount of task to claim rewards is increasing, perhaps we should merge DataKey, BattlePass, SupplyPack, Mail into one task running once a day. MetaReward moves into Meta task also.

[nEEtdo0d]

Next will move to separate module / folder when I get the chance. Think its straight forward.

The amount of task to claim rewards is increasing, perhaps we should merge DataKey, BattlePass, SupplyPack, Mail into one task running once a day. MetaReward moves into Meta task also.

I think I can do that, will comment if I lose track how. All of them have few configurations so squashing to one area and all are freebies. Task name suggestions, maybe Miscellaneous or Misc, ETC, or Freebies?

Probably set the run time to server reset then instead of end of day since the idea was collecting Mail after all the exercises but collecting them the next day is no difference.

[LmeSzinc]

Task name suggestions, maybe Miscellaneous or Misc, ETC, or Freebies?

Freebies.

Probably set the run time to server reset then instead of end of day since the idea was collecting Mail after all the exercises but collecting them the next day is no difference.

In SCHEDULER_PRIORITY place freebies just before opsi explore

[nEEtdo0d]

The amount of task to claim rewards is increasing, perhaps we should merge DataKey, BattlePass, SupplyPack, Mail into one task running once a day. MetaReward moves into Meta task also.

I think I moved them around correctly.

Stuck on how to move MetaReward, there isn't a Meta task. Do you mean OpsiAshBeacon? It's the only place that calls force task call on it. Remove MetaReward and just place MetaReward(...).run() where the force task call is? Have not be called daily anymore.

[nEEtdo0d]

Tested Freebies task, stable from what I've tested. Had a 3 merit entries in box and collected all 3, the original branch was only able to get one of them since I didn't realize Filter detected the same item as duplicate entries so didn't add the corresponding buttons to them.

So next how is MetaReward to be re-factored? No longer have it call daily and call its run directly in OpsiAshBeacon?

[LmeSzinc]

When OpsiAshBeacon and OpsiAshAssit finished, call the function of original MetaReward directly, MetaReward is not going to be a task. Another way is to be added into Freebies, I havent decided yet. From the experience before, people wants no red dots all day long, so it's better to have it collected after attacking meta.

[nEEtdo0d]

When OpsiAshBeacon and OpsiAshAssit finished, call the function of original MetaReward directly, MetaReward is not going to be a task. Another way is to be added into Freebies, I havent decided yet. From the experience before, people wants no red dots all day long, so it's better to have it collected after attacking meta.

Just to be sure these two places right? OpsiAshAssist never called it before so was just thinking the one place in L377

• https://github.com/LmeSzinc/AzurLaneAutoScript/blob/master/module/os_ash/meta.py#L377
• https://github.com/LmeSzinc/AzurLaneAutoScript/blob/master/module/os_ash/meta.py#L481

MetaReward(self.config, self.device).run(), also get rid of the self.config.task_delay in MetaReward since it won't be task anymore.

Straight forward, I can do a push and let me know if something needs to be corrected about it since can just force push it out.

Thanks

[nEEtdo0d]

If good, can merge. Otherwise let me know if I might have missed something with that last commit.

Should mention the original issue card that started all this #1684

[LmeSzinc]

Add config rediretctions.

[nEEtdo0d]

Add config rediretctions.

Good catch, added. Seems to work and thanks.