KingFighter [FREE] [AIO Fighter] [BANKS, EATS, LOOTS, FIGHTS, SPECIAL ATTACKS, POTIONS, PRAYER, SAFESPOTS] [MELEE/RANGE/MAGE] [DUNGEON SUPPORT] + MORE!,

[kingsolo 15]

still been trying to use this script and no luck. Every time i start the script he just won't click anything. I do pick a big enough radius but he doesn't move. Any more suggestions? thanks though!

Where are you fighting? I've not had any issues with it fighting anything so far.

[chartpk 1]

Hello,

 

I think there is one main issue which i've been noticing with Dreambot combat scripts. That is, after the script clicks on NPC to attack, the mouse stays at the same spot most of the time. Typically, a human will never just click to attack a monster, and leave the mouse right at the same spot after clicking attack. A human would move the mouse away, maybe towards the next NPC to get ready to attack next monster. I think this is a huge flaw and giveaway. As known, RS client collects mouse input data. Is this related to particular scripts, or is this integrated in dreambot itself?

[Articron 738]

Hello,

 

I think there is one main issue which i've been noticing with Dreambot combat scripts. That is, after the script clicks on NPC to attack, the mouse stays at the same spot most of the time. Typically, a human will never just click to attack a monster, and leave the mouse right at the same spot after clicking attack. A human would move the mouse away, maybe towards the next NPC to get ready to attack next monster. I think this is a huge flaw and giveaway. As known, RS client collects mouse input data. Is this related to particular scripts, or is this integrated in dreambot itself?

 

After an interaction method is called off the Dreambot API, there's no mouse deviation after of any sort.

 

However, scripters can either easily abstract the interaction or write some additional mouse movements after interacting with something to achieve the effect you'd like

 

 

Edit: from a programming standpoint the problem with this lies in the fact scripts are traditionally linear (or working off a single thread).

 

The human brain can pay attention to multiple things at the same time (mouse on next target, whilst concentrating on the current fight to make sure you know when to click, prayer points, HP,...) and decide on the next action depending on this pool of factors.

 

A true solution to achieve this kind of multitasking in a script could be found in the multithreading department, but it would be a bit tricky to achieve. 

[kingsolo 15]

After an interaction method is called off the Dreambot API, there's no mouse deviation after of any sort.

 

However, scripters can either easily abstract the interaction or write some additional mouse movements after interacting with something to achieve the effect you'd like

 

 

Edit: from a programming standpoint the problem with this lies in the fact scripts are traditionally linear (or working off a single thread).

 

The human brain can pay attention to multiple things at the same time (mouse on next target, whilst concentrating on the current fight to make sure you know when to click, prayer points, HP,...) and decide on the next action depending on this pool of factors.

 

A true solution to achieve this kind of multitasking in a script could be found in the multithreading department, but it would be a bit tricky to achieve. 

I could add some mouse movements in (Make it sometimes move and sometimes not) after we have interacted with an NPC if that would be better?

[chartpk 1]

I could add some mouse movements in (Make it sometimes move and sometimes not) after we have interacted with an NPC if that would be better?

That would definitely be a great step towards improvement. Do you think you can send me the script source so I can experiment with it and see if I can come up with something good?

 

PS: Another point to mention for example, is that sometimes the bot would attack an NPC hidden behind a wall/object or layer. The NPC is not physically visible within camera viewfield, yet it is being clicked on. I'm looking through the dreambot javadocs now. Maybe there's a method to check if npc is physically visible in camera viewfield? In that case, attack, otherwise move camera around or walk closer to npc. Some more advanced calculations could be made taking into consideration the euclidean distance between player and npc, canvas/game screen size and compass direction. If certain conditions are met, camera is moved in a natural way as to view the NPC as opposed to random camera movements. I think many so called "anti-ban" functionalities are actually instrumental to increasing bot suspicion. There's a lot I have in mind which can be improved, especially for more humanly interaction, such as increased missclicks, random clicks, double right clicks on players nearby. I think the important thing here is to humanize and uniquify interaction with the game, because that is ultimately what separates a human and a bot. If you'd agree, kingsolo, I would like to contribute to this script.

[Kumano 1]

Still using this script for hours per day and also are training my slayer with this.

 

Hope you are still updating this awesome script.

 

I think the script could be better when its used for aggressive npcs. Often another npcs tries to attack and the script still clicks on the other npc while gettting attacked.

[kingsolo 15]

That would definitely be a great step towards improvement. Do you think you can send me the script source so I can experiment with it and see if I can come up with something good?

 

PS: Another point to mention for example, is that sometimes the bot would attack an NPC hidden behind a wall/object or layer. The NPC is not physically visible within camera viewfield, yet it is being clicked on. I'm looking through the dreambot javadocs now. Maybe there's a method to check if npc is physically visible in camera viewfield? In that case, attack, otherwise move camera around or walk closer to npc. Some more advanced calculations could be made taking into consideration the euclidean distance between player and npc, canvas/game screen size and compass direction. If certain conditions are met, camera is moved in a natural way as to view the NPC as opposed to random camera movements. I think many so called "anti-ban" functionalities are actually instrumental to increasing bot suspicion. There's a lot I have in mind which can be improved, especially for more humanly interaction, such as increased missclicks, random clicks, double right clicks on players nearby. I think the important thing here is to humanize and uniquify interaction with the game, because that is ultimately what separates a human and a bot. If you'd agree, kingsolo, I would like to contribute to this script.

If you mean about attacking unreachable NPCs, Unless the 'Is NPC Unreachable?' box is ticked the script should by default not attack NPC's that are unreachable (E.g. locked in a room).

 

If you mean we attack NPC's that are hidden from view, Originally we would only fight NPC's that were visible on the screen however from my testing it created too many scenarios which meant we ended up standing still doing nothing for a period. (e.g.. NPC is behind a wall so we move camera to it but the NPC is still not in view so we walk near it but NPC is still not in view.) I found it easier just to allow it to click through walls.

 

Still using this script for hours per day and also are training my slayer with this.

 

Hope you are still updating this awesome script.

 

I think the script could be better when its used for aggressive npcs. Often another npcs tries to attack and the script still clicks on the other npc while gettting attacked.

It's a difficult one to avoid, from my testing it doesn't happen much and when it happens it's not for long.

 

I think the issue happens like this.. there are 3 npc's stood around us and we are fighting 1, once it is dead we have 2 viable NPC's stood next to us so we choose 1 to fight however before our mouse has clicked on our NPC, the other one has started attacking us we may try to click our NPC another time to fight before detecting we are in combat going back to normal. I'm not really sure of any way to get around this as a bot can't react as fast as a human to changes like this.

I have just pushed a new update which will occasionally (1 in 4 chance) move the mouse soon after we attack an NPC. 

[chartpk 1]

Thank you Articron for your informative post! I will look into what you've mentioned about multithreading and see what is possible.

Kingsolo:
There seems to be something wrong with the script, just now. 
When bot wants to attack NPC, it hovers crosshair a couple pixels above NPC it wants to attack. Then it just stands there for a couple of seconds moving the crosshair slightly, as if it's trying to search for the attack option on NPC - but the attack option isn't there because crosshair is slightly above actual NPC.

I notice this happens in a pattern. Camera is moved all the way down, then mouse is hovered above NPC. After a couple seconds it finally manages to lower the mouse a little and attack NPC, immediately after attacking it moves the camera a lot in some random direction.
In addition to the bug with mouse being placed above NPC, I think you should also reduce the bot moving camera around that frequently. Most combat bots move camera around as an anti-bot functionality. Maybe far too often even. While natural gameplay, you have some (if not a lot) of players that actually don't move the camera that frequently, maybe once every couple of minutes (maybe depending on how many NPC's are in the viewfield).

So in summary, these things:
1) Fix bug where mouse is hovered too high above NPC (I think this started occuring only after your recent update)

2) Reduce camera movement frequency
3) Maybe randomize things even more, such as not only have a fixed value of moving cursor away 1/4 of the time, but rather make it occasionally have sessions where it spends 2 or 3 minutes moving mouse away from NPC 4/5 times, sometimes moving mouse out of screen completely for a session of 5 minutes (as if you're doing other things on the computer) (by javadocs, method moveMouseOutsideScreen() does this), and sometimes only moving mouse slightly away from NPC 1/4 of the time - as you've currently set.

Edit:
An extra implemetation to further improve the fighter is to allow it to change target NPC like so:
1. Player is not fighting any target NPC yet. Bot is searching for target NPC.

2. Target NPC is located 10 tiles away from player position, bot clicks NPC and selects attack.
3. Right after bot has clicked attack, a new NPC spawned right next to player

4. Bot now quickly changes target and clicks attack on new NPC that just recently spawned next to player, as long as player is still not attacking the previous clicked NPC (this is only permitable once per fight session so that bot won't change targets too many times).
I think this has potential to improve bot efficiency, but most importantly contribute to more humanly gameplay. Because for a human player, if you see an NPC spawn right next to you, you'll change your mind and attack it because it's closer to you, rather than walking a couple tiles away to an NPC further away. Again, this could be randomized so that the bot does not ALWAYS do this, but sometimes - for example fluctating between 40 to 70% of the time. The fluctation between 40 and 80% could for example simply be made by checking the time -> current hour, and whether current hour is an odd number or an even number. If current time is for example 9 AM, number is odd, percentage of bot changing target if target npc is closer would be 70%. While if the current hour is 10 AM, percentage would be 40%.

Another improvement (And this one should also be randomized so that it is not done every single time):
While bot is fighting NPC, check:

var  cursorHasBeneMovedToMinimap = false;
if(player current position is far from the central tile && no target npc's are visible in camera viewbox && player is currently fighting NPC) {
 //Move cursor to minimap and place it somewhere close to the center tile area, but don't click yet. Only click after NPC you're currently fighting has died, and there are no other new NPC's spawned within camera viewfield

 var cursorHasBeneMovedToMinimap = true;
}

//NPC has died:

if(!npc.exists()){

 //Check if new NPC is available for attack in viewfield
 if(!checkIfNpcInViewField()) {

  //If cursor/crosshair was moved to minimap, and no other action has been taken by then, assuming cursor is still in minimap:
  if(cursorHasBeneMovedToMinimap) {

  //mouse.click() and let player move to central tiles where other NPC's are most likely to be/spawn.

}

 }
 }

 

PS: Would also be nice to see the radius around central tile colored in minimap.

[kingsolo 15]

1) Fix bug where mouse is hovered too high above NPC (I think this started occuring only after your recent update):

 

The update I pushed still needs approving so isn't live yet, if anything has changed it isn't the script. Check the script info page and I have some instructions on resetting the camera zoom on your RS client (It's the only thing I'm aware of that causes this issue).

 

2) Reduce camera movement frequency:

 

The camera moving is part of Dreambots interacting API, I have however thought about this in the past and will add a custom method in that only moves the camera if the NPC isn't on the screen.

 

3) Maybe randomize things even more, such as not only have a fixed value of moving cursor away 1/4 of the time, but rather make it occasionally have sessions where it spends 2 or 3 minutes moving mouse away from NPC 4/5 times, sometimes moving mouse out of screen completely for a session of 5 minutes (as if you're doing other things on the computer) (by javadocs, method moveMouseOutsideScreen() does this), and sometimes only moving mouse slightly away from NPC 1/4 of the time - as you've currently set.

 

The script already has the moveMouseOutsideScreen method implemented, it will do this SOMETIMES when we are waiting for an NPC to die and then bring the mouse back in when the NPC is dead.

 

 

An extra implemetation to further improve the fighter is to allow it to change target NPC like so:

1. Player is not fighting any target NPC yet. Bot is searching for target NPC.

2. Target NPC is located 10 tiles away from player position, bot clicks NPC and selects attack.
3. Right after bot has clicked attack, a new NPC spawned right next to player

4. Bot now quickly changes target and clicks attack on new NPC that just recently spawned next to player, as long as player is still not attacking the previous clicked NPC (this is only permitable once per fight session so that bot won't change targets too many times).

 

This sounds like it would be hard on memory, the bot works by storing the NPC inside an object which is what we interact with. Your suggestion would require us to keep scanning for a new NPC whilst we are waiting to see if we go into combat with our current target. Not sure if it's worth it for the sake of the bot walking further.

[ayosue 0]

Great Script. Works fine for me so far. Still testing and a question wandered my mind.

Is the script coded to stop fighting after food runs out in the bank?

And I added this to my list of scripts before reading the thread, but I've seen your pictures of the progress reports. I don't see any live progress reports like some other scripts do. Maybe it pops up after the script is stopped? I've stopped and started the script a few times before as well. Maybe I just missed a function in the GUI.