SRL Archive - SRL Suggestions

Please change back choose options to what it was!

I know the current chooseoptions fixes the options not found dialog. For example, when an option is not found, it moves the mouse OFF of the options box so that it can try again but this should be optional and up to the scripter.

Why? Because the way it currently is, I cannot do:

     MMouse.....
     ClickMouse2(MOUSE_RIGHT);
          if (Not WaitOptionMulti(['w-' + IntToStr(HowMany), 'draw-' + IntToStr(HowMany)], 1000)) then
            if WaitOptionMulti(['w-X', 'draw-X'], 600) then
            begin
                //////////////////////////
            end; 

Instead I am forced to do:

     MMouse.....
     ClickMouse2(MOUSE_RIGHT);
          if (Not WaitOptionMulti(['w-' + IntToStr(HowMany), 'draw-' + IntToStr(HowMany)], 1000)) then
         begin
           MMouse......
           ClickMouse2(MOUSE_RIGHT);         //I shouldn't have to do this twice!
            if WaitOptionMulti(['w-X', 'draw-X'], 600) then
            begin
               ///////////////////////
            end;
         end;

I suggest that the chooseoptions have a parameter whether or not to make the dialog disappear.. or at least an SRL variable that we can change to enable or disable that part of the function..

Agree! I hate the fact that it moves the mouse away.

Now I just check for the uptext and then use SlideMouse instead.

Ugh. Banking has become so much harder since this was implemented. Support

Supporting this, If it would Help us all then why not?

Or another parameter could be added, letting the script writer decide whether or not to move the mouse away if it doesn't find the option.

function OptionsExist(txt: TStringArray; Move: boolean): boolean;

Returns true if an Option in txt is found in the RS Option Menu, will move or do
nothing according to the boolean Move.

This shouldn't move the mouse if you set the Move boolean to false I think.

From: weequ
Simba Code:
[LEFT]function OptionsExist(txt: TStringArray; Move: boolean): boolean;

Returns true if an Option in txt is found in the RS Option Menu, will move or do
nothing according to the boolean Move.
[/LEFT]


This shouldn't move the mouse if you set the Move boolean to false I think.

Indeed but the wait option waits a specified time and during that interval, it keeps looking for the option. Waitoption should have that parameter as well then instead of defaulting it to move. Should be optional at least.

This is the part that bugs me:

  B := Options[0].BigBox;//to mmouse away
  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;

As long as the action is to do something, such as click left when the option is found or not found, then it will always move the mouse away..

I support ,functions should only do what they are created for ,any extra behavior may make them less flexible.

I'm still confused why was this done in the first place? I'd have to look through the GIT logs and it's probably a ways back.

Yeah, I just downgraded my SRL and then disabled updates…mine works fine as it is. :)

… why not just move the mouse back to where it was…?

From: beginner5
I support ,functions should only do what they are created for ,any extra behavior may make them less flexible.

Unless they're made to be flexible…

I like the way this is. As it is, the scripter ought to put a loop w/ failsafe anyways.

From: nickrules
… why not just move the mouse back to where it was…?



Unless they're made to be flexible…

I like the way this is. As it is, the scripter ought to put a loop w/ failsafe anyways.

@Narcle it was changed because whenever the option wasn't found, it stalled a lot of scripts since the menu stayed open and while it was open, the scripts kept searching for it. The fix was to close the menu and re-open to search again. That's up to the scripter to re-open the menu and try again though so I'm not sure why either.

EDIT: The reason it stalled was because when you right click an object, the menu covers the object.. If the menu is still up and the user is trying again, the object will never be found until the menu is closed which requires moving the mouse away. It's the spacing in the text that caused this sometimes.


@ Nick
But that's the thing.. The menu disappears so you have to right click again..
Imagine banking:

Right clicks.. Does not find first option.. Closes menu. Right clicks Does not Find next option.. Closes Menu.. Right Clicks, Finds options, Clicks it.

That could all be:

Right clicks.. Does not find first option, Does not find the second option, Looks for the Third and clicks. Having to click 3-4 times to look for and choose 1 from the same menu is ridiculous. Might as well right click once, search for all and choose one.

The way it is currently isn't fine. Closing the menu should either be optional via a parameter or not there at all. The scripter can do this themselves easily.

I still haven't found the change in GIT. As I ask again does anyone know why it was changed to this in the first place? This way if I change it back it doesn't break the purpose it was changed for in the first place.

From: Narcle
I still haven't found the change in GIT. As I ask again does anyone know why it was changed to this in the first place? This way if I change it back it doesn't break the purpose it was changed for in the first place.

See my edit for why it was changed in the last post. As to when? It only started happening since the last SRL Update when I posted this thread. Before that, it never did that so I have no clue why it's not on Git's logs. Says last edited 2 months ago. :S

This sounds like a bug rather then a change. ChooseOption hasn't been changed since Coh3n changed the color I believe and before that was my fix. The move mouse away feature has been in ChooseOption ever since it was made (years ago?).

Right clicks.. Does not find first option.. Closes menu. Right clicks Does not Find next option.. Closes Menu.. Right Clicks, Finds options, Clicks it.

It shouldn't be doing this.

Also that's the WithDraw function used right?

From: Narcle
This sounds like a bug rather then a change. ChooseOption hasn't been changed since Coh3n changed the color I believe and before that was my fix. The move mouse away feature has been in ChooseOption ever since it was made (years ago?).
It shouldn't be doing this.

Also that's the WithDraw function used right?

It does it for all the ChooseOption Functions I run.. The above was just an example. It never started happening until an update 2 days ago.

The awkward thing is that in the chooseoptionsmultiex function, if I change the:

if (Options <> Nothing) to If (Options = Nothing)

Then it won't move the mouse away and all will be fine. This behavior wasn't happening before which is why it's weird that you say it's been there forever.

I support this. More parameters!

Very strange…
The text.simba file hasn't been touched since March and ChooseOption has been the same since February when I revamped it. I'll do some testing later.

Right clicks.. Does not find first option.. Closes menu. Right clicks Does not Find next option.. Closes Menu.. Right Clicks, Finds options, Clicks it.

Right clicks.. Does not find first option, Does not find the second option, Looks for the Third and clicks. Having to click 3-4 times to look for and choose 1 from the same menu is ridiculous. Might as well right click once, search for all and choose one.

What you're dealing with (withdraw-X vs withdraw-#) is a highly isolated incidence where the context menu can change, and barely much more work. Impeding everyone else for something that only happens in one or two areas is silly.

if you're really determined, you could maybe check out GetChooseOptions - still more work than calling one function twice, but much easier to manipulate.

From: nickrules
What you're dealing with (withdraw-X vs withdraw-#) is a highly isolated incidence where the context menu can change, and barely much more work. Impeding everyone else for something that only happens in one or two areas is silly.

if you're really determined, you could maybe check out GetChooseOptions - still more work than calling one function twice, but much easier to manipulate.

Lol.. your kidding me right? Why don't you repeat all your code then. It makes absolutely no sense to close a menu to open it again to choose a different option from the same menu.

To check if 20 options are NOT in a menu and to choose a different one each time if found, your telling me I should open AND close that same menu 20 times. Where's the logic in that?

Btw your example isn't accurate. Withdrawing isn't the only time this can happen. It happens when picking up items, it happens in minigames, all over the place. YOU just haven't used it that's all.

A function shouldn't do more than it suggests. It's supposed to wait for an option to be found. If it's not there then return false. The scripter should move the mouse on their own and close the menu when they feel like it. A company asks you to write a program to communicate between Cell towers only in the US. You go and you write one that communicates between the US and China and Russia. You'd better find a new job.

Sorry but that's not going to happen. ChooseOption has always moved the mouse away before even I was here and it will continue to do so. This will be resolved in another way.

From: Brandon
Lol.. your kidding me right? Why don't you repeat all your code then. It makes absolutely no sense to close a menu to open it again to choose a different option from the same menu.

I already explained how this can be avoided…

From: Brandon
To check if 20 options are NOT in a menu and to choose a different one each time if found, your telling me I should open AND close that same menu 20 times. Where's the logic in that?

See above…

From: Brandon
Btw your example isn't accurate. Withdrawing isn't the only time this can happen. It happens when picking up items, it happens in minigames, all over the place. YOU just haven't used it that's all.

Actually, I think it's fairly safe to say that the number of objects which have different possible options, which lead to different paths, but accomplish the same task in the end, are infact, quite limited. When you go to kill a monster, it doesn't randomly switch between "Attack" and "Initiate aggressive conversation". Even then, there are several ways to go about the problem, and you just refuse to take the path, because you want to call the function twice, so that you may use it in a highly isolated situation, and force everyone else to include several lines of unnecessary code, making the issue more complex than it need be.

And, if you're so determined to save yourself as much work as humanly possible, you can copy and paste the function out of the SRL include, so that you can remove the 10 lines of code that perform the movement. Then, all you do is rename it, and call that function! So easy, you'd think it's witchcraft if you didn't know better!

From: Brandon
A function shouldn't do more than it suggests. It's supposed to wait for an option to be found. If it's not there then return false. The scripter should move the mouse on their own and close the menu when they feel like it. A company asks you to write a program to communicate between Cell towers only in the US. You go and you write one that communicates between the US and China and Russia. You'd better find a new job

Lol. "I made you something, but I made it better, and it's not at all hard to not make use of the extra functionality. Please don't fire me…"

E: And, hyperbole or not, if you're dealing 20 different possible options, it's downright stupid to call chooseOption 20 times in a row.