[gathicxv]

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: https://www.runemate.com/community/threads/list-of-program-arguments.372/

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...

 

[srpronto]

1. 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.

This

 

[aidden]

RuneMate by default saves a bot's options after you set it.

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.

 

[gathicxv]

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.

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

 

[aidden]

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

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-loadrofilename 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]

Bump.

@Aidden @Arbiter @Cloud Any news relating to these suggestions?

 

[cloud]

1. -
2. -
3. -
4. -
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. -Not practical with reflection-
7. -Bots can already accept arguments when starting from the command line, there just haven't been any authors implement them-
8. -May become a setting in time-
9. Shut down in X Minutes - Runs the bot for chosen amount of minutes

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.

 

[fontkodo]

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.

When do you think #5 will be added? I think it would heavily benefit the dev and user experience.

 

[arbiter]

Strongly approve of 1, 2, 3, and 5. Iffy on 9. Quote my post if you want an explanation of my choices.

 

[gathicxv]

Strongly approve of 1, 2, 3, and 5. Iffy on 9. Quote my post if you want an explanation of my choices.

 

[arbiter]

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

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.

 

[gathicxv]

1. Not sure I get it. How would this be different than using 1+2?
2. Not appropriate at a client level. Should be at a bot or plugin level.

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
 
@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?

 

[arbiter]

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.