fixthissite

Rather than creating the path all at once, why not generate your next "random" movement after reaching/finding the location you are currently walking to. You generate (asynchronously) a bunch of "next possible step" nodes and choose one. That way, you can generate billions upon billions of different paths. For those saying "the time itll take to process all those nodes" should pick up a multithreading book at some point. For those saying "too much memory", read up on how HotSpot manages garbage collecting. Trying it won't hurt. Creating paths before-hand is pretty damn insane if you're looking for realism.

Just to clear things up, although IntelliJ is a more advanced IDE, using it for scripting is an overkill. Yeah, the indexing is nice when you have tons of files between multiple languages, which is a big reason a developer may choose IntelliJ. But for programs with like 10 to 20 classes all written in Java, using IntelliJ is like killing an ant with a flamethrower. Once again, it comes down to preference. Some people like the feel of IntelliJ, some like the feel of Eclipse. I've used both, and my opinion is, Eclipse is just fine. Leave it alone guys. Btw, if you look, everyone is all "IntelliJ or get out", but give no reasons.... hmmm...

So I'm a beginner?Honestly, a lot of advanced developers still prefer to use vim. It's all about the person.

Nope. There are some bonus features, other than parallelism, but none of which you could be taking advantage of in this code

Nice, I'm sure it will help out quite a few people. Here's some advice to hopefully improve the readability (and managability) of your code: No need to check if entity != null twice (if statement and else if statement). Simply do if(entity != null) { if(menu.isOpen()) { } else { } } You have quite a few un-needed return statements. Rather than calling return when options == null, format your code to allow the flow of execution "do nothing" until the return statement at the bottom: private boolean hoverEntityOption(Entity entity, String option) throws InterruptedException { if(entity == null) return false; if(menu.isOpen()) { List<Option> options = menu.getMenu(); if(options != null) { Rectangle optionRec = null; for(int index = 0; index < options.size(); index++) { if(options.get(index).action.equals(option)) { optionRec = menu.getOptionRectangle(index); if(optionRec != null) { if(!optionRec.contains(mouse.getPosition())) { int x = menu.getX() + Script.random(10, 160); int y = menu.getY() + 23 + index * 15; Script.sleep(Script.random(200, 400)); return mouse.move(x, y); } } } } } } else { EntityDestination ed = new EntityDestination(bot, entity); mouse.click(ed, true); } return false; } As you can tell, I also fixed up the wierd scoping. If you ever find yourself declaring the tracker variable for a for loop outside of the loop, best believe you have a structuring problem. You were breaking from the loop, just to have another block of code (which depends on the tracker variable; the whole reason you have the for loop) return from the entire method. I would recommend the Stream API to decrease the amount of time it takes to iterate through a collection, as Alek suggested, but it might interfere with how you're specifying your mouse location. Still quite a bit of cognition needed to understand the method. We can lower it through decomposition: private boolean hoverOverEntityOption(Entity entity, String option) throws InterruptedException { if(entity == null) return false; if(menu.isOpen()) return moveMouse(option); else clickEntity(entity); return false; } private boolean moveMouse(String option) { List<Option> options = menu.getMenu(); if(options != null) for(int index = 0; index < options.size(); index++) if(options.get(index).action.equals(option)) { optionRec = menu.getOptionRectangle(index); if(optionRec != null) if(!optionRec.contains(mouse.getPosition())) { int x = menu.getX() + Script.random(10, 160); int y = menu.getY() + 23 + index * 15; Script.sleep(Script.random(200, 400)); return mouse.move(x, y); } } } private void clickEntity(Entity entity) { EntityDestination ed = new EntityDestination(getBot(), entity); mouse.click(ed, true); } Keep up the good work man

I'm not saying take all limits off; just blur the line between AIO, single tasked scripts and any other kind of script that may appear. Limiting the audience of a developer's script due to their experience is a pretty harsh thing to do, considering they're simply trying to provide good quality product. If people like the product more than what's currently out there, it makes sense that the developer(s) deserve the cash. I totally understand the rules, ensuring scripts don't drop down to un-imaginable prices. But preventing such competition to allow scripters with little experience to compete on the market for prices of $5 to $10 is a bit out there, and gives them no reason to truely improve their skills. "Life without competition is life without progress; a static society where the cream does not rise to the top because there would be no goals and no desire to march to the different drum beat and take something farther than it's ever been taken before."

Thanks for leading me to that. I haven't checked out the Upload Request section, since I haven't had a reason to go there (until now, obviously). But dividing the market in such a way slows down progress, as stated before.. I understand you guys want to allow less savy developers to have a chance on the market, but that handicaps the quality of scripts, seeing how people aren't forced to bring new things to the table in order to keep their business. I've stated before (many times) that most scripts are rehashes of other scripts, with a few slight modifications. Scripters have also agreed to this. Heated competition would force developers to increase their skills to stay alive on the market, which results in more innovation and better quality. How am I supposed to know without asking? That's all I did, please don't take it personal. I'm sure if you were in my position, you'd question it too. To give an example of the progress I'm talking about, why aren't AIO scripts more popular? Why is the transfer so slow? If a framework for easily making AIO scripts were available, would the prices change? Why are consumers still paying $7 for a script that performs 1 task (in a variety of ways in different locations, but 1 task)? If an AIO script was made cheaper than a single task script, developers will be forced to learn how to and start creating AIO scripts to stay in the market. That's progress. As for the next step, who knows. At this rate, we'll probably not find out within this lifetime

So a monopoly is not allowed, no matter how good the product/service may be? Not in the sense that one developer will be behind it, taking all the income. Comsumers should be able to decide what they want to buy, without quality being a concern, if it's possible to do so, which in this case, it is. Rules like this only slow down the progress of the community, as developers are not forced to innovate, leaving programmers to keep doing the ordinary. We won't get very far that way. No offense to the rules set in place (would be nice if there was a place to reference them), I understand their intentions, but I think the majority of the community would much prefer a community moving at a fast pace. I can't speak for them, but some kind of poll would allow them to decide.

Divinity is competing on the market, yeah? Why does he get say in the price of another competer's script?

Where do true AIO scripts, covering multiple possibly all skills? Are they allowed to be priced at normal script prices, more specifically within the $5 to $10 margin?

Are scripts allowed to be priced at any amount the developer chooses?

~

Gotta show the code for your first error. The second one is stating that there is already a class/enum/interface/annotation named "main".

It could be the scripts you are using, as well as the amount of bots you have running. I wouldn't blame the mirror client yet, seeing how it has had an effect on preventing bans. Would be best if you guys provided this kind of info, so the devs (or someone who has access to the scripts) can test it themselves. While you're at it, probably a good idea to provide your computer specs as well.

People using designs like the Node system tend to pass their script instance to each node for access to the API: final class Bank extends Node { private Script script; public Bank(Script script) { this.script = script; } //... } The problem with this is the ability to call onPaint, onLoop and other "critical" methods (onExit, onStart) from the script instance. This tutorial will show you how to create an instance of the API to pass around. First thing we need is an instance that supplies the methods we need (from MethodProvider). We can do this by extending upon the API type: final class DefaultAPI extends API { } You will be forced to declare an initializeModule method. Don't worry about it, just the devs not following interface segregation Leave it blank. You could fill it in, but you would be required to call it after instantiating API. Once you have your API type, create an instance of it in onStart in your Script subclass: final class MyScript extends Script { private API api; public void onStart() { api = new DefaultAPI(); } } Finally, we need to pass the context of our script to our api instance. We do this by calling exchangeContext on our api instance, passing in the script's bot: final class MyScript extends Script { private API api; public void onStart() { api = new DefaultAPI(); api.exchangeContext(getBot()); } } Please use the getter method getBot() and not the public field bot. So now our API instance has the context; we can call methods such as myPlayer() from our API instance. We should now pass around the API, rather than the entire script: final class Bank extends Node { private API api; public Bank(API api) { this.api = api; } //... } For those who might say "Who's stupid enough to call onPaint or onLoop?": Encapsulation does not only help prevent these miniscule mistakes, but helps lower the cognition needed by supplying you with only the things you actually need, rather than a bunch of other irrelevant things. The client should not be presented with onLoop or onPaint, since those do not have purpose within the Node class. Out of sight, out of mind.

They are indeed different. npc != null is referred to as a "null check". npc.exists() is a call from an object through a variable. npc is a "reference variable" - a variable used to "point" to an object. When a reference variable does not point to an object, it points to "null". The object contains the actual exists() method, not the variable. If npc is not pointing to an object, it cannot properly call the method, resulting in a NullPointerException. Unless you are 100% sure npc will not contain null, you do not need the null check. Although, if there's a possibility it will be null, you need the null check before you attempt to call npc.exists(). This is basic Object Orientation. If you'd like to know more, feel free to message me (don't be shy)

What situation are you referring to? Not all classes define an exists method

The rules state:"Authentication systems, script loaders, and distribution systems need prior approval from any Admin and/or Developer" So I'm not 100% sure about that. I'll wait for a developer to reply

That's real nice of you..Hopefully they'd make an exception if they were to review the code and possibly have someone trusted jar it.

It's a work around for how it should be handled, which is why I also asked if there were any exceptions to this, such as getting permission. And the SPI I intend to release has 15+ packages. Adding that to a project consisting of only a few classes is definitely a problem in my eyes.

What error? Have you tried updating your Java?

We can look at: if(hasTwoLogs) without needing extra cognition to work out the getInventory().getAmount(...) == 2 in our heads. If we really care about how we determine we have two logs (which there is no reason to, unless there's a bug), we can look at the assignment, but now we aren't forced to; we are instead given an actual name to read. It's a lot more useful when the condition has multiple expressions (|| or &&), but I still prefer it over placing the expression in the if statement. Slightly lowers the amount of thinking needed, as we can ignore the assignment (of the expression) without any confusion about the code. Compilers will inline the value if they see it's effectively final (not modified after initialization), so there's no performance impact; it's just to make things easier to understand when it comes to reading the actual processing part. On top of that, worrying about such small changes should be avoided (micro-optimizations) as they can consume quite a bit of time over the course of a project, while giving no noticable performance boost. You should never pre-optimize anyways: always monitor your program AFTER writing it, to see where optimization is really needed Keep in mind, that expression is a boolean, we are just storing it somewhere and giving it a name. Either way you do it, a single boolean is being allocated to the stack.

I didn't ask for a work around. This would be tedious for use in multiple projects, as well as clutter the project depending on the size of the API/SPI

I'm pretty sure it's boolean hasLogs = getInventory().getAmount("Logs") == 2; if(hasLogs) { //... }

I've heard pre-compiled code is not allowed in the SDN. Does this mean we are not allowed to create our own API/SPI for OSBot distributed through JARs? Assuming we were allowed to, are scripts allowed to extend upon a subclass of Script? Such as: abstract class ExtendedScript extends Script { } @ScriptManifest(...) public final class MyScript extends ExtendedScript { } I'm pretty sure I could test the second one myself if I were on a computer; sorry for the inconvenience. Are there any exceptions, or possibly a way to get permission, for these actions?