SRL Archive - SRL Bugs

Since EoC, when the action-bar is enabled, the procedure 'SetScreenMouse' can sometimes fail due to the action-bar being enabled on-screen blocking the initial right-click of the mouse as it right-clicks in the actionbar

Ah yes I've noticed this as well. In line 371 of antiban.simba (SRL/core) you'll see this:

YStart := RandomRange(MSY2, MSY2 - 55);

We could simply change that to something like…

YStart := RandomRange(MSY2-50, MSY2 - 105);

Assuming the ActionBar is around 50 pixels in height. We could also have it first check if the ActionBar is currently enabled and yes that modified line I posted above, or if it's disabled then use the current "RandomRange(MSY2, MSY2 - 55)". Either way, that should fix it.

Setscreenmouse slowly lowers the angle over time for me, kind of annoying since we cant check the angle.

This isn't going to be a simple fix. Based on the original code

YChange1 := YStart + RandomRange(278, 280);
YChange1 := YStart - RandomRange(278, 280);

our YChange have to be => 278 to switch from the lowest to highest or vice versa, but now the action bar limits our Y2 to 261, so to change from lowest to highest we will either need 2 tries, or close the action bar, and re-enable it afterwards.

EDIT: the current mechanism always moves to the max Y first, then makes necessary adjustment to the desired level (eg. to move from 1 to 9, it will first move =>278 to get to 10, then moves back slightly to reach 9), though we can change this mechanism, our limitation remains at max YChange of 261 (and to achieve this we must start from MSX1, or 261 if moving upwards, which is pretty botlike), so this function must be revamped to try twice when necessary, or we just close the action bar, adjust then reopen? But that's a bit bot-like imo.

EDIT2: oh now i realize why this mechanism of adjusting to the max first is made, as there is no way to detect our current angle, so the exact YChange required cannot be calculated unless starting from the lowest/highest angle.