fixthissite

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?

The guy on the left's head seems like it should be a little more forward. Other than that, it looks amazing man, keep it up! Do you do game sprites?

What decode said. This kind of stuff should be handled by the OSBot client anyways

What's with all these wack requests? One guy wanted code which determined if there were 10 buckets on the ground.. Mind if I ask the reason? Go look at the code I posted on that topic; a simple modification can make it work for what you want. It takes advantage of the Stream API. Simply add a Position parameter, and compare it against item.getPosition() using equals

Have you seen Saving Private Ryan? If you like war movies, that's a good one

Accidental repose - Ignore this message

class PaintTimer { private static final long NANO_SECOND = 1000000000L, BOUNDS = NANO_SECOND * 2; private long previousFrameTime; private long timeElapsed; private int secondsPassed; public int countDownUntil(boolean condition) { if(condition) secondsPassed = 0; long currentFrameTime = System.nanoTime(); timeElapsed += currentFrameTime - previousFrameTime; previousFrameTime = currentFrameTime; if(timeElapsed > BOUNDS) timeElapsed = 0; else if(timeElapsed >= NANO_SECOND) { secondsPassed++; timeElapsed = 0; } return secondsPassed; } } Your script would look something like: final class MyScript { private PaintTimer timer; public void onStart() { timer = new PaintTimer(); } public void onPaint(Graphics2D g) { int secondsPassed = timer.countDownUntil(getCondition()); //use secondsPassed } private boolean getCondition() { return ...; //your condition } }

After checking out the API, it seems there is no script field. But it seems getGroundItems() is declared in the Script class, so use that knowledge to fix up your code

It's not really about safety measures. It's the exact same execution; the null check is just performed in the equals method, hidden away.And count() returns a long, which is why I suggested casting. But depending on the situation, you could avoid the overhead of casting (trading memory for runtime performance) by keeping it a long.

No need for allGroundItems.size() > 0 The for loop already does this kind of check. Also, you could switch groundItem.getName() != null && groundItem.getName().equals(groundItemName) to groundItemName.equals(groundItem.getName()) Allowing the equals call to perform the null-check on getName. __________________________________ Using the Stream API: public long getAmountOf(String itemName) { java.util.List<GroundItem> groundItems = script.getGroundItems().getAll(); long numberOfItems = 0L; if(grounditems != null) numberOfItems = groundItems.stream().filter(item -> itemName.equals(item.getName())).count(); return numberOfItems; } This is based off Mysteryyy's use of script.getGroundItems().getAll(); I've never actually used this myself (yet). If you want to return an int, simply cast when you return. Although, you could just have a boolean method: public boolean near10Buckets() { return getAmountOf("Bucket") > 10L; } To prevent casting overhead.

Sounds more like the OSBot API needs some fixing, removing those "beginner's traps", making it easier to use.Sorry to hear about the potential fustration. Although, I believe a list of "pitfalls" would be better suited for the "Client Bugs & Suggestions" section. Fix the problem at it's core

That used to be the prefered way of avoiding tons of parameters (pass a map) until the builder pattern came around. A map doesn't enforce concrete configuration. When the client is setting the config using a map, they are unaware of what configuration options are available; it requires you to document what SHOULD go in the map. I actually came across a question on StackOverflow about this. The answers all suggest using a more type-safe solution. Maps aren't bad, and they are definitely less verbose than the builder pattern. But compile-time safety is a HUGE aspect. It's the reason why Oracle is choosing Jigsaw over OSGi for modularizing the JDK; OSGi enforces runtime modularization while Jigsaw enforces compile-time modularization

I actually proposed this a couple weeks ago to one of the scripers on here (Valkyr; hid skype name for confidentiality). Very possible, for quite a few reasons too.

Anyone who turned in quiz answers got a 1 on 1 review. Not everyone learns the same way, which is why I kept the public answers as generailized as possible. You can still look into each subject (trust me, they aren't going anywhere ;)). These answers are to help guide you towards information, not hand it to you on a silver platter! Although I wish I could sit down with everyone and give them the perfect lesson, there's too many people and not enough time.I encouraged people to turn in their answers for a more in-depth review. I'm sorry if you don't find these answers containing enough information, but keep in mind, this is not the tutorial section; the main intention of this wasn't to teach, although a lot of it revolved around learning. Feel free to message me with any questions you may have, and I'll be happy to answer anything you might be wondering (if it's within my knowing). Since there are no more open spots, moderators feel free to close this thread. Anyone who has questions, please message me instead!