FrostBug

Praise lord @Zach!

68 get

Nice Am curious as to how it clicks 2800 meters per second ;)

Looks decent; But to make it even better, perhaps add in some checks to make sure that the right entity is clicked, if multiple entities of the same type is on the cursor @ Laz, does osbot2 do that?

Not used particularly often in high-level scripts I reckon; But its used on occasion in games and graphical/mathematical programs I suppose

83 works perfectly fine for me, thanks!

Well played :E

Sounds like it might be fun; I'd be interested if you really do succeed in assembling a capable team; And by capable, I do mean that they should have game-writing experrience and at least some of them MUST have networking experience Experrience with developing as a team required too

this guy.. yesterday you wanted someone to set up Eclipse for you via teamviewer? Now you can outscript us all with superhuman scripts eh? The very definition of seeming legit.

PriorityQueue sorts whatever you insert into it by using its compareTo method; So you will want your NodeRectangle class to implement the Comparable interface (Comparable<NodeRectangle>), and compare their F values; Then calling poll on the PQ will always retrieve the best node with O(1) efficiency, and inserting into the PQ is O(log2n) efficiency

Nice looking application c: although it can be improved in a few places :E, I see you're manually searching for the best node for each iteration; Which is extremely costly compared to using a PQ which does this for you upon insertion

I can't imagine that plus signs would work fine, since they are interpreted as spaces a Dragon dagger(p+) for example, would be translated to Dragon+dagger(p+) = 3 words: "Dragon", "dagger(p" and ")"

Note that certain items with apostrophe or plus signs in their name may require URL encoding replace "+" with %2B and replace " ' " (apostrophe) with %27

Any news regarding ItemDefinition#getName for noted items?

JPS wouldn't be good for this type of graph at all He's not using a tile grid, but nodes placed somewhat randomly with X edges per node. JPS works best only when using a graph with large open spaces, like a tile grid. JPS would be inferior in this case, also due to the fact that his graph doesn't have any unwalkable nodes

:L nice This is a neat tool to play around with. it really shows the difference in efficiency http://qiao.github.io/PathFinding.js/visual/ What you had initially somewhat resembled a Depth First Search (DFS). Those are usually good for tree spanning. Unfortunatly that tool can't demonstrate DFS good luck with it

Sounds good :E, since OSBot kinda does need this Id recommend using java's PriorityQueue, it will automatically sort whatever you push into it by comparing. Which means that if you have your WalkingNode implement the Comparable interface, and have it compare their accumulated distances from the starting point, when popping a node from the queue, it will always be the node with the least distance from the starting point. Add a heuristic ontop of that (accumulated distance from start node + estimated distance to goal), and you're golden. Doing so it will always pop the node with the best potential for reaching the goal in the best possible way

A* implemented with an accurate heuristic (eg. A heuristic that is incapable of overestimations, which is easy in this case) is incapable of returning a path that is not the shortest possible. Also, 111 nodes in 34ms is relatively slow looking at your implementation, I can see that this really isnt a real Dijkstra algorithm, It wont search in the pattern illustrated by your gif. It works, but it will search very inefficiently. Dijkstra is implemented using a PriorityQueue or something of the like, with the ability to sort its content by comparing their potential (Accumulated distance from starting point). Using a deque simply does not accomplish this. It polls random nodes rather than the ones with the shortest distance, which may ultimately return suboptimal paths Overall its a decent piece of code, but has room for some improvements

If the cost of a graph edge is measured in distance, why would you use Dijkstra and not A*? A* Would reach the destination much faster, since it would search a lot less nodes. Using Euclid or a modified Manhattan heuristic would provide good results

Why does it log their IP address?

Math operations are usually very expensive (Especially the Pow() operation) I'd recommend just indexing a single-dimensional array @Liverare, not sure why you would want to do a 2d array EDIT: This is the one I use public static final int[] XP_TABLE = {0, 83, 174, 276, 388, 512, 650, 801, 969, 1154, 1358, 1584, 1833, 2107, 2411, 2746, 3115, 3523, 3973, 4470, 5018, 5624, 6291, 7028, 7842, 8740, 9730, 10824, 12031, 13363, 14833, 16456, 18247, 20224, 22406, 24815, 27473, 30408, 33648, 37224, 41171, 45529, 50339, 55649, 61512, 67983, 75127, 83014, 91721, 101333, 111945, 123660, 136594, 150872, 166636, 184040, 203254, 224466, 247886, 273742, 302288, 333804, 368599, 407015, 449428, 496254, 547953, 605032, 668051, 737627, 814445, 899257, 992895, 1096278, 1210421, 1336443, 1475581, 1629200, 1798808, 1986068, 2192818, 2421087, 2673114, 2951373, 3258594, 3597792, 3972294, 4385776, 4842295, 5346332, 5902831, 6517253, 7195629, 7944614, 8771558, 9684577, 10692629, 11805606, 13034431};

Whatever my boss says. Same as usual. Isn't that why we bot in the first place?

Looks useful; but.. Why would you make a singleton without a defined constructor :E? The purpose of singleton is to prevent multiple instances, hence a private constructor.. and the only reason u would do this is in cases where the class holds some sort of reference that should not be created multiple instances of; like a connection. But you create a new one every time anyway? also, is this on purpose? final String AVERAGE = "average",LOW= "recent_high", HIGH="recent_low"; HIGH = low and LOW = high?

Ah, that's quite a bit faster than I had expected o_O Gj on that ;), Guess a heuristic won't be necessary after all

What kind of complexity are you referring to? Even if the map is weighted for stuff like doors, a heuristic will immensely improve the runtime, as long as you dont let it overestimate the heuristic distances. How is the graph built? If its a node-edge based graph where each node has like.. 1-3 neighbours and long/medium distance edges, then I see no issue with a heuristic.. Dijkstra is not much better than Breadth first search, with a runtime of O(n2) compared to A*'s potentially linear runtime. If the graph is how I imagine it, I would recommend Euclid heuristic Performing a large-scale pathfinding between 2 faraway points would be ridiculously time consuming without one