fixthissite

That's strange.. I never used Eclipse GUI builder, but GUI builders usually take advantage of GroupLayout, not absolute positioning, for consistency reasons.Could you take a picture of your results? I'm not sure what your problem is. Are the combo boxes not showing up in your frame? Or are the results from the check boxes aren't the ones you expected? Please be more specific

Very detailed. Thank you I've helped a few friends with minecraft plugins. Let me know if you have any problems; I might be able to help. Although I can't be dedicated.. too much on my hands to take on another full project (sorry man)

What kind of knowledge?

Welcome If you're interested in programming, feel free to message me

Why not? And why would you come to this thread just to say that? There's nothing wrong with sharing your SO profile

It's a GREAT source of knowledge Edit questions/answers until you're at 50 rep (minimum to comment). You'll find yourself needing to comment a lot more than you'll be able to answer/ask, so unlock commenting ASAP

Post a link to your account!

Do you have the source code for the script? The stack trace is basically saying, "When the script tried creating an InteractionEvent, it tried using a variable which did not contain an expected object". Although the NPE occured "under the hood", that does not mean the cause of the problem resides there; you could have triggered something that caused it. To find the cause, we follow the stack trace. We can look through possible locations of the problem by reading the stack trace from bottom to top: The script thread calls onLoop of class PowerChopper. onLoop calls the method E of PowerChopper at line 186 of the PowerChopper file. Line 186 resides in the onLoop method; it's where onLoop calls E. E calls the method E of CoN at line 88 of PowerChopper. Line 88 resides in the E method (of powerchopper); it's where CoN#E is called. You should first examine the parts you have access to (PowerChopper#onLoop and PowerChopper#E). Once you have exhausted all the methods you have access to (once you have reached a method in the stacktrace that belongs to the API/Client), then you can ask someone who has access to that code to see what's going on. You must also know what a NullPointerException is. "under the hood", either a reference variable is not being initialized properly (thus pointing to null, and raising a NPE when used), or it's being passed the null value (you are passing it null). The second situation is what you want to watch out for.

Yeah, initializing in the field is similar to initializing in the constructor.Assign the values in onStart, not the field.

I always liked hybrids. Not sure how low of a combat level you're looking for, but I tend to see hybrids maxed at 108, 109 depending on whether you want Turmoil (found a ton of them while playing Stealing Creation; they're pretty damn deadly. Also, not sure if OSRS has turmoil). Would be easier if you listed some standards. I wouldn't consider myself an account specialist, but hopefully I could pitch some useful ideas

Don't forget to post your Swing related code to the Event Dispatch Thread! Ensures no inconcistencies with any GUI code that may be executing. As for the busy-waiting, wait/notify (guarded blocks) would be the best solution for what you want to achieve. It ensures a thread isn't continuously running while not executing any code (consuming CPU power). If you choose to busy-wait (maybe you find wait/notify too complex, which if so, message me), you should at least sleep for 1 or 2 millisec between each iteration, to ensure CPU usage isn't at max (You'd be surprised how much 2 ms helps). Hope you found this info beneficial! And thanks for the contribution!

You're getting a NullPointerException at line 27 of AKSkiller.java If you showed the chunk of code surrounding that line, I could help further. My guess is you're trying to use an API method within the constructor of the class that extends Script. Don't use the constructor. Instead, use the onStart method to write code you want to execute when the script starts. Calling things like myPlayer() in the constructor of your script class would result in a NPE, and seeing how you're getting one in the constructor, I'm guessing that's the reason.

The problem isn't high memory usage. Since the objects are short lived, they will be cleaned up as soon as a minor collection is performed. It's the amount of times the GC is required to perform. Your heap will fill up quickly, requiring far more collections than should be required. This can cause a performance impact when in comes to CPU time, not memory. Similar to defragmenting your hard drive, objects that don't get "sweeped" get reorganized. During this time, the object graph is considered to be in an inconsistent state, and all threads are blocked from accessing objects. This is called safepoint, but most refer to it as "Stop-The-World", and occurs not only for GC, but other "under the hood" systems. The more often STW occurs, the more latency you'll notice in your program. The more often a GC is required, the more often STWs occur

Very neat idea. You should tend to the excess onjects that are being created though. Keep in mind, Color is immutable, so decode returns a new Color instance each call. Depending on how fast your onPaint is executing, this could generate a lot of short-lived Color objects, requiring more GCs (although minor, enough minor GCs within a certain timeframe can result in a performance impact). Seeing how a new color generates only every second, you should only be creating a new Color after a second has passed

Trust me, I'm a huge fan of finite state automata (I actually suggested a FSM addition to the API, which got rejected.. Don't be fooled by the lack of foundation for the states in the post, was just pitching an idea).If implemented right, a FSM can save you quite a bit of processing. In the Node framework, if you had a WalkToWild node, it's conditions would be "hasFood && hasGear && !inWild". These conditions would make sense when transitioning from Start to WalkToWild, but doesn't make as much sense when transitioning from Bank to WalkToWild. After banking, we can be sure that we have food and gear (if not, better add a WalkToStore node or have it transition to EXIT, which I don't think any node frameworks account for exiting). So checking if we have food and gave gear is not needed after banking. In a FSM based script, we could specify the EXACT logic for transitioning between states. The problem is, we need to write logic for EVERY possible transition. This doesn't scale as easily as encapsulating all the rules for a node inside a node. So now it's about "Do I wanna save CPU time by removing these excess checks, at the price of increased verbosity?". That's where it comes down to opinion. I found this video (https://youtu.be/wsmMOJj6ETo), which explains different AI techniques (for gaming purposes); a pretty interesting watch (and introdroduction) for those getting into AI. Constantly checking the current state allows for more percise interpretation. For example, lets say WalkToBank was processing, but your bot came across an expensive item on the ground while walking there. Unless your WalkToBank state manually checks for items between each step, it's not gonna notice it. In a node framework, you could have a Loot node, which gets triggered when a good item is near you on the ground. Since the states could change at any second in a node framework, it allows you to account for more actions without needing to manually implement that logic for each state. I was all for FSM scripts when I got here. Now, due to the environment and goals, I feel the node framework was a very nice contribution to the community, and whoever proposed it first should get a cookie. Is it the most efficient? Nah. But it most definitely has it's benefits. As for the excess processing that arises from it, unless you're planning on implementing some intense system, it's nothing anyone should worry about. Sorry for the long post. Could talk about automata all day :P I was planning on working on a script with 2 other devs here, based on the goal-oriented framework I was going to release to the public (but decided not to due to it's complexity; didn't want it dying out before people saw it's potential), but came across quite a few roadblocks (rules with timing, pricing, script complexity, ect..). I've heard there's a lot more money doing something a bit more advanced, somewhat similar, but in a free market, so I'm looking at my options. I feel scripting isn't where I belong anyways; doesn't take advantage of the variety of technologies I've familiarized myself with /:

But this is suggesting focus is as simple as flicking a switch at random intervals. If Jagex were detecting such patterns in clicking (whether a user is focused or not), I really don't think they'd be checking only a player's focus level (kinda like you said, high and low), but also what they could be focusing on depending on at what moment during the activity. Like you said, you gotta account for irl activities such as watching tv, but I'm sure the amount of activities (and the attention required from those activities) can differ between countries, making it difficult to create a "silver bullet" system for focusing WITHOUT letting the individual botter (not scripter) adjust the settings how they feel it should be, ensuring focusing is unique on every bot. I'm not downing the idea at all; I actually really like the idea of changed tempo of clicks. It just seems unfinished, as if a few things were overlooked. If Jagex was checking how focused a player is as a bot scouting technique, I'm sure it would be a lot more elaborate than simply seeing if there's any periodical changes in click tempo. What I'm saying is if you really feel this is something that they'd check for, go all in with it; think of every possibility. Otherwise, it could be a cause of getting caught faster. If a bot is going at a somewhat constant pace (not 100% constant, but somewhat steady pace), there's not much evidence behind it being a bot; it could be a guy fueled up on red bull. But this is adding the possibility of a pattern (albiet one that may be hard to replicate depending on the implementation), and that's why I'm saying if it's not done correctly, it could actually cause bots to be more detectable.

Nice to see an eager mind at work on preventing bans Although focus might play a factor between distinguishing humans from bots, I don't think it's something they'd try to account for, seeing how diverse people can be in that aspect. I stay calm when I used to PK; tensing up would make me choke. The focus one might have can go from totally afk to spam clicking everything, and the times they'd have more focus differ. Bots don't wanna afk, and you'd have to find the "right moments" to get up to spam clicking levels. If not implemented right, I feel it would make bots more distinguishable from humans, and implementing it well would require time that can be used for something that may be more beneficial. This is just my opinion though. Thanks for putting the time into this! Sounds really neat, but needs more meat on it. Do developers have to implement their own focus system? Do bot users adjust the focus settings to make it unique to each bot, and not just each script? How could we prevent a botter from adjusting the settings to something which would make them easier to spot?

Metaprogramming is uncommon around these parts, but is use substantially in frameworks such as Spring and Hibernate. It's been becoming more popular with the release of Java 8, which allows you to annotate just about anything.I used it in this situation to reduce the amount of typing needed by the client (the person using this code). I wanted you guys to easily wire nodes to other nodes when you create the node class, without altering the current node design (to avoid confusion). I also gave the job of creating the actual node objects to the node managers, so you won't have to worry about accidentally creating an excess object, or forgetting to add a node that's needed by another node. As for the crazy code, you'll see a lot of Class<? extends Node>, which is probably what's throwing you off. Every class in your program has a class object (can be received with the instance method getClass() or a class literal: ClassName.class). As you're using this code, you'll notice yourself using quite a few class literals; that's what the Class<? extends Node> type is for: Class<? extends Node> clazz = BankNode.class; But you don't need to be reading that stuff anyways, unless you're really interested in the code behind all this.

Past accounts (if you know of any): dog_ Current account: Novak Reasoning: The only one I could find was for account sharing, not sure if that was the cause though, as it wasn't mentioned. It was also in 2014, so I'm not sure if he got unbanned and banned for another reason. I feel this member could be harmful to the community. He argues, passing around false info, and resorts to trolling once he has realized he's unsure of what he is talking about. He is very good friends with SwizzBeat, who is also banned (a thread to unban swizz was created, which was denied. Not too surprised). I noticed when he first mentioned we encountered on another site: REMOVED We debate it for a bit. He tries stating that although the system he proposed is more efficient, it's not as complex as this, which is easily debatable. I then go on to ask who he is: REMOVED He didn't mention it. When I asked him again, he finally pmed me saying he was "dog": REMOVED I clearly remember a "dog" who I got into an altercation with on another site. I accuse him of ban-evading, knowing the OSBot account he used. He replied with "nobody is ban evading you moron, please report me so that the mods laugh in your face". I replied, trying to confirm his account, in which he replied with: REMOVED Doesn't make much sense. But if you look at his history from "the other site", you'll be able to see his reckless behavior and lack of knowledge, which he tries to spread like cancer (he does have SOME knowledge obviously, but he talks a lot in which he doesn't care to look into). He doesn't defend himself easily, then resorts to trolling as you can tell in the pms (with the "deobing RS client", which he irrelevantly refers to). Here are some more pics of the conversation: REMOVED

How is a simple annotation "over-complicating things"? I'm sorry if you don't understand the language enough to use an annotation (which they really aren't that hard; I even gave an example), but the verbosity is not a problem for the functionality it gives. Even beginners can easily use this kind of syntax, and seeing how it's aimed at people who use the node framework, I don't see a problem. Please, mind telling me who you are on the other site, so I know who I'm talking to from there?

I was just stating facts. If you stated facts, maybe we would get to a conclusion. So what if I'm defensive? If I feel I'm correct, what's wrong with defending myself? If you aren't giving me any reasons as to why this code is inefficient, how are others supposed to be aware? By the way, mind saying who you are on the other site? And just for kicks, check out The Billion Dollar Mistake by Tony Hoare, where the inventor of the null pointer said himself it was a mistake.

Your proposal requires more processing than this. Using these systems, all the heavy work is done before onLoop starts, and the heavy work doesn't take long at all. As for naming, it's nice to know you have preferences. We all do. I'm going based off what I've seen to be popular, not what each person likes best. It was requested, so it's definitely not irrelevant. Some scripts are more advanced than others, which require increased decomposition to maintain. Not to mention, the lack of effort needed by the client as well as the type safety. Maybe you should post your test system and let the developers decide which is easiest to use.

DOWNLOAD (since JARs are not allowed to be used in scripts, the .rar contains the source files, which you can include in your project) UPDATED: The two systems have been merged. Let me know if there are any issues. Two people came to me asking how to implement certain functionality: 1. To link certain nodes to other nodes. Since some nodes won't come after other nodes (Bank will only come after WalkToBank), there's no reason to loop through EVERY node in the script depending on the current node. How could one implement a system that only check to see which node shohld be next out of the possible nodes, not all the nodes. 2. To allow other nodes to execute while the current node is executing. When the current node is WalkToBank and your player has low hp, the script will not eat, since the current node is WalkToBank and not eat. You could add a priority system, but the problem is not "performing one node before the other"; it's performing one node while another node is processing. There exists an asynchronous node executor, which executes a node on a background thread. But this does not account for possible memory incosnistencies by implementing memory barriers. Not to mention, such a burden isn't actually needed; a single-threaded system could give the same functionality, without the need for atomicy and synchronization, as long as the script is running at a specific frame rate (a guide on that coming soon; pm me if you aren't sure what that means). I have packaged both together. I haven't tested it with an actual script (performed some lazy tests), so let me know if there are any problems with it. NodeLinkerManager The idea is to take a group of nodes, and "map" them to a specific node. For example, the WalkToBank would only be followed to the Bank node, and in a pk script, a WalkToWild node will only be followed by FightPlayer and LookForPlayer. We want to link nodes to their possible outcomes. Usually, a node based script looks like this: class MyScript extends Script { private List<Node> nodes; public void onStart() { nodes = new ArrayList<>(); nodes.add(new WalkToBank(this)); // add other nodes } public int onLoop() { for(Node node : nodes) if(node.canProcess()) node.process(); } } abstract class Node { private MethodProvider api; protected Node(MethodProvider provider) { this.api = api; } protected MethodProvider api() { return api; } public abstract void process(); public abstract boolean canProcess(); } final class WalkToBank extends Node { // ... } The problem with this is, depending on the amount of nodes (which increase as decomposition is applied), the for loop in the onLoop method could take longer than it needs. This is because it could be checking nodes that could not possibly come after the current node. Instead, we want to check only the nodes that could possibly come after the current node. For this, you must specify which nodes can come after which nodes. This is done through the @Linked annotation: import fts.node.Node; @Linked(nodes = { Bank.class }) final class WalkToBank extends Node { // ...same as usual } The other difference is how you add nodes. First, you need to declare the NodeLinkerManager in your script. You then add the type of the node you want. Any linked nodes that are specified through the @Linked annotation are instantiated, as well as the node you specified. To ensure no excess objects are created, NodeLinkerManager handles ALL instantiation; you simply specify the type of a node through a class literal: final class MyScript extends Script { private NodeLinkerManager manager; public void onStart() { manager = new NodeLinkerManager(this); manager.add(WalkToBank.class); } public int onLoop() { manager.process(); return 2; } } NodeFragmentManager There are some actions that should be performed while other actions are performing. For example, if you are fighting, you might wanna check if you should eat or pot. You could hard-code the logic into the Fight node, but what if there are actions that apply to all nodes? The node fragment system sees those actions as "node fragments". A NodeFragment is the exact same thing as a Node, other than the ability to specify a NodeFragment when creating a node. You would specify the NodeFragment through the @Fragmented annotation: @Fragmented(fragments = { Eat.class; }) final class WalkToBank extends Node { // ... } final class Eat extends NodeFragment { // ...same as a regular Node } When the current node is WalkToBank, Eat will also process. This will allow the bot to eat while it's walking to the bank (if needed).

Trafficking. I suggest posting this somewhere other than the spam forum ;) Good question though, seeing how just about everything that isn't already covered is against the rules.

Math is important ;) Marketing is a skill in itself. Doesn't matter how good your services may be, if you don't market correctly, you could get nowhere (or possibly even further away than you were). With that said, I suggest finding someone to help you market; someone who has a way with words (rhetoric).