Results 1 to 22 of 22

Thread: Change Back ChooseOptions Please!

  1. #1
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default Change Back ChooseOptions Please!

    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:

    Simba Code:
    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:

    Simba Code:
    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..
    I am Ggzz..
    Hackintosher

  2. #2
    Join Date
    Feb 2012
    Location
    Somewhere, over the rainbow...
    Posts
    2,272
    Mentioned
    3 Post(s)
    Quoted
    45 Post(s)

    Default

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

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

  3. #3
    Join Date
    Jan 2012
    Posts
    319
    Mentioned
    0 Post(s)
    Quoted
    2 Post(s)

    Default

    Ugh. Banking has become so much harder since this was implemented. Support
    -My Scripts-
    Dude'sFighters
    Dude'sBonfires
    Donations help with scripting Paypal!

  4. #4
    Join Date
    Oct 2011
    Location
    Australia, Vic
    Posts
    1,517
    Mentioned
    2 Post(s)
    Quoted
    120 Post(s)

    Default

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

  5. #5
    Join Date
    Dec 2011
    Location
    New York, USA
    Posts
    1,242
    Mentioned
    12 Post(s)
    Quoted
    193 Post(s)

    Default

    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.

  6. #6
    Join Date
    Nov 2006
    Posts
    2,369
    Mentioned
    4 Post(s)
    Quoted
    78 Post(s)

    Default

    Simba Code:
    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.
    Quote Originally Posted by DeSnob View Post
    ETA's don't exist in SRL like they did in other communities. Want a faster update? Help out with updating, otherwise just gotta wait it out.

  7. #7
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by weequ View Post
    Simba Code:
    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.

    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:
    Simba Code:
    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 am Ggzz..
    Hackintosher

  8. #8
    Join Date
    Oct 2011
    Posts
    805
    Mentioned
    21 Post(s)
    Quoted
    152 Post(s)

    Default

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

  9. #9
    Join Date
    Sep 2007
    Location
    Michigan
    Posts
    3,862
    Mentioned
    2 Post(s)
    Quoted
    1 Post(s)

    Default

    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.
    (Scripts outdated until I update for new SRL changes)
    AK Smelter & Crafter [SRL-Stats] - Fast Fighter [TUT] [SRL-Stats]
    If you PM me with a stupid question or one listed in FAQ I will NOT respond. -Narcle
    Summer = me busy, won't be around much.

  10. #10
    Join Date
    Nov 2011
    Location
    Louisiana
    Posts
    881
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

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

  11. #11
    Join Date
    May 2008
    Location
    ;)
    Posts
    576
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

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

    Quote Originally Posted by beginner5 View Post
    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.
    Last edited by nickrules; 05-09-2012 at 02:03 AM.

  12. #12
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by nickrules View Post
    ... 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 am Ggzz..
    Hackintosher

  13. #13
    Join Date
    Sep 2007
    Location
    Michigan
    Posts
    3,862
    Mentioned
    2 Post(s)
    Quoted
    1 Post(s)

    Default

    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.
    (Scripts outdated until I update for new SRL changes)
    AK Smelter & Crafter [SRL-Stats] - Fast Fighter [TUT] [SRL-Stats]
    If you PM me with a stupid question or one listed in FAQ I will NOT respond. -Narcle
    Summer = me busy, won't be around much.

  14. #14
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by Narcle View Post
    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
    I am Ggzz..
    Hackintosher

  15. #15
    Join Date
    Sep 2007
    Location
    Michigan
    Posts
    3,862
    Mentioned
    2 Post(s)
    Quoted
    1 Post(s)

    Default

    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?
    (Scripts outdated until I update for new SRL changes)
    AK Smelter & Crafter [SRL-Stats] - Fast Fighter [TUT] [SRL-Stats]
    If you PM me with a stupid question or one listed in FAQ I will NOT respond. -Narcle
    Summer = me busy, won't be around much.

  16. #16
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by Narcle View Post
    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 am Ggzz..
    Hackintosher

  17. #17
    Join Date
    Jan 2012
    Posts
    1,104
    Mentioned
    18 Post(s)
    Quoted
    211 Post(s)

    Default

    I support this. More parameters!

  18. #18
    Join Date
    Sep 2007
    Location
    Michigan
    Posts
    3,862
    Mentioned
    2 Post(s)
    Quoted
    1 Post(s)

    Default

    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.
    (Scripts outdated until I update for new SRL changes)
    AK Smelter & Crafter [SRL-Stats] - Fast Fighter [TUT] [SRL-Stats]
    If you PM me with a stupid question or one listed in FAQ I will NOT respond. -Narcle
    Summer = me busy, won't be around much.

  19. #19
    Join Date
    May 2008
    Location
    ;)
    Posts
    576
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

    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.
    Last edited by nickrules; 05-10-2012 at 11:13 AM.

  20. #20
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by nickrules View Post
    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.
    I am Ggzz..
    Hackintosher

  21. #21
    Join Date
    Sep 2007
    Location
    Michigan
    Posts
    3,862
    Mentioned
    2 Post(s)
    Quoted
    1 Post(s)

    Default

    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.
    (Scripts outdated until I update for new SRL changes)
    AK Smelter & Crafter [SRL-Stats] - Fast Fighter [TUT] [SRL-Stats]
    If you PM me with a stupid question or one listed in FAQ I will NOT respond. -Narcle
    Summer = me busy, won't be around much.

  22. #22
    Join Date
    May 2008
    Location
    ;)
    Posts
    576
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    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...

    Quote Originally Posted by Brandon View Post
    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...

    Quote Originally Posted by Brandon View Post
    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!

    Quote Originally Posted by Brandon View Post
    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.
    Last edited by nickrules; 05-11-2012 at 12:00 AM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •