Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

Sign up now!

VisualRM [DEV]

Joined
May 27, 2017
Messages
61
what i mean is does it have an option to add like random behaviours in the script to make it not seem so robotic. Do you know what i mean?

Think like how you would do something as a human and then you can make it in VisualRM.
It will use all the anti-ban measures that the Playersense API provides.

E.g. if you're mining you can check if the rocks are occupied by others, if they are then you can 1) either world-hop or 2) you can go mine at other rocks. If these are also occupied you can do 1 or 2 again.
 
Niche bots at your disposal
Joined
Dec 23, 2015
Messages
1,099
what i mean is does it have an option to add like random behaviours in the script to make it not seem so robotic. Do you know what i mean?
So called random behaviours what you call anti-ban does not really exists. These random actions are actually an extra pattern you provide for the runescape detection system to detect you botting. All the advertisement you read about anti-ban on otehr bots or platforms is complete bullcrap. It does not exist. The best you can do is have a bot that works 100% of the time and does so efficiently. Also be smart about your botting and differentiate your actions and playtime.
VisualRM and most bots on RuneMate have integrated systems that slightly differentiate your playstyle from other users using the bot.By randomizing the actual usefull action you don't seem to look like just another bot. IF you would add random camera rotation or mouse hovers, the systems can easily detect that a significant amount of people doing a certain activity ingame all have the tendency to do camera movements and mouse hovers that have no fucking use.
So if a bot supports anti-ban, disable it please.
 
Learner
Joined
Jun 10, 2017
Messages
37
I saw a thread about this anti ban features. I want to post it again in here but I can't find it.

The one you shared a week or 2 ago. @Wet Rag
 
Oh I found it....

“Antiban” is a farce. What could you possibly think would make a bot resistant to bans?

Random mouse movements? Opening tabs and hovering skills? Moving your mouse off screen?

None of these actions are “antiban”. If you want to reduce your risk of getting banned, quit botting 24/7 and quit botting the same thing with the same bot day to day.

The only thing you can realistically expect from your bot authors is to write a stable bot that is robust enough not to get stuck regardless of the circumstances.

Stop asking for stupid fucking shit like “antiban”. It isn’t real. The stereotypical “antiban” users ask for is a predefined set of actions that are pseudorandomly selected at pseudorandom intervals. And guess what? This is predictable at a certain threshold.

Pseudo random number generators, which are used for these pseudorandom intervals use a deterministic algorithm for generating numbers and as the sample size increase both in duration and quantity (bot usage and user count), you can observe the overall trend of performing these “random” “antiban” actions. So quit asking for it.

The depth of complexity required for writing a bot with divergent playstyles is over the head of pretty much every bot author in the entire scene. And it’s also impractical. You’d have to implement machine learning algorithms that ultimately slowly achieve the goal of performing the action correctly and at an optimal speed. This period of poor performance while the bot is literally learning how to perform the action is something the user does not want to be involved in. So bot authors have written predefined logic for handling a specific set of actions a single way and it just works.

tl;dr: “antiban” doesn’t exist. People who ask for it are mentally retarded. Literally deluded. Quit botting all the time and expecting a bot to avoid bans for you. Be realistic and bot occasionally.
 
Joined
Oct 14, 2015
Messages
15
So called random behaviours what you call anti-ban does not really exists. These random actions are actually an extra pattern you provide for the runescape detection system to detect you botting. All the advertisement you read about anti-ban on otehr bots or platforms is complete bullcrap. It does not exist. The best you can do is have a bot that works 100% of the time and does so efficiently. Also be smart about your botting and differentiate your actions and playtime.
VisualRM and most bots on RuneMate have integrated systems that slightly differentiate your playstyle from other users using the bot.By randomizing the actual usefull action you don't seem to look like just another bot. IF you would add random camera rotation or mouse hovers, the systems can easily detect that a significant amount of people doing a certain activity ingame all have the tendency to do camera movements and mouse hovers that have no fucking use.
So if a bot supports anti-ban, disable it please.
wow i never knew this thank you for answering what seemed to be a stupid question i guess? thanks can't wait to try and make my own script with this tool, will be keen to donate as well if all goes well too!
 
Joined
May 3, 2017
Messages
1
I have no idea how to start the bot when ive loaded it something from repository. doersnt make sense. so frustrating.
 
Learner
Joined
Jun 10, 2017
Messages
37
Click the play button, after following the instruction of the bot author for the setup.
upload_2018-6-10_0-13-23.png
 

Attachments

  • upload_2018-6-10_0-12-47.png
    upload_2018-6-10_0-12-47.png
    5 KB · Views: 12
Learner
Joined
Jun 10, 2017
Messages
37
@tyb51 I have a question....

I figured out how to work with these buttons,
upload_2018-6-10_0-47-20.png

Regarding these nodes, how can I use these correctly? Says that I need to use interface condition node to cache blah blah blah.
upload_2018-6-10_0-49-11.png

Or is it possible to click somewhere in the screen using coordinates?
 
Last edited:
Joined
Feb 17, 2018
Messages
136
@tyb51 Hello.

There is urgent need of few things that I think are an absolute must in long run:

1) Breaking system: the kind where you can take short breaks or longer breaks with ease. Breaking system should not break the bot in any sense. For that, a new node can be made called "breaking node". The bot author would embed the breaking node in the bot at a place, where it would not break the logic of the bot. The breaking interface where break duration and frequency is customised can be made in a popup window like the 'open tracker' in bot. I personally like the breaking system of Regal bots, so the interface and functionality here can be inspired from them.

2) Randomisation options: I have used a fighting bot which i set to eat if health goes below 50%. Now the bot would always eat at the exact point when the health was just 1 hp below 50% health. Doing that for long sessions, again and again, is pure botish, do you not think?

A randomisation option would solve this. It can be embedded in every node with a comparator, Or calculation node too. So now, If lets say i have HP level of 60 and I have set the bot to eat at 50% health with a set randomisation of 3, the bot would eat from anywhere between 26-33 instead of eating at dot 30 HP every time. That would be a much better place for a bot to be.

3) Options for arrays: For example; In your sand crab script, the bot moves to a reset co ordinate. Even though I can set it to an area with the reset coordinate as centre and give it a radius, runemate automatically chooses the shortest path and goes through exact same route every time.

A solution for that is arrays. Instead of one coordinate, you can choose multiple coordinates and the bot would move to them randomly. Like you choose multiple Food options in the inventory condition of "contains any". These co-ords then can have their own areas with radiuses and so on.
This is one of the applications of arrays in the bot.

4) A clean interface of boolean variables with checkboxes: This would make the bot complete in interfacing terms. The bot author can simply make boolean variables by asking the user to checkbox what they require and the logic flow would be controlled by that.
For example, say i make an agility script with an option of high alching. I can insert a Boolean check in my bot logic flow and if high alch is true, then do it while doing agility. Now, the Boolean Would automatically(or by making it selectable in the boolean check node) will be available in Boolean interface. The user then can just click on checkbox if he wants to high alch or leave it be if he dont. A checked box would make the condition true and visa vera.
The benefit? Cleaner experience and proper botlike interface. The user would not have to go through entire bot flow to click one false to true, they will just select them by boolean interface!
The interface can be added like the 'open tracker' tab at the bottom of the bot.

Do let me know what you think, thanks!
 
Niche bots at your disposal
Joined
Dec 23, 2015
Messages
1,099
1) Breaking system: the kind where you can take short breaks or longer breaks with ease. Breaking system should not break the bot in any sense. For that, a new node can be made called "breaking node". The bot author would embed the breaking node in the bot at a place, where it would not break the logic of the bot. The breaking interface where break duration and frequency is customised can be made in a popup window like the 'open tracker' in bot. I personally like the breaking system of Regal bots, so the interface and functionality here can be inspired from them.

You can almost already implement your breaking system by using the timer node to activate every Random(x,y) seconds. I only need to add a multiplier box to the Pause node to be able to pause longer then the new available milliseconds OR ...(see next question)

2) Randomisation options: I have used a fighting bot which i set to eat if health goes below 50%. Now the bot would always eat at the exact point when the health was just 1 hp below 50% health. Doing that for long sessions, again and again, is pure botish, do you not think?

A randomisation option would solve this. It can be embedded in every node with a comparator, Or calculation node too. So now, If lets say i have HP level of 60 and I have set the bot to eat at 50% health with a set randomisation of 3, the bot would eat from anywhere between 26-33 instead of eating at dot 30 HP every time. That would be a much better place for a bot to be.


Randomisation will come when I add (more) modifier nodes. These will be nodes to extract or generate values for variables. By adjusting variables before using them you'll have your randomisation

3) Options for arrays: For example; In your sand crab script, the bot moves to a reset co ordinate. Even though I can set it to an area with the reset coordinate as centre and give it a radius, runemate automatically chooses the shortest path and goes through exact same route every time.

A solution for that is arrays. Instead of one coordinate, you can choose multiple coordinates and the bot would move to them randomly. Like you choose multiple Food options in the inventory condition of "contains any". These co-ords then can have their own areas with radiuses and so on.
This is one of the applications of arrays in the bot.


Its only logical you'll use the same path every time as a user, and that it'll be the shortest path. It will not click the exact same coordinates every time, that's more important. The randomisation above will also prove usefull here if you want.
PS: that rockcrab script was also mostly an example on how to use booleans, it tends to run around like crazy :p.

4) A clean interface of boolean variables with checkboxes: This would make the bot complete in interfacing terms. The bot author can simply make boolean variables by asking the user to checkbox what they require and the logic flow would be controlled by that.
For example, say i make an agility script with an option of high alching. I can insert a Boolean check in my bot logic flow and if high alch is true, then do it while doing agility. Now, the Boolean Would automatically(or by making it selectable in the boolean check node) will be available in Boolean interface. The user then can just click on checkbox if he wants to high alch or leave it be if he dont. A checked box would make the condition true and visa vera.
The benefit? Cleaner experience and proper botlike interface. The user would not have to go through entire bot flow to click one false to true, they will just select them by boolean interface!
The interface can be added like the 'open tracker' tab at the bottom of the bot.


I'm in the design phase of making a GUI builder for authors. As with everything in VisualRM it has to be relative generic, so not only Booleans, but also certain dropdown menus should be accessable. (E.g. a loot list, target list, lvl target etc etc). This will take some time, because it will require quite a big internal overhaul. So called "Engine work".Don't expect it to soon as I'm quit busy.

Do let me know what you think, thanks!

Good suggestion tho, I've been thinking about most of them myself
 
Joined
Feb 17, 2018
Messages
136
1) Breaking system: the kind where you can take short breaks or longer breaks with ease. Breaking system should not break the bot in any sense. For that, a new node can be made called "breaking node". The bot author would embed the breaking node in the bot at a place, where it would not break the logic of the bot. The breaking interface where break duration and frequency is customised can be made in a popup window like the 'open tracker' in bot. I personally like the breaking system of Regal bots, so the interface and functionality here can be inspired from them.

You can almost already implement your breaking system by using the timer node to activate every Random(x,y) seconds. I only need to add a multiplier box to the Pause node to be able to pause longer then the new available milliseconds OR ...(see next question)

2) Randomisation options: I have used a fighting bot which i set to eat if health goes below 50%. Now the bot would always eat at the exact point when the health was just 1 hp below 50% health. Doing that for long sessions, again and again, is pure botish, do you not think?

A randomisation option would solve this. It can be embedded in every node with a comparator, Or calculation node too. So now, If lets say i have HP level of 60 and I have set the bot to eat at 50% health with a set randomisation of 3, the bot would eat from anywhere between 26-33 instead of eating at dot 30 HP every time. That would be a much better place for a bot to be.


Randomisation will come when I add (more) modifier nodes. These will be nodes to extract or generate values for variables. By adjusting variables before using them you'll have your randomisation

3) Options for arrays: For example; In your sand crab script, the bot moves to a reset co ordinate. Even though I can set it to an area with the reset coordinate as centre and give it a radius, runemate automatically chooses the shortest path and goes through exact same route every time.

A solution for that is arrays. Instead of one coordinate, you can choose multiple coordinates and the bot would move to them randomly. Like you choose multiple Food options in the inventory condition of "contains any". These co-ords then can have their own areas with radiuses and so on.
This is one of the applications of arrays in the bot.


Its only logical you'll use the same path every time as a user, and that it'll be the shortest path. It will not click the exact same coordinates every time, that's more important. The randomisation above will also prove usefull here if you want.
PS: that rockcrab script was also mostly an example on how to use booleans, it tends to run around like crazy :p.

4) A clean interface of boolean variables with checkboxes: This would make the bot complete in interfacing terms. The bot author can simply make boolean variables by asking the user to checkbox what they require and the logic flow would be controlled by that.
For example, say i make an agility script with an option of high alching. I can insert a Boolean check in my bot logic flow and if high alch is true, then do it while doing agility. Now, the Boolean Would automatically(or by making it selectable in the boolean check node) will be available in Boolean interface. The user then can just click on checkbox if he wants to high alch or leave it be if he dont. A checked box would make the condition true and visa vera.
The benefit? Cleaner experience and proper botlike interface. The user would not have to go through entire bot flow to click one false to true, they will just select them by boolean interface!
The interface can be added like the 'open tracker' tab at the bottom of the bot.


I'm in the design phase of making a GUI builder for authors. As with everything in VisualRM it has to be relative generic, so not only Booleans, but also certain dropdown menus should be accessable. (E.g. a loot list, target list, lvl target etc etc). This will take some time, because it will require quite a big internal overhaul. So called "Engine work".Don't expect it to soon as I'm quit busy.

Do let me know what you think, thanks!

Good suggestion tho, I've been thinking about most of them myself

Good to know you are working on all these things.

For the shortest path thing, In my case the bot did click almost the same tile every time.

One more thing, have you fixed telegrab? It broke every time it was used and I made an issue for it on Bitbucket.
 
Niche bots at your disposal
Joined
Dec 23, 2015
Messages
1,099
Good to know you are working on all these things.

For the shortest path thing, In my case the bot did click almost the same tile every time.

One more thing, have you fixed telegrab? It broke every time it was used and I made an issue for it on Bitbucket.
Just tested, seems to work fine for me
 
Top