> There should be options: DORM_REWARD_INTERVAL (1 hour, 2 hour, 3 hour, 4 hour), USE_GEM_FOOD (yes, no)
>
> Should able to pick up love and coin in dorm, may hard to pick all of them, not a big deal.
>
> Call OCR to detect food remain and total
>
> Don't use template matching to detect which food is available, because the naval curry change from time to time. The unavailable food items have a white overlay, make good use of that.
- Adaptive parameters for perspective detection
> When alas get an perspective error, it stops. Catch the errors, auto adjust the parameters and retry.
>
> Read perspective_en.md, see how alas do map detection, and you need to have some basic knowledge of perspective.
- Restart when get stuck or lost connection
> Don't simply use `handle_popup_confirm()`, because many module also use that.
>
> After the restart, retreat from map, because alas can't resume from a unfinished map.
>
> Alas have highly wrapped API, you may need to touch some low-level functions to do that.
>
> When you're done, test the speed, see if it effects on the performance.
> I notice that ALauto use ascreencap, test and see if it's faster than uiautomator2.
>
> If so, add that option in GUI, and set to default.
- Update cnocr
> If we use the latest `cnocr`, we can recognize English letters better, get rid of `mxnet==1.4.1`, have smaller model size.
>
> But I already train 2 models under `cnocr==1.0.0`, named `stage` and `digit`, test if they are compatible.
- Re-train ocr models
> The existing ocr model named `stage` and `digit` are poorly trained, you need to make sure letters are full-filled the image.
>
> The fat letters which is frequently used game is `Impact`
>
> The slim letters use in level and oil is `AgencyFB-Regular`
>
> The letters in research which looks cool is `MStiffHeiHK-UltraBold`
>
> It's better to use only one model to recognize all.
- Add support research
> Do this after updating cnocr and retraining models.
>
> Imitating commission.py, use ocr to get research name, classify them, then choose
- Re-fit the relationship between map swipe and screen swipe
> This function is `_map_swipe` in module/map/camera.py line 36. If you want to focus camera from D3 to E4, then it will do a swipe (-200, -140). A simple linear fit turn `(1, 1)` to be `(-200, -140)`.
>
> I fit this in 7-2, but i found it no working well in some large maps. Alas have to call `focus_to_grid_center` in line 89 to fix camera position. But sometimes that failed, alas update map data to the wrong grids, and cause a series of error until `ensure_edge_insight` is called.
>
> I do know that the relationship between map swipe and screen swipe is complex, but linear would be enough, because we won't swipe too far.
>
> How close is the camera on the map will also effect the relationship, you can use the `mid` of vertical lines the measure that. So closer camera means larger diff in vertical.mid, and further swipe, try to fit the the exact relationship.
- Combine perspective.py and homg_trans_beta brunch in ALauto
> asd111333 shared his thoughts on map detection to me. His project is doing so good when there is only few empty grids on screen which is the weakness of Alas, and ALauto don't have a global map view, which is the strengthen of Alas.
>
> perspective.py can generate the camera setting needed in his approach, so no longer need to hard-code camera settings for different maps.
>
> Alas work in 720p and ALauto works in 1080p, so there is a 1.5x scaling.
> I imagined a way to use two approach. After entering map, call perspective.py to generate camera data, and use homo_trans till the end. If get any error, fallback to perspective.
>
> This will be faster and with lower error rate, and get rid of the parameters of `scipy.signal.find_peaks`
>
> I got a problem now. Alas use the edge of the map to locate camera. If edge is not insight, locate camera from history swipe which may be unstable. When edges appear again, use that to correct camera location. So even if i use homo_trans, i still need to call perspective from time to time.