Bobrocket

rip

Off the top of my head, a lot of the ones when smithing have bounds that go way above what they should be.

A lot of widgets have very weird bounds.

Just a bit of thought, would it be possible to calculate the actual bounds of a widget based on colours? I have no clue myself but if it's possible then that would be really good.

If you want to do something like that, you should look into distributions I wrote a small bit about distributions in my SmartKeyboard thread (cba to find it lol), but to sort of target the bullseye as it were (and then hit the bullseye 99% of the time), you'd take a normal distribution for both x and y: Point widgetPoint = new Point(getNormalDistributedRand(x1, x2), getNormalDistributedRand(y1, y2)); Another way is to add up 2 randoms, eg 2 6-sided die have the highest probability of rolling a 7. int randX = rand(1, 6) + rand(1, 6); Reading the link I sent again, read how they note "depends on placement". This is where statistics starts to become a very big part of botting. If you look at my API, I take a lot of this into account. Look at my NPC file here, note the hover(), getSuitablePoints(), and the variety of random functions. What we're essentially saying when we hover is we're trying to match a point that is as close to the mouse as possible (ie doing less work; in words of Fitt's law getting as small an index of difficulty as possible) that is also a suitable point on the NPC. Think of it as a car with thinking and stopping distances. You want the stopping distance to be as small as possible, so we can technically say that we want to stop at the centre, and by the time we enter the rectangle we have finished thinking. Sounds very confusing, but it's about as human-like as you can get.

Here's a good read for you: https://rs-hacking.com/resources/macroingdetection.pdf It's legitimacy is questionable, but it gives us good ideas of what to do. Some summary points: Bots lack accuracy and precision, which humans possess. (look at graph below) Low accuracy = far from the true value; high accuracy = close to true value Low precision = values very spread out; high precision = values close together Even when doing random(x, y) when taken enough times, the mean of random(x, y) is still going to be around (x + y) / 2.

typeKey() still has the delay afaik (hence why my SmartKeyboard is still pretty slow). Also, when pressing enter, you want to send 13 & 10 in rapid succession (\r\n): getKeyboard().typeKey((char)13); getKeyboard().typeKey((char)10);

Welcome! Always nice to see more scripters joining

Empty object will not throw errors when calling methods (thus making get...Finder.findClosest().interact/attack/pickpocket safe to use). Not null checking also allows a more understandable code base - "wouldn't an entity exist if it isn't null?".

NPC dwarf = getNPCFinder().findClosest("Dwarf"); if (dwarf.exists()) dwarf.attack(); else log("wtf"); :/ :/ :/ :/ :/

Someone had the source for an instant typer once upon a time, not sure how it was done but try looking into KeyEvents?

I know it's useless to reply at this point, it's been a long time. I'm not sure why I didn't say this in the first place, but in any data type present in OmniAPI, #exists() will define whether or not the object is both there and available to be interacted with (for example, in widgets it will check if the child isn't null and if the widget is visible). No need for nasty instanceof checks, no need for null checks either ;) if (getNPCFinder().findClosest("Dwarf").exists()) { getNPCFinder().getLastFound().attack(); } else { log("not there :("); } Or, in your case: NPC monsterX = getNPCFinder().findClosest("Monster X"); if (monsterX.exists()) monsterX.attack(); else if (regionB.contains(myPlayer())) walk(new Path(regionA)); Might be something to look in to ;)

As far as other APIs are concerned, they are typically made to bridge the gap between no knowledge and full knowledge (at least mine is). There are a lot of things that OSBot's API does that it shouldn't do, for example: getNpcs().closest("Dwarf").interact("Attack"); Will break your script if there is no "Dwarf" NPC. Little shameless self plug here, but my API allows this (eg no script breaking) getNPCFinder().findClosest("Dwarf").attack(); What you might notice in the change between .NET to Java that there isn't as much type checking (ie you do a lot of default(type) in .NET for a lot of classes whereas you don't really in Java). You also have to use the .equals(object) method in Java, instead of using == in .NET. Lastly, Java tends to use methods for public modifiers (eg .getItem() vs .Item). Good luck!

no

pussy

Here's a pic I found of me 2 years ago Enjoy

You start with the ! (not) operator if (!myPlayer().getPosition().equals(new Position(x, y, z)) { //not there }

if (myPlayer().getPosition().equals(new Position(x, y, z))) { //there } else { //not there }

I hope this doesn't awaken anything in me

Back in 2011-2013, a few friends and I were writing a game. Granted, we didn't get too far, and its "legacy" remains unnoticed. Some screenshots of showing the evolution of the game: November 2011 First "build" if you will. Late November 2011 Random map generation; no specific algorithm, just pure random. Late December 2011 We had moved from pure VB.NET w/ GDI+ to C# with XNA. Was better for everyone in the end. Jan/Feb 2012 (Sorry for low-res, it was a thumbnail that was cached) - we had made better progress on the map editor and more tiles etc. We also had a better map generating algorithm than before. If I get my hands on any other screenshots, I'll post them

So, I want to write a game. A small, 2D game. Looking for ideas on what it can/should/would be. I was thinking of a little roguelike game, no clue tho