Team Cape

Note: This guide is simple and for beginners. If you're not a beginner to programming for OSBot, or generally know your way around the API, you might be best off experimenting with this yourself. Regardless, this can be a good tutorial for anybody getting started. API Links: WalkingEvent: http://osbot.org/api/org/osbot/rs07/event/WalkingEvent.html WebWalkEvent: http://osbot.org/api/org/osbot/rs07/event/WebWalkEvent.html WHEN to webwalk vs. walk normally Webwalk - Long-distances - Handling barriers (e.g. doors, gates, agility shortcuts, teleports) Walking normally - Short distances - No barriers Walking Regularly There are two ways to complete this task. The first way: getWalking().walk(Position... positions) This means that you're allowed to give the method multiple positions. This is because it will find the closest position to your current position and walk there automatically. So let's say that I want to walk choose from multiple positions. I have: Position pos1 = new Position(1, 2, 0); Position pos2 = new Position(2, 4, 0); Position pos3 = new Position(1, 1, 0); getWalking().walk(pos1, pos2, pos3); This will walk to the closest of those 3 positions. This can also be done with areas. getWalking().walk(new Area(1, 2, 3, 4), new Area(5, 6, 7, 8), new Area(9, 10, 11, 12)); All of these are simple enough. Note that you don't need to put more than 1 Area or Position. You can just put 1, and it will, by default, go to that location. The second way: You can also do essentially the same thing with a WalkingEvent. For instance, you could say: WalkingEvent myEvent = new WalkingEvent(new Position(1, 2, 3)); //making the event execute(myEvent); //executing the event The disadvantage to this is that you can only put in one Position/Area, not multiple. It will not pick the closest, because it only takes one. However, there's also a large advantage to using a WalkingEvent. You can: - set the minimum distance threshold. Meaning that if you input a position to the walkingevent and give the following line: myEvent.setMinDistanceThreshold(0); it will walk to this tile exactly, not just within a radius of 2. You can also do this with the minimap distance. - set the threshold at which the event will toggle your 'run' setting on myEvent.setEnergyThreshold(47); means that it will click on run energy if you have 47% or more. - you can also set a break condition (perhaps the most useful), meaning that if this condition is met, the execution of the event will terminate. if you don't understand the format (below), don't worry about it - all you need to know is that if you put any boolean in there, if it returns a value of 'true', then the event will end, regardless of where it is in its completion. myEvent.setBreakCondition(new Condition() { @Override public boolean evaluate() { return myPlayer().isUnderAttack(); } }); this would make the event terminate when your player is under attack. now when the event is over, you either know that its execution finished with your player being attacked, or with you walking to your final destination. So, if we put this all together, it would look a little like this: WalkingEvent myEvent = new WalkingEvent(new Position(1, 2, 3)); //making the event myEvent.setMinDistanceThreshold(0); myEvent.setEnergyThreshold(47); myEvent.setBreakCondition(new Condition() { @[member='Override'] public boolean evaluate() { return myPlayer().isUnderAttack(); } }); execute(myEvent); //executing the event This event will walk exactly to the position at 1, 2, 3 (note* given that it is reasonably accessible without barriers and can reach the endpoint (otherwise you would use webwalking)). If not already running, and your run energy is >= 47, it will turn on your run. The final line executes the event and causes the script to start walking. Note* adding in all of these specificities are optional! The event has default conditions of a minimum distance threshold of 2, an energy threshold of 30, and no break condition. If you didn't want any of those details, you could've also just said: WalkingEvent myEvent = new WalkingEvent(new Position(1, 2, 3)); execute(myEvent); Also remember that this statement is equivalent to saying: getWalking().walk(new Position(1, 2, 3)); Webwalking OSBot's advanced webwalker is one of the features that makes OSBot so great - it handles most of the walking work for you, using advanced shortcuts, teleports, barrier handling, and designing its own path to a destination - pretty amazing. Note that it's best used if you need to travel long distances, or if there are barriers between you and your destination. If you just need to walk 5 tiles south, then chances are that you'd be better off walking normally (above)! Similar to regular walking, there are two ways. The first way: Position pos1 = new Position(1, 2, 0); Position pos2 = new Position(2, 4, 0); Position pos3 = new Position(1, 1, 0); getWalking().webWalk(pos1, pos2, pos3); Exactly like walking normally. You can also do it with areas: Area a1 = new Area(2, 3, 4, 5); Area a2 = new Area(5, 4, 3, 6); Area a3 = new Area(4, 6, 4, 1); getWalking().webWalk(a1, a2, a3); The second way: This way is also very similar to regular walking. Except instead of defining a WalkingEvent, we're going to be defining a WebWalkEvent. A great advantage of WebWalkEvents over WalkingEvents, however, is that WebWalkEvents can decide which Area or Position is closer from a list of positions or areas. So, if I wanted to, I could do: WebWalkEvent webEvent = new WebWalkEvent(pos1, pos2, pos3); or WebWalkEvent webEvent = new WebWalkEvent(pos1); or WebWalkEvent webEvent = new WebWalkEvent(a1, a2, a3); and it will grab the closest destination! The advantages of a WebWalkEvent over regular webwalking: - the ability to set a break condition (exactly like a WalkingEvent - see above for details) - the ability to set the energy threshold (exactly like a WalkingEvent - see above for details) - the getDestination() method that returns the Position the WebWalkEvent is going to Position sumtin = webEvent.getDestination(); //gives the position that the WebWalkEvent //is going to - the ability to use the simplest possible path --> this takes out concerns like using roads and just takes the quickest route to your destination. webEvent.useSimplePath(); - the ability to set a PathPreferenceProfile (a great friend to scripters!) - A PathPreferenceProfile determines how the WebWalkEvent will move. All of the possibilities for PathPreferenceProfiles are found here: http://osbot.org/api/org/osbot/rs07/event/webwalk/PathPreferenceProfile.html Example: If we didn't want our webwalker to use teleports or use paths related to quests, we could do the following: PathPreferenceProfile ppp = new PathPreferenceProfile(); ppp.setAllowTeleports(false); ppp.ignoreAllQuestLinks(true); webEvent.setPathPreferenceProfile(ppp); So if we put it all together, it might look a little something like this: WebWalkEvent webEvent = new WebWalkEvent(pos1, pos2, pos3); webEvent.useSimplePath(); PathPreferenceProfile ppp = new PathPreferenceProfile(); ppp.setAllowTeleports(false); ppp.ignoreAllQuestLinks(true); webEvent.setPathPreferenceProfile(ppp); execute(webEvent); And those are the basics of webwalking If I've left out / omitted anything, feel free to contact me, or if you don't understand anything, also feel free to ask questions below. Hope this was informative

mirror mode is superior to basically all injection clients. thats why i pointed out osbot's mirror mode. even without the mirror mode, though, it barely makes a difference at all. 1. if the ban rate were significantly lower, as alek said, osbot would've been dead and gone awhile ago (however it's thriving and actually doing better than any other botting service) 2. ban rates are basically the same across all clients, discounting mirror mode. in regards to how this makes osbot better, see my previous post about osbot's superior features, including far more scripts (that are also held to a higher standard), far superior and more complex webwalking, mirror mode, and an API that makes scripting far easier and less buggy for the scripters.

we wouldnt be here if we thought osbot was worse. the reason why more people use osbot is because its better in its script variety, mirror mode, webwalking, and way more

make more and post when they're out

LOL that ho that kicked zezima

the imposter can just tell the real person to send the exact same code. it's best to have them copy and paste a part of the conversation

make them copy and paste a section of the conversation in the pm they send you. often, imposters will get the real person to pm your osbot username. or just do it over the OSBot chatbox (there are logs of all discussions on there)

blasphemy

1. saying that ^ doesnt help your case 2. people tend to remember bad times more than good times. seems like if you had to save her from killing herself you might be a reminder of a worse time for her, or she might be thinking of a specific 'bad time' that makes her think you hurt her. decisions aren't grounded in stupidity. all human decisions are rooted in some form of logic that, chances are, you're not seeing.

tattoos

yeah depends on the CPU usage of the script

nah, all the cba's are on at 1 time though which is weird. then there are like 6-9 collective hours per day where there's no cba's

hola

beastly update yess

not a good idea to make a mule script. use a file writer inside of the mule, then use a file reader inside of the worker and parse the data from the mule.

pc++

2nd one is noted ID. 1st one is regular ID

manual breaks are best by far, so long as you're not doing them by a strict pattern

pc++ also fuck off

whenever