Client-Argument Request Mega-Thread

Discussion in 'Client & Site Suggestions' started by Gathicxv, May 2, 2015.

  1. Hi guys...

    I had a couple arguments in mind that I wanted to ask for... and so I just thought that I'd make this thread for all your client-sided argument ideas.

    If you haven't familiarized yourself already, read the existing client arguments here:

    Here is my list. Please give me your feedback on the viability/practicality of these ideas:
    1. Start with Client Minimized - Starts with the RuneMate client Minimized
    2. Start with Client Maximized - Starts with the RuneMate Client Maximized
    3. Start with Client Hidden - Where did the manual option to hide the client to the task-bar go??
    4. Start with Game Screen Maximized - This is the game screen, rather than the client... so for example, I would be able to say -{Client Minimized} -{Game Screen Maximized} and this would first maximize the RuneMate client and then minimize it... am I making any sense? If not, tell me and I'll explain it below.
    5. Start with Game Screen height x width (pixels) - Allows you to set the size of the game screen to best suit your load out.
    6. Do not load Game Visuals - Hide the actual actions taking in game from the user. This will make the client run more smoothly on toasters... However, this would not hide the paint, so I would be able to see the progress. Also, there should be a button in the settings to allow us to reverse this, if the bot stops for example.
    7. Use existing bot options? - RuneMate by default saves a bot's options after you set it. Also, there are arguments that exist already that allow you to start a bot immediately upon starting the client, however all this does is bring up the bot options GUI (Which are already set to your defaults). This argument will give permission for the bot to move forward with its previously saved settings.
    8. Stop if no experience gained in X Minutes - I still haven't forgotten about this one. And since it is an argument, it is 100% the user's fault if they screw this up and have the bot stop in the middle of combat...
    9. Shut down in X Minutes - Runs the bot for chosen amount of minutes
    I'll add more suggestions, as I think of them... in the meanwhile give me your feedback guys... and any any argument ideas that you may have...
  2. This
  3. This isn't correct. The bot has to store the settings itself, the client has nothing to do with that. Also the api has the functionality to allow bots to retrieve their own client arguments, this could be used to tell the bot to not open the gui and use the previously saved settings, however no bots that i'm aware of currently take advantage of this.
  4. Yes, but how would the user be able to tell the bot that they want it to load the last used settings in this specific instance? It would have to be an argument, right?

    But thanks for the clarification on how things work :)
  5. yeah so the way i'd see it working is a bot argument recognized by that specific bot perhaps auto-load:true or something like that. or maybe if the bot is capable of storing profiles you could do auto-load:profilename or auto-load:default
    and then the bot would check the value of the arg onStart and if it's set then the bot starts itself accordingly
    Gathicxv likes this.
    I've marked off and commented and things that I don't think we'll be adding, the two remaining are possibilities but may not happen.
    Gathicxv likes this.
  6. When do you think #5 will be added? I think it would heavily benefit the dev and user experience.
    Gathicxv likes this.
  7. Strongly approve of 1, 2, 3, and 5. Iffy on 9. Quote my post if you want an explanation of my choices.
    1. Automation usability++;
    2. ^
    3. ^^
    4. Not sure I get it. How would this be different than using 1+2?
    5. See #1.
    6. Not feasible.
    7. Already exists. Urge Bot Authors to implement.
    8. Not appropriate at a client level. Should be at a bot or plugin level.
    9. Similar to #8, but I could be convinced to make an exception because implementing it encourages safe botting.
  9. 1. Not different, but I want to be able to use both arguments at the same time.
    2. I disagree man. If I, the bot user, want to stop it for a personal reason, then I should be able to. I should have authority the over my account, not the bot author. If you are afraid that people will mess up their bots using it, then make it an argument, not a client option in the GUI. Don't tread on muh botting rights :p
    --- Double Post Merged, Aug 20, 2015, Original Post Date: Aug 19, 2015 ---
    @Arbiter with all due respect, could you give me a truly convincing reason as to why you don't want to give bot users this ability?
  10. It's not that I don't want to give bot users the ability to stop their bot, but rather that the suggested implementation is not the proper one. Like I said, it would be better introduced as a plugin.

Share This Page