Potentially low IQ suggestion, just put it here to help me remember for the future.
To account for slower functions blocking script actions, a minor optimization could be implemented that counts the execution time of function calls in addition to frames when calling sleep_frames. For example:
|
def click_signal(sig: str) -> None: |
|
logging.debug("called") |
|
coord = mouse.get_position() |
|
mouse.click("left") |
|
sleep_frames(3) |
|
result, image = scan_for_dialog("signal", coord[0], coord[1]) |
|
if result: |
|
logging.debug("scan_for_dialog returned true") |
|
sleep_frames(3) |
|
press_and_release(sig) |
|
press_and_release("backspace") |
In this function, we click the left mouse, then scan for the dialogbox, and if found, sleep another 3 frames before changing the signal and pressing backspace. Instead, we could sleep for the execution time, in frames, of scan_for_dialog + some const.
Say that scan_for_dialog takes 0.5 frames, and we want to wait 3 frames in total (current method's intentions). We end up waiting for 3.5 frames instead of just 3, because we do not take execution time into account. If this feature is implemented, we would only need to artificially wait for 2.5 frames (3 - function time) to meet our 3 frame threshold. This would lead to more uniform timing across different systems and function calls, and could help lay the groundwork for #45. Might also depend on #56, in case this method is less reliable and needs broader testing.
Potentially low IQ suggestion, just put it here to help me remember for the future.
To account for slower functions blocking script actions, a minor optimization could be implemented that counts the execution time of function calls in addition to frames when calling sleep_frames. For example:
SCR-SGPlus/script.py
Lines 123 to 133 in 928f0d9
In this function, we click the left mouse, then scan for the dialogbox, and if found, sleep another 3 frames before changing the signal and pressing backspace. Instead, we could sleep for the execution time, in frames, of scan_for_dialog + some const.
Say that scan_for_dialog takes 0.5 frames, and we want to wait 3 frames in total (current method's intentions). We end up waiting for 3.5 frames instead of just 3, because we do not take execution time into account. If this feature is implemented, we would only need to artificially wait for 2.5 frames (3 - function time) to meet our 3 frame threshold. This would lead to more uniform timing across different systems and function calls, and could help lay the groundwork for #45. Might also depend on #56, in case this method is less reliable and needs broader testing.