Tsum script JP hang during Tsum upgrade

[Sean-Hsueh]

@mcs wonder if you can reproduce this issue: https://www.youtube.com/watch?v=ry9evrrBayY

This is a single case reported by a v64 user recently. I can see the button seems being tapped but the screen still hang in the same page. The player can resolve this page by one click.

[Sean-Hsueh]

The phone used in this case is Redmi Note13.

In case you cannot reproduce this on your end, I will simply tell user this is caused by special screen ration on the phone, and we will not address this issue as we cannot cover all phones :)

[mcs]

I don't exactly understand what's going on here.

In theory on a 1920x1080 screen, the script should click the red marked button area the whole time:

According to the video material, the game screen is not exactly vertically centered. The upper black area uses around 130px, the bottom one just 85px, so it is probably necessary to enable the "Special screen ratio" option within the settings. I initially thought that this might lead to clicking on the corner of the button, but based on my current assumptions the button should still be hit fully:

The related code is https://github.com/r2-studio/robotmon-scripts/blob/master/scripts/com.r2studio.TsumBeta/src/index.js#L1466 which does two taps quite fast, maybe even without a real break. I don't know what tap(x, y, during) does with the parameter during. According to personal experience in my Robotmon coding beginnings, a value of 1000 does not block code execution for 1s as I initially thought, so I don't know if without a sleep() between the two taps, the first tap might be "swallowed" by the Redmi phone.

For v66, I will add a 50ms sleep between these taps just because such a small intentional deplay probably won't hurt anyone. Maybe that will solve the issue.

[poi5305]

I think tap will sleep/delay a while.

console.log(1, Date.now());
tap(1,1, 5000)
console.log(2, Date.now());

And the output is

[09:05:04.790] 1 1708391104837
[09:05:09.791] 2 1708391109839

[mcs]

Hrm, okay, good to know. Thank you for the clarification :-) In this case, I will revert the related commit on my fork. Nevertheless a strange issue.

[Sean-Hsueh]

I think we can close this case then :)

[mcs]

Just one addition wat I got wrong with duration: I did not expect it to first wait the amount of milliseconds and then do the tap, but thought it would first do the tap and then wait for duration milliseconds. But this is not the case because all screenshots I take after such a tap are taken immediately after the tap. I will add that detail to the global README.md just because that is the place where I look up the API documentation 😃