SRL Archive - SRL Old School RuneScape

GetChooseOption/ChoosOption are Excruciatingly Slow


YoHoJo

2013-03-05 10:13:07

I totally remember we had this same problem back in the day (not sure if realted or not though)
Using Simba 993 and Git OSR.

There is a very noticeably long wait between right click and clicking the proper option on OCR vs Regular RS.

(I'm using a text.simba that's a few days old from the repo since the newest was being odd with me).

Ashaman88

2013-03-05 10:16:42

I think the newest one for me was way faster than the older version, what was wrong with the newest?

YoHoJo

2013-03-05 10:20:28

From: Ashaman88
I think the newest one for me was way faster than the older version, what was wrong with the newest?


It's 7:20AM and I was up all night, I forgot :p but something about it was not working.
I'll get it again and see if it works then. I'll post back within 24 hours.

DannyRS

2013-03-05 10:32:20

Hmm, was near-instant enough for me :/


DeclarePlayers;
SetupSRL;
LoginPlayer;
MMouse(288,63,20,20);
ClickMouse2(mouse_right);
WriteLn(ToStr(GetChooseOptions));


Compiled successfully in 484 ms.
SRL Compiled in 15 msec
Paired with SMART[3468]
[('Inspect Tree patch', (225, 86, 356, 99),(223, 65, 356, 161)),
('Guide Tree patch', (226, 101, 356, 114), (0, 0, 0, 0)),
('Walk here', (226, 116, 356, 125), (0, 0, 0, 0)),
('Examine Tree patch', (226, 131, 356, 144), (0, 0, 0, 0)),
('Cancel', (226, 146, 356, 155), (0, 0, 0, 0))]
Successfully executed.

YoHoJo

2013-03-05 10:34:52

On newest:
Finding them just fine
[('Use Bank booth', (45, 187, 227, 196), (42, 166, 227, 277)), ('Use-quickly Bank booth', (45, 202, 227, 215), (0, 0, 0, 0)), ('Walk here', (45, 217, 227, 226), (0, 0, 0, 0)), ('Examine Closed bank booth', (45, 232, 227, 241), (0, 0, 0, 0)), ('Examine Bank booth', (45, 247, 227, 256), (0, 0, 0, 0)), ('Cancel', (45, 262, 227, 271), (0, 0, 0, 0))]


But If WaitOptionMulti(['se-', '-q', 'qui', 'kly'], 500) Then is not clicking any of them.


That's why I'm using an older version (which is slow).

DannyRS

2013-03-05 10:38:50

From: YoHoJo
On newest:
Finding them just fine


But If WaitOptionMulti(['se-', '-q', 'qui', 'kly'], 500) Then is not clicking any of them.


That's why I'm using an older version (which is slow).


try it like this?

If WaitOptionMulti(['Use-quickly', 'quick'], 500) Then

Edit - boxes in WaitOptionMulti are miss-clicking for me, anyone else?

YoHoJo

2013-03-05 10:43:06

From: DannyRS
try it like this?

If WaitOptionMulti(['Use-quickly', 'quick'], 500) Then


Still nope. Right clicks, properly debugs out the options, but WaitOptionMulti does not work.
It just moves the mouse away (as in not found, and moving so the option box leaves).


EDIT:
Oh wait!
After right click, I think it's TRYING to click an option, but just missing horrendously, it's left clicking in my chatbox very far from the option menu, but it looks like it's trying!

Edit:
Even just plain old ChooseOption is not working for me, it's trying but clicking in a very wrong spot!

DannyRS

2013-03-05 10:48:34

From: YoHoJo


EDIT:
Oh wait!
After right click, I think it's TRYING to click an option, but just missing horrendously, it's left clicking in my chabox very far from the option menu, but it looks like it's trying!

Edit:
Even just plain old ChooseOption is not working for me, it's trying but clicking in a very wrong spot!


Same here, @Le Jingle What you do ? :p

YoHoJo

2013-03-05 10:49:40

DannyRS, you said it was working just fine for you :0, now what?
Someone mind linking me to the latest WORKING version of text.simba for OSR!

Le Jingle

2013-03-05 10:51:29

So the method(s) in question derive from getChooseOptions()?

Also, could it be something font/OCR related (shout out to anyone knowing this)?

I fixed a bug where it wouldn't use the correct box to click, perhaps now, it's another bug. (I'm guessing there's multiple colors being combined from the sounds of it)

May I ask what you're testing the WaitOptionMulti on?

DannyRS

2013-03-05 10:51:42

From: Le Jingle
So the method(s) in question derive from getChooseOptions()?

Also, could it be something font/OCR related (shout out to anyone knowing this)?

I fixed a bug where it wouldn't use the correct box to click, perhaps now, it's another bug. (I'm guessing there's multiple colors being combined from the sounds of it)

May I ask what you're testing the WaitOptionMulti on?



From: YoHoJo
DannyRS, you said it was working just fine for you :0, now what?
Someone mind linking me to the latest WORKING version of text.simba for OSR!


GetChooseOptions is fine and boxes seem fine, but the mouseboxes in choosing stuff are way out for some reason

YoHoJo

2013-03-05 10:52:57

Ohh I see whats up, yeah the params for MouseBox in ChooseOptionMultiEx must be messed up, probably a one line fixer (or a few lines).

DannyRS

2013-03-05 10:55:19

From: YoHoJo
Ohh I see whats up, yeah the params for MouseBox in ChooseOptionMultiEx must be messed up, probably a one line fixer (or a few lines).


function ChooseOptionMultiEx(Texts: TStringArray; TextType: String; Action: fnct_ActionOptions): Boolean;

How to fix, remove the T-R Failsafe

case Action of
ClickLeft:
begin
if PointInBox(T, B) then
ClickMouse2(true)
else
MouseBox(B.x1, B.Y1, B.x2, B.Y2, mouse_left);
end;
Move:
if not PointInBox(T, B) then
MouseBox(B.x1, B.Y1, B.x2, B.Y2, mouse_move);

Nothing:
begin
end;

else
srl_warn('ChooseOptionMultiEx', 'ClickRight not a valid click for RS menus!', warn_AllVersions);
end;

Ashaman88

2013-03-05 10:56:16

Were there any changes last night? It was working fine dropping items last night, very strange!

DannyRS

2013-03-05 10:58:11

From: Ashaman88
Were there any changes last night? It was working fine dropping items last night, very strange!


the failsafes causing it to be off for some reason now,

@Le Jingle, see my post above for the cause ^^^^

Le Jingle

2013-03-05 11:32:18

Looking into it.. :s Seems an update was pushed the pass day that messed something in the chain up

DannyRS

2013-03-05 11:59:11

From: Le Jingle
I am unable to produce the error above.

Make sure you are up to date with the latest OSR includes too.

I've tested:

WaitOptionMulti(['se-', '-q', 'qui', 'kly'], 500);

WaitOptionMultiEx(['se-', '-q', 'qui', 'kly'], 'all', clickLeft, 500);

WaitOption('se-', 500);

These all work fine for me. There shouldn't be a failsafe that will skew the boxes either.. It is to make sure your Box.X2 is never smaller than your Box.X1…
Again, is there any way that this is due to old includes, also, if this persists, can you show me or tell me how to replicate this?

-Lj



B := Options[i].Bounds;

The boxes have the full Bounds for me on return from B := Options.Bounds;

so the click is way off by this:


GetMousePos(T.x, T.y);

MouseBoxEx(T.x+ B.x1 + R, T.y+B.Y1 + 20, T.x+B.x2 - R, T.y+B.Y1 + 40, R, mouse_left);

e.g.
[('Inspect Tree patch', (214, 118, 345, 131)]
becomes for example,
MouseBoxEx(300+ 214 + R,  200+118 + 20, 214+345 - R, 200+118 + 40, R, mouse_left);

Le Jingle

2013-03-05 12:22:06

Found the problem,
@slushpuppy; edited the ClickLeft case action line for some reason.. This made the click-able area be two fold, instead of the proper boxes. Again no idea why he changed that, but I requested a pull for a fix.

To see what I mean, here's a before (currently what's broke) and after (what the code should be). This is the only line that will need editing.


{ BEFORE - Bad}

(*
ChooseOptionMultiEx
~~~~~~~~~~~~~~~~~~~

.. code-block:: pascal

function ChooseOptionMultiEx(Texts: TStringArray; TextType: String; Action: fnct_ActionOptions): Boolean;

Finds Popup menu, then clicks on it.
Will look for the first string first and so on.
It will search for the Text Type you input valid arguments are
'action', 'player': The white text
'npc': The yellow text
'object': The cyan text
'all': Searches for all colors of text.
Will default to 'all'.

.. note::

by Wizzup? & Nava2 & N1ke!
Last Modified: 22/12/12 by riwu
Slushpuppy - 03 march 13

Example:

.. code-block:: pascal

*)
function ChooseOptionMultiEx(Texts: TStringArray; TextType: String; Action: fnct_ActionOptions): Boolean;
var
B: TBox;
i, H, x, R: Integer;
T: TPoint;
Options: array of TOptions;
begin
Result := False;
Options := GetChooseOptions();
if (Length(Options) < 1) then
Exit;
H := High(Options);
for i := 0 To H do
begin
if ArrInStr(Texts, Options[i].Str) then
begin
Result := True;
B := Options[i].Bounds;
GetMousePos(T.x, T.y);
R:= Min(((B.X2 - B.X1) shr 1), 5);
case Action of
ClickLeft:
begin
if PointInBox(T, B) then
ClickMouse2(true)
else // below line is faulty.. shouldn't be adding all these together
MouseBoxEx(T.x+ B.x1 + R, T.y+B.Y1 + 20, T.x+B.x2 - R, T.y+B.Y1 + 40, R, mouse_left);
end;
Move:
if not PointInBox(T, B) then
MouseBoxEx(B.x1 + R, B.Y1, B.x2 - R, B.Y1 + 5, R, mouse_move);

Nothing:
begin
end;

else
srl_warn('ChooseOptionMultiEx', 'ClickRight not a valid click for RS menus!', warn_AllVersions);
end;
Exit;
end;
end;
B := Options[0].BigBox;
if Action <> Nothing then
begin
x := Max(B.X1 - 52, 0);
if x = 0 then
x := B.X2+10;
MMouse(x, Max(B.Y1 - 50, 0), 40, B.Y2-B.Y1);
Wait(200 + Random(100));
end;
end;


{ AFTER - Good }

(*
ChooseOptionMultiEx
~~~~~~~~~~~~~~~~~~~

.. code-block:: pascal

function ChooseOptionMultiEx(Texts: TStringArray; TextType: String; Action: fnct_ActionOptions): Boolean;

Finds Popup menu, then clicks on it.
Will look for the first string first and so on.
It will search for the Text Type you input valid arguments are
'action', 'player': The white text
'npc': The yellow text
'object': The cyan text
'all': Searches for all colors of text.
Will default to 'all'.

.. note::

by Wizzup? & Nava2 & N1ke!
Last Modified: 22/12/12 by riwu

Example:

.. code-block:: pascal

*)
function ChooseOptionMultiEx(Texts: TStringArray; TextType: String; Action: fnct_ActionOptions): Boolean;
var
B: TBox;
i, H, x, R: Integer;
T: TPoint;
Options: array of TOptions;
begin
Result := False;
Options := GetChooseOptions();
if (Length(Options) < 1) then
Exit;
H := High(Options);
for i := 0 To H do
begin
if ArrInStr(Texts, Options[i].Str) then
begin
Result := True;
B := Options[i].Bounds;
GetMousePos(T.x, T.y);

R:= Min(((B.X2 - B.X1) shr 1), 5);

case Action of
ClickLeft:
if PointInBox(T, B) then
ClickMouse2(true)
else
MouseBoxEx(B.x1 + R, B.Y1, B.x2 - R, B.Y1 + 5, R, mouse_Left);// reverted line (correct)

Move:
if not PointInBox(T, B) then
MouseBoxEx(B.x1 + R, B.Y1, B.x2 - R, B.Y1 + 5, R, mouse_move);

Nothing:
begin
end;

else
srl_warn('ChooseOptionMultiEx', 'ClickRight not a valid click for RS menus!', warn_AllVersions);
end;
Exit;
end;
end;
B := Options[0].BigBox;
if Action <> Nothing then
begin
x := Max(B.X1 - 52, 0);
if x = 0 then
x := B.X2+10;
MMouse(x, Max(B.Y1 - 50, 0), 40, B.Y2-B.Y1);
Wait(200 + Random(100));
end;
end;

https://github.com/SRL/SRL-OSR/pull/48

DannyRS

2013-03-05 12:33:49

From: Le Jingle
Found the problem,

Slushpuppy edited the ClickLeft case action line for some reason.. This made the click-able area be two fold, instead of the proper boxes. Again no idea why he changed that, but I requested a pull for a fix.


Weird, what was all the adding for @slushpuppy ?

Le Jingle

2013-03-05 12:37:38

From: DannyRS
Weird, what was all the adding for @slushpuppy ?


Opps edited your post >.< Meant to make a new reply

From my point of view, I'm guessing he requested this near the time when I submitted the fix for the boxes offset. So, I think he was trying to compensate for the boxes being based off the Point(0,0) from the mainscreen, but the edited getChooseOptions() box offset is a more reliable fix. Again, just assuming, so it's understandable I suppose, just a lack of communication really between developing. :]

Justin

2013-03-05 20:32:26

I have a feeling that Slushpuppy might of been testing with the wrong include since SRL_NavBar adds +20 because of the Login screen for RS. I could be wrong but that's the only thing I can think of that would of caused a +20

slushpuppy

2013-03-06 06:43:07

From: Le Jingle
Opps edited your post >.< Meant to make a new reply

From my point of view, I'm guessing he requested this near the time when I submitted the fix for the boxes offset. So, I think he was trying to compensate for the boxes being based off the Point(0,0) from the mainscreen, but the edited getChooseOptions() box offset is a more reliable fix. Again, just assuming, so it's understandable I suppose, just a lack of communication really between developing. :]

^^

Previously getchooseOptions weren't relative to the mouse cursor, hence my patch.